Jody wrote:
> But it is not as cool as the code example you made...I will try and run
> it with the BufferedImage produced by the image export wizard when I get
> a chance this evening. I am not sure how I can figure out if a writer
> supports my image or not ...
Simple: Ask its SPI.
ImageWriterSpi spi = it.next();
if (spi.canEncodeImage(img)) {
... do something.
}
What is harder is create a human readable list of supported file formats from
the SPIs. The way ImageIO declares each writer's capabilities is just unusable
for this purpuse.
Problem is f.e. that the natively-accelerated JPEG writer declares
JPEG, JPG (which are the same), but also JFIF and also JPEG-LOSSLESS and
JPEG-LS (again the same)
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.
---
P.S. My sample code has a weak point as I just find: There are several
different writers for JPG, and each writer overwrites the image produced by the
previous one. (Running them one by one shows that all writers work well.) But
it also means that going through the list and making one entry per writer will
produce double entries too.
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).
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. ;-)
--
Matthias Basler
[EMAIL PROTECTED]
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel