Menu

#237 Incorrect MAXVAL scaling when reading PAM images

v1.0_(example)
closed-fixed
None
5
2014-08-11
2013-06-13
Nick Bowler
No

When using gm display to view some netpbm PAM images, I noticed that the
rendered image was much darker than it is supposed to be. This appears to be
due to improper handling of the MAXVAL parameter in the format.

The image only displays correctly if MAXVAL is 255 or 65535; any other value
will produce an overly dark image. If an alpha channel is present, the image
will also be more transparent than it is supposed to be.

This can be reproduced by using the pamdepth application in netpbm on any
image to scale MAXVAL to, say, 64. For example, using one of the images from
the GraphicsMagick test suite:

% gm convert input_truecolor_70x46.miff test.pam
% gm display test.pam     <-- this works
% pamdepth 64 test.pam > test64.pam
% gm display test64.pam   <-- this image should look similar to the source
                              image, but ends up far too dark.

As a workaround, one can use the pamdepth tool to renormalize the image values
and load the resulting image with GraphicsMagick, or use netpbm's own conversion tools to save in another format.

A similar problem occurs for the PPM "raw" (binary) format. However, the
"plain" (ascii) formats work fine, and the image values are scaled correctly.
Continuing the above example:

% pamtopnm -plain test64.pam > test64.ppm
% gm display test64.ppm   <-- this works

Discussion

  • Bob Friesenhahn

    Bob Friesenhahn - 2013-08-10

    It seems that what you are expecting is for the values to be scaled up by the ratio of the maximum value representable by the number of storage bits per sample (8, 16 bits) and the specified maxval value.

    The PAM specification (and the PPM specification) does not describe maxval very well.

    I will figure out how to fix this.

     
  • Bob Friesenhahn

    Bob Friesenhahn - 2013-08-10
    • assigned_to: Bob Friesenhahn
     
  • Bob Friesenhahn

    Bob Friesenhahn - 2013-08-10

    An annoyance with this issue that since GraphicsMagick has no notion of a 'maxval' internally, the values need to be scaled and this scaling might result in a loss of value precision.

     
  • Bob Friesenhahn

    Bob Friesenhahn - 2013-08-25

    This is fixed by Mercurial changeset d72704492111

     
  • Bob Friesenhahn

    Bob Friesenhahn - 2013-08-25
    • status: open --> closed-fixed
     
  • Nick Bowler

    Nick Bowler - 2014-01-21

    OK, in the latest release this works now for images with TUPLTYPE RGB, but not for TUPLTYPE RGB_ALPHA. A depth 63 image with an alpha channel appears to be displayed fully transparent, regardless of the alpha values. In previous versions the images had all pixels more transparent than they should be, but not fully transparent.

    As before, using pamdepth 255 to renormalize the alpha values before processing with GraphicsMagick works wonders.

    Instrumenting the code in coders/pnm.c, for this image GetOpacitySample is returning values between 192 and 255. When multiplied by sample_scale (around 4 for this image) all these values become very large and clamped down to 255, which appears to mean fully transparent in GraphicsMagick. I believe something like the attached patch is still needed.

    The attached test images are: checker255.pam is the MAXVAL 255 source image, checker63.pam is the MAXVAL 63 image created from the source using pamdepth. The two images should be identical, but gm display shows only checker255.pam correctly, checker63.pam is displayed fully transparent.

     

    Last edit: Nick Bowler 2014-01-21
  • Bob Friesenhahn

    Bob Friesenhahn - 2014-01-22

    Sorry for not fixing this properly before and thanks for the proposed patch. The fix is now in Mercurial and will be in the next GM development snapshot.

     
  • Nick Bowler

    Nick Bowler - 2014-01-22

    And sorry for not testing it sooner :P

    Seems to be working now, thanks!

     

Log in to post a comment.