Nabble - Sun - Java-Imageio-Interest

Saving image along with metadata changes white to red

2008-03-31T16:02:46Z

Hi everybody,

In my image resize/compress code I'm trying to save an image along with its Exif metadata but for some images the image becomes red. I'm using com.sun.imageio.plugins.jpeg.JPEGImageReader and com.sun.imageio.plugins.jpeg.JPEGImageWriter. The image type is

TYPE_3BYTE_BGR

getMetaData() seems to be the culprit because if I put null instead it works.
Here is an excerpt of my code:

 IIOImage destIIOImage = new IIOImage(thumbImage, null, srcIIOImage.getMetadata());
        BufferedOutputStream out;
        ImageWriter writer = null;


        ImageOutputStream imgout = null;
        FileOutputStream fos =null;
        try {


            fos = new FileOutputStream(outFile);
            out = new BufferedOutputStream(fos);
 
            quality = Math.max(0, Math.min(quality, 100));


            Iterator it = null;
            if(inFile.toUpperCase().endsWith(".JPG") || inFile.toUpperCase().endsWith(".JPEG")){


                it = ImageIO.getImageWriters(new ImageTypeSpecifier((BufferedImage)image), "jpg");
                if(it.hasNext()){


                    imgout = ImageIO.createImageOutputStream(out);
                    writer = (ImageWriter) it.next();
                    writer.setOutput(imgout);
                    ImageWriteParam param = writer.getDefaultWriteParam();


                    param.setCompressionMode(ImageWriteParam.MODE_EXPLICIT);
                    param.setCompressionQuality(quality/100f);
 
 
                    IIOMetadata meta = writer.getDefaultStreamMetadata(param);


                    
                    writer.write(meta, destIIOImage, param);
                    image = null;
                }
            }

Using the simple code everything works fine but I can't control compression quality:

ImageIO.write(image,"jpg",file)

I also tried to use ImageWriteParam param = new JPEGImageWriteParam(Locale.getDefault());
instead of

 ImageWriteParam param = writer.getDefaultWriteParam();
but that didn't work either

Thanks,

Carl Antaki =========================================================================== To unsubscribe, send email to listserv@... and include in the body of the message "signoff JAVA-IMAGEIO-INTEREST". For general help, send email to listserv@... and include in the body of the message "help".

ImageIO static lookup issues

2007-12-12T15:11:41Z

ImageIO static lookup issues

There has been almost no traffic on this list in 2007, and the last post I made over a year ago never got a reply, so this is a shot in the dark.

The problem that I have seen with ImageIO numerous times in the past 4 years or so is the fact of static lookup and access. It doesn't take a lot of experience with static references to learn that they are both very powerful and very susceptible to problems. Particularly in an environment where multiple independent components share a single VM and memory heap, conflicts in static access can create unexpected behavior and even catastrophic failure. Add in a complex ClassLoader hierarchy, as exists in most J2EE application containers, and the effects are compounded by the difficulty of tracing problems to their source.

The reason this affects ImageIO is as follows: Suppose I have two applications (A and B) that both use a custom ImageIO ImageReader called MyImageReader. If those two apps are run in the same VM -- for instance, under a J2EE app container -- then their two sets of ImageReaders are both statically loaded by the same instance of the ImageIO class. Suppose there is a jar called MyImageReader.jar, located on the classpath of EACH of these apps -- for example, in their EAR file. This generally results in two copies of the MyImageReader class being loaded, because due to the security model of app containers the classes in App A are not visible to App B, by necessity.

So now we've got two instances of the same class, MyImageReader{A} and MyImageReader{B}. Now suppose App A wants to read an image. It calls ImageIO.getImageReaders(inputStream) or a similar API. The ImageIO class, which can access and call both {A} and {B}, interrogates the two reader SPIs and returns an Iterator with an instance of both MyImageReader{A} and MyImageReader{B}. App A, let's say, takes the first reader, which is its "own" instance of MyImageReader{A}, and everything works fine.

Now what happens when App B uses the exact same sequence of calls? It should end up with an instance of MyImageReader{A}, which is inaccessible to it. Therefore some kind of error will occur, depending what the app tries to do with the reader.

The fundamental problem here is that an app cannot interrogate the ImageIO class in a way that returns only plugins that are accessible within the calling classloader. Is there some way that you can see to do this? Or is there some kind of check that could be performed so that App B can detect when a plugin it receives is not visible to it and it should discard it as unusable?

There may be some simple workaround that I haven't come up with yet, but it seems to me a problem that should have a more well-engineered solution.

Thanks for any input,

Mike Nidel

=========================================================================== To unsubscribe, send email to listserv@... and include in the body of the message "signoff JAVA-IMAGEIO-INTEREST". For general help, send email to listserv@... and include in the body of the message "help".

Imaging and graphics job opening at Sun.

2007-10-04T11:37:29Z

Hello all,

The Java 2D graphics and JAI imaging team here at Sun have an immediate
opening for an engineer to join us to work on imaging and graphics
for Java SE.

The full details of the job are posted at the link below where
you may also submit your resumé to apply.

http://www.sun.com/corp_emp/search.cgi?funcs=&loc=&keyword=555887&x=&y=

-Phil Race, Java 2D.

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA-IMAGEIO-INTEREST". For general help, send email to
listserv@... and include in the body of the message "help".