Version: 3.5.5 (using KDE KDE 3.5.5) Installed from: Debian testing/unstable Packages OS: Linux I noticed a strange behaviour while opening a 16-bit integer/channel Portable Pixmap Image, created and saved with krita. One possible way to reproduce this is to : - open krita and create a new Custom Document, - choose RGB 16-bit integer/channel for the color space and sRGB built-in (lcms internal) for the profile, - draw whatever you want, - save it as a Portable Pixmap Image (ppm), - close krita, - reopen with krita the file you have just saved, - you obtain a completely black image :-( Note that opening the same file with ImageMagick's 'display' displays the file correctly. (Originally reported by Arnaud Guiton as Debian #406203)
Ur, version is 1.6.1, sorry.
I can confirm, but the file I have created is also displayed black with {image|graphics}magick, btw, do you know wether debian uses graphicsmagick or imagemagick ?
Debian's krita package depends on libgraphicsmagick1. I could recognize the file when opened with showFoto. GIMP complained about "PNM: Invalid maximum value." "Opening '/home/chealer/Desktop/ktest.ppm' failed: Plug-In could not open image" Apparently Krita generates an invalid PPM, and not all programs are able to deal with that.
Hi ! I think it's ok if Gimp can't open it, because it's not supposed to work with 16-bit data. After reporting the bug on Debian BTS, I read the ppm specification (http://netpbm.sourceforge.net/doc/ppm.html) and did some more tests. I created a completely white 128x128 square in krita (in 16-bit mode) and saved it in a ppm file. As previously noted, the file opens correctly with my version of imagemagick but not with Krita or the Gimp. But, if I manually change the maximum color value the ppm header from 65535 (2^16-1) to 255 (2^8-1) with a hex editor, both Gimp AND Krita successfully open the file and display my white square. I also noticed that when I open the original white square (with the value 65535 in the header) with Krita, it shows "RGB (8-bit integer/channel)" in the status bar, instead of "RGB (16-bit integer/channel)". Maybe it's a clue that the bug does not come from the ppm generation but from the ppm opening/decoding ?
Ok, I may I found something If I understand correctly, krita use graphicsmagick to load the ppm file. The problem is that Debian's graphicsmagick is *not* compiled with 16-bit mode. I did the following tests (again with with 128x128 16-bit white square) : $ gm identify white.ppm white.ppm PNM 128x128+0+0 DirectClass 8-bit 96.0k 0.010u 0:01 $ gm display white.ppm --> display a black square. I then rebuilt graphicsmagick with the --with-quantum-depth=16 option. After that : $ gm identify white.ppm white.ppm PPM 128x128+0+0 DirectClass 16-bit 96.0k 0.000u 0:01 $ gm display white.ppm --> display a *white* square. I also tried top open it with krita, but it fails : $ krita white.ppm Magick: No decode delegate for this image format (). What do you guys think ?
I tried (also on debian) and my graphicsmagick is built without 16-bit support as well. Saving a file created as described in c#1 and reopening it in krita shows nothing but black (it also tells me that the file is 8-bit in the statusbar).
Yes, it seems that graphics magick silently convert to 8bits (it also do it when using it from the command line), but a least now I get the image.
We want to retire gm, and cyrille has put ppm for himself on the roadmap.
It is fixed in trunk, with the new ppm filter for 2.2.
do you want to backport the ppm filter to 2.1? If not, I think you can close this bug.
yes indeed fixed