RT presents a checkbox that allows choosing to create uncompressed .tiff files. In that, RT appears to default to making compressed files. However, it is my understanding that the .tiff specification supports several compression types. I’ve done a bit of experimenting and (based on metadata) it looks like RT chooses different compression types from time to time. So far I’ve found compression coded as either “deflate” or “LZW”. A bit of research causes me to think that “deflate” is itself an imprecise term. Apparently there is an Adobe version and a ZIP (sometimes called PKZip) version. While they may be similar there must be some difference.
I suppose it is possible that I shouldn’t care but generally speaking I like to be able to predict the type of file that I’m producing. While making the file smaller is the reason for using compression, I’m more concerned about compatibility. Possibly even to the point of using uncompressed files. In that, I want to be able to produce a file that can be distributed to unknown parties and they will be able to process it. While I have more to learn before weighing in on what kind of compression has the best, or for that matter even desirable, compatibility the idea that I cannot control such is troubling.
Is it possible to control the type of compression used when producing .tiff files?
To my understanding these two types of compression are mainstream when it comes to TIFF. Have you experience any incompatibilities? If so, how so?
There are no specific cases of incompatibility that are known to me. However, one reason the target audience is unknown is that I’m trying to create pictures that can last well into the future and don’t require any technical savvy in order to process them.
My thinking is that any user of RT would want to have control over the type of file being produced. My guess is that absence of other complaints is attributable to lack of knowledge. A possible solution, but not very desirable, is to have RT produce uncompressed files and then use other software to perform the compression.
Also, something I failed to mention is that RT seems to crash predictably when I create such files. This is also not comforting and suggests some lack of stability on the part of RT. However, the crash appears to happen subsequent to creation of the files and the files that get produced can be subsequently input to both RT and a few other viewers that I use.
My computers are 32bit which seems to have left me stuck with RT5.0.
I’m not sure that future proofing digital files should be that much of a concern-- thinking along those lines, you’d choose the simplest format, probably one without compression, and also a format that has multiple Free Software libraries that can read the files.
Keeping the files uncorrupted or not otherwise lost is probably more difficult than choosing a file type.
That being said, deflat and LZW are both extremely common and have been for some time. I wouldn’t worry about saving files with those compression algorithms.
If you’re really concerned, print the files, print a lot of them, print them on archival material, and store them archivally in geographically places.
Using an open-source TIFF library as RawTherapee does ensures that.
An unfortunate reality when using unsupported software on obsolete hardware.
Some further experimenting makes it look like “Deflate” is the prevailing option. However, I do have one that I made yesterday which says “LZW”. I haven’t been able to reproduce that result today. If the “LZW” result is attributed to anything I did I haven’t figured out the cause.
Also, it looks like the error I mentioned is pretty consistent when producing .tiff files. An error message is consistently produced which says “filename cannot open”. Today RT did not crash but it looks like the error may occur when the file browser detects the presence of the file and possibly tries opening it while it is still opened for output. Those files don’t appear in the file browser until RT is restarted.
@ajax I don’t know how much you would like to know about zip and lzw; but if you type “zip lzw” into your favorite search engine, very likely one of the top links will point to https://havecamerawilltravel.com/photographer/tiff-image-compression/. It has been a top hit since it was originally published.
@afre - that is a very helpful article you linked to. I had noticed just a couple days ago that using LZW compression produced a tiff file that was larger than the uncompressed file, and then promptly until your linked article reminded me.
GIMP-2.9 offers LZW, Pack Bits, Deflate, and Jpeg (whatever that might be - does it just output a jpeg?). Is “Deflate” the same as “Zip”? What is Pack Bits?
Hmm, my apologies! I forgot how to use the internet!
Anyway, apparently deflate is a form of ZIP compression: https://en.wikipedia.org/wiki/Zip_(file_format)
Which brings us right back to the original question: Are all the various possible Zip compression algorithms well-supported? I’ve had considerable trouble over the years with Software A not being able to read tiff files compressed by Software B, though I don’t have any current examples to provide, and don’t have any clue what compression algorithm was used by the various “Software A’s”.
This is not an exhaustive list of the compression schemes available: https://en.wikipedia.org/wiki/TIFF#TIFF_Compression_Tag. The key column to take note of is Specification. Usage and support may not necessarily be representative of actual usage stats; they come from user surveys.
Maybe? I don’t use it because it is lossy. Well, there is a lossless version but compatibility is practically nonexistent.
Just to be clear I had found and reviewed both
https://havecamerawilltravel.com/photographer/tiff-image-compression/ and https://en.wikipedia.org/wiki/TIFF#TIFF_Compression_Tag prior to making the original post.
Based on discussion herein along with my own thoughts I’d say that producing compressed files with RT is fine so long as you know what software is going to be used to process the resulting files. In that, it’s fine for intermediate files where you might like to preserve the ability for further editing with RT or even other software such as GIMP which is known to support the compression. However, I don’t plan to compress files intended for distribution to parties using unknown software.
Given the complexity of .tiff compression revealed herein one would think that RT should at least be specific about revealing its’ choice for compression. From a bit more experimentation it appears to me, based on how other software interprets the metadata produced by RT, that RT is using the Adobe Deflate method which appears to be a version that uses the same method as Zip. While I earlier stated that I’d produced a file in LZW format with RT, I haven’t been able to reproduce that result and am beginning to think that I was confused and erred on that point.
I don’t think you need to worry about LZW as it is in TIFF 6.0 proper, whereas Deflate is an extension. Both are supported by Adobe apps and Adobe is the current developer of TIFF specs.
Have the RT devs confirm with you, but I suspect LZW compression is used in situations where the user benefits from it; e.g., if it performs better than Deflate in 8-bit images.
RT uses Deflate when saving compressed TIFF
FYI: If you really want to reduce file size, gzip/bzip2 the TIFF files. My experience with most TIFF related methods of compression usually results in little file size reduction, while encumbering the TIFF compression fiascal.
And when creating/saving 32-bit color images, TIFF compression is usually useless; with gzip/bzip2 resulting in far better file size reduction.
But as far as compatability, most users know nothing of gzip/bzip2, unless they have 7-zip installed for dealing with the gzip/bzip2 archived files.
I wish more applications would recognize a file suffix of “.tif.gz” or “.tif.bz”, or a TIFF image compressed using gzip/bzip2. This fiascal with TIFF compression methods would then be done and over with!
Images can be stored in TIFF files, compressed with JPEG compression (8 bits/channel, lossy). I don’t know why anyone would want that, instead of saving JPEG files. I suppose it would be a way of packaging multiple JPEGs in a single file.
I recall there being an application or two but I don’t remember so I didn’t say anything, but I guess storing multiple JPEGs could be one use case. I mean raw files do that with preview and thumbnails…