Hi, <div class="gmail_quote">2012/12/13 Tom Buitenhuis <<a href="mailto:hjt.buitenhuis@gmail.com" target="_blank">hjt.buitenhuis@gmail.com</a>> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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: <a href="http://www.nucmed.si.mahidol.ac.th/nucmed1/pip/interfil1.html" target="_blank">http://www.nucmed.si.mahidol.ac.th/nucmed1/pip/interfil1.html</a> 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: <a href="http://en.wikipedia.org/wiki/Row-major_order" target="_blank">http://en.wikipedia.org/wiki/Row-major_order</a> 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? </blockquote></div> 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