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 791531 - Import damages colormap numbering
Import damages colormap numbering
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: Plugins
2.9.6
Other All
: Normal normal
: 2.10
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2017-12-12 17:22 UTC by TKZV
Modified: 2018-05-24 18:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
A file that will be damaged by GIMP import-export. (19.71 KB, image/png)
2017-12-12 17:22 UTC, TKZV
Details
A file with damaged palette. (20.75 KB, image/png)
2017-12-12 17:23 UTC, TKZV
Details

Description TKZV 2017-12-12 17:22:18 UTC
Created attachment 365449 [details]
A file that will be damaged by GIMP import-export.

When I import indexed 8-bit PNGs, one of colormap entries is deleted and the rest are shifted. This is very problematic for people working with large libraries of images with identical colourmaps, when everybody assumes that index unambiguously defines a colour.

To reproduce:
1. Open the attached "TECHNOMAD-original.png" in a program that can display the "palette" of indexed colours (I used IrfanView 3.98). — There are 256 colours. The first are:
 0: #000000 (actually, it's transparent)
 1: #FCFCFC
 2: #E8E8E8
 3: #D8D8D8
 ...
 16: #FCD000
 ...

2. Open the same file in GIMP. When prompted to convert to RGB working space, select "keep". Open "Colormap" window. — There are only 255 colours. The first are:
 0: #FCFCFC
 1: #E8E8E8
 2: #D8D8D8
 3: #C4C4C4
 ...
 15: #FCD000
 ...

3. Export the file to 8-bit PNG under another name. Check its palette. (See also the attached "TECHNOMAD-exported.png".) — The 1st colour is black again, #FCFCFC disappeared, and the rest are shifted by 1 from their original positions.

4. Import the exported file to GIMP again; when prompted to convert, press "keep", check the colormap. — There are only 254 colours, they are shifted by 2:
 0: #E8E8E8
 1: #D8D8D8
 2: #C4C4C4
 ...
 14: #FCD000
 ...
Comment 1 TKZV 2017-12-12 17:23:07 UTC
Created attachment 365450 [details]
A file with damaged palette.
Comment 2 Michael Natterer 2017-12-12 18:25:38 UTC
This is a duplicate of some older bug, but I don't find it right now.
Comment 3 Michael Schumacher 2017-12-18 22:54:28 UTC
We got bug 637413 which is about removing exactly one color from the palette - but there are currently no promises about the color map of an image, and there is several other bug report concering that, for example:

bug 680453 - removing unused colors
bug 771185 - collapsing duplicate entries
Comment 4 Michael Natterer 2018-01-01 15:16:59 UTC
I never understood why we mess with the original order of imported
colormaps at all, unless absolutely needed.

While we can't promise anything, there is no reason to do changes
without reason.

Setting 2.10 milestone because this can be changed completely locally
in the import/export plug-ins.

(I still think this is a duplicate of one of the older bugs, just
differently worded...)
Comment 5 GNOME Infrastructure Team 2018-05-24 18:53:29 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/1256.