I'm doing some work in Motion with PS-created tifs. Should I be using LZW compression or not? Would it speed up or slow down my work in Motion? Obviously filesize would decrease, but would there be an extra load on the computer reading/decompressing the file within motion?

your thoughts, please.



Edited 1 time(s). Last edit at 06/26/2007 12:11PM by clay.

LZW is only going to work well if your images have a fair amount of common color, such as a lot of white space, or blocks of the same color. For photos you're not going to see much benefit size-wise.

While I don't have a specific answer for your situation, there are some things about LZW compression that you should understand to know when it's appropriate just from a file size point of view.

LZW compression works by compressing repeated sequences of bytes within a file (and they usually need to be relatively near eachother). This works really well with ascii text because words tend to repeat.

For graphics LZW might not be appropriate, a scanned photo will not compress, and may even get larger (and slower). The types of things that may compress well are computer generated graphics on a solid color background.

You should try a few experiments with your real-world data just to look at file sizes with/without LZW compression.

thanks for the info. The tifs I'm working with right now are computer generated graphics--really just a couple of big geometric shapes comprised of solid colors. So sounds like LZW might be a good fit in this instance.

I'll have to give it a try and see how it goes.

> For graphics LZW might not be appropriate, a scanned photo will not compress, and may even get larger (and slower).

Not true. In the hundreds of thousands of lzw tif files that I have worked with over the years, I have never seen an image get larger due to lzw compression. An image *might* not get significantly smaller using lzw compression, but in all likelihood it will.

In fact, given the growing dimensions of digital photographs, I've seen lzw compression rates increase significantly over the years as the growing amount of image data increases the likelihood of repetitive strings within the file.

You may be thinking of another compression technique -- perhaps Stuffit compression. When various compression programs lack the appropriate compression algorithm to deal with a particular kind of file they often generate larger output files than the original file alone would account for. Stuffit, in particular, is notable for doing that with audio files and some kinds of graphics.

Also, any slowdown due to using lzw vs uncompressed tif images is probably undetectable on any Mac made in this century.

OTOH, it did add almost a second's delay when I opened such images in Studio/8 on my Mac II, so I recommend that you do some testing to see which method is most efficient if your primary Mac is more than 20 years old. ;)

With today's giant drives, I'd advise avoiding LZW compression like the plague. It can cause serious problems at the press stage, for instance, and who knows what else? I barely avoided a disaster on a print job a couple of years ago, saved by a sharp-eyed customer rep.

Uncompressed is the the way to go, Baby!



Edited 1 time(s). Last edit at 06/26/2007 06:53PM by MysteryGuest.

Quote
MacMagus
> For graphics LZW might not be appropriate, a scanned photo will not compress, and may even get larger (and slower).

Not true. In the hundreds of thousands of lzw tif files that I have worked with over the years, I have never seen an image get larger due to lzw compression. An image *might* not get significantly smaller using lzw compression, but in all likelihood it will.

Well, maybe you haven't seen these, but I have, with tiffs that were scanned photos in very high resolution with 16 bits per sample. With that kind of resolution, you really don't get repeated strings of 8 bit bytes that LZW needs to be effective. Besides being larger, they were a very slow.

LZW is a lossless compression algorithm, and it can't do nearly as well as something like JPEG where you can trade off quality for size.

All lossless compression algorithms have cases where the output might be larger than the input. If there was always a guarantee that a compression pass will get smaller, then you would be able to do multiple passes and get an infinite amount of data down to zero bits. Take a look at section 9.1 of the compression FAQ.

[www.faqs.org]

"It is mathematically impossible to create a program compressing without loss
*all* files by at least one bit (see below and also item 73 in part 2 of this
FAQ). Yet from time to time some people claim to have invented a new algorithm
for doing so. Such algorithms are claimed to compress random data and to be
applicable recursively, that is, applying the compressor to the compressed
output of the previous run, possibly multiple times. Fantastic compression
ratios of over 100:1 on random data are claimed to be actually obtained."

> Well, maybe you haven't seen these, but I have

If you have a full-color tiff image file that's of greater dimensions than 32x32 pixels and has a greater file size with lzw compression than an otherwise identical source file then in all likelihood, you've also done something extra to it like reducing the color palette, saving icons or thumbnails with the image or saving it with layers or adding comments.

Where I suspect you've seen larger files with lzw compression is in GIF images, not tiff's. Due to the limited color palette, it's much more likely that you'd have the result you're going on about with a GIF than a tiff. While you could make a tiff file with the same limitations as such a GIF file, that's usually kind of stupid.


> With today's giant drives, I'd advise avoiding LZW compression like the plague. It can
> cause serious problems at the press stage, for instance...

That's BS. Are you living in the 1980's? Name a SPECIFIC and CURRENT problem related to the output of lzw tiff images.

I'll give you a few examples of specific problems: I once had a RIP that choked on output from PageMaker containing both lzw tiff images and postscript images with compressed tiff previews... in 1991. Here's another example: Seven years ago, I had a client whose plotter choked on lzw tiff images with embedded postscript... it turned out that the PC paint program that he was using to create the tiff images was also embedding illegal characters in the eps, so I guess we can't blame that on lzw. Nothing much since then. How about you?

I'm in the business. I haven't heard of a problem related to lzw-tiff images since the early 1990's. Even arcane PC tiff files with wacky program-specific tags have become a near mythological monster of the past.

Maybe you're thinking of compression in PDF documents. Now THAT's a headache... well... that WAS a headache. About 5 years ago. Now that I think of it, it's been awhile since I had a problem with compression in a PDF document, too. Most pdf problems I encounter relate to incompatible features from different versions of Acrobat or (growing rarer these days) font conflicts... but let's leave that discussion for another thread.

I've been using LZW compression with TIFFs for a while and I've never seen one get larger than the original. Just to test it, I took a RAW image and converted it to uncompressed TIFF and I then saved the image. I then took the image and re-named it and saved it as a LZW compressed TIFF. The uncompressed file was a little larger than 29 mb and the compressed TIFF was a little larger than 17 mb.

Michael

I haven't used an LZW compressed TIFF since about 1985.

I remember them taking significantly longer to open (like by a factor of 3).

I'd rather take up the extra disk space now a days that take longer to open.

---