[ITK] BigTIFF and tiffinfo

[Gib Bogle]

Something cleared up (sort of):  I discovered that while the ITK build of the itktiff project links tif_win32.c, the tiff-4.0.3 build was not linking this file.  It turns out that this is controlled by a build option in nmake.opt:

#
# Uncomment following line to enable using Windows Common RunTime Library
# instead of Windows specific system calls. See notes on top of tif_unix.c
# module for details.
#
#USE_WIN_CRT_LIB = 1        # Gib commented this

When I commented out this line and rebuilt libtiff, tiffinfo no longer fails at the 2 GB boundary.  I don't understand what it's about, but it does resolve that mystery.

Gib
________________________________
From: Community [community-bounces at itk.org] on behalf of Gib Bogle [g.bogle at auckland.ac.nz]
Sent: Monday, 22 September 2014 12:21 p.m.
To: community at itk.org
Subject: Re: [ITK] BigTIFF and tiffinfo

Followup: I ran tiffdump on this file, and surprisngly it was able to read to the end of the file, and all the offsets look fine.  So it seems that tiffinfo is at fault - very strange since one would expect that tiffdump and tiffinfo would use identical methods.  More tiff strangeness...
________________________________
From: Community [community-bounces at itk.org] on behalf of Gib Bogle [g.bogle at auckland.ac.nz]
Sent: Monday, 22 September 2014 10:45 a.m.
To: community at itk.org
Subject: [ITK] BigTIFF and tiffinfo

The saga continues...

I finally found and built tiff-4.0.2, to get tiffinfo.exe.  This has revealed a problem with the tiff files built using the ITK that Slicer has created.  This version was pulled using this cmake line:
  set(ITKv4_GIT_TAG 056d97b66a1ddbae77e2217c5bd96e436c7e44fc) # slicer-v4.6.0-2014-09-19-056d97b

When I execute 'tiffinfo -D big1300.tif' or any uncompressed tiff bigger than 2 GB tiffinfo gets a seek error when it tries to go over the 2 GB mark:

...
TIFF Directory at offset 0x7fd0fcf4 (2144402676)
  Subfile Type: multi-page document (2 = 0x2)
  Image Width: 1300 Image Length: 1300
  Resolution: 25.4, 25.4 pixels/inch
  Bits/Sample: 8
  Compression Scheme: None
  Photometric Interpretation: min-is-black
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 1
  Rows/Strip: 6
  Planar Configuration: single image plane
  Page Number: 1265-1300
  Software: InsightToolkit
TIFF Directory at offset 0x7fead588 (2146096520)
  Subfile Type: multi-page document (2 = 0x2)
  Image Width: 1300 Image Length: 1300
  Resolution: 25.4, 25.4 pixels/inch
  Bits/Sample: 8
  Compression Scheme: None
  Photometric Interpretation: min-is-black
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 1
  Rows/Strip: 6
  Planar Configuration: single image plane
  Page Number: 1266-1300
  Software: InsightToolkit
TIFFFetchDirectory: big1300.tif: Seek error accessing TIFF directory.
TIFFReadDirectory: Failed to read directory at offset 2147790364.

There is no problem with the compressed version of the image.

This has added to my confusion.  A program built with the same ITK library can read this file, raising the possibility that it is tiffinfo itself that can't handle a memory pointer > 2 GB.  But I did build libtiff and tiffinfo using Win64.  And Vaa3D also gets this seek error when reading the file.

Any ideas?

Gib

PS It is probably totally irrelevant to the tiff issue, but I happened to notice that there are a few occurrences in other places of checks for _WIN64, which is not defined.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/community/attachments/20140922/e9ff1b51/attachment-0002.html>