AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
November 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



Valid HTML 4.01!



Thread

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

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

Lee,

Lee Howard wrote:
> > 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
info@awaresystems.be
http://www.awaresystems.be/
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html