| Summary: | displays a black image instead of the expected 16-bit integer/channel PPM image | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Philippe Cloutier <chealer> |
| Component: | File formats | Assignee: | Cyrille Berger <cberger> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | arnaud-deb, cberger, halla, lemma, sven.langkamp |
| Priority: | NOR | Keywords: | triaged |
| Version: | 1.6.1 | ||
| Target Milestone: | --- | ||
| Platform: | Debian testing | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Philippe Cloutier
2007-02-14 18:21:21 UTC
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 |