Bug 192461 - 16-bit TIFF render as 3x3 black & white mosaic [patch]
Summary: 16-bit TIFF render as 3x3 black & white mosaic [patch]
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Plugin-DImg-TIFF (show other bugs)
Version: 0.10.0
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-12 18:37 UTC by Alphazo
Modified: 2017-08-01 20:23 UTC (History)
3 users (show)

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


Attachments
PATCH (7.54 KB, patch)
2009-12-22 22:12 UTC, Jens Mueller
Details
updated version of the patch (7.54 KB, patch)
2009-12-27 23:57 UTC, Jens Mueller
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alphazo 2009-05-12 18:37:34 UTC
Version:           0.10.0-1ubuntu3 (using KDE 4.2.1)
OS:                Linux
Installed from:    Ubuntu Packages

I've added a number of 16-bit TIFF to Digikam. Both thumbnails and previews show a black & white mosaic (3x3) of the same picture while default Nautilus image viewer renders them well.

Here is a screenshot of what is displayed under DigiKam:
http://natzo.com/capture.png

Here is what it should look like (as seen under Nautilus):
http://natzo.com/2008-04_Mithe-Demi_Finale_A_206-Mod.png

and here is the original TIFF file (45MB)
http://natzo.com/2008-04_Mithe-Demi_Finale_A_206-Mod.tif

Dany
Comment 1 Marcel Wiesweg 2009-07-25 15:40:12 UTC
The given image has a separate planar configuration (TIFFTAG_PLANARCONFIG == PLANARCONFIG_SEPARATE) and is 16bit. For loading 16bit we cannot use libtiff's convenience methods but use TIFFReadEncodedStrip directly.
Currently we do not support this type of image, I am not quite sure what is the right way to interpret such tiles.
I found this http://www.gnu-darwin.org/www001/ports-1.5a-CURRENT/graphics/xpaint/work/xpaint-2.7.8.1/rw/readTIFF.c file as an example but they read row-by-row and 8bit data. We read strip-by-strip and 16bit.
Comment 2 Andi Clemens 2009-12-05 00:13:52 UTC
How is gwenview handling this? It is displayed correctly in there...
Comment 3 Marcel Wiesweg 2009-12-05 12:24:47 UTC
I assume in Gwenview it's loaded in 8bit?
Comment 4 Alphazo 2009-12-05 23:43:45 UTC
Here is the result of my latest tests: 
- showFoto KDE 4.3.4 : BAD
- ristretto 0.0.22 : GOOD
- GPicview 0.2.1 :GOOD
- Gwenview KDE 4.3.4 : GOOD
- fotoxx 8.8 : GOOD
- DigiKam 1.0RC : BAD
Comment 5 Jens Mueller 2009-12-22 22:12:42 UTC
Created attachment 39265 [details]
PATCH

this patch add support for 16bit images with PLANARCONFIG_SEPARATE encoding in tiffloader (fixes this bug)
Comment 6 Jens Mueller 2009-12-27 18:12:55 UTC
As you digikam-devels are the fastest bug-responsive crew on earth and there is no feedback about the above patch I think the main problem is that I missed to give some detailed infomation about. In case of PLANARCONFIG_SEPARATE every strip do only contain one color channel. All strips of one color channel are side by side to another, that means first there are stips containing blue, the came all the strips containing green and so on. That's all.
Comment 7 caulier.gilles 2009-12-27 18:18:00 UTC
Thanks for explaination Jens. I think this bug is tracked by Marcel. Wait and see...

Gilles Caulier
Comment 8 Marcel Wiesweg 2009-12-27 21:32:28 UTC
Sorry, it was sitting in a large pile of TODOs.
Have you updated your SVN checkout recently and merge the latest changes?
Currently the patch does no longer apply, there were some endianness bugs fixed.
Comment 9 Jens Mueller 2009-12-27 23:57:46 UTC
Created attachment 39394 [details]
updated version of the patch

As I do not own a big-endian machine, i can not guarantee that color channels are mapped right on powerpc.
Comment 10 Marcel Wiesweg 2009-12-29 15:14:27 UTC
SVN commit 1067391 by mwiesweg:

Support loading 16bit TIFFs with TIFFTAG_PLANARCONFIG == PLANARCONFIG_SEPARATE.
Applying patch by Jens Müller, thank you.

BUG: 192461

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


WebSVN link: http://websvn.kde.org/?view=rev&revision=1067391