Summary: | TIFF loader is broken on big-endian architectures [PATCH] | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | pochini |
Component: | Plugin-DImg-TIFF | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | caulier.gilles |
Priority: | NOR | ||
Version: | 2.0.0 | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | http://commits.kde.org/digikam/b27eae029207187882ae094e94158abfd903d379 | Version Fixed In: | 3.0 |
Sentry Crash Report: | |||
Attachments: | Fix TIFF loader on big-endian architectures |
Thanks a lots for your patch. Please take a look in my reprository, where a lots of different tiff files are available to test : http://digikam3rdparty.free.fr/TEST_IMAGES/TIFF/ I'm waiting your future improved patch... Gilles Caulier Pochini, Do you see my Comment #1 ? Gilles Caulier No, the message was buried in the mess of my mailbox. However I continued development. I got stuck with a problem when saving images. In some cases the saved image is corrupted. I know how to reproduce it, but I wasn't able to figure out why it happens. I also tried to debug libtiff without luck. I'll try again... Git commit b27eae029207187882ae094e94158abfd903d379 by Marcel Wiesweg. Committed on 29/09/2012 at 15:07. Pushed by mwiesweg into branch 'master'. Apply patch by pochini@shiny.it to fix TIFF loading on big endian, and attempt to fix saving as well by using ushort instead of messing with single bytes. Untested due to lack of hardware to test. FIXED-IN: 3.0 M +59 -148 libs/dimg/loaders/tiffloader.cpp http://commits.kde.org/digikam/b27eae029207187882ae094e94158abfd903d379 |
Created attachment 58481 [details] Fix TIFF loader on big-endian architectures Version: 2.0.0 (using KDE 4.5.2) OS: Linux In the TIFF loader all those if-QSysInfo::ByteOrder in the 16 bits color path are wrong because the order of color components is always the same for any architecture. I removed all of them and I left the "else" code paths only. NOTE: I was able to test only the 3-samples-per-pixel PLANARCONFIG_CONTIG part of the code because I haven't images in other formats. The 8 bits image loader is fine. The saver is also buggy, but the bugs cancel each other when !imageHasAlpha(). There are also other issues I will investigate (and try to fix) later. The attached patch fixes the loader only. I wrote and tested it for 1.8.0 and forward ported it to the latest GIT version. Reproducible: Always