Bug 192461

Summary:	16-bit TIFF render as 3x3 black & white mosaic [patch]
Product:	[Applications] digikam	Reporter:	Alphazo <kde-1091>
Component:	Plugin-DImg-TIFF	Assignee:	Digikam Developers <digikam-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal	CC:	kde-1091, marcel.wiesweg, tschenser
Priority:	NOR
Version:	0.10.0
Target Milestone:	---
Platform:	Ubuntu
OS:	Linux
Latest Commit:		Version Fixed In:	1.1.0
Sentry Crash Report:
Attachments:	PATCH updated version of the patch

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