[Insight-users] 64-bit and mhd long int output
(watershed 'labelled' image)
Stephen R. Aylward
aylward at unc.edu
Wed Nov 2 23:21:18 EST 2005
Thanks for the pointer.
I'm updating MetaIO based on the Nrrdio code. Thanks!
I'll checking 64 bit support for metaIO tomorrow...
Stephen
Gordon Kindlmann wrote:
> hello,
>
> This seems to intersect with an earlier thread, no?
>
>> From: brad.king at kitware.com
>> Subject: [Insight-developers] Platform-independent type names
>> and 64-bit integers
>> Date: July 7, 2005 9:28:46 AM EDT
>> To: insight-developers at itk.org
>>
>> Hello all,
>>
>> Recently there has been interest in adding support for the NRRD file
>> format's 64-bit integer types. In order to do this properly we need
>> to use a 64-bit integer type on every platform. There is no basic C
>> integer type that is commonly 64 bits in size, but there is at least
>> one type (long, long long, or __int64) available on every platform we
>> support that is 64-bits.
>>
>> Not long ago I added a set of platform-independent type names to VTK
>> with names like vtkTypeInt64 and vtkTypeUInt8 (see VTK/Common/
>> vtkType.h). I propose adding a similar set of typedefs to ITK to
>> address this problem. Platform-independent I/O is generally much
>> easier with such types anyway.
>>
>> I propose names such as "itk::TypeInt32" or "itk::Type::Int32" for
>> the typedefs, but I'm open to suggestions for better names.
>>
>> Comments?
>> -Brad
>
>
> In nrrd, the use of "__int64" on windows, and "long long" everywhere
> else, has been working fine on all the ITK dashboard machines (both 32
> and 64 bit!) for a few years now. That is, the nrrd sanity checks
> pass, and these verify that the values can be created and manipulated
> with no major problems.
>
> The mapping from nrrdTypeLLong and nrrdTypeULLong to the "LONG" and
> "ULONG" works currently on 64 bit machines, but as, Stephen describes,
> without adding new component type names to ITK, there is no way to do
> this on 32 bit machines.
>
> If you look in Insight/Code/IO/itkNrrdImageIO.cxx, you can see that
> "UNKNOWNCOMPONENTTYPE" gets used when nrrdTypeLLong or nrrdTypeULLong
> is encountered on a 32-bit machine. Incidentally, there's no "long"
> type in nrrd because it is the one type that is guaranteed *not* to
> have a platform-independent size.
>
> Gordon
>
>
> On Nov 2, 2005, at 5:08 PM, Stephen R. Aylward wrote:
>
>> Hi Robert,
>>
>> Thanks for pointing this out.
>>
>> What pixel type are you using? What does sizeof return for your
>> pixel type?
>>
>> Regretfully I don't see an easy solution. For example, we will
>> probably need to define a new itkImageIOBase::ComponentType type and
>> a new MetaIO::ValueEnumType to deal with longs on 64 bit machines.
>> As is, GetComponentSize does a sizeof(long) to determine the size of
>> itkImageIOBase::ComponenType::LONG. Since sizeof(long) differs by
>> machine/OS, reading/writing images with pixel type LONG won't work
>> on/from 64 bit machines - this is true for MetaIO images and any
>> other image/pixel format that relies on ITK's report of ComponentSize
>> and ComponentType. There is simply no easy way to support 128bit
>> longs on a 32 bit machine.
>>
>> The easy "non-solution" is to use a different pixel type. Ideally
>> USHORT or maybe even UINT will work...
>>
>> Did you add this problem to the bug tracker?
>>
>> Thanks,
>> Stephen
>>
>> Atwood, Robert C wrote:
>>
>>> The good news is that the results on a Intel em64t (SUSE 9.1 gnu/ Linux
>>> distib) for my use of the watershed appear good and somewhat faster
>>> than
>>> on the 32 bit machine. The bad news is that I only get half the output.
>>> I traced the problem to 'magic numbers' for the data element size
>>> defined as constants in metaTypes.h shown below. I am not sure how
>>> it should be fixed in keeping with overall ITK program
>>> style, I would use a preprocessor directive for a quick fix assuming
>>> that CMAKE can set a macro by probing the system information Is there
>>> already a macro created for this purpose?
>>> or perhaps it is better in the long run to use a sizeof() -- then I
>>> don't think it can be const and cannot be set in the header file?
>>> Also, I could not find the itk::MetaImageIO member object
>>> m_MetaImage in
>>> the Doxygen list of all members, though it appears in the header
>>> file as
>>> displayed by Doxygen.
>>> ********** CVS status of the file *******************
>>> ===================================================================
>>> File: metaTypes.h Status: Up-to-date
>>> Working revision: 1.4
>>> Repository revision: 1.4
>>> /cvsroot/Insight/Insight/Utilities/MetaIO/metaTypes.h,v
>>> ************* Excerpt from metaTypes.h ****************
>>> 27 typedef enum
>>> 28 {
>>> 29 MET_NONE,
>>> 30 MET_ASCII_CHAR,
>>> 31 MET_CHAR,
>>> 32 MET_UCHAR,
>>> 33 MET_SHORT,
>>> 34 MET_USHORT,
>>> 35 MET_INT,
>>> 36 MET_UINT,
>>> 37 MET_LONG,
>>> 38 MET_ULONG,
>>> 39 MET_FLOAT,
>>> 40 MET_DOUBLE,
>>> 41 MET_STRING,
>>> 42 MET_CHAR_ARRAY,
>>> 43 MET_UCHAR_ARRAY,
>>> 44 MET_SHORT_ARRAY,
>>> 45 MET_USHORT_ARRAY,
>>> 46 MET_INT_ARRAY,
>>> 47 MET_UINT_ARRAY,
>>> 48 MET_LONG_ARRAY,
>>> 49 MET_ULONG_ARRAY,
>>> 50 MET_FLOAT_ARRAY,
>>> 51 MET_DOUBLE_ARRAY,
>>> 52 MET_FLOAT_MATRIX,
>>> 53 MET_OTHER
>>> 54 } MET_ValueEnumType;
>>> 55
>>> 56
>>> 57 const unsigned char MET_ValueTypeSize[MET_NUM_VALUE_TYPES] = {
>>> 58 0, 1, 1, 1, 2, 2, 4, 4, 4, 4, 4, 8, 1, 1, 1, 2, 2, 4, 4, 4,
>>> 4, 4, 8, 4, 0 };
>>> 59
>>> *********************copied from Doxygen web pages
>>> **********************
>>> http://www.itk.org/Doxygen/html/classitk_1_1MetaImageIO-members.html
>>> m_FileName itk::ImageIOBase [protected]
>>> m_FileType itk::ImageIOBase [protected]
>>> m_Initialized itk::ImageIOBase [protected]
>>> m_IORegion itk::ImageIOBase [protected]
>>> m_NumberOfComponents itk::ImageIOBase [protected]
>>> m_NumberOfDimensions itk::ImageIOBase [protected]
>>> m_Origin itk::ImageIOBase [prot
>>> http://www.itk.org/Doxygen/html/itkMetaImageIO_8h-source.html
>>> 00097 private:
>>> 00098 00099 MetaImage m_MetaImage;
>>> 00100 00101 MetaImageIO(const Self&); //purposely not implemented
>>> 00102 void operator=(const Self&); //purposely not implemented
>>> 00103 00104 }; _______________________________________________
>>> Insight-users mailing list
>>> Insight-users at itk.org
>>> http://www.itk.org/mailman/listinfo/insight-users
>>>
>>
>> --
>> ===========================================================
>> Dr. Stephen R. Aylward
>> Associate Professor of Radiology
>> Adjunct Associate Professor of Computer Science and Surgery
>> http://caddlab.rad.unc.edu
>> aylward at unc.edu
>> (919) 966-9695
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users at itk.org
>> http://www.itk.org/mailman/listinfo/insight-users
>>
>
--
===========================================================
Dr. Stephen R. Aylward
Associate Professor of Radiology
Adjunct Associate Professor of Computer Science and Surgery
http://caddlab.rad.unc.edu
aylward at unc.edu
(919) 966-9695
More information about the Insight-users
mailing list