Bug 186054 - FILEIO : add non-rgb TIFF files support [patch]
Summary: FILEIO : add non-rgb TIFF files support [patch]
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Plugin-DImg-TIFF (show other bugs)
Version: 0.10.0
Platform: Fedora RPMs Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-03 18:13 UTC by Geert Janssens
Modified: 2017-07-30 16:28 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.10.0
Sentry Crash Report:


Attachments
tiffloader.patch (872 bytes, patch)
2015-05-08 22:41 UTC, Maik Qualmann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Geert Janssens 2009-03-03 18:13:04 UTC
Version:           10.0-rc2 (using KDE 4.2.0)
OS:                Linux
Installed from:    Fedora RPMs

This issue was mentioned shortly in another bug, which is now closed:
https://bugs.kde.org/show_bug.cgi?id=125916
(see comment 54: https://bugs.kde.org/show_bug.cgi?id=125916#c54)

At present digikam only supports TIFF images in RGB format. However, I recently added a lot of CMYK TIFF images to my library (I have received them from my prepress agency).

Digikam is pretty useless with those images. For example:
* thumbnail generation silently fails with this message on the command line:
Digikam::TIFFLoader::load: Can not handle image without RGBcolor-space
* trying to preview the images fails with message:
Cannot display preview for "xxxx".tif
* the same goes for the image editor

As bug #125916 is closed and I can't find any other bug report on this, I decided to add another wish to implement this functionality.
Comment 1 Geert Janssens 2009-04-06 19:52:54 UTC
This issue is still there in digikam 10.0 final.

Gilles, in https://bugs.kde.org/show_bug.cgi?id=125916#c54 you mention

> I have a solution to handle non-RGB color-space picture
> using lcms library, but i have not yet implemented this
> one in my computer.

Would be be difficult to implement this ? This fix would really improve my user experience with digikam, so if not to difficult I would really like to see it fixed in the next version.
Comment 2 Geert Janssens 2009-06-10 10:42:31 UTC
Can this bug be fixed before the final 1.0 release, please ?
Comment 3 Michal Thoma 2009-08-12 15:56:36 UTC
I'm also missing CMYK support for the similar reasons. I have good bunch of high quality scans in CMYK. Unfortunately Digikam can't display although it correctly identifies image is CMYK.
Comment 4 Geert Janssens 2009-11-09 21:49:14 UTC
I tested this today with 1.0.0beta5 on rawhide. The problem is still there.

And no reply from the developers on whether or not it will be fixed...

My apologies if I sound like nagging, but I think it would be a really useful improvement and Gilles suggested in the previous bug that the fix would not be too complicated.
Comment 5 Geert Janssens 2009-12-01 14:11:03 UTC
Nothing seems to happen with this bug.

I wonder, is cmyk support for tif images actually something that should be in digikam directly, or rather in one of the base libs (like libtiff or something).

Can a digikam dev voice his opinion about this ? If it's not digikam, it can be reassigned.

Anyway, I just want to see some progress on this bug, and I'm trying to find out why it stalls right now.
Comment 6 Marcel Wiesweg 2009-12-02 21:09:44 UTC
I'm not sure how complicated the fix is, I have no experience with CMYK images. Probably  not something to be done shortly with a few lines of code.
If someone knows it's easy give us a hint.
Comment 7 caulier.gilles 2009-12-02 23:36:04 UTC
Marcel,

Look in JPEG loader. JPEG support CMJN too and you have add some code (taken from Qt if i remember) to convert to RGB color space... I think the same can be do in TIFF loader.

Else, perhaps ImageMagick or Krita tiff loader as this code (based on libtiff). I can take a look.  

Gilles
Comment 8 Jens Mueller 2009-12-22 22:20:12 UTC
For 8bit images only: why do we give up so early? We use for 8bit images TIFFRGBAImageGet(...), this function can handle nearly all tiff encodings (also CYMK), but in tiffloader.cpp line 192 only RGB and MINISBLACK color codings are allowed.
Comment 9 caulier.gilles 2014-09-02 13:20:27 UTC
*** Bug 268059 has been marked as a duplicate of this bug. ***
Comment 10 caulier.gilles 2014-09-02 13:22:08 UTC
*** Bug 219542 has been marked as a duplicate of this bug. ***
Comment 11 caulier.gilles 2015-05-06 06:29:29 UTC
*** Bug 347271 has been marked as a duplicate of this bug. ***
Comment 12 Maik Qualmann 2015-05-08 22:41:23 UTC
Created attachment 92503 [details]
tiffloader.patch

This patch enabled the loading of TIFF images with YCbCr or CMYK color model with 8 bits color depth.
Maik
Comment 13 caulier.gilles 2015-05-09 09:06:15 UTC
Patch is fine for me...

Gilles
Comment 14 Geert Janssens 2015-05-09 10:26:00 UTC
Wonderful ! I'm looking forward to seeing this patch integrated in a future version of digikam.

One comment: if the tiffloader now is capable of displaying CMYK images as well as RGB ones, shouldn't the error message for unknown formats be a bit more precise ?
Comment 15 Maik Qualmann 2015-05-09 13:46:31 UTC
Git commit 2c5e7c2bbab6cf6b7f1797c7788876d27a0dc6b8 by Maik Qualmann.
Committed on 09/05/2015 at 13:42.
Pushed by mqualmann into branch 'master'.

apply patch #92503 to enabled the loading of TIFF images with YCbCr or CMYK color model
FIXED-IN: 4.10.0

M  +2    -1    NEWS
M  +4    -1    libs/dimg/loaders/tiffloader.cpp

http://commits.kde.org/digikam/2c5e7c2bbab6cf6b7f1797c7788876d27a0dc6b8
Comment 16 Maik Qualmann 2015-05-09 13:52:10 UTC
(In reply to Geert Janssens from comment #14)

> One comment: if the tiffloader now is capable of displaying CMYK images as
> well as RGB ones, shouldn't the error message for unknown formats be a bit
> more precise ?

To create a better error message, I have on my TODO list.

Maik
Comment 17 caulier.gilles 2015-05-09 15:26:03 UTC
Git commit 5e862379f6265b01fb7849c8f65609cac898ca74 by Gilles Caulier.
Committed on 09/05/2015 at 15:25.
Pushed by cgilles into branch 'frameworks'.

backport commit #2c5e7c2bbab6cf6b7f1797c7788876d27a0dc6b8 from git/master to frameworks branch

M  +4    -1    libs/dimg/loaders/tiffloader.cpp

http://commits.kde.org/digikam/5e862379f6265b01fb7849c8f65609cac898ca74