| Summary: | endianess problem under Linux-PowerPC (with png images at least) | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Yannick Roehlly <yannick.roehlly> |
| Component: | Plugin-DImg-PNG | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | 0.9.0 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 0.9.0 | |
| Sentry Crash Report: | |||
| Attachments: |
Generated thumbnail screenshot
Image viewing screenshot debug output The test image tarball with four patches "b + a3" patch screenshot |
||
|
Description
Yannick Roehlly
2006-07-30 14:52:47 UTC
Created attachment 17169 [details]
Generated thumbnail screenshot
Created attachment 17170 [details]
Image viewing screenshot
Thats really difficult for me to test without a PPC machine. Could you perhaps apply the given patch - it will create a small debug file in your working dir for every png you are opening - and send me the file created for the debian logo. Perhaps there are differences to LittleEndian (I am not even sure if there should be differences or not) Created attachment 17173 [details]
debug output
Thanks, I received your output. It seems to be correct, BGRA on little and ARGB and big endian. Could you post an image editor screenshot of an image with pure red,green,blue, perhaps http://en.wikipedia.org/wiki/Image:Computerspectrum.png The problem only affects PNG images, raw, jpeg and tiff are all right? Hi Marcel, Instead of uploading a lot of screenshots, here comes an image comparing the original, the digikam thumbnail and the showfoto vue for a pure red png, a pure green one, a pure blue one and the spectrum you indicated. As you can see, the problem seems a bit different for the thumbnail generation and for the showfoto vue. I have tested various formats: - png : wrong - jpeg : thumbnail good, showfoto unknow as it doesn't display jpegs (bug #131550) - pnm : good - gif : good - tiff : unknow, digikam eats all my cpu :'( Sincerely, Yannick Created attachment 17191 [details] The test image Test image corresponding to the comment #6 Thanks a lot for your help!
Ok, I tried to do some logic and it seems that it's ARGB vs. BGRA, though the third square does not seem to fit.
If I had a PPC I would use trial&error, perhaps you want to test a bit?
There is line 237 of libs/dimg/loaders/pngloader.cpp
png_set_add_alpha(png_ptr, 0xFFFF, PNG_FILLER_BEFORE);
which might be changed to
png_set_add_alpha(png_ptr, 0xFF, PNG_FILLER_AFTER);
and there is line 301
png_set_swap_alpha(png_ptr);
which might be changed to
png_set_bgr(png_ptr);
or
{png_set_bgr(png_ptr);png_set_swap_alpha(png_ptr);}
Perhaps one of these 2*3=6 possibilities is correct?
:-)
As to your tiff problem, run digikam, load a tiff, 100% CPU, then identify the process with ps ax, and run gdb att <PID> (or run digikam directly under gdb and bit ctrl+c to stop it), and type "thr appl all bt" to get a backtrace of all running threads, one of them probably in an endless loop.
Hi Marcel, According to bug #125955 (3rd comment), it seems that on big endian it's ABGR. Maybe you can contact the person responsible for the patch. If you wan't me to test the 6 possibilities, you'll have to be a little more explicit, I don't speak C++. ;-) Created attachment 17208 [details]
tarball with four patches
I'm sorry you have so much work with helping us fix this, but there is no other
way for me to do this. Especially not by thinking, I have no experience with
endianness problems and I don't know what needs to be fixed (I hope that the
png loader is at all the right place to be fixed, we will see that if you try
some image plugins...) We might wait for Gilles when he returns in three weeks,
I don't know if he has experience.
The attached tarballs contains four patches. The "a" patches are exclusive, you
will have to revert (with svn or with patch) the other before applying the
next. The "b" patch is independent from them. So (including no "a" version
applied) it's 4*2=8 :-)
Hi Marcel, It's not 4*2 but 4*2-1. The "no patch at all" doesn't work. ;-) So far, I've tested the four combinations with the b patch applied. The "b + a3" seemed to work, but no for the openlogo which appears in blue (see the screenshot I'll just post). When I was just about to become mad, I found the problem. The openlogo has indexed colors (thanks The Gimp); switching it to RGB makes it appear correctly. So the "b + a3" version works but not for indexed color pngs. I will test the "without b" versions to see what it comes out. Maybe you should take advice from de PPC guru (the person who corrected Krita?). Yannick Created attachment 17213 [details]
"b + a3" patch screenshot
The blue Debian logo correspond to the indexed color png file which is
displayed incorrectly. It appears blue also in showfoto.
Version with only patch a3 does not work. SVN commit 569447 by mwiesweg: Fix PNG loader for PPC. As suggested by testing, use the same code for little and big endian. (This now changes all color types, not only RGB as the first patch) CCBUGS: 131549 M +59 -53 pngloader.cpp Great ! This works even for the indexed png. Good work. Thanks. Closing as fixed |
