Bug 165650 - digikam appears to add a color profile for printing?
Summary: digikam appears to add a color profile for printing?
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: ColorManagement-Profiles (show other bugs)
Version: 0.9.4
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-03 19:16 UTC by Simon Oosthoek
Modified: 2022-02-01 11:19 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In: 1.0.0


Attachments
screenshot of problem case (539.80 KB, image/png)
2008-07-08 09:58 UTC, Simon Oosthoek
Details
the keep/convert dialogue shown by the gimp (19.89 KB, image/png)
2008-07-08 09:59 UTC, Simon Oosthoek
Details
example image (532.54 KB, image/jpeg)
2008-07-08 10:30 UTC, Andi Clemens
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Oosthoek 2008-07-03 19:16:04 UTC
Version:           0.9.4rc1 (using KDE 3.5.9)
Installed from:    Compiled From Sources
Compiler:          gcc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7) 
OS:                Linux

For some reason, when I edit a photo in digikam's editor, a lot of the times (perhaps all of the times) the photo will have problems printing at profotonet.nl. The last time I had this problem, I discussed this with profotonet and it seems they could see a second colour profile in the jpg. On the screen, the image looks perfectly normal. I still have to do more tests and I need to find the right pictures to upload as examples. I don't know how to interpret a JPEG image regarding colour profiles :-(

A workaround for this is not to use digikam's editor for editing and use the gimp (2.4.5) instead.

I suppose any information regarding what happens with colour profiles in digikam could be useful to unravel this bug...

Cheers

Simon
Comment 1 Simon Oosthoek 2008-07-04 10:25:38 UTC
Some more information...

I can see the problem, when I open the file afterwards in the gimp, it asks to keep or convert the color profile. When converting it, the colour issue shows up.

The shop was quite considerate of my problem, but they told me to throw away the software, because next time they won't pay for my problem ;-)

Apparently the problem is that the output JPEG file contains two references to a color profile and they are different from each other. This should not be the case, but due to the way programs read JPEGs, the viewed version seems ok, but the colours change after the color profile is converted (which happens in the printer)

/Simon
Comment 2 Simon Oosthoek 2008-07-08 09:58:12 UTC
Created attachment 25921 [details]
screenshot of problem case

In this screenshot, you can see an image, converted from .ARW in digikam's
editor, saved to .jpg and then opened in the gimp. The Gimp notices a color
profile and offers to keep or convert it. I choose convert and then you get the
image shown in the screenshot. (When I choose keep, it looks the same)
Comment 3 Simon Oosthoek 2008-07-08 09:59:15 UTC
Created attachment 25922 [details]
the keep/convert dialogue shown by the gimp
Comment 4 Simon Oosthoek 2008-07-08 10:08:47 UTC
the jpeg in question is too big for uploading, it can be found here:
http://margo.student.utwente.nl/simon/temp/DSC01940-dk.jpg  (3.1MB)


Comment 5 Simon Oosthoek 2008-07-08 10:23:22 UTC
The same raw file processed using ufraw and the gimp:
http://margo.student.utwente.nl/simon/temp/DSC01940-gimp.jpg
Comment 6 Andi Clemens 2008-07-08 10:30:49 UTC
Created attachment 25923 [details]
example image

I can confirm this, look at my images here. I opened the JPEG (not converted
from RAW) into Gimp and digiKam, looks good in both programs. After that, I
sharpened the image in digiKam and created a new copy of it. Now I loaded both
images in Gimp, the second one has a color profile that doesn't match the
original image.
Also I noted that if I use filters in digiKam, not only sharpness but all kind
of image manipulation, the resulting images seem to be zoomed in a little bit.
For example I do color cast correction and safe the image in a new copy. Now I
watch both images in fullscreen inside of digiKam. When switching between both
images, the second image (the new copy) is slightly bigger, but not in the
overall dimensions. So it looks like the image has been cropped and scaled back
to the original size.
Comment 7 Dik Takken 2008-10-05 14:31:15 UTC
Possibly related:

I have a cheap digital camera that only produces JPG files. When opened in DigiKam, it says it has a sRGB profile with a 5000K whitepoint, and asks me if I want to convert the image to my editing profile (which is aRGB). When I do so, the images all show way too cold colors. But when I open the same image in CinePaint, it says the image does NOT have a profile and asks if I want to assign one to it. So, I assign sRGB to it, and the image looks fine. Weird...

I have no experience printing these images yet.
Comment 8 Scott 2008-11-18 03:51:25 UTC
I can confirm this bug with .94 final. Reproduce as follows:

1. Save file from UFRaw using default sRGB output which tags file as sRGB color, but does not embed a color profile. sRGB tags without embedded profiles are also commonly output from many cameras.

2. Open file in Digikam (with color management off) and save.

3. Open and save the file with Imagemagick using the option -profile Path/sRGBprofile.icc and observe a drastic blue color shift.

OR

Upload file to Zenfolio, which converts and embeds sRGB profiles by default, and observe a drastic blue shift.

AND/OR

Use Jeffry's online EXIF viewer to see warnings regarding color profile not matching the color profile tag.

http://regex.info/exif.cgi

Hopefully this will be fixed in 0.95?
Comment 9 Simon Oosthoek 2009-01-11 20:17:24 UTC
At the moment, this bug is this there in 0.9.5-svn. I do hope this will be fixed before a release candidate is tagged.

Cheers

Simon
Comment 10 Simon Oosthoek 2009-01-18 12:40:21 UTC
I just noticed the problem isn't limited to saved JPEG files, I also saw it in a PNG file.
Comment 11 Tobias Schula 2009-04-11 01:34:31 UTC
Bug still present in 0.10.0. 

As mentioned above by Dik Takken, while saving digikam adds a wrong profile to the picture. This profile claims to be sRGB, but has a shifted white point. Instead of the normal D65 (6500 K) it says D50 (5000 K). 

So opening it with a software that can read and use icc profiles (e.g. photoshop, firefox) causes a nasty colour shift. It also affects image printing services. Two days before I sent 50 pictures to http://saal-digital.de and about a dozen were edited with digikam. I was about to exhibit them this weekend, but now all edited pictures have this nasty shift.

Digikam is a great tool to organise, edit and correct pictures, but this bug causes a lot of extra work for me because now I must rework my pictures with other programs to work around this bug.

I also added a bug report yesterday containing roughly the same: https://bugs.kde.org/show_bug.cgi?id=189250
I think it's now obsolete and could be closed, I just don't know how to do that.
Comment 12 Greg Kennedy 2009-08-04 23:06:06 UTC
I am having the same issue with the Ubuntu package (2:0.10.0-1ubuntu3).  I don't mess with color management settings but DigiKam is tacking on a bad ICC profile when I save images to disk.  Here's a very clear sample image: http://greg-kennedy.110mb.com/img/666656.jpg

Very frustrating, I never would have noticed until I enabled Firefox's new ICC profile option.  Hopefully there's an easy workaround.
Comment 13 Kevin Radloff 2009-08-06 05:53:42 UTC
As a workaround, you can use "mogrify +profile 'icc' filename" to strip the offending color profile from an image.
Comment 14 caulier.gilles 2009-08-15 11:00:06 UTC
A lots of work have been done by Marcel recently about digiKam color management code.

Please test current code from svn 1.0.0-beta4.

Gilles Caulier
Comment 15 caulier.gilles 2009-08-15 11:09:56 UTC
*** Bug 200153 has been marked as a duplicate of this bug. ***
Comment 16 Marcel Wiesweg 2009-08-20 23:15:37 UTC
The root of all the problems here is indeed the defective sRGB profile that we shipped until bug #189250 got fixed. This profile was - most unfortunately - not the one referred to when cameras tagged their images as sRGB. With the color management dialog from current SVN you can clearly see the difference in the DSC01940 file when you choose to discard the embedded profile and assign sRGB IEC61966-2.1 instead. The profile currently shipped with libkdcraw in identical to the one distributed by Adobe in its ICC profiles package. DSC01940-gimp has the correct profile embedded.
The testcase from #12 has no embedded profile.