[ITK] BigTIFF and tiffinfo

[Gib Bogle]

Hi Matt,

Yes, I checked a while ago that Fiji can read these images.  The issue with tiffinfo had me worried, because that's straight from the horse's mouth, so to speak.  Knowing about that build option puts my mind at rest.  I still need to find out the cause of Slicer's bizarre behaviour, which I don't expect to be related to this issue.

I have also been trying to get Vaa3D to read the BigTIFFs.  Using the experience with tiffinfo, I've just succeeded in building an executable that works OK.

Cheers
Gib
________________________________________
From: Matt McCormick [matt.mccormick at kitware.com]
Sent: Monday, 22 September 2014 2:54 p.m.
To: Gib Bogle
Cc: community at itk.org
Subject: Re: [ITK] BigTIFF and tiffinfo

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
>