Matthias Basler wrote:
Simple: Ask its SPI.
ImageWriterSpi spi = it.next();
if (spi.canEncodeImage(img)) {
... do something.
}
Thanks - I had missed that method (that will let me filter out a few
more formats).
I wonder if anybody in the ImageIO team spent a thought on how to automatically
discover that there are 3 DIFFERENT formats in the 10 variations given?
Maybe they expect people to choose the file extension? But again, .jpg and
.jpeg are the same.
Yeah it is kind of a mess...
---
Actually I took the chance an created an image file format dropdown in my Swing
widgets library, but it suffers from exactly this problem.
Slowly I get the impression the best thing (from a UI developer perspective) is
- a) hard coding the DIFFERENT supported file formats for the UI and just check
if at least one writer can support them and is able to write the image
(spi.canEncodeImage()) and
- b) let ImageIO decide which writer to take for each format (similar to what
you had done, except you used the file extension).
I looked at the code ImageIO does not decide; it just chooses the first
one near as I can tell. The FactorySPI system can sort them into some
kind of order - but the IIRegistry thing would get that order as well.
OR, if hard coding sounds inacceptable,
- a) fetch all different file extensions, remove all upper/lower case
duplicates and
- b) live with the fact that .tiff/.tif and .jpg/.jpeg will be listed
separately.
Looking forward to the results when you try to run my test code from within
uDig.
I am still accepting bets if the images come out OK or not. ;-)
I am looking forward to that as well - I just have a bunch of work for
customers to do today. Hense my general tone about uDig 1.1.0 being a
distraction :-P
Still this is all good stuff to sort out; I will let you know when I get
some results for you.
Jody
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
