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
April 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.04.29 22:52 "Color TIFF/JPEG compression questions", by Jason Frank
2005.04.29 23:16 "Re: Color TIFF/JPEG compression questions", by Joris Van Damme
2005.04.30 15:51 "Re: Color TIFF/JPEG compression questions", by Jason Frank
2005.04.30 07:08 "Re: Color TIFF/JPEG compression questions", by Andrey Kiselev
2005.05.02 13:44 "Re: Color TIFF/JPEG compression questions", by Ed Grissom
2005.05.02 14:16 "Re: Color TIFF/JPEG compression questions", by Joris Van Damme
2005.05.02 16:12 "Re: Color TIFF/JPEG compression questions", by Jason Frank
2005.05.02 16:29 "Re: Color TIFF/JPEG compression questions", by Jason Frank
2005.05.02 17:55 "Re: Color TIFF/JPEG compression questions", by Joris Van Damme
2005.05.02 18:17 "Re: Color TIFF/JPEG compression questions", by Jason Frank
2005.05.02 18:43 "Re: Color TIFF/JPEG compression questions", by Joris Van Damme
2005.05.02 18:48 "Re: Color TIFF/JPEG compression questions", by Bob Friesenhahn
2005.05.02 18:48 "Re: Color TIFF/JPEG compression questions", by Jason Frank
2005.05.02 19:11 "Re: Color TIFF/JPEG compression questions", by Andrey Kiselev
2005.05.03 05:46 "Re: Color TIFF/JPEG compression questions", by Andrey Kiselev

2005.04.29 23:16 "Re: Color TIFF/JPEG compression questions", by Joris Van Damme

Jason,

Without viewing the image, I'm guessing the YCbCr subsampling is the problem...

It's in the file twice, redundantly. It's in a tag value. But, since the strip
is supposed to make sense as a jpeg as a whole, it's in there too. And even if
it wouldn't, the actual compressed data does not make sense to a jpeg
decompressor given wrong YCbCr subsampling values, so in that sense, from an
information point of view, it's in there...

This is all for good reason... We learned the hard way it's best for individual
strips/tiles to make sense as a valid jpeg all by themselves. But to set up
needed decoding steps, knowledge about the YCbCr subsampling values are
needed... So this is a good scheme, but, sure enough, if any given piece of data
is in there twice or more, one vendor sooner or later will manage to muck up...

Technically, it's most often a seperate jpeg codec that is responsable for the
complete jpeg tile/strip decompression/compression. So, it makes sense to assume
the YCbCr subsampling values inside the jpeg data are most likely to be the
correct ones, when contradicated by the values in the TIFF IFD. So, at one time,
Frank decided to add support for this type of invalid files by scanning the
first strip/tile in a very early stage, and correcting the values read from the
TIFF IFD from that.

This explaines the warning messages...

> JPEGPreDecode: Warning, Improper JPEG sampling factors 2,1 Apparently
> should be 1,1..
> JPEGPreDecode: Warning, Decompressor will try reading with sampling
> 2,1..

Is that all there is to it? No, I don't think so... I see that the YCbCr
subsampling tag is in the tag dump produced by tiffinfo, but not in the output
of tiffdump, unless I missed it somehow... Possibly the tag isn't even there,
and some resorting to default values takes place at some stage.

> TIFFReadDirectory: Warning, 1.tif: unknown field with tag 513 (0x201)
> encountered.

This is the JpegInterchangeFormat tag. See
http://www.awaresystems.be/imaging/tiff/tifftags/jpeginterchangeformat.html. It
was used in old-style jpeg compression, compression value 6. It's not recognized
by LibTiff, since it's considered a 'compression dependent' tag, that only is
recognized in combination with compression 6 (which I personally don't think is
a good idea, but hey).

My guess is that Snowbound writes files that are not just a bit invalid. Did
they decide to just pick some elements of compression 6, and some of compression
7, and call that jpeg-in-tiff?

> Segmentation Fault

Of course, there's no excuse, this isn't Snowbound's segmentation fault.

> The biggest issue I have is that I can't find a viewer that I know
> supports color tiffs correctly.  If someone has a recommendation there,
> I'd be very grateful.

Good, valid, compression 7, new-style jpeg-in-tiff, is supported by almost every
mainstream viewer, including the one you refered to. Another option is to forget
about jpeg compression inside tiff alltogether, and use LZW or Deflate. But of
course, that's not a substitute if you need to good compression ratio of lossy
compression.

> Is the image invalid?  Do I
> need to talk to Snowbound?

Definitely. Refer them to Technote2, that is also absorbed in Specification
Supplement 2.

Technote2:
http://www.remotesensing.org/libtiff/TIFFTechNote2.html
Specification supplement 2:
http://partners.adobe.com/public/developer/en/tiff/TIFFphotoshop.pdf

> Should I try to get a stack trace on the
> SEGV?

Andrey will I think appreciate that, together with a good bugzilla entry.

> Should I try to hack up a program to change the sampling factors
> internally and see if I can then process the file?

LibTiff already does that, all by itself, as explained above.


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