After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 149723 - PGMs can have a maxval greater than 255
PGMs can have a maxval greater than 255
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: Plugins
2.0.x
Other All
: Normal enhancement
: 2.10
Assigned To: GIMP Bugs
GIMP Bugs
: 316823 524618 540350 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-08-09 13:06 UTC by Ari Pollak
Modified: 2017-02-21 08:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
source FIT file (294.25 KB, application/x-gzip)
2004-08-09 16:39 UTC, Ari Pollak
Details
resulting pgm file generated by imagemagick convert (293.94 KB, application/x-gzip)
2004-08-09 16:40 UTC, Ari Pollak
Details
PPM file demonstrating the same bug (265.38 KB, image/x-ppm)
2008-03-27 13:52 UTC, Jason Rumney
Details

Description Ari Pollak 2004-08-09 13:06:28 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.
Comment 1 Michael Natterer 2004-08-09 13:32:08 UTC
Indeed. Setting to enhancment and 2.2
Comment 2 weskaggs 2004-08-09 15:39:20 UTC
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.
Comment 3 Dave Neary 2004-08-09 15:52:46 UTC
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.
Comment 4 Ari Pollak 2004-08-09 16:39:20 UTC
Created attachment 30369 [details]
source FIT file
Comment 5 Ari Pollak 2004-08-09 16:40:07 UTC
Created attachment 30370 [details]
resulting pgm file generated by imagemagick convert
Comment 6 Ari Pollak 2004-08-09 16:40:27 UTC
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).
Comment 7 Sven Neumann 2004-08-09 16:57:37 UTC
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.
Comment 8 Dave Neary 2004-08-09 22:08:34 UTC
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.
Comment 9 Sven Neumann 2004-08-09 23:46:56 UTC
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 ...
Comment 10 Dave Neary 2004-08-10 08:15:23 UTC
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.
Comment 11 Sven Neumann 2004-09-16 18:28:33 UTC
Bumping this off the 2.2 milestone since obviously noone is working on it and it
shouldn't block the release.
Comment 12 Sven Neumann 2005-09-21 17:19:43 UTC
*** Bug 316823 has been marked as a duplicate of this bug. ***
Comment 13 Michael Schumacher 2008-03-27 12:10:54 UTC
*** Bug 524618 has been marked as a duplicate of this bug. ***
Comment 14 Jason Rumney 2008-03-27 13:47:22 UTC
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.
Comment 15 Jason Rumney 2008-03-27 13:52:49 UTC
Created attachment 108110 [details]
PPM file demonstrating the same bug

From link in bug 524618
Comment 16 Sven Neumann 2008-03-27 21:05:50 UTC
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.
Comment 17 Michael Schumacher 2008-06-26 19:37:39 UTC
*** Bug 540350 has been marked as a duplicate of this bug. ***
Comment 18 Michael Schumacher 2016-07-22 11:01:23 UTC
I guess this could be examined for 2.10.
Comment 19 Massimo 2016-07-22 11:49:02 UTC
(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
Comment 20 Michael Natterer 2016-07-22 21:29:03 UTC
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.