Tiff file compression
(aka Imaging for Windows sucks)
   
 
Oct 9, 2003
 
It was almost noon and I was doing a routine email check before I went off for lunch. Within those 50+ spam mails, I got a case study paper in SealedMedia (spdf) format. I am (together with my team members) supposed to study that paper and hand in a report a few weeks later for one of my part-time degree courses. Since that file would expire after a month, I thought it would be a good idea to back it up into another format while I can still open it. I used an exporter to generate a tiff file from the spdf. But unfortunately the export program can't write compressed tiff file. And that 321KB spdf file became a 64MB tiff file at 200dpi with 8bpp (and a whopping 433MB if I use 300dpi with 24bpp).

No big deal. I can just use another utility to convert it into compressed tiff. So I thought.

 
Imaging for Windows
The first converter came into my mind was Imaging for Windows (also known as Wang Image Viewer in Windows 95). I never used it before but I believe it could do the job. After loaded the tiff file successfully (btw, don't use drag-and-drop with Imaging... it crashes the program...), I immediately selected the Save As command under the File menu. Hoping that I can choose to save the file in compressed format.

No luck here.

OK. Fine. Do a little exploration on the menu. It turns out that there is indeed a compression option under the Page/Properties popup. But it is in page level! That means I need to navigate all 18 pages in the file and select the compression option for each page! I mean, why on earth would someone want to use different compression methods on different pages in a single tiff file? Even so, couldn't the program designers provide an option to apply the same compression method to the whole file?

Enough complain. I still need that compressed tiff file. So I do the selection for all 18 pages (and waited for each page to compress before I can move on to next page). Since I don't want to overwrite the original tiff file, I then choose the Save As command to save the compressed tiff file in another name. The hard disk started crunching and busy writing the output file. I waited a whole minute and the writing is still going on. I fired up the Explorer to check what was going on. It turns out that Imaging writes the file in a strange and inefficient way. It seems to be writing a page out to a temp file. Append the next page to that temp file. Copy and overwrite the output file with that temp file. Then append the next page...... until the whole file complete.

OK. I can understand that there might be users out there who need different compression methods within a tiff file. But why does Imaging writes file in this #@$#%$^$@ way?!! Anyway, after several minutes of hard disk crunching, I finally got my compressed file. Done. Time to have lunch... but wait! @##%^@$!#$$!!!! Why the files size is still over 60MB??? I selected the LZW compression and I am expecting more compression than THAT!

I fired up IrfanView to check the output file. It turns out that only the last page was compressed! I switched back to the Imaging program and check. Only the last page, the page that was displayed before I hit Save As, is selected with compression. All other pages are now switched back as No Compression. @#%^#!^!!!!

At this point, I can conclude that this Imaging program sucks and I better off use either ImageMagick or tiffcp to do the job. While waiting for my poor AMD K6 200 (o/c 225) doing the compression under FreeBSD, the programmer inside me started to wonder whether the Imaging problem is simply a programming bug in the UI... So I made a copy of the original uncompressed tiff file. Loaded it into Imaging again. Repeated 18 times to select the comperssion method for each page. Then I used the Save instead of Save As command to write the output file. And bingo! The output file is under 2MB and all pages are compressed correctly

The moral here? Use the good old Unix command line programs whenever you can. Anyway, time for lunch.

 
The ActiveX approach
During the lunch, I kept thinking about that the slow file saving and the compression bug in Imaging. Maybe the ActiveX component of Imaging can do a better job. And maybe I should write a simple program with that ActiveX and avoid the Imaging UI hereafter. So after the lunch, I fired up the VB studio and started to explore the ActiveX component of Imaging.

And guess what I found? It seems that the "select compression per page" feature is built right into the ActiveX and not a UI design problem! Both the CompressionType and CompressionInfo properties of the Kodak Image Edit Control are read only. The only way to set compression is to use the SaveAs command!

And the biggest problem is that only the currently displayed page will be saved with the selected compression! Other pages are saved with no compression (the default). No wonder that the Save As command in Imaging has that "bug"! So I guess the only way to compress all pages is to compress and save each page separately and combine them later. That might explain the strange temp files generated by Imaging during writing files.

How can a designer expect someone to reuse such an ActiveX?

 
Conclusion
Imaging sucks.

BTW, there is an Easter Egg in Imaging. Select About Imaging under the Help menu. Press i on your keyboard. There will be a popup window showing a staff list.

 

All text and images at this website are copyright © 2002,2003 Clarence Ho. All rights reserved.