Description

If sourcestructure.json has defined visits _1, _2, _3, _4. But visit 3 is not really present in the sourcedata, the import crashes.

Tasks

• When sourcestructure.json defines Visits TP1, TP2, TP3, TP4 with names '_1','_2', '_3','_4'. Then it all works, but when one visit is missing for one patient (i.e. only having visits TP1, TP2, TP4), the import crashes in DICOM2NII.
• Conversion of BIDS2Legacy of ses-1, ses-2, ses-4 will result in sub1_1, sub1_2, and sub1_3 instead of sub1_4.
• Use regexp for VisitTokenAliases
• Flavors test
• Make this example in flavors by renaming one visit

Discussion

• Import sessions TP1, TP2, TP4 like they are from DICOM2BIDS, even if the suggested list is TP1, TP2, TP3, TP4.
  -> not sure what you mean here, I would need to check this. Here, if we say
  TP1 -> ses-1
  TP2 -> ses-2
  TP3 -> ses-4
  we should keep this order, strictly to what was defined in sourceStructure.json (if the user does it wrong, the user will be punished by a warning or error)

HENK: If there are three dates that suggest TP1 TP2 TP4, in BIDS they should always become ses-1 ses-2 ses-3 (that's how ExploreASL works now, it cannot deal with missing sessions/visit). But of course if there are missing sessions for some but others do have the sessions/visits, you are right
JAN: As stated above. In sourcestructure JSON, we define _1, _2, _3, _4 for TP1, TP2, TP3, TP4. But Michael messed up the implementation and the TP_X is assigned _X only when all visits are there. If a visit is skipped for a single subject, it assigns the incorrect _X. That's a pure bug.

• In BIDS2Legacy, import sessions ses-1, ses-2, ses-4 as _1, _2, _4 and not _1, _2, _3
  HENK: you mean convert right :) not Import.
  -> in BIDS2Legacy we should always ensure that we have successive sessions/visits, so:
  if all subjects have the same, then:
  ses-1 -> _1
  ses-2 -> _2
  ses-4 -> _3
  (because this is what ExploreASL can handle, I don't think we can handle missing sessions/visits within the pipeline)
  JAN: You miss the point. I want to do exactly what is in sourceStructure. And sourceStructure names visits _1, _2, _3, _4. And this is then converted to _1, _2, _3, _4. But when a single subject misses visit _3, then it creates _1, _2, _3 instead of _1, _2, _4. Which is obviously wrong as this doesn't make any sense at all. The whole reason for this error is that Michael didn't use session names and number, but rather their current order. Which stops working immediately as there's a skipped session for a single subject, thus creating a complete mess.
  JAN: Besides, we can't convert ses-1,2,4 as _1,_2,_3 with BIDS2Legacy. Because it would mess up things completely. Some subjects have sess-1,2,3,4, some ses-1,2,4 -> this can't be changed and the exact same numbers have to be used. Again a clear bug ;)

Henk: But it would perhaps be better to always do exactly what is defined in sourceStructure.json (dicom2BIDS) and in BIDS folders (BIDS2Legacy)
Jan: Yes. This is exactly what was wrong and what I fixed now.

Release notes

Allow missing visits in sourcedata.