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.
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.
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
Just keeping this bug open and assigned to Cyrille as a reminder that the todo in kis_tiff_converter.cpp should still be fixed.
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.
This code isn't bogus. It's isSuitableForOutput() which is bogus. So this patch shouldn't be applied to trunk.
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?
I knew there was a reason 1.6.4 wasn't releasable. That change makes more harm than good.
*** This bug has been marked as a duplicate of 150890 ***
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.