[Gate-users] Voxelised source problem with ASCII input

Tue Apr 19 15:15:05 CEST 2011

The 3 nested loop are what you must do. In order for(axisZ) for(axisY)
for(axisX).
The second block in your file is good, except that instead of writing "int"
you have to write "unsigned short int".
Once you'll do that, try to import your image in imageJ using "File, Import,
Raw, unsigned short int 16bits" to see if you'll get what you want.
Then GATE will be able to read that file.

Concerning the read of your ascii file using "import raw" in imageJ, it is
normal that you can see only number below 9, because writing such a number
in ascii requires only one byte and then a blank space, so a total of 2
bytes, that is the size of an unsigned short int written in binary format !
so it is just a coincidence !

Cheers,
Simon

On Tue, Apr 19, 2011 at 12:33 PM, David Oxley <d.c.oxley at rug.nl> wrote:

>  Hi Simon,
>
> Thanks again for getting back to me. Perhaps I dont need imageJ after all.
> I am happy to write directly to a 3D image, I just dont know how, but please
> see below for specific comments.
>
>
> >If you are able to import your ascii image as "File, Import, Raw" and can
> visualize it, then it means that your image is not in ascii >format but is
> well in unsigned short int and that your problem is solved !
> Well, I can actually only visualise it if the values are less than 9, but I
> am simplifying the problem for now. If I have values of 10 or greater, the
> image just looks a mess and seems to load wrong. I imagine I am missing some
> seperators or something.
> I posted this question on the imageJ forum itself, as I saw it as unrelated
> to GATE.
>
> But perhaps more to the point.
> I have a 3D ROOT histogram (TH3F) which I have a C++ function to write to a
> file. Of course, I can write this to essentially any format, I just need to
> know enough about the format. This is what I could not find out for this 3D
> image format.
> Originally (before using the interfile) I was writing the file using three
> nested loops, one for each axis, and an ofstream.
> For the interfile, I did also try replacing the ofstream with an fwrite
> command in an attempt to try a list of binary numbers.
> I tried using both of these as my data file for GATE, the one referred to
> in the header, but they were not recognized and the code produces a
> segmentation fault as there was no source.
>
> I have just copied the functions I was using out of my library and attached
> them in a file to this email. Perhaps I can just write directly to a 3Dimage
> without using imageJ. That is fine with me. I just dont know the format. OK,
> binary, unsigned short integer, but then is it just a list or are there
> seperators? If it is just a list, I am not sure why the function "binary"
> did not work.
>
>
> Thanks again for your time and patience
>
>
> Dave
>
>
> ----- Original Message -----
> *From:* Simon Stute <gate.stute at gmail.com>
> *To:* David Oxley <d.c.oxley at rug.nl>
> *Cc:* gate-users at lists.opengatecollaboration.org
> *Sent:* Tuesday, April 19, 2011 10:52 AM
> *Subject:* Re: [Gate-users] Voxelised source problem with ASCII input
>
> Hi David,
>
> Yes, I use ImageJ.
> If you are able to import your ascii image as "File, Import, Raw" and can
> visualize it, then it means that your image is not in ascii format but is
> well in unsigned short int and that your problem is solved !
> In imageJ you have a "File, Import, Text image", that can import an
> ascii-described image. But I realized yet that it is only for 2D I think ...
> So it is not the solution...
>
> How did you generate your original ascii image ??
> If it was done by any program, modify it to save in binary and not in
> ascii.
> You can also translate your image in C in less than 10 lines.
>
> Cheers,
> Simon
>
>
> On Mon, Apr 18, 2011 at 1:54 PM, David Oxley <d.c.oxley at rug.nl> wrote:
>
>>  Hi Simon,
>>
>> thanks once more for your help, but I am still having some problems.
>> Do you use this imagej software yourself? I basically have a question
>> related to that, but I can reidrect it elsewhere too.
>>
>> First, I think the header has worked, but converting the data is still a
>> problem.
>>
>> you say "save it into raw data in unsigned short int"
>> if i load my image using File>Import>Raw> then i give the file name> then
>> I select 16 bit unsigned int, <width> , <height> number of slices , then I
>> can see my image . But when I try to save it, I used File >Save As > Raw
>> data...   the output <file>.raw seems to just be ascii again. If I look at
>> it with less, it is the same as the input file, not in binary format. Are
>> you sure this was the right format?
>>
>>
>> Do you use this software and know what the format should be?
>>
>> Dave
>>
>>
>>  ----- Original Message -----
>> *From:* Simon Stute <gate.stute at gmail.com>
>> *To:* David Oxley <d.c.oxley at rug.nl>
>> *Cc:* gate-users at lists.opengatecollaboration.org
>>   *Sent:* Friday, April 15, 2011 3:10 PM
>> *Subject:* Re: [Gate-users] Voxelised source problem with ASCII input
>>
>> Hi Dave,
>>
>> On Thu, Apr 14, 2011 at 1:57 PM, David Oxley <d.c.oxley at rug.nl> wrote:
>>
>>>  Hi Simon,
>>>
>>> thanks for your quick reply, I hope you dont mind me following up with
>>> further questions.
>>> I will try to divide it into two categories (1) the InterFile and (2) the
>>> bug.
>>>
>>> InterFile:
>>> The header you sent me: am I right that this is written in FORTRAN and
>>> that the ! 's denote comments? So you are essentially defining a byte order
>>> and then an x , y, z size with two scaling factors and a slice thickness.
>>> I am still not clear on this '3D image'. What is its format and how can I
>>> create it? Is it just a list of unsigned short integers, or is there more to
>>> it? What do you mean by labels? Perhaps a simple example will help, if I
>>> have a 2 x 2 x 2 source distribution with (obviously) 8 voxels with an
>>> activity of 1,2,3,4,5,6,7,8 in each voxel where do I add the labels to this?
>>> Sorry, I just dont really know what you mean by 3D image.
>>>
>>>
>>
>> Interfile is an image format widely used in nuclear medicine. You can
>> search google for more detailed infos, but here are the main ones.
>> Briefly, an image is formed by two separated files : the header, and the
>> data.
>> The header is an ascii file than contained the few lines I send you in the
>> previous mail. Perhaps it looks like Fortran code, but it is not :-) It just
>> follows an official way to write interfile header informations.
>> The data is in fact the 3D image. It is in binary format. GATE only accept
>> "unsigned short int" format. The value that contains this images are not
>> activity values, there are totally arbitrary values (what I meant by
>> labels). Then your translator will translate these arbitrary values into
>> activity amount of your choice. It is the same when using ascii images.
>> To build your image, you can for example open your ascii one with imagej
>> (probably one of the few software that can read ascii image), and save it
>> into raw data in unsigned short int. Then create by your hands the header
>> file by copying the lines I send to you and replacing meaningful
>> informations (data image file name, number of voxels, size of voxels, etc),
>> like I wrote in the header by your_....
>> A 3D image in raw binary format is always saved like this: for all slices,
>> and for all y, write all x. y is the axis perpendicular to the floor, and x
>> parallel to the floor. You don't need to create one file per slice.
>>
>>
>>
>>>
>>> The bug:
>>> While awaiting a response, I had kept trying to load my source
>>> distrubution in with ascii and hoped to understand where the compression
>>> that I saw was coming from. Eventually I reduced my distribution just to a
>>> straight line. Following the manual, the file must begin with nx, ny,nz and
>>> then be a list of numbers. If I do this I get, like the original post you
>>> helped with, always the same distribution. But I had also tried adding a
>>> voxel size in the second row
>>> nx, ny, nz,
>>> dx , dy, dz ,
>>> list of numbers
>>>
>>>
>>
>> Having a very quick look at the source code, you must specify nx, ny, nz
>> followed by dx, dy, dz. And then you list the voxel values. The user's guide
>> is wrong, and the code is bugged.
>> I recommend you again to use interfile format, but it is not really a
>> recommendation as you have no choice for the moment :-)
>>
>>
>> This ascii voxelized source reader will be fixed, but cannot say when.
>> Sorry.
>>
>>
>> Cheers,
>> Simon
>>
>>
>>>  (I am sure I read this somewhere, but I now cant find where anymore)
>>> But for my straight line, this seems to work. I dont see any compression
>>> and the simulation runs. Plotting the source positions, it looks like my
>>> source - a straight line again. Basically, I am now wondering if the whole
>>> ascii input is unuseable or if this was part of the problem. Can you tell me
>>> more about what the bug was?
>>>
>>>
>>> Dave
>>>
>>> ----- Original Message -----
>>> *From:* Simon Stute <gate.stute at gmail.com>
>>> *To:* David Oxley <d.c.oxley at rug.nl>
>>> *Cc:* gate-users at lists.opengatecollaboration.org
>>> *Sent:* Thursday, April 14, 2011 1:00 PM
>>> *Subject:* Re: [Gate-users] Voxelised source problem with ASCII input
>>>
>>> Hi David,
>>>
>>> From my knowledge, the bug for ascii description of voxelized sources has
>>> not been yet fixed.
>>> From my point of view, managing interfile images is much more convenient
>>> (or any binary one), at least for visualization purpose, as many viewers
>>> cannot open ascii images.
>>> When you use interfile input, you do not have to describe it as a slice
>>> sequence like you said. You just have to make a 3D image in unsigned short
>>> int format, that contains labels. Then with your translator, you tranform
>>> labels in activity amount in each voxel.
>>> I give you there, the most simplified interfile header that contains
>>> enough informations to be used with GATE.
>>>
>>>
>>> !INTERFILE :=
>>> !GENERAL DATA :=
>>> !data offset in bytes := 0
>>> !name of data file := your_image_in_unsigned_short_int_format.i33
>>> ;
>>> !GENERAL IMAGE DATA :=
>>> !total number of images := your_number_of_slices
>>> imagedata byte order := LITTLEENDIAN
>>> ;
>>> !number of images/energy window := your_number_of_slices
>>> !matrix size [1] := your_number_of_pixels_along_x_axis
>>> !matrix size [2] := your_number_of_pixels_along_y_axis
>>> !number format := unsigned integer
>>> !number of bytes per pixel := 2
>>> scaling factor (mm/pixel) [1] := the_pixel_size_along_x_axis_in_mm
>>> scaling factor (mm/pixel) [2] := the_pixel_size_along_y_axis_in_mm
>>> !number of slices := your_number_of_slices
>>> slice thickness (pixels) := the_slice_thickness_in_mm
>>> !END OF INTERFILE :=
>>>
>>>
>>> It should do the job.
>>> When the bug for ascii description will be fixed, I will let you now.
>>>
>>> Good luck,
>>> Simon
>>>
>>> On Wed, Apr 13, 2011 at 5:29 PM, David Oxley <d.c.oxley at rug.nl> wrote:
>>>
>>>> Dear all,
>>>>
>>>> I am trying to implement a voxelised source of positrons into a
>>>> cylindrical PET scanner using the ASCII method of defining the source and a
>>>> linear translator.
>>>> my question follows on from a discussion in the archives between Simon
>>>> Stute and Ismet Isnaini (
>>>> http://article.gmane.org/gmane.comp.science.opengate.user/1356/match=voxelized+source+ascii,
>>>> last post 22-Feb-2011) where they concluded reading in a voxelised source
>>>> using the ascii method had a bug in it.
>>>>
>>>> I am not sure if I am seeing the same bug, but I am not sure how GATE
>>>> knows my voxel size and I see large amounts of my data are compressed into
>>>> the early entries of my source.
>>>>
>>>> First, I am wondering if there have been any developments on this bug as
>>>> using an ASCII file really sounds much easier.
>>>>
>>>> If not, then I was hoping for more information about this InterFile
>>>> alternative. In the voxelised source section of the manual it appears there
>>>> is only one interfile, in this case hof.h33. But earlier in the manual there
>>>> is a link to
>>>> http://www.colin-studholme.net/software/rview/rvmanual/fileform.html#interfile, where there is talk of a header and a different image for each slice. I
>>>> want my source to be a matrix, 100 x 100 x 100 voxels with a voxel size of
>>>> 1mm x 1 mm x 1mm and I know what the activity should be for each of the
>>>> voxels.
>>>> Does this mean if I have an ascii file  with 100^3 entries, I need to
>>>> make 100 images ending in .IMG for the InterFie format? Are these saved as
>>>> binary or ascii? Is the header binary?
>>>>
>>>> Perhaps someone has come across this problem before or knows more about
>>>> this InterFile format than I do.
>>>>
>>>> Just finally, I would rather not use the InterFile format, if someone
>>>> has fixed the bug or has been able to use the ascii voxelised source without
>>>> problems, I would greatly appreciate their help.
>>>>
>>>> Thanks in advance to you all for taking the time to assist.
>>>>
>>>> Kind regards,
>>>>
>>>> Dave
>>>>
>>>> =================================
>>>>
>>>> Dr. David Oxley
>>>>
>>>> Postdoctoral Researcher
>>>> Kernfysisch Versneller Instituut
>>>> Zernikelaan 25
>>>> NL-9747 AA Groningen
>>>> The Netherlands
>>>>
>>>> d.c.oxley at kvi.nl
>>>> d.c.oxley at rug.nl
>>>> _______________________________________________
>>>> Gate-users mailing list
>>>> Gate-users at lists.opengatecollaboration.org
>>>> http://lists.opengatecollaboration.org/mailman/listinfo/gate-users
>>>>
>>>
>>>
>>
>