<div dir="ltr">Hello Matt, <div><br></div><div style>thanks for the report. The analyze reader included in Gate should be able to read big/little endian (see file ganereal/src/GateAnalyzeHeader.cc). However, I personally have not tested this. </div>
<div style><br></div><div style>Anyway, we have had (other) problems with the analyze image file format and now advocate the use of mhd/raw (sometimes called <a href="http://www.itk.org/Wiki/ITK/File_Formats">metaimage</a>) file format instead. It has some similarity, but the header .mhd is in text (so useful to read/change). The .img and .raw are exactly the same data. mhd file format allows to store origin coordinate of the images (for example overlay of image+dose, see for example with <a href="http://vv.creatis.insa-lyon.fr">vv</a>)</div>
<div style><br></div><div style>Hope it helps. </div><div style>David</div><div style>PS: please post on the gate-users mailing list</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 21, 2013 at 2:40 PM, Matt <span dir="ltr"><<a href="mailto:mdbelley@gmail.com" target="_blank">mdbelley@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Dr. Sarrut,<div><br></div><div>I may have encountered another bug with the radiotherapy applications in GATE. The problem is encountered when using the ANALYZE image format for use with the Dose Actor. I have found a temporary work-around. I am not sure if the problem is with GATE itself, it may be with the way I am creating the ANALYZE image in ImageJ and AMIDE.</div>
<div><br></div><div><div style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">I start with a raw (big-endian) ".bin" output file of a voxelized phantom phantom with pixel values of 0,1,2,3. </div>
<div style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif"><ul><li>I open this raw file (big-endian byte order) in either AMIDE or ImageJ. </li><li>I "Save As ANALYZE" to get two files -- a ".hdr" and a ".img" file.</li>
<li>If I simply use these files as input to GATE, the byte order (endianess) is usually wrong. Instead of values 0,1,2,3, Gate interprets the phantom values as 0, 256, 512....</li></ul></div><div style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">
<ul><li style="margin-left:15px">Here is what I have been doing as a work-around</li><ul><li style="margin-left:15px">In ImageJ, I open the ANALYZE ".img" raw file with "little-endian" byte order so that the values that are displayed are wrong (0,256,512). </li>
<li style="margin-left:15px">I then re-save the file as ".img" to change the byte order. Now, Gate uses the correct values in the simulation of 0,1,2,3...</li></ul></ul><div><br></div><div>I would appreciate if you are able to tell me if this is a problem with Gate or if it is a problem with the way I am generating the ANALYZE images. It seems like Gate is not able to use the ".HDR" file to determine byte order.</div>
<div><br></div><div>Best Regards,<br>Matt</div></div><div class="im"><br><div class="gmail_quote">On Wed, Nov 21, 2012 at 6:52 AM, David Sarrut <span dir="ltr"><<a href="mailto:David.Sarrut@creatis.insa-lyon.fr" target="_blank">David.Sarrut@creatis.insa-lyon.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Matt, <div><br></div><div>a short update regarding the potential problem with Penelope model : it seems to appear when a material contains a element fraction equal to zero. A bug in G4 leads to infinite loop. A workaround could be to remove those line (with fraction=0) in the GateMaterialDatabase. </div>
<div><br></div><div>hope it helps, </div><span><font color="#888888"><div>David</div></font></span><div><div><div class="gmail_extra"><br><br></div></div></div></blockquote></div>
<div><br></div></div><div class="im">-- <br>Matthew Belley <div><br></div><div>Doctoral Student </div><div>Medical Physics Graduate Program, Duke University </div><div>Duke Radiation Dosimetry Laboratory, Duke University Medical Center </div>
<div>
Durham, North Carolina 27705</div>
</div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">David Sarrut, Phd<br>Chargé de recherche CNRS<br>CREATIS, UMR CNRS 5220, Inserm U 1044<div>Centre de lutte contre le cancer Léon Bérard<br>28 rue Laënnec, 69373 Lyon cedex 08<br>
Tel : 04 78 78 51 51 / 06 74 72 05 42<br><a href="http://www.creatis.insa-lyon.fr/~dsarrut" target="_blank">http://www.creatis.insa-lyon.fr/~dsarrut</a><br>_________________________________</div><div> "2 + 2 = 5, for extremely large values of 2"<br>
_________________________________</div></div>
</div></div>