-trim only trims horizontally when density is odd

[zardoz]

I have noticed that running…

Code: Select all

convert -density $dens file.pdf -trim output.png

…will only crop the image horizontally when the value of dens is odd. When an even value is used, the image in cropped along both axes.

E.g., running these commands on this PDF document yields density 105; trimmed only horizontally and density 106; trimmed along both axes. It seems this contrast can be observed for any even vs. odd DPI setting.

I see this behavior when running ImageMagick 6.9.8.3.

[magick]

Add -fuzz 5% -trim to your command-line. Does that help?

[zardoz]

Add -fuzz 5% -trim to your command-line. Does that help?

It does help, but it will take at least 47% of fuzz to make a difference in the given case. Is this expected? I’m surprised by this since the underlying PDF is the same in both cases, and setting density to even values never requires any fuzz (which is expected since the input background is completely uniform). This is for an automatic usecase, so ideally no fuzz should be needed when the background is uniform.

Does using odd DPI values introduce any noise that would explain this behavior?

[fmw42]

I have no problem using -fuzz 1% with -density 300. The density should have no bearing on the trim. I am using IM 6.9.8.3 Q16 Mac OSX. Perhaps it has to do with your version of Ghostscript. I am using GS 9.19

Code: Select all

convert -density 300 6gWB.pdf -fuzz 1% -trim +repage tmp.png

This works just fine for me. Be sure to add +repage after the trim

[zardoz]

I have no problem using -fuzz 1% with -density 300. The density should have no bearing on the trim. I am using IM 6.9.8.3 Q16 Mac OSX. Perhaps it has to do with your version of Ghostscript. I am using GS 9.19

As indicated in the description, the density does seem to have a (erroneous?) bearing on the trim for some reason. Density 300, 302, etc. works for me too, but when using 299, 301, 303, the image will only be trimmed horizontally. As for GS, I’m using v. 9.21.

[fmw42]

I can now confirm that the odd density does cause a problem. This fails for me, also. IM 6.9.8.3 Q16. Also IM 7.0.5-4 Q16 (GS 9.19)

Code: Select all

convert -density 301 6gWB.pdf -fuzz 1% -trim +repage tmp.png

Code: Select all

im7 magick -density 301 6gWB.pdf -fuzz 1% -trim +repage tmp.png

It also fails if saved to TIF or JPG.

[snibgo]

Resterizing a PDF at different densities will create a different size image, so could make a slight but important difference that could prevent a trim. But that doesn't seem to be happening here.

For any image, a second trim should have no effect. But it does here:

Code: Select all

convert -density 105 6gWB.pdf +write info: -trim +repage +write info: -trim +repage info:

6gWB.pdf PDF 893x1155 893x1155+0+0 16-bit sRGB 0.125u 0:00.125
6gWB.pdf PDF 807x1155 16-bit sRGB 0.234u 0:00.125
6gWB.pdf PDF 139x11 16-bit sRGB 0.000u 0:00.000

The first trim removes the left margin. The second trim then removes the rest. I don't know why this is. Perhaps a bug?

Tested with IM 6.9.5-3 and Ghostscript 9.19.