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

2005.03.22 18:33 "Re: [Tiff] tif_jpeg.c and 12bit JPEG Files", by Joris Van Damme

Frank wrote:
> Does anyone feel
> a compelling need to be able to read YCbCr downsampled raw data
> from JPEG encoded TIFF files?

Lee wrote:

There was also some discussion on the JPEG mailing list about adding support for CIELAB JPEG (fax). Patches to enable this support are available. I believe that this discussion occurred a week or two earlier than David's post to that list. In the end, however, it sounded like the libjpeg maintainers were not interested in applying such patches to libjpeg6, and indicated that they would not be looking at including them until "v7". I have done some work to libtiff to allow libtiff to make use of CIELAB JPEG in a "patched" libjpeg.

Especially with the many different 'forks' of LibJpeg around (don't forget that other fork, the huge lossless compression patch), I think it pays to be logical, and clean. For starters, LibJpeg is perfectly able to encode/decode any color space you want, as long as you make it 'color space ignorant' by setting colorspace to JCS_UNKNOWN (if I remember correctly). That is a perfect way to be perfectly extensible, and has served me in the past to encode and decode CIELAB jpegs without any problem. (I say again: with the unmodified LibJpeg, simply by setting colorspace to JCS_UNKNOWN, and doing whatever convertion I need from/to CIELAB before I feed it to the compressing LibJpeg or after I receive the date from the decompressing LibJpeg. This is the intended purpose of this JCS_UNKNOWN colorspace, it is the designed way to extend LibJpeg to work with any colorspace you desire.)

This sort of reasoning should also be preserved in LibTiff library. Colorspace handling and compression handling should remain perfectly seperate steps, and one should always be able to retrieve data in the exact colorspace it is in the file. This guarantees extendability (cfr CIELAB), as well as being a defenite requirement both in advanced imaging (do nothing unless really needed, and only when really needed, and that includes color space conversion) as well as with 'shortest-cut' transcoding (don't pass through RGB or even downsampling/upsampling if you're converting an YCbCr jpeg-in-tiff to a jpeg, for example).

I never understood tif_jpeg.c (but I haven't spent lots of time trying). It seemed needlessly complicated. In my own TIFF codec, I completely seperate the color handling steps (not even regarded a codec issue actually), downsampling/upsampling step and compression step. That is some effort and may seem unfortunate as it does not make use of some things offered by LibJpeg. However, those things aren't offered by the LZW or flate codec either, and in the end, LibJpeg isn't used but as another compression, codec. So whatever short-cut reusing some of the LibJpeg features, in the end either you have to recode those features anyway to make sure the TIFF code also offers them in combination with other compression codec, or either the TIFF codec is incomplete. So at the end of the day, the most logical seperation of compression and downsampling/upsamling and colorspace handling, is effectively the shortest route too, as well as the most extensible. When next another need comes along, like 12bit CIELAB jpeg-in-tiff, or whatever may happen in the future, it doesn't need any further extension of the code (if you regard the seperate colorspace handling before encoding or after encoding not part of actual codec, which is logical, otherwise it does of course need extension but *only* of added convertion steps you might need).

If it might at any stage be helpful, I can share my jpeg-in-tiff version, where this is done. It is of course pascal, but perhaps it can serve as a documentation saving you part of the road.

Joris Van Damme
Download your free TIFF tag viewer for windows here: