After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 778289 - Open as Layers corrupts any PNGs after first
Open as Layers corrupts any PNGs after first
Status: RESOLVED DUPLICATE of bug 755438
Product: GIMP
Classification: Other
Component: General
2.8.20
Other All
: Normal normal
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2017-02-07 14:44 UTC by dougdigdag
Modified: 2017-02-07 15:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Screenshot illustrating the bug. (116.56 KB, image/png)
2017-02-07 14:44 UTC, dougdigdag
Details

Description dougdigdag 2017-02-07 14:44:39 UTC
Created attachment 345120 [details]
Screenshot illustrating the bug.

In GIMP 2.8.20 running on Windows 7, opening multiple PNG files with the "File - Open as Layers" menu item causes all but the first image to load in a corrupted fashion.  See the attached image for an illustration of the problem.

This problem was encountered while following a tutorial for using GIMP to create animated GIFs at the URL https://thiscouldbebetter.wordpress.com/2014/11/21/creating-an-animated-gif-using-gimp-2-8/.  When the simple PNG images from that tutorial are loaded as layers, all but the first images appear as mostly black, with faint lines indicating some features of the original images.

The corruption seems to be persistent, rather than simply a display artifact, because saving and reloading as an .xcf doesn't change anything.  

The problem can be seemingly be worked around by first creating a "dummy" layer with "File - New" before using "File - Open as Layers", and then deleting the dummy layer.

This problem did not occur in previous versions of GIMP 2.8, as evidenced by the animated GIF posted along with the aforementioned tutorial that was created using the process described therein.
Comment 1 Simon Müller 2017-02-07 15:18:34 UTC
The reason for this behavior is the following:

The first image (Nr. 1) uses indexed colors with an embedded color palette that only contains certain red and black colors, see the attachment. 
This palette gets then applied to every following image, which causes every color that does not appear in the color palette to be mapped to black (the first color of the palette).

I don't really see a problem with this behavior. Gimp correctly loads the embedded color palette of the first image and sets the color mode to indexed according to the images' properties - which is exactly what you should expect.

Creating a new image before loading the layers prevents this from happening because this is explicitly setting the color mode to rgb.

Maybe one could argue that the indexed color mode should never be used when loading multiple images at once to prevent such a thing from happening - but I think the current behavior is the logical way of handling indexed images.
Comment 2 Michael Schumacher 2017-02-07 15:45:01 UTC
Having only one colormap per indexed image is an arbitrary decision - even GIF does support a colormap per frame.

But this isn't something that's going to change in the 2.8.x stable branch.
Comment 3 Michael Schumacher 2017-02-07 15:47:37 UTC
Thanks for taking the time to report this.
This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 755438 ***