Legacy ImageMagick Discussions Archive

I work on scanned images that are bitonal (1 bit per pixel), I'd like to use ImageMagic to render SVG files to PBM format at the same DPI as the real scanner, and specify the document layout in SVG in units of inches (using the printing instructions), and also in the future it is likely that we will have multiple different scanners at multiple resolutions.

So I have an SVG image input.svg: The real scanner has a DPI of 200x200. It would seem that the obvious command to do is: .

I think this should generate a 1728x3800 image. However, using both identify and gimp to figure out the size, it generates a "4800x10555" image.

This generates: Generates the image with the proper resolution, but embeds the wrong DPI, so when looking at it in GIMP only the pixel units are correct, all of the image units are completely wrong. Using -units doesn't help. Generating using numerous linear density values does not end up with numerous linear DPI values. Any help would be much appreciated. When running the convert command without a DPI, it correctly generates a 72DPI image.

I am using an x86_64 binary, installed from CentOS 5.2 install, version ImageMagick-6.2.8.0-4.el5_1.1.src.rpm.

identify --version
Version: ImageMagick 6.2.8 04/17/08 Q16 file:/usr/share/ImageMagick-6.2.8/doc/index.html
Copyright: Copyright (C) 1999-2006 ImageMagick Studio LLC

Thanks in Advance for any help,
Kirby

I have no idea what is going wrong with your SVG image. You are right that 200 dpi should produce an image the size you wanted.

First are you sure the 200dpi is not correct? The size of the image may be wrong, but maybe the figure inside that image is correct, and only the canvas size is wrong. Double check the pixel size of the drawn rectangle, not the canvas image itself.

Second if 120dpi is correct (both size and content), then you can reset the density for the output image using a -set density 200 AFTER reading the SVG image (and IM has rasterized it into memory), before saving it.

I haven't done as you've suggested as the problem is on my work machine, and I'm at home. I will try that first thing when I get in tomorrow. I know I've tried moving the density, it was among the first things I tried. That uses the default 72DPI, and no matter what density you use will return the same image size. I'm reasonable sure that the box is the correct pixels at -density 120, and wrong elsewhere, but I didn't actually do the math.

However at home on my Mac OS 10.4 using Fink (and a really out of date version):

convert -version
Version: ImageMagick 6.1.8 03/22/06 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2005 ImageMagick Studio LLC
The image comes within a pixel of what I expect (I can just post process it and add the pixel if need be):
tmp.jpg [1727x3800]

Any chance, somebody can run the command on their platforms and post the output of: ?

When I get into work, I'll try removing the x86_64 version I have and run the i386, and potentially try building the HEAD from version control and see how things behave.

The actual image is going to be quite a bit more complex, but I was planning on generating the complete SVG image after I had the toolchain figured out. I'm just working on getting the toolchain going. I just took the inkscape output and hacked it down to a relatively minimal set.

computerslicer23 wrote:I know I've tried moving the density, it was among the first things I tried.

I didn't suggest MOVE the density, I suggested changing the density AFTER reading it. That is...

Adding '-set density 200' as you suggest above does convince GIMP that the image is 200DPI. It still concerns me that I'll be bit when this issue is "fixed". The fact is confusing and counter to the documentation concerns me that at some future point the -density command will be fixed, and my scripts will break (either by me upgrading my platform and a supporting library, or ImageMagick itself has the problem and is fixed).

The conversion factor appears to make the black mark wide enough in pixels. I have double checked, using CentOS 5.2 x86_64 and building the source from 6.4.2-4 from the ImageMagick site does not fix the problem (I installed it into ~/local, not sure if not installing it into /usr or /usr/local would be a problem, ~/local/bin is in the path first).

Using 32-bit CentOS 5.2, I have the same problem with the pre-built binaries, and with the 6.4.2-4 source build also.

We also use LFS, but I have not had time to build all of the required dependencies to try it on there.

Kirby

I've observed the same behavior (6.3.7 02/19/08 Q16 on Ubuntu), but wasn't sure if it was me or a bug. For what it's worth, I came up with the following relation: the DPI to specify on the command line is

specifiedDPI = 72 * SQRT( desiredDPI / 72 )

In my case desired was 360 and specified was 161, but it also works for 200 and 120, so it's probably the same issue.

It is a bug, and should be reported on the bugs forum so that it can get fixed.

For scripts, as soon as you know the version number of IM that has this fixed, you can add a version number test so that the script will work for both old and new IM's.

Many of the script developers do this providing the 'alturnative' (usally slower or not as good) techniques when the IM the script is using is too old. See http://www.imagemagick.org/Usage/api/#version for an example of this for getting the list of fonts IM has been told about .