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
August 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.08.15 01:15 "TIFF Thumbnail", by Katrina Maramba
2005.08.15 02:19 "Re: TIFF Thumbnail", by Joris Van Damme
2005.08.15 14:41 "Re: TIFF Thumbnail", by Ed Grissom
2005.08.15 23:15 "Re: TIFF Thumbnail", by Joris Van Damme
2005.08.19 08:06 "Re: TIFF Thumbnail", by Katrina Maramba
2005.08.19 08:27 "Re: TIFF Thumbnail", by Joris Van Damme
2005.08.24 04:59 "Re: TIFF Thumbnail", by Katrina Maramba
2005.08.24 10:10 "Re: TIFF Thumbnail", by Joris Van Damme
2005.08.26 03:20 "Re: TIFF Thumbnail", by Joris Van Damme

2005.08.26 03:20 "Re: TIFF Thumbnail", by Joris Van Damme

Katrina, Folks,

Joris wrote:
> If the file is under 1 megabyte in size, you may send it to my
> personal e-mail address, and I'll take a closer look.

Katrina has send me a file to look at... It is an extremely weird TIFF
if ever I saw one. Here's next a complete tagdump, and my comments on it
below:

File "P0000049.TIF"
   Byte order: Motorola
   Format: Classic TIFF

IFD Tree
   Page 0 at offset 8
      SubIFD 0 at offset 22724
      SubIFD 1 at offset 22920
      Exif IFD at offset 636
   Page 1 at offset 4096

Page 0
      Offset: 8
      Next IFD: 4096
   NewSubfileType (1 LONG): -
   ImageWidth (1 SHORT): 1792
   ImageLength (1 SHORT): 1200
   BitsPerSample (3 SHORT): 8, 8, 8
   Compression (1 SHORT): No compression
   PhotometricInterpretation (1 SHORT): RGB
   Make (22 ASCII): "Eastman Kodak Company"
   Model (32 ASCII): "KODAK DC290 Zoom Digital Camera"
   StripOffsets (1 LONG): 33776
   Orientation (1 SHORT): 0th row is top, 0th column is left-hand side
   SamplesPerPixel (1 SHORT): 3
   RowsPerStrip (1 SHORT): 1200
   StripByteCounts (1 LONG): 6451200
   XResolution (1 RATIONAL): 192
   YResolution (1 RATIONAL): 192
   ResolutionUnit (1 SHORT): Inch
   SubIFDs (2 LONG): 22724, 22920
   33426 (0 LONG):
   Copyright (33 ASCII): "(c) 1999 FlashPoint Technology  "
   33434 (1 RATIONAL): 0,0166666666666667
   33437 (1 RATIONAL): 2,8
   Exif IFD (1 LONG): 636
   36867 (20 ASCII): "1999:07:13 06:04:43"
   37377 (1 SRATIONAL): 6
   37378 (1 RATIONAL): 3
   37380 (1 SRATIONAL): 0
   37382 (1 RATIONAL): 1,26
   37383 (1 SHORT): 2
   37384 (1 SHORT): 0
   37385 (1 SHORT): 1
   37386 (1 RATIONAL): 0
   41493 (1 RATIONAL): 140
   41495 (1 SHORT): 2

SubIFD 0
      Offset: 22724
      Next IFD: 0
   NewSubfileType (1 LONG): Reduced-resolution version
   ImageWidth (1 SHORT): 96
   ImageLength (1 SHORT): 64
   BitsPerSample (3 SHORT): 0, 0, 0
   Compression (1 SHORT): No compression
   PhotometricInterpretation (1 SHORT): RGB
   StripOffsets (1 SHORT): 0
   Orientation (1 SHORT): 0th row is top, 0th column is left-hand side
   SamplesPerPixel (1 SHORT): 3
   RowsPerStrip (1 SHORT): 64
   StripByteCounts (1 SHORT): 18432
   XResolution (1 RATIONAL): 72
   YResolution (1 RATIONAL): 72
   ResolutionUnit (1 SHORT): Inch

SubIFD 1
      Offset: 22920
      Next IFD: 0
   NewSubfileType (1 LONG): Reduced-resolution version
   ImageWidth (1 SHORT): 288
   ImageLength (1 SHORT): 192
   Compression (1 SHORT): JPEG ('old-style' JPEG, later overriden in
Technote2)
   Orientation (1 SHORT): 0th row is top, 0th column is left-hand side
   XResolution (1 RATIONAL): 72
   YResolution (1 RATIONAL): 72
   ResolutionUnit (1 SHORT): Inch
   JPEGProc (1 SHORT): 1
   JPEGInterchangeFormat (1 LONG): 23086
   JPEGInterchangeFormatLength (1 LONG): 10689

Exif IFD
      Offset: 636
      Next IFD: 0
   ExposureTime (1 RATIONAL): 0,0166666666666667
   FNumber (1 RATIONAL): 2,8
   ExifVersion (4 UNDEFINED): 2.10
   DateTimeOriginal (20 ASCII): "1999:07:13 06:04:43"
   DateTimeDigitized (20 ASCII): "1999:07:13 06:04:43"
   ShutterSpeedValue (1 SRATIONAL): 6
   ApertureValue (1 RATIONAL): 3
   ExposureBiasValue (1 SRATIONAL): 0
   MaxApertureValue (1 RATIONAL): 214748364,8
   MeteringMode (1 SHORT): CenterWeightedAverage
   LightSource (1 SHORT): Unknown
   Flash (1 SHORT): Flash fired
   FocalLength (1 RATIONAL): 0
   MakerNote (1024 UNDEFINED): 1, 0, 1, 0, 0, 0, 4, 0, 69, 97, 115,...
   FlashpixVersion (4 UNDEFINED): 1.00
   ColorSpace (1 SHORT): sRGB
   ExposureIndex (1 RATIONAL): 140
   SensingMethod (1 SHORT): One-chip color area sensor
   FileSource (1 UNDEFINED): Recorded on a DSC
   SceneType (1 UNDEFINED): Directly photographed

Page 1
      Offset: 4096
      Next IFD: 0
   ImageWidth (1 SHORT): 96
   ImageLength (1 SHORT): 64
   BitsPerSample (3 SHORT): 8, 8, 8
   Compression (1 SHORT): No compression
   PhotometricInterpretation (1 SHORT): RGB
   StripOffsets (1 LONG): 4292
   Orientation (1 SHORT): 0th row is top, 0th column is left-hand side
   SamplesPerPixel (1 SHORT): 3
   RowsPerStrip (1 SHORT): 64
   StripByteCounts (1 SHORT): 18432
   XResolution (1 RATIONAL): 72
   YResolution (1 RATIONAL): 72
   ResolutionUnit (1 SHORT): Inch


So, what's in there?

- 'Main image' is what is called 'Page 0' in the above tagdump = IFD 0
in main list.

- This IFD 0 has two SubIFDs, both marked with NewSubfileType tag value
'Reduced-resolution version', therefore a decoder should assume that
these are new-style reduced resolution versions of the 'main image'.

- This IFD 0 also has an EXIF child IFD.

- There's a second IFD in the main list, called 'Page 1' in the above
tagdump = IFD 1 in main list. The producer of the file is aware of the
SubIFDs tag, obviously, and this second IFD does not have the
SubfileType or NewSubfileType tag. Both are good indications that this
second IFD should be regarded as a separate page. However, upon visual
inspection, it is clear that this IFD 1 is actually another reduced
resolution version of IFD 0. Thus, the first two bugs in this file are
that pre-SubIFD notion of reduced resolution versions and post-SubIFD
notion thereof are mixed, and that a reduced resolution version is not
marked as such. There is no way software can detect this situation, thus
decoders are forced to incorrectly conclude there are two separate
independent pages in this file.

- 'Page 0' (= IFD 0 in main list) contains a tag with 0 values (33426,
haven't got a clue what it is). I haven't double-checked, but I believe
that is illegal according to TIFF spec.

- 'Page 0' (= IFD 0 in main list) contains EXIF tags. That used to be
common practice in the early days of EXIF, before they decided to move
all EXIF info in a dedicated private IFD. However, there is also such a
dedicated private IFD tag. Using both this old-style EXIF and new-style
EXIF on the same IFD, well, it's weird at the very least. Additionally,
some EXIF tags are only mentioned in image IFD, some other EXIF tags are
only mentioned in EXIF IFD. There are no contradicting tags though.

- 'SubIFD 0' (= first SubIFD of IFD 0) says BitsPerSample is 0, 0, 0,
and StripOffsets is 0. Both is of course complete nonsense. The number
of channels is consistent with Photometric RGB, though, and to add some
more weirdness the StripByteCounts value is set to 18432, which is
consistent with ImageWidth, ImageLength, BitsPerSample and Compression.

- 'SubIFD 1' (= second SubIFD of IFD 1) is compressed with the old-style
JPEG scheme. I've never seen that in anything but a single main IFD.
I've not (yet) been able to visually verify what it actually contains
since my code is a bit messed up right now. But anyway, the conclusion
with old-style JPEG should always be that it is illegal, breaks TIFF,
and is thus overridden by new-style JPEG-in-TIFF, specified in
specification supplement 2
(http://partners.adobe.com/public/developer/en/tiff/TIFFphotoshop.pdf).

> While parsing the thumbnail data through the API
> TIFFReadRGBAStrip, it had an error in TIFFRGBAImageOK
> that says "Sorry, can not handle images with 0-bit
> samples."
>
> I checked in AsTiffTagViewer, it displayed:
>
> BitsPerSample   Short    3 (count)     8,8,8 (value)

The first refers to SubIFD 0, the second refers to Page 1.

Katrina, this is probably the single worst TIFF I ever saw. It will be
quite a challenge. Some of the stuff is impossible to decode properly
(for instance, it is impossible for code to deduce that IFD 1 is a
reduced resolution version of IFD 0). Other stuff will depend on the
ability of your code to recover from errors in smart ways (for instance,
SubIFD 0 will lead to a decoding error, and so will SubIFD 1 unless you
jump through hoops decoding the illegal old-style JPEG, and smart
decoders must allow proper decoding of IFD 0 even after possibly failing
on these reduced resolution versions). Yet other stuff is rather
arbitrary (for instance, should one use the EXIF info in the image IFD
in this situation, or the EXIF info in the EXIF IFD, or should one merge
these?).

Good luck! If you feel up to it, complaining to the vendor of the
software that writes these monstrous files is the responsible thing to
do. Feel free to use my above comments on the file if you decide to do
so.


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