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.
Agreed.
As a kid I recall stepping on one and thick white milk squirted out. Another kid said “just like a Jr. mint!” Ever since then, I have been unable to mentally separate Jr. mints from cockroaches. And to be clear, that association was not an upgrade for the roaches.. it was a mental downgrade to Jr. mints.