Incorrect mapping?

[siminup]

Hi all! The mapper incorrectly identifies files from several participants as relevant to another. I.e., I can see in the GUI that for participant 032 it selects all relevant files, but also a fmap from 043 and a func run from 048. Has anyone had this problem? What could be the reason? Checked number of files in each folder across participants, no differences there. Thank you.

[marcelzwiers]

Hi there,
It is not a problem but a feature, i.e. the bidsmapper picked up that fmap from 043 was not exactly the same as fmap from 032 (and the same for the func scans). Just select the two scans (CTRL-click them) and use your right mouse button to open the context menu and select "compare". Can you show me the result?

[siminup]

Thank you very much! Comparing the files, we discovered one functional run had a different repetition time - that must be it.
Regarding the fmaps, however, I am not sure what the problem might be, as the mapper picks up magnitude1 from one participant and magnitude2 from another (see image below).

[marcelzwiers]

The screenshot of the main window is not what I meant. Please select the run-items that you want to compare (control-click them) and use your right mouse button to go into the context menu

[siminup]

Thank you! The two have different echo times, but they are the correct echo times: 4.92 for magnitude1, and 7.38 for magnitude2. The two files identified are, however, from different participants, although we did not find any missing files or folders.

[marcelzwiers]

Yes, but you should compare the run-items that you think are the same and therefore should only show once in the bidseditor. It makes no sense to compare magnitude1 and magnitude2, you should compare the "same" scan between subject 032 and 048

[siminup]

Yes. The issue, however, is that the mapper does not identify magnitude2 at all for the first participant, 032, even though the files are there.

[siminup]

A follow-up, in case someone else has the same issue: the problem was that echo times were identical for mag1 and mag2 in one of our participants. Thank you for your help!

[marcelzwiers]

BIDScoin expects one Series per Series-folder, but Siemens decided to store both magnitude Series in one folder (this is very irregular). BIDScoin automatically finds the magnitude2 images nevertheless, you don't need to worry about them. Sometimes for some subjects, for some unknown reason, suddenly the magnitude2 images can be stored in front of the magnitude1 images. Then you will see both of them in the bidseditor, but also then you don't need to worry, just name them properly and BIDScoin will take care of the rest.

A follow-up, in case someone else has the same issue: the problem was that echo times were identical for mag1 and mag2 in one of our participants.

This confuses me about what your exact issue was. You mean BIDScoin's automatic typing made a mistake and you had to reclassify it as magnitude1? You say it was solved, so what was the solution?

[siminup]

Thank you! This makes sense. Changing the suffix from magnitude2 to magnitude1 in the GUI seems to solve the problem (it probably automatically searches for magnitude2?). I can see both in the BIDS folder after conversion.

[marcelzwiers]

I must say that I find it highly suspicious that bidscoin classifies a magnitude1 as a magnitude2, so please make sure it is indeed a mag1 image. And another note, running dcm2niix yourself is not needed, but should have no effect on running bidscoin

[siminup]

Yes, we ran dcm2niix just to check the NIfTI metadata, not as a part of our pipeline; it succesfully teased out magnitude1 from magnitude2 on the same data which bidsmapper failed to do so. Is it possible that the mapper classification is influenced by the order in which it reads the files?

[marcelzwiers]

You know that the bidscoiner also runs dcm2niix on the seriesfolder, just like you did. Have you even tried the bidscoiner? Or what did you mean with "the bidsmapper fail to do so". It is described in the docs that you don't need to worry about magnitude2, because the bidscoiner will automatically deal with it during runtime.

[marcelzwiers]

Have you looked at the docs?
https://bidscoin.readthedocs.io/en/latest/bidsmap_features.html#field-maps

For instance, it could be that you have magnitude1 and magnitude2 data in one series-folder (which is what Siemens can do). In that case, when running the bidseditor, you should select the magnitude1 suffix and let bidscoiner automatically pick up the magnitude2 during runtime (or vice versa). The same holds for phase1 and phase2 data.

[siminup]

Here are the problems we encountered (on two separate datasets):

• The mapper sometimes identified magnitude 1 from one participant, but also included magnitude 2 from another participant. We simply removed the latter from the mapper (file number and sizes were consistent across these two participants). We ran bidscoiner and saw the output was fine.
• The mapper sometimes only identified magnitude 2, in which case swapping the suffix with magnitude 1 seemed to do the trick. We ran bidscoiner and saw the output was fine.

When we first encountered these issues, our technician ran dcm2niix on the seemingly problematic files to see if they can indeed be converted, and look at the echo times in the metadata output. We know bidscoiner uses dcm2niix.

[marcelzwiers]

Please read the docs and what I said about the order that Siemens sometimes changes. Don't remove anything, just leave them as mag1/mag2 and continue running the bidscoiner. Then look at the results and see if you indeed have a problem

[siminup]

Thank you, will do!