Description

This is a multi-PLD with revPE: see flavor branch flavor-\#1204_XA31_multiPLD

• 19_20220930_pcasl_3d_mTI15_COGA1 is the multiPLD, including M0
• 23_20220930_pcasl_3d_COGA1_revPE is the revPE M0

In BIDS, the revPE M0 should go into fmap (see example Siemens_PCASL_3DGRASE_VB17A_TopUp_1). Does this mean we need a revPE token in sourceStructure? Or is this automatically detected based on the phase encoding direction (in Siemens all TopUp parameters are detected by dcm2nii).

ASL protocol included as PDF file. The presentation by Joost was on the same sequence but slightly different settings if this helps.

Tasks

• Added to flavors and everything updated.
• RevPE IntendedFor M0scan included in ASL.nii #1213
  Question 1: should the fmap/M0scan reversed PE M0 point to another M0scan, or to the ASL scan?
  Question 2: if it should point to the other M0scan, should it point to the ASL scan in the case of M0 included?
  JAN: We had long discussions about this for BIDS and about ExploreASL and we have concluded the revPE should point to the corresponding M0. So the behavior you are describing is what we have agreed upon in case the M0 file is there.
  In our case, you are right. No existing M0 file, so it should point to ASL. This will probably resolve in the derivatives, so it won't be a real problem now for the processing. Lets make a new issue for that - ok?
  HENK: Done
• Delete the original branch

ASL module issues:

• PLDs are reported including 0 PLDs? PDLs: 0, 0, 0, 0, 0, 0, 400, 400, 800, 800, 1200, 1200, 1400, 1400, 1600, 1600, 1800, 1800, 1900, 1900, 2000, 2000, 2100, 2100, 2200, 2200, 2300, 2300, 2400, 2400
  JAN: Yes, that is correct. We were given a max_LD=2000 and a list of TIs. If max_LD>TI then PLD=0 and LD = TI. For Max_LD<TI, LD = max_LD and PLD = TI - max_LD. This is how Siemens defines that. The only issue might be - that our program will not like the 0-PLDs - that's what I was complaining about. But the PLDs are correct and we have to deal with that in the code.
  HENK: this is now addressed in PLD=0 warning with PLD and labeling duration vector #1214.

• Warning: Field Initial_PLD in xASL structure has multiple values, from 0 to 2400, which is outside of the recommended range <10,10000> ms. xASL_bids_parms2BIDS (line 227) xASL_adm_LoadParms (line 108) xASL_stat_GetDICOMStatistics (line 81)
  JAN: See above. PLD=0 with LabDur=1200ms is causing that. Previously, we were not really counting that such things can happen. But this new sequence is like that and it is OK and it makes sense. Perhaps we should redefine this security check. Though this is just a quality check, nothing really going wrong.
  HENK: OK, see my suggestion in PLD=0 warning with PLD and labeling duration vector #1214.

• Warning: TotalReadoutTime JSON field missing from all JSONs (we do have PhaseEncodingDirection though it seems. What about AcquisitionMatrix and EffectiveEchoSpacing?
  JAN: Good point, I haven't checked about those. They should be read automatically. If not, they should be provided manually in studyPar. So if it's not in the output, then either it is not in the DICOM, or we don't know how to extract this. But otherwise, there is an automatic procedure
  HENK: Can you please check this, I know for a fact that dcm2nii outputs this automatically for Siemens. I cannot find it in the derivatives/temp/*.json though.

Found it, we need to calculate this:

TotalReadoutTime This is actually the "effective" total readout time, defined as the readout duration, specified in seconds, that would have generated data with the given level of distortion. It is NOT the actual, physical duration of the readout train. If "EffectiveEchoSpacing" has been properly computed, it is just EffectiveEchoSpacing * (ReconMatrixPE - 1). ((We use the time between the center of the first "effective" echo and the center of the last "effective" echo, sometimes called the "FSL definition".)) See also HERE.

EffectiveEchoSpacing The "effective" sampling interval, specified in seconds, between lines in the phase-encoding direction, defined based on the size of the reconstructed image in the phase direction. It is frequently, but incorrectly, referred to as "dwell time" (see the "DwellTime" parameter for actual dwell time). It is required for unwarping distortions using field maps. Note that beyond just in-plane acceleration, a variety of other manipulations to the phase encoding need to be accounted for properly, including partial fourier, phase oversampling, phase resolution, phase field-of-view and interpolation. This parameter is REQUIRED if corresponding fieldmap data is present.
Conveniently, for Siemens data, this value is easily obtained as 1 / (BWPPPE * ReconMatrixPE), where BWPPPE is the "BandwidthPerPixelPhaseEncode" in DICOM Tag 0019, 1028 and ReconMatrixPE is the size of the actual reconstructed data in the phase direction (which is NOT reflected in a single DICOM Tag for all possible aforementioned scan manipulations). See here and here

JAN: Yes I know. And this calculation is included in ExploreASL. But the data are simply not there :D No effectiveEchoSpacing, no bandwidthperpixelphaseencode. I don't think that I've removed that during the anonymization - so try asking Joost or print a JSON or DICOM header of the original DICOMs. But in those that i've carefully anonymized for Flavors - it is no longer there.
HENK: 1) where is this calculation code then (also there seem to be 2 calculation options)? 2) OK so this is a problem of too strict anonimization, not only for the current Joost data (which is indeed anonimized) but also for the anonimization tool that you use. See #1215.

• Warning: Significant amount of negative voxels in TopUp result, could be a bug. xASL_fsl_TopUp (line 356)
  JAN: Perhaps can be solved by fixing the DICOM params?
  HENK: will check

• Failed 'Old Segment' (in registration)
  Index exceeds the number of array elements (0).
  In file "/Users/henk/ExploreASL/ExploreASL/External/SPMmodified/spm_minmax.m" (v2774), function "spm_minmax" at line 66.
  In file "/Users/henk/ExploreASL/ExploreASL/External/SPMmodified/spm_preproc.m" (v4916), function "spm_preproc" at line 132.
  In file "/Users/henk/ExploreASL/ExploreASL/External/SPMmodified/toolbox/OldSeg/spm_run_preproc.m" (v4873), function "spm_run_preproc" at line 20.

The following modules did not run:
Failed: Old Segment

JAN: Oh - perhaps something wrong with the image?
HENK: no sh*t sherlock ;) or captain obvious ;) I will check this after fixing the TopUp

Population processing issues:

• Warning: x.Q.readoutDim parameter missing, skipping determining ASL sequence... xASL_adm_DefineASLSequence (line 27)
  JAN: Previously, we had single-sequence datasets. So x-struct in population module was filled with specific parameters for a single sentence and we could derive the vendor. But now, we assume that a study can contain all different kinds of data. And x-struct is cleaned at the start of the population module. So we can't DefineASLSequence - simply because there's no general sequence per study. Only specific one per subject/session/visit.

HENK: Yes, and this is good behavior, the Population module should be ignorant to the ASL sequence type. This is deal with in #870

• Warning: x.Q.Vendor missing, skipping determining ASL sequence; xASL_adm_DefineASLSequence (line 30); xASL_module_Population (line 243)-> xASL_wrp_GetROIstatistics
  JAN: See above. That is wrong by design. There is no general sequence existing for the entire study. So it can't be defined - that is correct. This function here simply became obsolete. Though I am not sure how to deal with all this of course.
  HENK: I will deal with this in Sequence-dependency population module #870.

Release notes

Added multi-PLD Siemens XA31 product flavor.