I am writing a series of BITMASK buffered images created through GC.createCompatibleImage() into a file using GIF writer, as an animated GIF image and setting the properties such as delayTime, disposal method etc using the metadata. The images are written properly. But when I load them using Toolkit.getImage(), the image's colors are inverted and does not match with the actual image. Native viewers are able to load the image properly.

This is reproducible on all platforms only on the JDK7-b14 2D PIT build. Not reproducible on JDK7-b13 promoted build. Looks like a regression introduced in b14 PIT. 

I have attached a sample test (GIFCreateImageTest). Execute the sample test. A series of images will be loaded and 2 animated GIF images will be loaded at the end. If the colors of the animated GIF is different from the individual frames, the bug is reproduced.
Posted Date : 2007-06-17 16:48:08.0

N/A

This test creates frames for animated gif using two colors:
red for background and blue for sector.

Before b14 for each frame of animated image int this test GIF image writer created local color table with 4 elements,  where first element represents artificial transparent color (had been added due to BITMASK transparency type of the source image), then blue color and red color (which were presented in the image) and then empty slot to align the length of palette to power of two. I.e., local color table looked as follow:

 0 -> black (artificial transparent pixel)
 1 -> blue
 2 -> red
 3 -> blue (empty slot)


Starting b14 (fix for 6287936) GIF image writer creates local color table that seems to be a bit more correct:

0 -> blue 
1 -> red

and no transparent pixel (because given image is in fact opaque).

However, gif frame with such color table  makes visible old problem
related to handling GIF images with short palette by Toolkit decoder.
Note that attached gif image is displayed as red square with
transparent (instead of blue) sector starting 1.4.2, whereas all
native applications display red square with blue sector.
So, this problem  is not a regression in b14.
Posted Date : 2007-06-18 15:29:59.0

This problem is caused by mistake in setDiffCM() method of ImageRepresentation class. In case when old palette is longer than new palette, this method incorrectly
calculates transparent pixel using data beyond new palette bounds.
Posted Date : 2007-06-19 12:15:12.0

This problem happens when palette of subsequent frame is shorter that previous
one. In this case method comapreLUTs() of ImageRepresentation is used to merge
palettes and to create lookup table used for adjustment of new frame raster to
the merged palette.

We iterate through palette entries up to max(current.length, new.length).
If new palette is shorter than current palette, then zeroed palette entry
(beyond the new palette bounds) is read as next entry in new palette.

This zeroed entry fits to our condition used for transparent pixel detection
and it causes appearance of extra (and incorrect) transparent pixels in merged
palette.

Suggested change prevents us form reading beyond palettes bounds: now we
iterate  through new palette entries only and check for current palette length
to avoid reading of extra current palette entries.
Posted Date : 2007-07-30 16:19:15.0