LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
November 2009
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2009.11.30 07:01 "Re: TIFFTAG_JPEGTABLES mandatory for JPEG-in-TIFF since 3.8.x ?", by Joris Van Damme
Lee, > Is it silly of me to not want TIFFTAG_JPEGTABLES written to the TIFF? No, it isn't. From a JPEG point of view, there roughly exists two options. - One is to use standard tables. One good reason for doing this, is that you want compression to be a single-pass process, when you need compression speed and/or want to avoid the buffer involved in a two-pass compression process. - The other option is to use optimized tables. One good reason for doing this, is if you want the best possible compression ratio. From a TIFF point of view, there roughly exist three options that make sense, and then there's a fourth that sneaks in when there's editing and recompressing being done on a limited number of strips or tiles. - One option corresponds to the use of standard tables in JPEG. When you want the best possible compression speed and/or want to avoid the buffer involved in a two-pass compression process, you can prefer to have standard tables on all strips/tiles. In this case, it makes sense not to include the tables in every single strip/tile, but to write them only once in the JpegTables tag. - Another option corresponds to the use of optimized tables. If you want the best possible compression ratio, and your strips/tiles are not too small, it may very well make sense to not include the JpegTables tag, but include tables in every strip/tile, individually optimized for the best possible compression ratio of that particular strip/tile. - If your strips/tile are reasonably small, and/or your picture is reasonably uniform, I guess it may turn out the best possible compression ratio may be to use tables that are optimized for the complete picture instead of a single strip or tile, and include those in a JpegTables tag, and not include them in every strip/tile. It may be that the gain from including tables only once outweights the gain from table optimization on an individual strip/tile basis. - Last but not least, TIFF can support editing and rewriting of a single tile or strip. In such cases, it can happen that the rewriter includes tables in an individual strip/tile, that may be optimized for that particular strip/tile, while the original writer choose to use the JpegTables tag instead. As such, there can be tables in both the JpegTables tag and in some or all of the strips/tiles. This too, is perfectly legal, the latter taking precedence on any individual strip/tile. > Since I need to make the application be compatible with libtiff 3.8.2 - > if there's not a way to avoid writing TIFFTAG_JPEGTABLES with that > version when writing JPEG-in-TIFF, then I'll probably just need to write > TIFFTAG_JPEGTABLES properly... but I wanted to understand if this was > intentional behavior by libtiff, or if this is a bug, or if I just don't > know what I'm doing (likely). Must be categorized as a bug. It's not the only one, related to that tag. I seem to remember that the decompressor holds on to the tables of the previous individual strip/tile when decompressing a subsequent individual strip/tile, effectively using wrong and unrelated tables when the previous strip/tile overwrites tables in JpegTables tag, and the subsequent strip/tile doesn't. Best regards, Joris