Extensions handling and multi-echo reconstruction

[beorostica]

As @cncastillo mention in a previous email: """... we are not currently handling the counters properly. I think I implemented this before Pulseq added counters LABELs as part of EXTENSIONS. It is a very good idea to read them if they are available and add them to the raw data. The closer to the scanner the better. If the counters are not set in the sequence we can do a "good guess" like we have now. But our current guess does not work with multi-echo seqs in which the acquisitions are interleaved. A patch solution would be to have an optional parameter "multiecho=true/false" to correct the counters.
Regarding the k-space positions, I believe integrating should give the correct k-space positions for both echoes, unless there is something I am missing."""

[aTrotier]

Right now : println(seq.DEF["additional_text"])only return some parts of the extension :

# Format of extension lists:
# id type ref next_id
# next_id of 0 terminates the list
# Extension list is followed by extension specifications
[EXTENSIONS]
1 1 1 0
2 2 1 0
3 1 2 0
4 1 3 3
5 2 2 0
6 1 3 5

# Extension specification for digital output and input triggers:
# id type channel delay (us) duration (us)
extension TRIGGERS 1

and in my file I have the others extension types :

# Format of extension lists:
# id type ref next_id
# next_id of 0 terminates the list
# Extension list is followed by extension specifications
[EXTENSIONS]
1 1 1 0
2 2 1 0
3 1 2 0
4 1 3 3
5 2 2 0
6 1 3 5

# Extension specification for setting labels:
# id set labelstring
extension LABELSET 1
1 0 ECO
2 1 ECO
3 0 LIN

# Extension specification for setting labels:
# id set labelstring
extension LABELINC 2
1 1 LIN
2 1 PAR

Any idea how we should implement that ?
My first guess is to store the label LIN, PAR, SLC, SEG, REP, AVG, SET, ECO, PHS
in each ADC when we use seq=read_seq(). Something like :

seq.ADC[1].label.LIN
seq.ADC[1].label.ECO

[cncastillo]

Hi, it is definitely an issue that seq.DEF["additional_text"] does not include the labels, but that variable is a temporary hack. I have been thinking for a while the best way to approach this.

I believe extensions are not necessarily a property of the ADC, despite the LabelSet and LabelInc extension used only for the ADCs, so I would want them to be more general.  We should definitely be reading the block "[EXTENSIONS]" properly in  read_Extension and storing the extension types for the sequence i-th block so seq.EXT[i] is a Vector{ExtensionType} containing for example  [Trigger(...), LabelSet(...), LabelInc(...)] (not always all of them). Then what each extension type means, needs to be defined. 

Then seq.EXT would be a Vector{Vector{ExtensionType}} and Trigger<:ExtensionType, LabelSet<:ExtensionType, LabelInv<:ExtensionType.

It indeed makes sense to do seq.ADC[i].label, but in this case, it would need to be get_label(seq, i), as the label is calculated with information from the whole sequence (or at least the blocks <= i), by adding the counters defined in LabelSet and LabelInc. For convenience, we could define a method for getproperty(seq, :label) so seq.label[i] calls get_labels(seq)[i] or something like that.

I believe this is the best way of doing it, so each extension just defines a new Extensiontype with its own functions, and they can be self-contained. What do you think?

[aTrotier]

Up this topic :)

I am developing a more complex sequence with multiple interleaving between slice / specific phase encoding / contrast.
For now, I am manually editing the label in the simulated raw object but It will be really great to add that possibility.

I might take a look when I have more time :)

[cncastillo]

Sure! I added this issue as a goal for the next release :)

[aTrotier]

I am starting to work on that 👍