LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
September 2006
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
2006.10.03 11:26 "Re[4]: [Tiff] Status of ISO JBIG and CIELAB JPEG support", by Jean-yves Le Ridant
> Now as to the content... I'm not going to add my usual lengthy analysis > for every file, since that would make this a multipage post, but > enumerate only the few problem areas. > ** dad_cie.tif ** > This uncompressed 8bit CIELab file seems perfectly fine. > I note that you don't specify the Subsampling tag, and don't use > subsampling inside the data. The combination of this should mean that > you have the 'strict' view on subsampling, i.e. that it only applies to > YCbCr. > ** dad_icc_jpeg.tif ** > This JPEG compressed 8bit ICCLab file seems perfectly fine. > I note that you DO specify the Subsampling tag, and the JPEG compressed > data is indeed subsampled. The combination of this should mean that you > have the 'wide' view on subsampling, i.e. that it applies to any color > space with a first brightness channel and two chroma channels (YCbCr, > CIELab, ICCLab, ITULab). > I'm not saying either of the above is incorrect, I'm not qualified to > sort this out. But I am saying this is a problem area in TIFF, and your > choice is not consistent. I agree and its for parts a result, when trying to add some general support for lab/jpeg/tiff files, of dealing with specs, some "state of art" of libtiff 3.7.3 ( don't know if things have changed ), tifftools ( mainly tiffcp ), photoshop, and ... my own user's requests. ;-) For what I remember, ( I have done this job in 06/2005), a problem for example, rely on default 2,2 subsampling ( when you enter "wide view" of subsampling). NB : photoshop handle jpeg/cielab ( with progressive in jpegtiff ?) and when saving an uncompressed cielab file, do not write a subsampling tag 1,1 ... It's an example, there's a lot of others, which all rely at some point, to a very strong binding in "(lib)tiff world" of YCbCr/downsampling/Jpeg, so a lot of assertions made in calculations of image/tile/strip size, that have to be "fixed" in some core modules of libtiff. And I no more qualified than you to affirm what is "correct", nor say how things should be "fixed". But, IHMO, as soon as this is not fixed, one can't expect have a correct processing of lab/jpeg files by the readwrite scanlines, strips, tiles interface, easy to maintain with a system libtiff, and thru releases of libtiff. That's why I said to Wandering of rather consider using libtiff to manage tags and coded data, and use libjpeg to process compression/decompression. > This is a JPEG compressed 16bit YCbCr file. That's no good. JPEG > compression can be combined only with 8bit and 12bit per channel data. I > feel the correct decoding response to this is an error message, and > that's exactly what my decoder is doing. Note that if you "hard tag" the file to 12 bits data in place of 16, things come correct, and yatiffcp will decompress a packed 12 bits samples file ... then recompress it, then you hard tag to 16 bit, the decompressed .... ;-))) Shortly, a lot useless manipulation of unusable 12 bits files. lol A brief word : all those conversions are handled at a low level, ( some by jpeglib ), with respect of scale or shift depending of color space. A Tiffcp have not to know about this. > Funny, though, you seem to have a JpegTables tag in this file, and yet > have JPEG tables in the single strip JPEG stream. That's OK, of course, > the latter just override the first, but it's funny nonetheless seeing > the detailed quality in your other files. Argh ! Perhaps something to deal with communication tif_jpeg/jpeglib about 'write tables' in relation with 'optimize' flag ... [...] > The colors are off, this is likely not ICCLab at all. Inside the single > strip JPEG stream, there's an APP1 marker that should not be there, as > well as a DNL marker. Despite of the DNL marker, the image length seems > to be properly encoded inside the SOF0 marker. > Thus, this file much ressembles the fax000... bugzilla attachement that > we started out with in this lengthy thread. I guess you're probably > aware of that? Just make sure people don't mistake it for a valid > testfile. I do not intend these file to be "valid testfile". I only say that for people interested by jpegintiff, particularly lab in tiff, they are well handled by photoshop, structure and colors(1), that they perfectly match the requests of a "colorblind" jpeg codec without some problems relying to the signed cielab in jpegfiles. (1) has long as one agree as you and marti ( and me ) that'all D50, and the good way for D50 .... And of course, Fax..., on the directory "Wanderer fax" is the file submitted by Wandering. About DNL, while my JpegLib is seriously reworked ( 8/12/16 bits at runtime, nothing about dnl ), I can link the same libtiff with original V6b, and I never had to worry about DNLs. Image height and width ( frames in turn from jpeglib point of view ) are at the end initialized from tiff's header image/strip/tile size, and dnl ignored by jpeglib. So if a problems of to few to many scanlines occurs ..., its libtiff as usual ;-) -- Jean-Yves