Running this gives the geometry but not the density:

$ identify -verbose myfile.pgm | grep -iE 'geometry|pixel|dens|size|dimen|inch|unit'

There is also a “Pixels per second” attribute which means nothing to me. No density and not even a canvas/page dimension (which would make it possible to compute the density). The “Units” attribute on my source images are “undefined”.

Suggestions?

  • @Zachariah
    4•2 months ago

    If I’m not mistaken, ImageMagick doesn’t know the canvas size or printer you’ll be using. It only knows the height and width in pixels.

    The pgm format doesn’t seem to have an attribute for ppi https://netpbm.sourceforge.net/doc/pgm.html

    • @[email protected]OP
      2•2 months ago

      That was my intuition but then consider this bug in unpaper:

      https://github.com/unpaper/unpaper/issues/230

      I have a script that runs unpaper on PGM files. When the DPI is 600, that bug in unpaper is triggered, but no problem if the source is 300dpi. So it means there is a difference. Although I suppose it’s possible that it’s not really DPI that causes unpaper to produce a truncated image; it could come down to sheer number of pixels. Guess I could work that out by testing further with smaller source scans.

      The reason for my question is that I’d like to write my script to work around that bug. If a source file has more than 300 dpi, I would use ImageMagick instead of unpaper to do the bileveling.

      (update)
      I cropped a 600dpi image in half using GIMP. Then fed that into unpaper. The bug was not triggered and the full canvas was processed correctly. So I think you are right… DPI is not a concept on PGM files. Which implies unpaper’s bug is simply a limitation on the number of pixels it can handle. It’s apparently incidental that scanning a full size page at 600 dpi results in more pixels than unpaper can handle.

      • @Zachariah
        2•2 months ago

        Yeah, I’d guess it’s the number of pixels (or number of bytes) triggering the bug, but it’s being communicated to the user as dpi.

        dpi is (usually) really a function of the graphics program, and images can be scaled/shown/printed at different (with limitations) dpi regardless of pixel dimensions. Usually, dpi dictates the native size of the image in the real world (on the monitor or on paper), or can affect the clarity of the image if the resolution of the image doesn’t match the resolution of the display. It’s not exactly the size of the image—but it’s often closely related.