GNOME Bugzilla – Bug 670873
[TESTCASE] ICC Profile loaded and saved but not used. - Big savings.
Last modified: 2015-06-14 22:48:36 UTC
Created attachment 208478 [details] 1x1 big jpg with ICC profile I make research on git version, but I had encounter similar behavior on earlier gimp version also. For time to time I get some files that after save are too big. I.e. 1x1 jpg have hundreds of kB. Since now, I made some workaround this by copying contents of image and paste it in new empty one. But now I make some research, and find out that this 'big size' is caused by embedded ICC profile. However this profile seems not be used by gimp itself. it is only loaded and saved... After loading file with such profile, gimp don't ask if convert to sRGB, It simply use it (sRGB). Probably, it also didn't convert it by default, because often this files have strange colors. It seems that, some parts of gimp detects ICC profile, but others don't. I think that following steps are needed. 1. Inform user about unused, unsupported or broken color profile. 2. Ask user what to do; keep or discard such profile. and not directly related to this bug but helpful. 3. Add option to discard/convert color profile on file save/export. I've add affected jpg as testcase. This is not original file because I'm not owner of it. But probably I can send original affected tiff image to people interested by this problem.
Created attachment 208479 [details] 1x1 big tiff with ICC profile
At first I thought this bug report said that Gimp was opening actual CMYK images, converting them to the "sRGB built-in" RGB color space, and upon export, exporting RGB images with the old CMYK profiles still embedded. However, the attached test images aren't CMYK images. They do have embedded CMYK ICC profiles, but Gimp, Krita, Cinepaint, and exiftool all indicate that the images are actually RGB images with incorrectly embedded CMYK profiles. I used Gimp 2.9 to open a known good CMYK image created with Krita, and a second known good CMYK image downloaded from the internet. In both cases Gimp correctly understood that the image was a CMYK image and correctly converted it to "sRGB built-in", and upon exporting the image, exiftool showed that the CMYK profile was gone (and the resulting file size was several hundred kilobytes smaller). However, upon export, Gimp doesn't remove the (incorrectly) embedded CMYK profiles from the test images attached to this bug report unless an sRGB profile from disk is assigned to the image before the image is exported. Krita does remove the incorrectly embedded CMYK profiles, but Krita always embeds "sRGB built-in" and Gimp never does. So the real bug seems to be that Gimp doesn't remove the incorrectly embedded CMYK color space profile upon export if "sRGB built-in" is assigned to an RGB image that already has an incorrectly embedded CMYK profile. A possible course of action would be to program a pop-up advising the user of the incorrectly embedded CMYK profile and suggesting that an RGB profile from disk should be assigned before exporting the image.
In master, it's no longer possible to attach whatever incorrect profile to an image because validation code was added. This bug mixes several issues, let's focus on the "big savings". An incorrect profile is already never attached to an image, so it's lost on import. I don't think we will add code to preserve such broken profiles for export. Remains the issue of simply saving space in the file, so to just discard the profile at any time, which is a duplicate of bug 646511. *** This bug has been marked as a duplicate of bug 646511 ***
This bug is not actually a duplicate of bug 646511, which is about the angst and horror visited upon web developers by various browsers' color *mis*management, with Firefox being a prime offender because of its "half-color-managed" default settings. This bug is about the fact that: On the one hand the old GIMP correctly did detect that the image was in fact an RGB image, despite the fact that the image somehow still had a CMYK profile embedded. But on the other hand, upon export, the old GIMP (before the latest round of CM code) incorrectly left the incorrect CMYK profile still embedded in the image, unless a profile from disk were assigned, in which case the assigned RGB profile from disk would overwrite the incorrectly embedded CMYK profile. Your new code correctly detects that the CMYK profile was completely wrong and shouldn't have been left embedded in the image in the first place. And then your new code correctly doesn't embed that wrong CMYK profile when it exports the RGB image, with or without an assigned RGB profile from disk. So your new code completely fixes this bug. One might consider putting in a warning that some other software did something stupid and left a CMYK profile embedded in an RGB image, but such a warning is likely to cause more confusion than clarity. The "big savings" is the fact that CMYK profiles are very large. In this case, the 1x1 tiff with the erroneously embedded CMYK profile was taking up 544KB on disk. After opening with GIMP (updated to the new CM code) and exporting to disk as a tiff, the exported tiff only takes up 296 bytes instead of 544 kilobytes. So it seems to me that this bug can be closed as fixed.
Good point. Re-resolving as simply FIXED.