Bug 139657 - Blueish tint in low saturation images converted to CMYK
Summary: Blueish tint in low saturation images converted to CMYK
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Plugin-DImg-TIFF (show other bugs)
Version: 0.9.0
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-06 02:09 UTC by Ar
Modified: 2017-08-08 15:13 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 0.9.4


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ar 2007-01-06 02:09:05 UTC
Version:           0.9.0 (using KDE KDE 3.5.5)
Installed from:    Ubuntu Packages
OS:                Linux

This is with Digikam 0.9.0 final.

This is the scenario: I start with an sRGB JPEG image with very low saturation (looks nearly B&W). Open it in image editor, then save it as is as TIFF (8 bits, no compression).

Open the tiff in Krita or in Photoshop. Convert to CMYK. Voila, looks blueish.

Now: open the original JPEG directly with Krita (or photoshop). Save as tiff (RGB, 8 bits, no compression). Now reopen the tiff in Krita/PS and convert it to CMYK. Voila, looks nice, no blueish tint.


I run into this issue the hard way, after carefully preparing my images and then importing them to my Lab's  print order management application, that does some 'softproofing' that actually smells and behaves like CMYK conversion. All my carefully digikam-processed images were blueish!!

With Nikon D80-generated sRGB JPGs, Krita tiffs, Photoshop tiffs, look nice in this app. Digikam tiffs look blueish, totally different from what digikam shows. Maybe a color-profile-related problem?

My workaround is: generate the tiffs with Krita, then continue the workflow on digikam. Seems to work fine (will confirm when the prints are delivered...)

Will attach the original jpg, and two tiffs, one generated with digikam's image editor and the other with krita. All default options. (I played in krita removing alpha channel, changing color space, etc, it always works OK (images never turn blue)).
Comment 1 Ar 2007-01-06 02:24:51 UTC
The test images can be found here:

http://www.arielpablo.com.ar/unprotected-files/

The original photo is jpg and can be found there.
The two created tiffs were 40Megs each, I downsampled them both with Digikam. Same behavior can be observed in the downsampled image.

In Krita, doing Image > Convert Image Type > CMYK (8 bits etc, all default options).

The tiff created by krita still looks OK after the conversion. The tiff created by digikam turns bluish.

Comment 2 Frank Siegert 2007-01-20 14:40:48 UTC
I can confirm this in digikam compiled from trunk r625297.

The debug output from opening the file in the editor until saving it as tiff is the following:

digikam: Found JPEGLossless plugin
QFile::open: No file name specified
QFile::open: No file name specified
digikam: /home/newuser/Pictures/test/dsc_0006.jpg : JPEG file identified
digikam: Exif color-space tag is sRGB. Using default sRGB ICC profile.
digikam: Exif Orientation: 1
digikam: mimetypes=image/x-portable-bitmap image/x-pcx image/x-portable-greymap image/x-xbm image/x-targa image/png image/x-portable-pixmap image/jpeg image/x-xpm image/x-eps image/x-bmp image/jp2 image/x-rgb image/tiff
digikam: Saving to :/home/newuser/Pictures/test/NR22oa.digikamtempfile.tmp (tiff)
digikam: (401x600) JPEG image preview size: 45784 bytes
digikam: Dirty: /test
kio_digikamalbums: [static Digikam::DImg::FORMAT Digikam::DImg::fileFormat(const QString&)] Failed to read header of file "/home/newuser/Pictures/test/NR22oa.digikamtempfile.tmp"
digikam: Dirty: /
digikam: renaming to /home/newuser/Pictures/test/dsc_0006.tiff
digikam: ImageInfo::copyItem 1 dsc_0006.jpg to 1 dsc_0006.tiff
digikam: Dirty: /
digikam: Dirty: /test
digikam: Dirty: /
Comment 3 caulier.gilles 2008-03-18 13:52:59 UTC
Ar, Frank,

This entry still valid with 0.9.3 release or current implementation from svn ?

Gilles Caulier
Comment 4 Ar 2008-03-19 00:11:26 UTC
The problem seems to be fixed in 0.9.3

Thanks
Comment 5 caulier.gilles 2008-03-19 06:13:28 UTC
Ok, thanks for the report. 

I close this file now.

Gilles Caulier