|Summary:||TIFF files with Exif.Image.Orientation = 1 aren't decoded properly|
|Product:||[Applications] digikam||Reporter:||Guillaume Paumier <guillom.pom>|
|Component:||Plugin-DImg-TIFF||Assignee:||Digikam Developers <digikam-bugs-null>|
|Latest Commit:||Version Fixed In:||2.0.0|
Description Guillaume Paumier 2011-06-03 20:59:35 UTC
Version: 2.0.0 (using KDE 4.6.2) OS: Linux Some pro- and semi-pro cameras allow the photographer to save the images in TIFF format. In this case, the file can contain two pages: one for the high-resolution image, and one for a low-resolution thumbnail. Digikam seems to have problem decoding such files. I'm not sure if the issue comes from the multipage TIFF, or the EXIF orientation, or both. Wiping out the EXIF metadata fixes the problem, but obviously that's not an acceptable general solution. Reproducible: Always Steps to Reproduce: * Open http://dl.dropbox.com/u/17707983/DSC_0301.TIF (35.2 MB) in digiKam * Zoom to 100% Actual Results: * Strips are visible when viewing the image at 100% * Strips are actually saved when saving the file in another format, so it's not only a display issue. Expected Results: * The image should be decoded properly.
Comment 1 Guillaume Paumier 2011-06-03 21:18:30 UTC
Note: After further investigation, I can tell this isn't a multipage issue (adjusting the bug summary accordingly). I've used tiffsplit and the same problem happens on single-page TIFF files with Exif.Image.Orientation = 1 Single-page TIFF test file at http://dl.dropbox.com/u/17707983/tiffstripes.tif (34.5 MB) The issue could be circumvented by manually resetting the image orientation, except digikam can't write metadata to TIFF files ( bug 271757 ).
Comment 2 Guillaume Paumier 2011-06-03 21:57:53 UTC
(In reply to comment #1) > > The issue could be circumvented by manually resetting the image orientation, > except digikam can't write metadata to TIFF files ( bug 271757 ). OK, so now resetting the image orientation works for TIFF files; I swear it didn't a few days ago :) I guess this is what you get for using trunk! So, temporary workaround: reset the image orientation, and rotate the picture. This doesn't fox the underlying issue, though.
Comment 3 Marcel Wiesweg 2011-06-11 23:11:35 UTC
Yes, quite interesting: It seems the pixels in the individual rows are not rotated, only the complete rows are rearranged.
Comment 4 Marcel Wiesweg 2011-06-11 23:25:43 UTC
Guillaume: orientation is 8 The key is given here: http://www.asmail.be/msg0055572905.html
Comment 5 Marcel Wiesweg 2011-06-11 23:27:56 UTC
Git commit 26fead33cae1e5174911a51182bdb0a47479aadf by Marcel Wiesweg. Committed on 11/06/2011 at 23:27. Pushed by mwiesweg into branch 'master'. Do not handle rotation by exif flag with libtiff, which will do weird stuff like only rotating rows. BUG: 274865 M +2 -1 NEWS M +3 -1 libs/dimg/loaders/tiffloader.cpp http://commits.kde.org/digikam/26fead33cae1e5174911a51182bdb0a47479aadf