Bug 148864

Summary:	CMYK colors distorted when loading / saving
Product:	[Applications] krita	Reporter:	flodin+kdebugs
Component:	General	Assignee:	Cyrille Berger <cberger>
Status:	RESOLVED DUPLICATE
Severity:	normal
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Gentoo Packages
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description flodin+kdebugs 2007-08-15 20:55:47 UTC

Version:           1.6.3 (using KDE KDE 3.5.5)
Installed from:    Gentoo Packages
Compiler:          gcc (GCC) 4.1.2 (Gentoo 4.1.2) 
OS:                Linux

Steps to reproduce:
1. Start krita, create a CMYK 8-bit image with Adobe CMYK profile
2. Fill the image with cyan (RGB 0,255,255).
3. Use the color picker to see the CMYK color; it says Cyan 97, Magenta 0, Yellow 52.
4. Save image as TIFF and close krita.
5. Start krita again, load the TIFF image.
6. Use the color picker to see the CMYK color again.

Observed: The color picker now says Cyan 65, Magenta 12, Yellow 39. Each time you load and save the image, the color becomes paler. It seems as if krita saves the color-corrected image data rather than the original image data, then the next time you load the color correction is applied again and again.

Expected: The color should be exactly the same when you load the image back in again.

This problem makes the CMYK support impossible to work with: whatever you do it is distorted whenever you save the image.

Comment 1 Halla Rempt 2007-08-15 21:28:47 UTC

Thank you for your report. I think the problem happens on loading, since saving an image from Krita and then loading it in Photoshop (5.5, choosing "no conversion") gives the same percentages as in Krita. I'll investigate, although I may have to reassign to Cyrille.

Comment 2 Halla Rempt 2007-08-15 21:36:46 UTC

SVN commit 700532 by rempt:

This chunk of code is bogus. Removing it fixes bug [Bug 148864] New: CMYK colors distorted when loading / saving, but apparently there's still something to be done here.
CCBUG:148864


 M  +3 -3      kis_tiff_converter.cc  


--- branches/koffice/1.6/koffice/filters/krita/tiff/kis_tiff_converter.cc #700531:700532
@@ -270,9 +270,9 @@
         TIFFClose(image);
         return KisImageBuilder_RESULT_UNSUPPORTED_COLORSPACE;
     }
-    
+    cmsHTRANSFORM transform = 0;
+#if 0    
     // Create the cmsTransform if needed 
-    cmsHTRANSFORM transform = 0;
     if(profile && !profile->isSuitableForOutput())
     {
         kdDebug(41008) << "The profile can't be used in krita, need conversion" << endl;
@@ -280,7 +280,7 @@
                                        cs->getProfile()->profile() , cs->colorSpaceType(),
                                        INTENT_PERCEPTUAL, 0);
     }
-
+#endif
     
     // Check if there is an alpha channel
     int8 alphapos = -1; // <- no alpha

Comment 3 Halla Rempt 2007-08-15 21:38:41 UTC

Just keeping this bug open and assigned to Cyrille as a reminder that the todo in kis_tiff_converter.cpp should still be fixed.

Comment 4 flodin+kdebugs 2007-08-17 07:48:52 UTC

Thank you for the fast fix. I have applied the patch on my system and it resolves the problem on my end.

However it appears that the exact same issue exists in the jpeg converter (looks like copy-pasted code).

Leaving open wrt boud's remark, and the fact that the jpeg converter also needs to be fixed.

Comment 5 Cyrille Berger 2007-08-20 21:09:59 UTC

This code isn't bogus. It's isSuitableForOutput() which is bogus. So this patch shouldn't be applied to trunk.

Comment 6 Halla Rempt 2008-03-18 15:30:06 UTC

How can we fix this? The following code was already present in 1.6:

        // Check if the profile can convert (something->this)
//         LPMATSHAPER OutMatShaper = cmsBuildOutputMatrixShaper(d->profile);
//         if( OutMatShaper )
//         {
//             d->suitableForOutput = true;
//         }
        cmsCIEXYZTRIPLE Primaries;

        if (cmsTakeColorants(&Primaries, d->profile))
        {
            d->suitableForOutput = true;
        }

What's the right way? Or should we bug Marti about this?

Comment 7 Cyrille Berger 2008-03-18 18:57:23 UTC

I knew there was a reason 1.6.4 wasn't releasable. That change makes more harm than good.

Comment 8 Cyrille Berger 2008-03-18 18:57:36 UTC


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

Comment 9 James Richard Tyrer 2008-03-18 19:37:50 UTC

Have you tried opening the first saved image in a viewer application which doesn't apply a color profile?  If your experience is the same as mine, the saved image displayed without a profile (actually displayed using sRGB) should look the same as the image of the original created image in Krita.