2005.03.29 16:08 "Re: [Tiff] tif_jpeg.c and 12bit JPEG Files", by Bob Friesenhahn
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...?
That is what the "MK1" library currently does. However, last I heard, David Gilbert was off creating a dual interface version of the library so that 8 bit users would not pay the "penalty" of 16-bit JSAMPLE, but 8/12 bit users could still support 12 bits from one library. I have heard nothing regarding progress with this approach.
To me, the 16-bit JSAMPLE is really only a performance impact for 8-bit users who expect to memcpy() directly to and from libjpeg's buffers. Applications which iterate through the JSAMPLE array in order to copy to/from their own format should see little performance difference.
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/