Bug 150890

Summary:	Sometimes fails to honor the embeded ICC profile when opening PNG files
Product:	[Applications] krita	Reporter:	James Richard Tyrer <tyrerj>
Component:	General	Assignee:	Cyrille Berger <cberger>
Status:	RESOLVED FIXED
Severity:	normal	CC:	flodin+kdebugs, halla, lemma
Priority:	NOR	Keywords:	triaged
Version:	1.6.1
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed In:
Attachments:	Sample image file Profile

Description James Richard Tyrer 2007-10-16 14:14:44 UTC

Version:           1.6.3 (using KDE KDE 3.5.8)
Installed from:    Compiled From Sources
Compiler:          GCC 4.2.1 
OS:                Linux

Test case:

Open a PNG file without an embedded profile in Krita

Convert image to a smaller gamut RGB profile.  I used a profile for a Fuji Frontier printer: 

Fuji_Frontier-PD_CA-Type-ONE_V2

Save to a PNG file.

Confirm that the profile is embedded with the ImagicMagick command: 

identify -verbose <file>.png

Close Krita.

Reopen the file in Krita.

Now with the menu: 

Image -> Image Properties

and note the: "Profile" which for me is now: "sRGB Build In".

Comment 1 Cyrille Berger 2007-10-16 14:56:57 UTC

Can you attach the png and possibly the profile ? Krita can't use all profiles, it needs a profile that can do both "input" and "output" convertion. What's surprising is that you were able to use it in the first place for color conversion. So maybe there is a bug in the detection wether the profile is suitable or not.

Comment 2 James Richard Tyrer 2007-10-16 16:01:59 UTC

Created attachment 21831 [details]
Sample image file

Comment 3 James Richard Tyrer 2007-10-16 16:13:28 UTC

Created attachment 21832 [details]
Profile

Comment 4 Cyrille Berger 2007-10-16 17:44:26 UTC

I can confirm that profile works fine inside in Krita and that the code used to detect wether a profile isn't suitable for use in Krita is wrong.

We currently have two versions of that code, one which use an internal function of lcms and one that use a standard API. But both are 'hacks'.

Testing the presence of icSigAToB0Tag, icSigAToB1Tag, icSigAToB2Tag, icSigBToA0Tag, icSigBToA1Tag and icSigBToA2Tag in the profile using cmsIsTag might give better results. But currently it's impossible to test if I am correct in trunk.

Comment 5 Cyrille Berger 2008-03-18 18:57:37 UTC

*** Bug 148864 has been marked as a duplicate of this bug. ***

Comment 6 James Richard Tyrer 2008-03-18 19:33:41 UTC

Bug 148864:

"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."

Yes, this is what I observed.  That, what was saved was the displayed image rather than the data corrected for 'Intent'.

IIUC, this only happens with some profiles which something in Krita doesn't "like" and therefore refused to use for saving and/or loading.

Might I suggest that an error message would be appropriate here rather than just saving a file which is useless.  At least till the problem can be totally resolved.

Comment 7 Cyrille Berger 2008-03-18 22:42:13 UTC

Firstly, saving is not the issue, loading is. Secondly, making a warning dialog box (an error is out of question since it would prevent to open files) would probably as much time as writting a better check for the validity of the file. Lastly, it's not going to happen in 1.6.x, because no one is developing for it anymore, so be patient and wait for the fix in 2.0.

Comment 8 James Richard Tyrer 2008-03-19 00:33:12 UTC

Sorry that I wasn't clear.  

Yes, Krita correctly saves a file which it can not load correctly.

Comment 9 Elián Hanisch 2008-10-26 13:11:24 UTC

I can reproduce this with lastest krita beta2, opening the attached png still shows a "sRGB Build In" profile

Comment 10 Cyrille Berger 2008-10-29 00:05:23 UTC

This bug is now fixed