Hi Evgueni,

thank you for the modifications. I tested the fill_array option and that worked fine. Calculating the coil sensitivity maps with the Inati-method also works fine now.

Concering the sorting, would it be possible to change it such that it removes anything apart from "image" samples/acquisitions? If it does not do that, I think we will get an error as soon as we use real data, because then the number of kx-points is usually different between image and noise data and it cannot be sorted into an array.

I had a problem when trying to compile cGadgetron. using "make clean" and then "make" in the folder xGadgetron/cGadgetron:
hg++ -O3 -fPIC -std=c++11 -DNDEBUG -I/home/stir/devel/iUtilities -I/usr/local/include -c -o cgadgetron.o cgadgetron.cpp
In file included from cgadgetron.cpp:9:0:
/usr/local/include/ismrmrd/dataset.h:12:18: fatal error: hdf5.h: No such file or directory
compilation terminated.

I had a look and apparently there are two make files "Makefile" and "Makefile_VM". I copied the "HDF5_INCLUDE" part from "Makefile_VM" to "Makefile" and that fixed the problem. I hope that was ok.

Concering your questions. There are actually 12+ levels. The smallest entity is usually the readout line or frequency encoding line or kx which is acquired within a few ms. I think in the code it is most of the time referred to as one acquisition. Then there are
encode step 1 - which is also called phase encoding or ky and is the "second" dimension
encode step 2 - is also called slice encoding or kz
then there is slice, repetition, average, echo,...

One repetition can have multiple echoes, averages,.... there is hardly any limit.

A 2D image consists of kx and ky samples, a 3D image consists of kx, ky and kz. The difference between kz and slices is, that slices are multiple 2D images WITHOUT Fourier encoding along the third slice dimension, wheres kz means that it is a fully 3D Fourier encoded volume.

Hope this helps a bit. Let me know if you have any further questions.

Regars and Happy New Year to you too!
Christoph


-----CCP-PETMR Developers list <[log in to unmask]> schrieb: -----
An: [log in to unmask]
Von: Evgueni Ovtchinnikov <[log in to unmask]>
Gesendet von: CCP-PETMR Developers list <[log in to unmask]>
Datum: 29.12.2016 15:57
Betreff: Re: github and coil map calculation

Hi Christoph

 

Thanks a lot for the explanations.

 

I have this question about the hierarchy of data: do I understand correctly that there are three levels

 

1.       Encode step 1

2.       Encode step 2 / 2d slice

3.       3d slice / average / contrast / phase / repetition

 

I am more or less certain about the first two levels but not about 3 – can it actually be split into more levels (say, each repetition can have several phases inside it or vice versa)?

 

In any case, all this looks pretty complicated to me, so I would suggest we stick to 3D acquisition data for the first release (in python order: acquisition, coil, sample) – for one thing, sorting is then not required before using as_array() and other such data exchange methods, it is only needed for coil sensitivity computation and plotting.

 

By the way I have implemented fill() and flags() methods for pGadgetron.AcquisitionsContainer class. Perhaps at some stage I should do indices as well (encode step 1, slice etc.) and some other header data – which items do you think are first priority?

 

Thanks again for your help,

 

Happy New Year!

 

E.

 

PS. A comment on sorting in acquisitions_handling.py was wrong – my sorting does not remove things like noise measurement acquisitions.

 

From: [log in to unmask] [mailto:[log in to unmask]]
Sent: 23 December 2016 06:44
To: Ovtchinnikov, Evgueni (STFC,RAL,SC)
Cc: [log in to unmask]
Subject: RE: github and coil map calculation

 

Hi Evgueni,

thank you very much for fixing it so quickly. I will try it tonight.

Regarding the meanings of the different ISMRMRD flags.
ENCODE_STEP1 - that is the phase encoding along ky
ENCODE_STEP2 - that is the phase encoding along kz (which is only relevant for 3D MR datasets)
AVERAGE - in order to improve SNR or average over multiple motion states to reduce motion artefacts, multiple copies of the same k-space data can be acquired and are then averaged in the reconstruction
SLICE - this is the slice direction but only applies to acquisitions which obtain multiple 2D slices, for a 3D acquisition this would also be 1
CONTRAST - depending on the timing of an MR sequence, different image contrast can be achieved (T1-weighted, T2-weighted,...). One parameter to determine the contrast is the echo time (i.e. time between excitation and gradient/spin echo formation). In one scan, data can be acquired at different echo times (which is for example done when acquiring the fat-water-separated images used for AC calculation). The index "contrast" would then refer to the first, second, third,... echo
PHASE - this varies a little but commonly it is used for different phases of a cardiac cycle. In order to resolve the motion of the heart during the cardiac cycle, the same k-space data is commonly acquired for each part of the cardiac cycle and then labelled with the phase index
REPETITION - this index means that the same k-space is acquired multiple times but not synchronised to the cardiac cycle (otherwise it would be a phase) and not to be averaged in the reconstruction (otherwise it would be an average)

SET and SEGMENT I am also not so sure about because I don't think I have ever come accross it so far.

Hope this helps.

Regards,
Christoph

--
Dr. Christoph Kolbitsch
Medical Physics and Metrological Information Technologies
Physikalisch-Technische Bundesanstalt
Abbestr. 2-12
10587 Berlin, Germany
phone: +49 30 3481 7761



Von:        <[log in to unmask]>
An:        <[log in to unmask]>
Kopie:        <[log in to unmask]>
Datum:        22.12.2016 22:34
Betreff:        RE: github and coil map calculation




Hi Christoph,
 
I fixed the bug and pushed the latest changes, please try again.
 
I have not done fill yet – I am still improving as_array() method (see my latest commits). It would help me a lot if you could explain me the meaning of ‘encode_step1/2’, ’average’, ‘contrast’ and other things like that. The list of relevant ISMRMRD flags is below – for now, I only fully understand the meaning of first and last in slice. I have some idea about repetitions, but I have not seen any datasets that would use the respective flags.
 
    ISMRMRD_ACQ_FIRST_IN_ENCODE_STEP1               =  1,
    ISMRMRD_ACQ_LAST_IN_ENCODE_STEP1                =  2,
    ISMRMRD_ACQ_FIRST_IN_ENCODE_STEP2               =  3,
    ISMRMRD_ACQ_LAST_IN_ENCODE_STEP2                =  4,
    ISMRMRD_ACQ_FIRST_IN_AVERAGE                    =  5,
    ISMRMRD_ACQ_LAST_IN_AVERAGE                     =  6,
    ISMRMRD_ACQ_FIRST_IN_SLICE                      =  7,
    ISMRMRD_ACQ_LAST_IN_SLICE                       =  8,
    ISMRMRD_ACQ_FIRST_IN_CONTRAST                   =  9,
    ISMRMRD_ACQ_LAST_IN_CONTRAST                    = 10,
    ISMRMRD_ACQ_FIRST_IN_PHASE                      = 11,
    ISMRMRD_ACQ_LAST_IN_PHASE                       = 12,
    ISMRMRD_ACQ_FIRST_IN_REPETITION                 = 13,
    ISMRMRD_ACQ_LAST_IN_REPETITION                  = 14,
    ISMRMRD_ACQ_FIRST_IN_SET                        = 15,
    ISMRMRD_ACQ_LAST_IN_SET                         = 16,
    ISMRMRD_ACQ_FIRST_IN_SEGMENT                    = 17,
    ISMRMRD_ACQ_LAST_IN_SEGMENT                     = 18,
 
By the way, I am not entirely comfortable with git, so if you could keep a commented out copy of whatever you are changing/removing (we will get rid of it eventually), then it would be much easier for me to see what you have changed.
 
From: [log in to unmask] [mailto:[log in to unmask]]
Sent: 22 December 2016 20:51
To: Ovtchinnikov, Evgueni (STFC,RAL,SC)
Cc: [log in to unmask]
Subject: github and coil map calculation
 
Hi Evgueni,

I tried to push my latest modifications of the demos onto github but if I look on the github homepage at my latest commit I also see changes in cgadgetron.cpp for example. Is this ok or did my push overwrite some of your latest changes?

Could you please have a look at the demo 'coil_sensitivity_maps.py'. In line 102 I try to use the 'Inati' method but I run into an error there because a function is missing. Could you have a look if this can be fixed easily? Otherwise I would remove this part of the demo.

Did you already have time to write a fill-function to put k-space data back into a reconstruction chain?

Regards,
Christoph

<[log in to unmask]><[log in to unmask]>