[Insight-users] 2GB VTK IO limit

[Luis Ibanez]

Sean, Brad,

Yeap, there are many places in ITK that do not use the appropriate
types for managing large files and buffers in 64bits architectures.

We have fixed the MetaImage format, and test it Nightly with files 
larger than 2Gb, but have not done the same with other fileformats.

The ImageIOBase have the proper typedef for managing file sizes:

     Insight/Code/IO/itkImageIOBase.h  line 244:

        typedef std::streamoff    SizeType;


In order to start addressing this issue,

The signatures of ByteSwapper and its calls from itkVTKImageIO
have now been converted to use "::size_t"  instead of unsigned long.


Please let us know if you find any problems,
and/or if this helps with the limitations that you were observing
in 64bits Macs.


   Thanks


      Luis



---------------------
Sean McBride wrote:
> On 10/10/08 12:31 AM, Mathieu Malaterre said:
> 
> 
>>Looking at the code I would think this is coming from piece such as:
>>
>>itkVTKImageIO.cxx:
>>...
>>ByteSwapper<short>::SwapRangeFromSystemToBigEndian((short *)buffer,
>>static_cast<unsigned long>(this->GetImageSizeInComponents()) );
>>...
>>
>>What is the size of an 'unsigned long' on macosx +gcc ? Anyway if VTK
>>support larger file, this piece of code (and other cast) should be
>>fixed.
> 
> 
> The Mac OS ABI specifies that 'unsigned long' is 32bit when building as
> 32bit, and is 64bit when building as 64bit.  It is one of the (few)
> basic types the changes size between ABIs.
> 
> In any case, 'unsigned long' is indeed the wrong type to use for things
> like file length.  POSIX file APIs tend to use types like off_t.  On OS
> X, off_t is 64bit on both the 32bit and 64bit ABIs.
> 
> Writing portable 32/64 bit-safe code is surprisingly non-trivial.  ITK
> and VTK are riddled with such errors, as a cursory inspection reveals.
>