TIFF and LibTiff Mail List Archive


2006.11.30 16:14 "[Tiff] ITULAB JPEG support", by Lee Howard
2006.12.01 11:00 "Re: [Tiff] ITULAB JPEG support", by LERIDANT Jean-Yves
2006.12.01 22:21 "Re: [Tiff] ITULAB JPEG support", by Joris Van Damme
2006.12.05 20:14 "Re[2]: [Tiff] ITULAB JPEG support", by Jean-Yves Le Ridant
2006.12.01 22:25 "Re: [Tiff] ITULAB JPEG support", by Joris Van Damme
2006.12.01 23:46 "Re: [Tiff] ITULAB JPEG support", by Lee Howard
2006.12.02 00:30 "Re: [Tiff] ITULAB JPEG support", by Joris Van Damme
2006.12.02 01:36 "Re: [Tiff] ITULAB JPEG support", by Frank Warmerdam

2006.12.02 00:30 "Re: [Tiff] ITULAB JPEG support", by Joris Van Damme


All I'm saying is that it's not a solution at all in LibTiff, because a) it ties ITULAB support in JPEG compression, and b) it further pollutes hacks and complications that come from subcodecs delivering data essentially different from what is specified in the IFD.

Okay, I understand now.

Unfortunately, I'm not the right person to fix libtiff's current problems, and the only way that I know how to code-in ITULAB support is by following what I already see happening with other codecs.

I totally understand that point of view. Still, the mess is such that going with the current flow might actually be harder then doing it the right way.

Is someone actively working on fixing libtiff's current JPEG issues, or is this something that's on indefinite hold?

Neither. I'm currently too busy, but in one or two months from now I will take full responsability for tif_jpeg.c, provided that it is at all possible to cure the mess. This last condition means that at no point will I start playing Donkey Kong and throw patch after patch after patch to try and hold the JPEGCOLORMODE mess together. So I'll add good alternatives first, like this TIFFReadSubsampledXxx I've mentioned in another post, and possibly partly or completely add backwards compatible support for JPEGCOLORMODE that falls back on these new good alternatives for de-subsampling. If people agree at that point that I can drop the JPEGCOLORMODE mess in tif_jpeg.c, I'll be read and able to clean up tif_jpeg.c and assume responsability for it from that point on.

This is a whole separate and lengthy issue all by itself, though... The problem is that currently the JPEGCOLORMODE abomination a) resolves subsampling in JPEG compressed data and b) translates color from YCbCr to RGB. TIFFReadSubsampledXxx will resolve subsampling independent of compression. That means that if I implement backwards compatible support for JPEGCOLORMODE through the use of TIFFReadSubsamplesXxx, that covers a), but there is a color translation step left to resolve. So either I'll have to add that to the backwards compatible support for JPEGCOLORMODE, locally, or either JPEGCOLORMODE support will change. Neither option seems satisfactory.

So, more thinking and talking needs to be done on the subject. Possibly, but not surely, people might have to deal with changed or dissapeared JPEGCOLORMODE support. If, and only if, we do decide a changed or dissapeared JPEGCOLORMODE is the lesser of evils, we'll have to push it through at LibTiff 4.0 release as that is the point in the near future where API/ABI can change.

But the bottom-line is that there will be someone assuming responsability for tif_jpeg.c starting in a few months from now, provided he's given the option to do more meaningfull improvement then forever chasin' the bugs' tails.

Best regards,

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