[ITK] BigTIFF and tiffinfo

[Matt McCormick]

Hi Gib,

Thanks for sharing the information.

A good program to validate TIFF behavior would be FIJI [1], whose
primary image format is TIFF's.

HTH,
Matt

[1]  http://fiji.sc/wiki/index.php/Fiji

On Sun, Sep 21, 2014 at 9:57 PM, Gib Bogle <g.bogle at auckland.ac.nz> wrote:
> 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.
>
> _______________________________________________
> Community mailing list
> Community at itk.org
> http://public.kitware.com/mailman/listinfo/community
>