[Loris-dev] BIDS - AcquisitionType

Mon Oct 4 15:23:54 EDT 2021

Hi Cecile,

Thanks, this is helpful. I think one important fact that you may not be aware of for this study (or may have forgotten) is that we only have BIDS data as our “original” data. We don’t have access to the original DICOM files.

Would you be available to join a Zoom discussion we are having right now?

https://mcgill.zoom.us/j/85419914478?pwd=d0I1S2NKNUhBcmZKRURvZTRkN1Bvdz09

Thanks,

Sridar

From: Cecile Madjar <cecile.madjar at mcin.ca>
Date: Monday, October 4, 2021 at 3:15 PM
To: "Sridar Narayanan, Dr." <sridar.narayanan at mcgill.ca>
Cc: "Morales Pinzon, Alfredo" <AMORALESPINZON at bwh.harvard.edu>, "loris-dev at bic.mni.mcgill.ca" <loris-dev at bic.mni.mcgill.ca>, Rozie Arnaoutelis <rozie.arnaoutelis at mcgill.ca>, "Douglas Arnold, Dr." <douglas.arnold at mcgill.ca>, "Guttmann Charles,M.D." <guttmann at bwh.harvard.edu>, István Ákos Mórocz <istvan.morocz at mcgill.ca>
Subject: Re: [Loris-dev] BIDS - AcquisitionType

Hi Sridar,

Happy to help :-). Below are my answers to your questions:

  1.  In studies where the primary image upload is done in DICOM, LORIS automatically converts and links a copy of each image volume in MINC. Can it do the same thing when the primary image upload is in BIDS format?
In the future, yes. I am actually developing a dcm2bids pipeline in my spare time. I have made a lot of progress on this this summer but this is not ready yet unfortunately. My deadline for this is this spring but I really hope to have that ready sooner!! Maybe a little Christmas gift? ;-)

In the meantime however, outside of the standard imaging_upload_file.pl<http://imaging_upload_file.pl> pipeline, we have a script called imaging_non_minc_insertion.pl<http://imaging_non_minc_insertion.pl> that allows the insertion of NIfTI files along with a JSON sidecar file into LORIS. So the pipeline could be tweaked to:
1) run dicom_archive/dicomTar.pl (instead of uploadNeuroDB/imaging_upload_file.pl<http://imaging_upload_file.pl>) to create the DICOM archives
2) create a tiny script to untar the DICOM archives and run dcm2niix (for example to create the BIDS JSON sidecar along with the NIfTI file) on the DICOMs.
3) run uploadNeuroDB/imaging_non_minc_insertion.pl<http://imaging_non_minc_insertion.pl> on the NIfTI and JSON files that were created with dcm2niix (or other converter equivalent). Note: this imaging_non_minc_insertion.pl<http://imaging_non_minc_insertion.pl> can be run on any file types other than MINC as long as the proper options are provided to the script so that LORIS knows to which candidate and visit the file should be attached and with which scan type.

  1.
  2.  If not, could we convert the BIDS/NIFTI files into MINC and upload them, or will this conflict with the existing NIFTI files?
I am not entirely sure to understand the question. You would want to do dcm2nii and then nii2mnc?
Note: if there is already a file in the files table with the same SeriesUID/EchoTime combination, then an error will be issued saying a scan has already been inserted with the same SeriesUID/EchoTime combination. We had to add the EchoTime field because we noticed that SeriesUID was not unique for fieldmaps...

  1.
  2.  Can the primary image upload be in MINC format? Up to now, we have only uploaded MINC files for secondary data (e.g. masks).
Yes, the script uploadNeuroDB/minc_insertion.pl<http://minc_insertion.pl> can be called independently to insert a MINC file directly. The script options are listed when you run it with option -help

  1.
  2.  When data are uploaded as DICOM, the generated MINC files seem to have a standardized structure, STUDY_DCCID_VisitLabel_scantype_counter.mnc, (e.g. IPMSA_609372_w24_pdw_001.mnc). Is that a LORIS feature or Pisti, did you organize the input tar files with that naming structure? The BIDS NIFTI files do not have a standardized structure, which breaks downstream processing pipelines.
The STUDY_DCCID_VisitLabel_scan_type_counter.mnc is a LORIS convention for the MINC files. The DICOMs are not organized under that naming structure though because the processes run on the DICOM do not do candidate ID checks and other validations on the DICOMs. This is done on the MINC/NIfTI level only. However, in the tarchive_series and tarchive_files tables there is a list of files with their SeriesUID and EchoTime so it can be easy to figure out with database queries which DICOM files correspond to the inserted MINC file.

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

Thanks,

Sridar

From: Cecile Madjar <cecile.madjar at mcin.ca<mailto:cecile.madjar at mcin.ca>>
Date: Monday, October 4, 2021 at 2:03 PM
To: "Morales Pinzon, Alfredo" <AMORALESPINZON at bwh.harvard.edu<mailto:AMORALESPINZON at bwh.harvard.edu>>
Cc: "loris-dev at bic.mni.mcgill.ca<mailto:loris-dev at bic.mni.mcgill.ca>" <loris-dev at bic.mni.mcgill.ca<mailto:loris-dev at bic.mni.mcgill.ca>>, Rozie Arnaoutelis <rozie.arnaoutelis at mcgill.ca<mailto:rozie.arnaoutelis at mcgill.ca>>, "Sridar Narayanan, Dr." <sridar.narayanan at mcgill.ca<mailto:sridar.narayanan at mcgill.ca>>, "Douglas Arnold, Dr." <douglas.arnold at mcgill.ca<mailto:douglas.arnold at mcgill.ca>>, "Guttmann Charles,M.D." <guttmann at bwh.harvard.edu<mailto:guttmann at bwh.harvard.edu>>, István Ákos Mórocz <istvan.morocz at mcgill.ca<mailto:istvan.morocz at mcgill.ca>>
Subject: Re: [Loris-dev] BIDS - AcquisitionType

Hi Alfredo,

Indeed, you could change the AcquisitionProtoolID in the files table so that it points to the t1g scan type.

Cécile

On Mon, Oct 4, 2021 at 1:28 PM Morales Pinzon, Alfredo <AMORALESPINZON at bwh.harvard.edu<mailto:AMORALESPINZON at bwh.harvard.edu>> wrote:
Hi Cécile,

Thank you for the explanation, I will use this solution for a future dataset.

Right now, I have already uploaded the datasets, and would like to change the scan type for some of the images. For instance I need to some T1w to t1g, which is a T1 with gadolinium. Can I change directly the AcquisitionProtocolID for the files in the database for the right one?

Best,
Alfredo.

On Oct 1, 2021, at 4:51 PM, Cecile Madjar <cecile.madjar at mcin.ca<mailto:cecile.madjar at mcin.ca>> wrote:

        External Email - Use Caution

Hi Alfredo,

I found the line of code that set the scan type to the BIDS suffix in LORIS-MRI: https://github.com/aces/Loris-MRI/blob/c69c89d0c64838e4a174b4a267a1406ce724878a/python/lib/mri.py#L279<https://secure-web.cisco.com/1UotySIw4Y2UoN0ITMqzfPkDOydrk7qYoBcSx9vos65ADL0nt4u1wQ89tO6cofPRHe7ZfZfa7BS5RTZ14d2w6mn-7-caoug2oyTPjfsq4w43Hkk45pzAq7isYEmrQ1JsG0bzYc6wldk7P4oiYp6L1g8R5nMjhdKe05hfwTTZ5E-ZRZJDx3n8OB8hRhx_W1sdTDxTfzk_7wurHqkj7xdiRJxH3MQO0aMq_Por4w9xLwvYqH_iwLF4BGeCVIaXPbnjQrCMIDULeStGAwClTF4jFug/https%3A%2F%2Fgithub.com%2Faces%2FLoris-MRI%2Fblob%2Fc69c89d0c64838e4a174b4a267a1406ce724878a%2Fpython%2Flib%2Fmri.py%23L279>

In line 278, nifti_file.get_entities() will return T1w for files that are named according to BIDS sub-xxx_ses-xxx_<various_parameters>_<suffix>.nii.gz. In your case, the suffix is T1w, which is what is being used to determine a scan type.

I don't know what t1c or t1g refers to but I am guessing that some of the information is available elsewhere in the filename or the JSON file to determine what is what? In which case, you could modify line 279 so that the scan_type is determined based on the criteria you wish to use.

Does that make sense?

Hope this helps,

Cécile

On Thu, Sep 30, 2021 at 10:57 AM Morales Pinzon, Alfredo <AMORALESPINZON at bwh.harvard.edu<mailto:AMORALESPINZON at bwh.harvard.edu>> wrote:
Hi Cécile,

We would like to improve the acquisition type assigned in LORIS for some images that we had uploaded into LORIS for two BIDS datasets. For instance we would like to change some “T1w" to “t1c" or “t1g", depending on some parameters. Is it possible? could you guide me on how can I do this change in LORIS? I’m happy to write some sql scripts if needed.

Best,
Alfredo.

On Aug 17, 2021, at 9:04 AM, Cecile Madjar <cecile.madjar at mcin.ca<mailto:cecile.madjar at mcin.ca>> wrote:

        External Email - Use Caution

Hi Alfredo,

I just verified the BIDS specification. The modality (aka acquisition type) is the last component of the file name, so in the case of the MT0 T2w, the t2w acquisition type is correct. What is stored behind the acq- string are actually acquisition parameters not the acquisition type per se.

If you really want to add the acq prefix to the scan type, you could always modify this line of code<https://secure-web.cisco.com/1_Mi0tGkwGZlsC_57j1f44QdA8RR5bpfcRJl1P5pDWTBiInJ_GWqb9syT49tK6o51AxJLJtwBNmpzBN3bQhvE_pjfHOiuYOKPeT3YUubJi_JXX731ZWY79KebVrJdBoyzREnIeb9c1T9JHLg_2TrmPxVCnrloRbAWzDJJshhsrR3Q3IJm8IjN2QbVOjsBvie5QlmMnBVBjCc1qW82vDI5bEqNVxXJ9yLNDaiAmzhZUeSHgEN_JMBHFSCU9zlB4g--byo7cedmGj5Xiri8LWMMSQ/https%3A%2F%2Fgithub.com%2Faces%2FLoris-MRI%2Fblob%2F15df82251e8011b263effebbf95104737bfc97b4%2Fpython%2Flib%2Fmri.py%23L282> so that it also takes the acq prefix when looking for a scan type?

Cécile

On Mon, Aug 16, 2021 at 3:51 PM Morales Pinzon, Alfredo <AMORALESPINZON at bwh.harvard.edu<mailto:AMORALESPINZON at bwh.harvard.edu>> wrote:
Dear LorisDev team,

I have a question regarding the AcquisitionType assigned to images imported using the BIDS functionality: how do you assign the AcquisitionType?

For some cases it looks good, but some it doesn’t match the “acq” label in BIDS:

Example of correct acquisition type:
===
        {
            "OutputType": "native",
            "Filename": "sub-BGK104001_ses-month36_run-2_T1w.nii.gz",
            "AcquisitionType": "T1w"
        }
===

Example of wrong acquisition type, in this case it should be MT0.
===
        {
            "OutputType": "native",
            "Filename": "sub-BGK104001_ses-month36_acq-MT0_run-1_T2w.nii.gz",
            "AcquisitionType": "t2w"
        },
===

Would it be possible to modify the way the acquisition types are being assigned so that it takes the “acq” label from BIDS?

Thank you for your help.

Best regards,
Alfredo.
The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Mass General Brigham Compliance HelpLine at http://www.massgeneralbrigham.org/complianceline<http://secure-web.cisco.com/1ig3dr6i1WdAs8_-Q_MeK7GXwa0dgT1TgKI1JS7MC0k4yUeF62G6kVevDIHZj5n8tYT0kmV7nj6Fy6sEMEe-xDkf6WhZtm0M-v0uUlyhiKd_DcQ1aSPrfn2jxfJIreAitqwR42XMZb84w7G5WECzE46VWrQ3SZQgrrNHlOq19WKP-mKl5SKE-kGJwNUp4d3l-NeVnWGOTeEoLAx7yXW4HO4FcWICnHaw7zpvritbMeXJqEIaabeQmg8ZEyf_niv71lNvwche53TaBWI6any_S-g/http%3A%2F%2Fwww.massgeneralbrigham.org%2Fcomplianceline> . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.

Please note that this e-mail is not secure (encrypted).  If you do not wish to continue communication over unencrypted e-mail, please notify the sender of this message immediately.  Continuing to send or respond to e-mail after receiving this message means you understand and accept this risk and wish to continue to communicate over unencrypted e-mail.
_______________________________________________
Loris-dev mailing list
Loris-dev at bic.mni.mcgill.ca<mailto:Loris-dev at bic.mni.mcgill.ca>
https://mailman.bic.mni.mcgill.ca/mailman/listinfo/loris-dev<https://secure-web.cisco.com/1d3CFTBToT4j_It30C0sMIZMcTjPqg9RYBFR977oo5ohdasD5Q6U_0ZthyISkUY7Scl8QHwLUGl1JPlpSq6nGt24dMn4qVx8wLxa2UEgaCQgBVAFsdSgusVbLZfj66xn8uFJW_6Qn157m_S9eVZtPrTxUxdhnqC-Yle4xue7mwU5VhzucMFWdxp7uxzLYfwjG35JojFFEy8Aa2x9j2hSO3E-NPuUnrYeqQtR4GFLMRpTbp_8xv4S_0T1hH6fYlqR6JyiOCvcB7AV9LbjIr5GAkQ/https%3A%2F%2Fmailman.bic.mni.mcgill.ca%2Fmailman%2Flistinfo%2Floris-dev>

The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Mass General Brigham Compliance HelpLine at http://www.massgeneralbrigham.org/complianceline<http://secure-web.cisco.com/1vNmj03p92XKeNCHdbzJ-j02hi9iHbmDxay9AX247pJJJvtYwtIZyiBHqc3DUdFuSQn-nLRXFZ7dK9HaISl9ToR42zIgDmGv42q0HWNyO2XbXVYuBO2blnxwrBHKNPEKpJXf6YZ5d86OueTBOIiPRNj-any8ibCsVdxK7Sju1vNDuN1iGp5AHOyUP_7nkK_UmAKzldlMZf9wxrrGxNW1bCF5SBeMzRLWc22DUtkJj__QzI9J1VVoJEscG6fZqitTlJgnLwTgWQRQLokaxkFBUxw/http%3A%2F%2Fwww.massgeneralbrigham.org%2Fcomplianceline> . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.

Please note that this e-mail is not secure (encrypted).  If you do not wish to continue communication over unencrypted e-mail, please notify the sender of this message immediately.  Continuing to send or respond to e-mail after receiving this message means you understand and accept this risk and wish to continue to communicate over unencrypted e-mail.

The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Mass General Brigham Compliance HelpLine at http://www.massgeneralbrigham.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.

Please note that this e-mail is not secure (encrypted).  If you do not wish to continue communication over unencrypted e-mail, please notify the sender of this message immediately.  Continuing to send or respond to e-mail after receiving this message means you understand and accept this risk and wish to continue to communicate over unencrypted e-mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.bic.mni.mcgill.ca/pipermail/loris-dev/attachments/20211004/64bacf10/attachment-0001.html>