Version: 0.9.0-beta1 (using KDE 3.5.4, Debian Package 4:3.5.4-1 (testing/unstable)) Compiler: Target: powerpc-linux-gnu OS: Linux (ppc) release 2.6.17 The new 0.9.0-beta1 (tested with up to svn 567816) may have an "endianess problem" under PowerPC with PNG images. I'll try a attach screenshots to illustrate this bug (well, if it's possible as it's my first use of KDE bug report system) based on the Debian logo (http://www.debian.org/logos/openlogo-nd-100.png). The generated thumbnails have wrong colors as shown in snapshot1.png. When viewing the image, Digikam seems to have the same problem described in Krita bugs #125944 and #127296 (although this bug affected Krita a zoom levels other than 100% and here the bug seems not to be related to the zoom level). The "alpha channel checker" is shown and the colors are wrong (or, as suggested in bug #125944, the blue channel is correctly displayed, but red and green are interpreted as alpha). The screenshot snapshot2.png shows the problem.
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