[Insight-users] 64-bit and mhd long int output
(watershed 'labelled' image)
Gordon Kindlmann
gk at bwh.harvard.edu
Wed Nov 2 20:35:34 EST 2005
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
>
More information about the Insight-users
mailing list