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 10:28 "Re: TIFFTAG_JPEGTABLES mandatory for JPEG-in-TIFF since 3.8.x ?", by Joris Van Damme
Lee, > In this particular case I'm dealing with a JPEG image that is provided > from a fax machine, and I'm merely wrapping it with TIFF in order to > provide the application with multi-page color fax reception support in > one file... as well as the ability to use other TIFF tags for data > storage. So unless I intend to alter the image that is provided by the > fax machine (and I don't), then I just will be dealing with the JPEG > as-is. Yes, that is an interily different situation. I was commenting on what made sense from the compressor/decompressor codec point of view, I wasn't at all commenting on a JPEG-wrapping-in-TIFF situation. You're dealing with a single strip, if I understand correctly. Whether the tables are optimized or not, is not even relevant, you just need to tables to be included in such a way that they logically apply to the strip. That means you can 1) write them in the JpegTables tag and not the compressed strip, or either you can 2) write them in the strip and not the JpegTables tag, or you could even 3) write them in both and still be legit. The second option is probably most practical. But from a practical point of view, your legit options are restricted by LibTiff support. That means you probably need the option 1), or option 3). That does mean you'll have to actually extract the tables from your JPEG, and provide a tables-only JPEG wrapper around them, thus deriving the suitable value for the JpegTables tag. > ** Create a JPEGTables field if no directory has yet been created. > ** We do this just to ensure that sufficient space is reserved for > ** the JPEGTables field. It will be properly created the right > ** size later. Just goes to show that a hack is not ever a solution, but always a guarantee to run into more trouble at a later stage. At which point, all too often, more hacks are thrown in. > Does this mean that I should be setting YCBCRSUBSAMPLING? That YCBCRSUBSAMPLING concept in LibTiff is so thoroughly drowned in hacks, made worse by the futile and plain incorrect attempt to have the JPEG subcodec do color transformation using the JPEGCOLORMODE pseudo-tag where every TIFF subcodec should actually be color ignorant, made worse still by the library's inadequate handling of tags in the first place... No doubt many people will dissagree, and maybe they're right and I'm wrong, but in my mind the whole thing is hopeless because there's been too much hacking trying to make things work instead of making things correct. I will only comment on a theoretical TIFF point of view without attempting to provide LibTiff answers in this area. The spec says the default for YcbcrSubsampling is 2,2. That means the meaning of the absence of the tag depends on the Photometric, and that's just bad design. The problem becomes apparent when some rightly feel other color modes, like ITULAB, should enjoy subsampling support, leaving others that don't actually have specific knowledge of the color mode to dissagree on the subsampling values when the tag is absent, or even when it's present but ignored. I recommend to *always* include the YcbcrSubsampling tag when writing Ycbcr or ITULAB in whatever compression mode, and to always provide a correct value for the tag, never to depend on a default or a decoder auto-correcting feature. That's the best way to ensure the best possible interchange. Best regards, Joris