[Insight-users] 64-bit and mhd long int output
(watershed 'labelled' image)
Atwood, Robert C
r.atwood at imperial.ac.uk
Thu Nov 3 05:52:28 EST 2005
Dear Stephen:
I saw the other follow up after I already wrote this message, but I am
sending it for people's information anyways. I have not added a bug
tracker entry, usually I ask on the list first, and generally find out
that the bug is mine. This time, it looks from the other follow-up like
a solution already exists .. ? So perhaps I should not add to the bug
until I try the new CVS version!
Or, should it be added anyways, since it applies to previous versions?
I am using
typedef itk::Image<unsigned long, 3> LabeledImageType;
typedef itk::ImageFileWriter< LabeledImageType > LabeledWriterType;
The choice is dictated by the type returned by WatershedImageFilter
LabeledWriterType::Pointer lwriter = LabeledWriterType::New();
lwriter->SetInput(watershed->GetOutput());
The output type of WatershedImageFilter is not templated, it is
specified as unsigned long. Only the input type is templated
typedef itk::WatershedImageFilter<ScalarImageType> WatershedFilterType;
So the 'non solution' cannot be used as such, rather I will need to
cast/convert the output into another image of unsigned int before
writing (or els modify itkWatershedImageFilter). USHORT would not hold
the range of values required. I am not sure why watershed uses long int
normally , if it holds only the same range of values of int (presumably
historical reasons?) None of the data types I have used are 128 bit.
Karthik: thanks for the explanation of the behavour of Doxygen.
Thanks
Robert
Here are the sizes reported by sizeof():
**************** program ***************
#include "stdio.h"
main(){
system("uname -a");
printf("int %i\n",sizeof(int));
printf("unsigned int %i\n",sizeof(unsigned int));
printf("long %i\n",sizeof(long));
printf("unsigned long %i\n",sizeof(unsigned long));
printf("short int %i\n",sizeof(short int));
printf("unsigned short int %i\n",sizeof(unsigned short int));
printf("float %i\n",sizeof(float));
printf("double %i\n",sizeof(double));
printf("long long %i\n",sizeof(long long));
}
****************** output using Intel 32 pentium 4 xeon ***************
[~progs]$ gccv333 --version
gccv333 (GCC) 3.3.3
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
[~/progs]$ ./size
Linux hive.beowulf.cluster 2.4.20master #1 SMP Mon May 19 10:21:06 BST
2003 i686 unknown
int 4
unsigned int 4
long 4
unsigned long 4
short int 2
unsigned short int 2
float 4
double 8
long long 8
****************** output using Intel em64t ***************
[~/progs/itk_progs_cvs> cc --version
cc (GCC) 3.3.3 (SuSE Linux)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
[~/progs/itk_progs_cvs> ./size
Linux hive2 2.6.5-7.201-smp #1 SMP Thu Aug 25 06:20:45 UTC 2005 x86_64
x86_64 x86_64 GNU/Linux
int 4
unsigned int 4
long 8
unsigned long 8
short int 2
unsigned short int 2
float 4
double 8
long long 8
-----Original Message-----
From: Stephen R. Aylward [mailto:aylward at unc.edu]
Sent: 02 November 2005 22:08
To: Atwood, Robert C
Cc: insight-users at itk.org
Subject: Re: [Insight-users] 64-bit and mhd long int output (watershed
'labelled' image)
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
More information about the Insight-users
mailing list