2005.03.22 17:20 "[Tiff] tif_jpeg.c and 12bit JPEG Files", by Frank Warmerdam

2005.03.29 11:24 "Re[2]: [Tiff] tif_jpeg.c and 12bit JPEG Files", by Jean-Yves Le Ridant

This is not really compatible with the way the libtiff interfaces work. Libtiff normally provides the data as a scanline, strip, or tile where the bits-per-sample of the data is the same as reported by libtiff, and the values occupy the full range of the sample. As part of the "decompress" step, the data should be converted to packed 12-bit form. This can easily be done "in-place" if necessary while reading since 12-bits is smaller than 16-bits. A secondary buffer would be needed while writing.

In order to make 12-bit JPEG in TIFF available to a broader variety of applications, an option could be provided via a virtual tag (similar to that used by the LogLuv support) to set libtiff in a mode where 12-bit JPEG in TIFF pretends to be a 16-bit format. 12-bit JPEG in TIFF files would be reported as 16-bits/sample. In this case the samples should be scaled to 16-bits. The only change necessary for applications already supporting 16-bit TIFF is to set the option requesting that 12-bit TIFF be supported like 16-bit TIFF.

Yes, but the problem of a "clean" release with jpeglib for 8 and 12 bits samples? As said by other contributors, I agree that's much a burden to carry. JSAMPLE, JSAMPROW, GET_JOCTET.... that parse the code. And 12 bits compression by jpeglib *must* be two pass mode...

I use Jpeglib v6 in the way of Joris, 12 bits CIELAB, with JCS_UNKNOWN..., and it work very fine. The only matter, for a 'clean' release, is having 2 build of the Jpeglib, includes/typedef,.... and it's a matter. The less changes, would be having a 12 bits jpeglib build, and feed 8 or 12 bits data in a 16 bits JSAMPLE...?

( sorry for his poor english ).