[Insight-developers] [Insight-users] Visual Studio and std::streampos

[Bradley Lowekamp]

Hello Julien,

What version of VS are you using? What file format are you trying to use?

Just to double check how did you check the size of std::streamoff? Most systems seems to have a 64-bit number for this value, even bcc does. 

If it really is the case that std::streamoff is only 32-bits, there are other problems the just the return value of ImageIO::GetImageSizeInBytes. Essentially it means that your C++ std iostreams can not deal with files greater the 2GB. As the std::streamoff values are needed to seek around and search files for random access. IO of large files just will not work in C++. It's a show stopper.

The other possibility is that streamoff is actually larger and that you are only getting a negative value does due to an internal overflow of a 32-bit integer. This could be solve.

Brad

On Jan 21, 2010, at 2:29 PM, Luis Ibanez wrote:

> Hi Julien,
> 
> Thanks for letting me know about your tests.
> 
> Just for the history of this code, the use of std::streampos
> is something that we adopted in 2007 in response to a
> suggestion from the group at CNES:
> http://www.itk.org/mailman/private/insight-developers/2007-September/009576.html
> 
> since the previous type was restricting the size of images
> we could manage with ITK.
> 
> I see the point that it would be desirable to be
> able to get the real size of the image, even when
> working on a 32-bits system.
> 
> I'm not sure what could be a good way of implementing
> this in a portable and safe way.
> 
> 
>      Any suggestions ?
> 
> 
>              Thanks
> 
> 
>                    Luis
> 
> 
> ---------------------------------------------------------
> On Thu, Jan 21, 2010 at 8:39 AM, Julien Michel <julien.michel at c-s.fr> wrote:
>> Luis Ibanez a écrit :
>> 
>>> This would be considered a bug, if the size of
>>> the image gets to be reported in a way that
>>> prevents the streaming mechanism to work.
>> 
>> Luis,
>> 
>> I apologize for the delay. Actually, I could not try ITK tests because the
>> image file format is not compatible with any of the ITK ImageIO (we use one
>> of our own).
>> 
>> However, I took a closer look and it appears that things are not that bad :
>> itk::ImageIOBase::GetImageSizeInBytes() will return a negative number if the
>> image is a 2 bytes per pixel one whose size exceed 1073744823 pixels because
>> on 32 bits windows it is supposed to return a std::streampos which is
>> defined as long in this case.
>> 
>> But the code calling GetImageSizeInBytes() to determine the size of the
>> buffer to allocate was on our side, and I managed to workaround it to avoid
>> calling this method (actually, the new version is better).
>> 
>> So yes, I think there is a problem with using std::streampos to represent
>> image size in bytes on 32 bits windows in itk::ImageIOBase, but no, it does
>> not impact the image reading capability on ITK side.
>> 
>> Thanks a lot,
>> 
>> Regards,
>> 
>> Julien
>> --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> 
>> Julien MICHEL - Ingénieur d'études - Traitement d'images
>> CS Systèmes d'Information - Division ESPACE
>> Département Information Géographique & Image
>> Téléphone : +33 561 17 64 27
>> Email : julien.michel at c-s.fr
>> 
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> 
>> 
> _______________________________________________
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> 
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.html
> 
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers

========================================================
Bradley Lowekamp  
Lockheed Martin Contractor for
Office of High Performance Computing and Communications
National Library of Medicine 
blowekamp at mail.nih.gov


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20100121/c6d1a900/attachment.htm>