•Re: IMAGE MAGIK / GIMP/ IMAGES

{Arggghh, not this again!!!}

An image doesn't have a resolution. An image has pixels. A rendering engine will take those pixels, and put them into print-pixels at a particular resolution.

There's no such thing as a "72-DPI image". The DPI makes sense only when the bits from that image are finally rendered.

If you want a 3inch-square image on screen, generate 200-ish pixels in each dimension. If you want a 3-inch-square image when printed at 300dpi, then generate 900x900 pixels. Just do the math. It's not the responsibility of any of the graphics packages to do the math for you.

And dare I say again, "computer images do not have a DPI". Sigh.

-- Randal L. Schwartz, Perl hacker

Comment on •Re: IMAGE MAGIK / GIMP/ IMAGES

Replies are listed 'Best First'.
Re: •Re: IMAGE MAGIK / GIMP/ IMAGES by thpfft (Chaplain) on May 18, 2002 at 19:48 UTC
that's true up to a point - the image itself has as many dots as it has - but a computer image file does tend to have a resolution, among other bits of metadata. It doesn't make any difference to browser display, or to the image data itself, but it makes a large and sometimes costly difference to the way the image appears as soon as it is printed or converted. In a print context there's no necessary coupling between size of image and number of pixels, and getting the best out of lines and screens and resolutions is a black and dying art. it sounds like the destination for Angel's pictures is a setting that cares about image resolution and does not wish to open and redescribe every image so that it prints correctly. but the answer is simple: you can set the resolution with perlmagick using the `density` attribute. i've just run a quick test using: `#!/usr/bin/perl use Image::Magick; my $image=Image::Magick->new; $image->Read(filename => 'amnesty.jpg'); $image->Set( density => '288x288' ); $image->Write( filename => 'test/test.jpg' ); $image->Write( filename => 'test/test.tiff' ); $image->Write( filename => 'test/test.gif' ); $image->Write( filename => 'test/test.png' ); undef @$image;` [download] and the resolution seems to be updated correctly in every case except the gif, which would figure. the resulting images can be pulled straight into quark and work as expected, but there is trouble with photoshop, which has its own embraced-and-extended notion of where metadata should be stored and seems to ignore the imagemagick profile. more about that on the mailing list.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: •Re: IMAGE MAGIK / GIMP/ IMAGES
by thpfft (Chaplain) on May 18, 2002 at 19:48 UTC

that's true up to a point - the image itself has as many dots as it has - but a computer image file does tend to have a resolution, among other bits of metadata. It doesn't make any difference to browser display, or to the image data itself, but it makes a large and sometimes costly difference to the way the image appears as soon as it is printed or converted. In a print context there's no necessary coupling between size of image and number of pixels, and getting the best out of lines and screens and resolutions is a black and dying art.

it sounds like the destination for Angel's pictures is a setting that cares about image resolution and does not wish to open and redescribe every image so that it prints correctly.

but the answer is simple: you can set the resolution with perlmagick using the density attribute. i've just run a quick test using:

#!/usr/bin/perl

use Image::Magick;
my $image=Image::Magick->new;
$image->Read(filename => 'amnesty.jpg');
$image->Set( density => '288x288' );
$image->Write( filename => 'test/test.jpg' );
$image->Write( filename => 'test/test.tiff' );
$image->Write( filename => 'test/test.gif' );
$image->Write( filename => 'test/test.png' );
undef @$image;
[download]

and the resolution seems to be updated correctly in every case except the gif, which would figure.

the resulting images can be pulled straight into quark and work as expected, but there is trouble with photoshop, which has its own embraced-and-extended notion of where metadata should be stored and seems to ignore the imagemagick profile. more about that on the mailing list.

[reply]
[d/l]
[select]