Problem in AWTTextureIO when using images from BufferedImage.getSubimage()

I think this might be a bug....?

When I load a BufferedImage, then extract several portions of it with .getSubImage(x,y,w,h), and then use those sub images to create Textures I get the textures as if I had called .getSubImage(0,0,w,h).

I think this is because AWTTextureIO is not correctly taking into account all of the offsets in the data reported by the buffered image. (BufferedImage appears to do some tricks to prevent it from having to copy any memory.)

JDK 6's GIF writer seems to have the same bug, see http://bugs.sun.com/view_bug.do?bug_id=6795544 for a description of what I think is a very similar bug.

I am willing to post a small test case if no one more familiar with the JOGL code says 'yay' or 'nay'.

On 09/02/2013 02:07 AM, bkuker [via jogamp] wrote: sure, pls create a bug report incl. your unit test.

the latter maybe even a proper unit test
we can pull as a git commit ?
copy-paste on of our many .. and change it to make your point.

thank you!

~Sven

So a little test program I could do, but a unit test would be tricky because its a matter of looking at it and seeing the wrong part of the image. I have confirmed the problem:

The code

        tex = AWTTextureIO.newTexture(GLProfile.getDefault(), i.getSubimage(x,y,w,h), false);

displays incorrectly for x !=0, y != 0 but the code

        tex = AWTTextureIO.newTexture(GLProfile.getDefault(), workaround(i.getSubimage(x,y,w,h)), false);

works as expected, given the function

        private static BufferedImage workaround(BufferedImage i) {
                BufferedImage d2 = new BufferedImage(i.getWidth(), i.getHeight(), i.getType());
                d2.getGraphics().drawImage(i, 0, 0, null);
                return d2;
        }

which produces an identical image, but with 0 band offsets in the BufferedImage's backing data buffer. The downside to the workaround is extra memory usage and extra copying of the data before AWTTextureIO shuffles it off to GL.

I'll go start that bug report :)

Just as a followup to this thread, and sorry I am being so chatty, https://jogamp.org/bugzilla/show_bug.cgi?id=823 is the bug I have created, with code to reproduce.

The problem only occurs for certain types of images because AWTTextureIO has a code path that replicates the workaround that is followed for some image types. I could reproduce the problem with a PNG but not with a JPEG.

If you are having this problem you can change your image type, or re-blit the image onto a new buffer as above before passing it in to JOGL.