Re: Resizing large TIF files

[mwah]

tiff 'convert' ... ImageMagick ... 1.5 seconds ... to a 1024x768 PNG. The originals are ... 40KB ... The PNG is truecolour and closer to 300KB ...

I'm not sure to have understood what you did and why it didn't work. These times and sizes are not what I got here.

For testing purpose, I screen-copied this PerlMonk web page with your question, pasted it into Photoshop, resized it to 2200x1600, converted it to bitmap and blurred it until it's monochrome tiff (lzw) had about 48KB. This file was named 'originalmono.tiff'

Now I started cygwin and issued a

$> for i in `seq -w 1 100`; do cp originalmono.tiff originalmono${i}.tiff; done

which gave me 100 of these 48K images (originalmono001.tiff etc). Next, a snippet using Imager (0.61, which is what I use most of the time) was written:

 use strict;
 use warnings;
 use Imager;
 
 my $fn='originalmono';
 my $img = Imager->new();
 my $tdiff = time();

 opendir my $dirh, '.' or die "Can't read: $!";
 while( my $name = readdir $dirh ) {
    if( $name =~ /^$fn\d+.+tiff$/ ) {
       $img->read(file=>$name) or die $img->errstr();
       #  *** qtype=>'preview' /  qtype=>'normal'
       my $omg = $img->scale(xpixels=>1024, ypixels=>768, type=>'min',
+ qtype=>'preview');
       #  *** file=>"$name.png" / file=>"$name.gif"
       $omg->write(file=>"$name.png") or die "Can't write: ", $img->er
+rstr;
    }
 }
 $tdiff = time() - $tdiff;
 closedir $dirh;
 print "$tdiff seconds\n"

In 'preview' scaling mode, the 100 png's are out after 21 sec (.png size: 21K), in 'normal' scaling mode (which is: "quality mode"), the 100 files are done after 98sec (.png size 48K). If you change the output format to 'gif', the 100 gifs ('normal mode') take about 100 sec, each .gif-File is 33K. BTW: This is an Athlon64/3200 under Win-XP. I re-checked the run times under Linux/vmware, they differ only by a second or two.

Regards

mwa

[tonyc]

If his original TIFF images are fax compressed it may takes a bit longer to uncompress them than to decompress LZW, which might explain some of the performance difference. I know libtiff's group 3 compression code was fairly slow way back when I dealt regularly with fax.

You might want to try mixing scaling mode for decent performance, and I'd expect decent quality for scaling monochrome images too (Imager 0.54 +).

[grantm]

Ah OK it looks like I'm using a fairly old version of Imager which doesn't support mixing mode - an upgrade is obviously in order.

By the way Tony, thanks a lot for all the work you've put into Imager it really is an excellent module which I've put to good use on a number of projects.

[grantm]

I'm not sure to have understood what you did and why it didn't work. These times and sizes are not what I got here.

Actually, your results are entirely consistent with mine. The problem is that your code uses 'preview' quality rather than the default 'normal' or high quality scaling. If I use 'preview' quality I also can resize an image in about 0.3 seconds.

The images I'm working with are scans of paper forms. Some of the resulting image is the text and lines printed on the form and the rest (the more interesting bit) is the handwritten text that someone wrote. In the original files, lines are 1-2 pixels thick - say 1.5 pixels thick on average. If I resize the images in 'preview' mode, the resulting files use 1bit depth so the file size is good but the image quality is poor - sections of lines and letters disappear altogether and legibility is significantly reduced. However if I use 'normal' quality, there is barely any degradation in legibility. The resulting files essentially end up anti-aliased which necessarily uses more shades of gray so the file size increases. Obviously the extra quality also comes at a significant CPU cost (about a factor of 10 over preview quality).

So the bit that I obviously failed to make clear was that I'm not trying to produce thumbnails or previews. I want to reduce the images so that they display on screen at about the same size as the physical form and retain sufficient legibility that users never need to refer to the full size originals. The originals appear too big and 'zoomed' for practical purposes. All the resizing techniques that I've tried do meet these legibility requirements (with the exception of Imager's preview mode). I've also determined that reducing from 24bit RGB to 8 colour (3 bit) indexed colour barely affects legibility at all. 2 bit colour is border line (might be OK if I could preselect the palette) and 1 bit colour is not good enough. It's the processing overhead and file bloat that I'm keen to reduce if possible.

Thanks for taking the time to try it out and reply.

[dk]

So the bit that I obviously failed to make clear was that I'm not trying to produce thumbnails or previews

Yes you didn't - and that changes the problem entirely. There are a number of pixel-interpolating algorithms, and the fastest is "nearest neighbor", or Imager::preview in your terms. A good visual balance for image downscaling is usually produced by the bicubic algorithm, but Image::Magick has also qw(Quadratic Triangle Hermite Hanning Hamming Blackman Gaussian Catrom Mitchell Lanczos Bessel Sinc) (at least those I know), and you might want to try which works best for you.