RepetitionTime* parameters - what are they and where to find them?

Hi everyone,

For some context, I’m working with ASL data (pASL at the moment) and I would like to store/organize this data in accordance with the BIDS standard. The bids-validator package has been a wonderful tool to help make this reorganization process easier.

That said, I’m getting an error (code: 200 - REPETITION_TIME_PREPARATION_MISSING) indicating that I need to include the RepetitionTimePreparation parameter in the the associated JSON sidecar and have been unable to find any discussion of it online (outside of the BIDS spec itself).

I’ve found the section of the BIDS documentation which describes this parameter (in the second table following the linked heading) however I’m having a bit of trouble figuring where to find this information/parameter.

So my question centers on:

  • Is this a parameter that I can simply read off of a protocol sheet, or
  • Is this a “derived” or “computed” parameter, say, for example:
    RepetitionTimePreparation = RepetitionTime - <something_else>
    
  • Relatedly, is it true that in most cases one would expect that (approximately)
    RepetitionTime ~ RepetitionTimePreparation + RepetitionTimeExcitation
    

For reference the pASL sequences were acquired on a 3T Siemens Prisma Fit scanner (If that helps).

1 Like

@andrewrosss I would be happy to add this value and the others defined by BIDS for ASL if someone could explain how. I provide examples of the DICOM data, sequence PDFs and all the ASL sequences installed on our Siemens Prisma as part of dcm_qa_asl. From these, I have worked out all the parameters to run FSL’s BASIL (see the nii_basil script for extracting the required value from the JSON file dcm2niix creates. The values listed by dcm2niix have a one-to-one correspondence with Siemens terminology (so the values in the dcm2niix JSON match the Siemens PDF). However, it is unclear to me how to translate these to the values defined by BIDS.

I suggest you contact the BEP005 ASL moderators (Henk Mutsaerts and Michael Chappell) for clarification. If you do resolve this, I would be grateful if you could share the solution.

As an aside, in my experience the Siemens product PASL sequences are inferior to the research pCASL sequences available on the Prisma. If you are just starting out, you may want to consider updating your sequences. FSL’s BASIL is able to leverage the multi-PLD pCASL sequences effectively.

@Chris_Rorden Thanks for the input! The resources you linked to look like they could be very helpful. Furthermore, I will definitely reach out to the maintainers of BEP005. I’m happy to report back any findings I come across.

Regarding PASL/pCASL, funnily enough the PASL data is, for all intents and purposes, “historical” as we have moved to collecting 3D GRASE pCASL (multi-delay) sequences. I’m aiming to have it all BIDS-ified. It’s nice to know that we made a change in the right direction!

Would be happy to update the ASL page in the bids starter kit when you get more info.

If you are running into issues, others will too. :slight_smile:

In the context of ASL, RepetitionTimePreparation is REQUIRED and describes the length of a single ASL cycle of labeling+PLD+readout+any time gap. So simply labeling to labeling. It doesn’t need to be calculated and is typically equal to the ‘RepetitionTime’ you obtain from the DICOM (for ASL typically 3-6s).

The reason why RepetitionTimePreparation is used instead of RepetitionTime for ASL is that sometimes, ASL control/label and M0 images are obtained in a single 4D sequence. And we wanted to have a possibility to provide both the TR for M0 and for ASL. In BIDS, RepetitionTime can be a scalar only, while RepetitionTimePreparation can be a vector and can thus accommodate such a scenario. In normal cases, a single TR value in RepetitionTimePreparation is sufficient.

@jan-petr I understand that these parameters are desired, but it is unclear how to infer them from any DICOM, sequence PDFs or consoles. At the moment, the BIS standard and BEP005 outlines a wish list of required and useful parameters, but no consideration is given to have users are supposed to determine these parameters. Please consider the Siemens ASL DICOM and PDF files I provide here and here. These are all the product and research sequences installed at my center, I am also glad to acquire data from other Siemens ASL sequences if people want to suggest them. I have updated dcm2niix to extract all the parameters listed in the Siemens sequence PDFs from the DICOM CSA headers, but it is unclear how to use these to calculate the desired parameters. The parameters dcm2niix currently extracts appear to be sufficient for FSL BASIL. I would be happy to update dcm2niix to help users automatically and reliably have BIDS compatible ASL images, but I am not sure how to derive these values.

From a users perspective, the frustrating aspect of the recent BIDS BEPS is that they generate a wishlist of desired or required parameters without any consideration of how a user can practically compute these values. This is very different from initial development of BIDS, where Chris Gorgolewski worked very closely with me and other developers to ensure consistent and accurate extraction of the desired parameters. I earnestly want to support this BEP, but am unclear regarding how to translate the manufacturers terms to those outlined in BIDS.

1 Like

@Chris_Rorden Thanks for the comment and sorry that this wasn’t clear. In BIDS BEPS, there isn’t unfortunately enough space to provide the instructions. We have just submitted a manuscript to Scientific reports that provides further information and we will obviously have to work on providing more information.

I understand your frustration. The issue with ASL is that there are too many different implementations, 1-3 product version from each manufacturer and even more patches, so at the ExploreASL team we are also struggling to extract all the correct parameters (not even talking of BIDS BEPs). At the BEP005 ASL team, feel free to contact Henk or Patricia for general questions, or me and Marco for technical details on the definition or on the validator.

To answer your question for your data: ASL and M0 are acquired separately. So RepetitionTimePreparation can be always a single number: 4.1s for ASL, 6.81s for M0, and 3.71s for the multi-PLD ASL. Note that for the multi-PLD, the PLD differs from 250ms to 1500ms. The TR still appears to be 3.71s for all volumes, so RepetitionTimePreparation can be a scalar 3.71s. However, there are sequences with even bigger variation in PLD where TR can be different between volumes and this then has to be reflected by providing RepetitionTimePreparation as a vector.

@jan-petr, thanks for your feedback. As long as the logic is described, we can include it into our converters (for example, specific heuristics for different Siemens sequences). I do think having reference datasets that show the sequence PDFs and DICOMs as well as the reference conversion to BIDS/NIfTI is crucial for describing these.

What is the RepetitionTimePreparation for M0 scans that are acquired as the first volume prior to the control label pairs, such as Thomas OKell’s to_ep2d_VEPCASL sequence (see the first volume intensity in this graph)?

What additional BIDS parameters should we extract for Philips ASL data?

As an aside, as a developer attempting to support open science, I am frustrated by the license used by ExploreASL. I am unable to explore the logic of this tool as I could no longer distribute my code under an open BSD license. It is not only that I do not want to do this, but it would contravene the NIH resource sharing agreement of my funding.

I strongly believe that the crucial component of science is research, and the most important component of research is that it is both searching and repeatability. License like those used by FreeSurfer, FSL and Explore ASL contravene the FAIR principles of science. The ability to inspect the code made in analysis can help explain differences between studies and allow accurate replication. I think there is a strong rationale for professional software, and I use professional software every day. However, I do think we should be very cautious as a community of using software with restrictive licenses for science.

The choice of this license will necessarily restrict the individuals who can use this tool, and identify limitations of this tool and who can help extend this tool. As code is complex, users who are unable to inspect code will be unable to ascertain if it is working as expected. Consider the wildly popular FSL tool fslmaths, I created a truly open source clone without looking at the FSL code. The surprising revelation is how many functions do not work as one might assume.

While FSL, FreeSurfer and ExploreASL all are free for academic use in terms of financial cost, they are not free as in freedom.

1 Like