GNOME Bugzilla – Bug 149723
PGMs can have a maxval greater than 255
Last modified: 2017-02-21 08:31:26 UTC
From Debian bug report http://bugs.debian.org/264487 : In pgm.c, some pgm files are incorrectly rejected. Namely, those binary pgm's with maxval>256: CHECK_FOR_ERROR(((pnminfo->maxval<=0) || (pnminfo->maxval>255 && !pnminfo->asciibody)), pnminfo->jmpbuf, But binary pgms are allowed to have a maxval up to 65535. See pgm(5). ---- I don't actually have any pgms lying around, but a quick glance at pnm.c shows that this hasn't change as of GIMP 2.0.4.
Indeed. Setting to enhancment and 2.2
Actually it is correct for the code to reject them, because it is not capable of reading them. But you are certainly right that this would be desireable.
Can you attach a couple of PGMs with maxval > 255, please? We should probably truncate higher-order values, rather than reject them outright (by which I mean, if maxval = 511, we sould read 9 bits per pixel, and discard the low-order bit) Dave.
Created attachment 30369 [details] source FIT file
Created attachment 30370 [details] resulting pgm file generated by imagemagick convert
From bug reporter: The .FIT is the source file, I then used imagemagick's `convert` to make the pgm. (I tried netpbm fitstopnm first, but it didn't work .. I'll bug them too). By the way, the bug indicates that the lower bits "should be truncated"; this is wrong (from an astronomer's POV). Like I said, in astronomy, its all about dynamic range. If the lower bits (of pgm, or fits, whose gimp plugin I haven't checked) get truncated, then gimp is unusable for astronomy. Low bits should get read in, and mapped somehow to the 255 greyscale they computer can display. And I should be able to change that mapping (ie curves feature, histogram, etc.). If there's an interesting feature that I want to see, and its brightness lies between 255 and 512, truncating the low order bits will mean that my feature now has, at best, 1 bit of remaining detail. See the ds9 image viewer, maybe; it'll let me change the brightness and contrast to all for arbitrary mappings (in this case, what I likely want is for those 255 values to be mapped linearly onto 0->255. Log scale is also useful).
GIMP does only support 8bit per color channel (at least now and for the short term future) so we don't have a choice but truncating the lower bits on load.
That's not inconsistent with what's being said here, though. What the reporter is asking for, more or less, is to be able to apply levels & curves on the raw data to map them into the available 255 slots as he wishes. If that means squeezing 16 bits into 8, then so be it. But that might mean selecting 255 levels in the middle of the dynamic range. It's more or less the same functionality which is present in the dcraw plug-in. Dave.
Yes, and IMHO it's too much functionality for a plug-in. What the dcraw plug-in is doing is good but this functionality needs to be provided by GIMP, not duplicated in lots of plug-ins. We could consider to move some LUT code to libgimpbase and add a GUI with preview to libgimpui. All plug-ins that need to import higher color depths than GIMP can handle could then use this to offer a consistent way of importing the data. Or we could simply focus on GEGL ...
We should definitely focus on GEGL, but at least people know what's available if they feel like doing this in their own time in the meantime.
Bumping this off the 2.2 milestone since obviously noone is working on it and it shouldn't block the release.
*** Bug 316823 has been marked as a duplicate of this bug. ***
*** Bug 524618 has been marked as a duplicate of this bug. ***
I suggest that if this bug is not able to be fixed quickly, the error message should be changed from "Invalid maximum value" to "Unsupported maximum value", at least for maximum values between 256 and 65535. The current message misleads the user into blaming the tools that created the PGM/PPM file, where the problem is actually a limitation of GIMP.
Created attachment 108110 [details] PPM file demonstrating the same bug From link in bug 524618
Good idea: 2008-03-27 Sven Neumann <sven@gimp.org> * plug-ins/common/pnm.c (load_image): changed message to say "Unsupported maximum value" instead of "Invalid maximum value" as suggested in bug #149723.
*** Bug 540350 has been marked as a duplicate of this bug. ***
I guess this could be examined for 2.10.
(In reply to Michael Schumacher from comment #18) > I guess this could be examined for 2.10. Probably this could have been closed after: https://git.gnome.org/browse/gimp/commit/plug-ins/common/file-pnm.c?id=647f0ada2af7b91c7b5110b46a0230cd3f79f112
Indeed, thanks. commit 647f0ada2af7b91c7b5110b46a0230cd3f79f112 Author: Mukund Sivaraman <muks@banu.com> Date: Sat Mar 26 15:09:59 2011 +0530 Add support for reading 16-bit raw PPM files This should be useful for loading the output of programs such as dcraw.