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
January 2005

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

2005.01.07 20:18 "JPEG (T.30-E, fax) in TIFF", by Lee Howard
2005.01.08 02:36 "Re: JPEG (T.30-E, fax) in TIFF", by Joris Van Damme
2005.01.08 16:36 "Re: JPEG (T.30-E, fax) in TIFF", by Lee Howard
2005.01.08 23:03 "Re: JPEG (T.30-E, fax) in TIFF", by Joris Van Damme
2005.01.09 05:46 "Re: JPEG (T.30-E, fax) in TIFF", by Lee Howard
2005.01.13 13:41 "Re: JPEG (T.30-E, fax) in TIFF", by Joris Van Damme
2005.01.13 15:21 "Re: JPEG (T.30-E, fax) in TIFF", by Lee Howard
2005.01.21 20:44 "Re: JPEG (T.30-E, fax) in TIFF", by Andrey Kiselev
2005.01.21 22:19 "Re: JPEG (T.30-E, fax) in TIFF", by Lee Howard
2005.01.14 02:22 "Re: JPEG (T.30-E, fax) in TIFF", by Joris Van Damme
2005.01.14 04:52 "Re: JPEG (T.30-E, fax) in TIFF", by Lee Howard
2005.01.20 23:41 "Re: JPEG (T.30-E, fax) in TIFF", by Lee Howard
2005.02.08 17:02 "Re: JPEG (T.30-E, fax) in TIFF", by Joris Van Damme
2005.02.08 18:38 "Re: JPEG (T.30-E, fax) in TIFF", by Lee Howard
2005.01.21 20:30 "Re: JPEG (T.30-E, fax) in TIFF", by Lee Howard

2005.01.14 02:22 "Re: JPEG (T.30-E, fax) in TIFF", by Joris Van Damme

Lee,

> Okay, following your advice as best as I can I have come up with:
>
>    http://gateway.howardsilvan.com/fax000003470.tif

It took a while, but I was finally able to decode the TIFF with code that does
not depend on LibTiff, for crosstesting. I'll privatly send you a reduced
resolution ordinary YCbCr jpeg of the result in the copy to you, for
checking.

** StripOffsets/StripByteCounts **

The count of these tags is wrong, but you already knew.

** FillOrder **

This value is wrong. It should instead be default, or not be there at all.
LibTiff might be forgiving of this wrong value, but that's a flaw rather then a
feature - I suspect it just doesn't care when combined with JPEG compression,
and it should, because the fillorder handling is a step in the decoding process
that is theoretically completely independent, even if some of the decompressors
can more optimally handle it together with decompressing.

** YCbCrSubsampling **

This value is wrong. In JPEG-style notation, the subsampling is 2:1:1, and that
corresponds to the TIFF-style YCbCrSubsampling values 2,2. This is the default,
so if you're sure that all your source JPEGs will have the same subsampling, you
could just ignore this tag and not set it at all.

** Decode **

I haven't (yet) been able to check whether the source JPEG contains the APP
marker used to specify Decode parameters other than the ITULAB default, because
I seem to have misplaced the spec that explained that APP marker and can't find
any old code and can't remember, either. But, using the default to decode your
image yields visually pleasing results, and I know from past experience that
non-default Decode parameters are rare at best. So I guess we now know
reasonably sure that you can probably ignore the Decode tag, too.

** More general **

Unless, of course, you are set out to build yourself a solution that works for
*any* ITULAB color-fax-jpeg, as opposed to the ones from the same single source,
in that case you'll probably have to detect proper values for the
YCbCrSubsampling and Decode tags from your JPEG stream. Let me know if that is
the case, and I shall try and find time to help out if I may, this is all very
interesting...

Plus, I'm still keen on the general JPEG to JPEG-in-TIFF converter... I'm
thinking of a general scheme, something like
- sequentially add blocks of JPEG data to the single strip (so that the scheme
fits a slow JPEG reception without temp buffer, like you want it)
- while doing so, also sequentially feed these blocks to LibJpeg, which should
be linked in LibTiff anyway, so as to read all relevant properties like color
space, subsampling, etc, from the JPEG stream. At this stage, also especially
note DNL, and if so, remember position to write fix-up and count lines
- when that's done, fill in the tags with the info read from the JPEG stream.
- also do the DNL fix-up now, if necessary

I'm unsure, however, how much of tag setting LibTiff allows to be postponed
untill after the strip writing stage.

I you or anyone on this list wishes to join in to explore this further, now
would be a good time to say so.

In any case, please keep us informed whatever happens next. It's not the first
time ITULAB related stuff comes up in this list, so it would be nice to see and
archive where this is going.

Like you, I'm also hoping to hear from anyone who wishes to extend tiffcp to be
able to deal with these ITULAB tiffs. It should be possible to build a new
testfile that is more correct, since the FillOrder and YCbCrSubsampling mistakes
should be easy to correct, and Decode should be as easy to ignore as before. All
that remains is the Strip tags count bug, but we could even work and extend
tiffcp from a TIFF testfile that is buggy in that regard, since LibTiff seems to
automatically compensate by 'trimming' those tag values.


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