[Gate-users] Voxelized source orientation

[Tom Buitenhuis]

Hi Jérôme

Thanks for the reply, this clears up some problems I've been having.

Do you know how GATE reads in the voxelized phantom via the ANALYZE 7.5
image? Because I think the same is happening with the phantom, but I can't
seem to locate the code responsible for reading in the binary file.

Kind regards,
Tom Buitenhuis





On Thu, Dec 13, 2012 at 5:19 PM, Jérôme Suhard <jerome at suhard.fr> wrote:

> Hi,
>
>
> 2012/12/13 Tom Buitenhuis <hjt.buitenhuis at gmail.com>
>
>> According to the documentation of these file formats, data is stored in
>> row-major order. For example, for the InterFile 3.3 format, the specs can
>> be found here:
>> http://www.nucmed.si.mahidol.ac.th/nucmed1/pip/interfil1.html
>>
>> Relevant section:
>> "I.5. IMAGE DATA
>>
>> A. Image arrays are to be arranged with the first value (in the binary
>> data) corresponding to the pixel in the top left corner and with the value
>> corresponding to the pixel in the bottom right corner occurring last. Image
>> arrays in V3.3 remain 2-D. The order of the pixel data shall increment by
>> column from left to right, and then (for each such row) by row, from top to
>> bottom. This is also known as row major order."
>>
>> more info on row-major order:
>> http://en.wikipedia.org/wiki/Row-major_order
>>
>> However, when I simulate a voxelized source, the activity seems to have
>> the y-axis inverted, i.e. it seems that GATE ignores this row-major part of
>> the InterFile specification. An example of this can be seen in the attached
>> image. On the left, there is a window where I display the InterFile source
>> in AMIDE, which correctly interprets the specs. The top, white, part of the
>> source has an activity of 10 Bq, where the bottom, green, part has an
>> activity of 500 Bq. On the right of the image, I display the root output of
>> the source-position of simulated coincidences, where we can see that the
>> top-part now has the higher activity, instead of the bottom part.
>>
>> The same seems to hold for the Analyze 7.5 voxelized phantom. When we
>> center both the source and the phantom, this shouldn't be a problem in a
>> cylindrical symmetric PET-scanner, but when we translate one with respect
>> to the other, this could be problematic. The fix is ofcourse easy, i.e.
>> translate in the -y instead of the +y direction, but when this is
>> undocumented, incorrect simulations will be performed.
>>
>> Does anyone else have any experience with this? Am I making a mistake, or
>> is this a bug in the implementation of the file specs in GATE?
>>
>
> GATE doesn't conform to InterFile specs. It just parses some keys
> according to the function GateSourceVoxelInterfileReader::ReadKey(FILE* fp)
> in source/physics/src/GateSourceVoxelInterfileReader.cc .
>
> Here are the relevant portions:
>
> if ( key ==  "matrix size [1]" ) {
>     sscanf(value,"%d",m_dim);
>   } else if ( key ==  "matrix size [2]" ) {
>     sscanf(value,"%d",m_dim+1);
>   } else if ( ( key ==  "number of slices" ) || (key ==  "number of
> images") ) {
>     sscanf(value,"%d",&m_numPlanes);
>   } else if ( key ==  "scaling factor (mm/pixel) [1]" ) {
>     sscanf(value,"%f",m_pixelSize);
>   } else if ( key ==  "scaling factor (mm/pixel) [2]" ) {
>     sscanf(value,"%f",m_pixelSize+1);
>   } else if ( key ==  "slice thickness (pixels)" ) {
>     sscanf(value,"%f",&m_planeThickness);
>   } else if ( key ==  "name of data file" ) {
>     m_dataFileName = std::string(value);
>   } else if ( key ==  "number format" ) {
>     if ( (strcmp(value,"float")==0) || (strcmp(value,"FLOAT")==0) )
>       m_dataTypeName = "FLOAT";
>     else if ( (strcmp(value,"unsigned integer")==0) ||
> (strcmp(value,"UNSIGNED INTEGER")==0) )
>       m_dataTypeName = "UNSIGNED INTEGER";
>     else
>       G4cout << "Unrecognised type name '" << value << "'" << G4endl;
>   } else if (key == "imagedata byte order") {
>         if ( strcmp(value,"BIGENDIAN") == 0 )
>                 m_dataByteOrder = "BIGENDIAN";
>         else if ( strcmp(value,"LITTLEENDIAN") == 0)
>                 m_dataByteOrder = "LITTLEENDIAN";
>         else
>                 G4cerr << "Unrecognized data byte order '" +
> G4String(value) + "', assuming default BIGENDIAN\n" << G4endl;
>   } else {
>     // G4cout << "Key not processed: '" << key << "'" << G4endl;
>   }
>
>
> Best regards,
> --
> Jérôme Suhard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengatecollaboration.org/mailman/private/gate-users/attachments/20121220/8c912f83/attachment.html>