[Gate-users] Voxelized source orientation

[Jérôme Suhard]

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/20121213/01ad17f6/attachment.html>