bids-specification
bids-specification copied to clipboard
bids-standard
aslcontext.tsv dummy volumes
Hi, I have an ASL dataset that I am hoping to convert to BIDS format (to eventually use with ASLPrep), but the sequence that our group is using is structured as an M0 volume, a dummy volume, and then 9 label-control pairs, and the current BIDS specification for the aslcontext.tsv file does not seem to have any option for indicating a dummy volume, just label/control/m0. Could an option for labeling dummy volumes (or an "other" or "ignore" option) potentially be added to the specification for aslcontext.tsv so that it is possible to convert this type of ASL sequence to valid BIDS format? Thank you!
I don't really understand what a "dummy volume" is in this context, or why dummy volumes are included in the protocol, but this was also brought up by lucia_sanchez_aranda on NeuroStars (https://neurostars.org/t/plds-calibration-image-and-dummy-volumes-in-aslprep/26373), so it seems like multiple people are struggling with this.
This has come up once again (https://neurostars.org/t/aslprep-cannot-calculate-deltam/29969), so I'd like to get some resolution on it. What is a "dummy volume" in an ASL scan? What is its purpose? Why put it after the M0 scan and before the control-label pairs? What kind of contrast does it have?
@HenkMutsaerts @patsycle Do you have any insight here? It would be trivial to add a dummy or similar value to volume_type, but I don't know enough to say whether that's appropriate or whether there's another way to achieve what these posters want to achieve.
Hi all, I don’t have a direct answer to these questions, but wanted to add that I’ve been able to successfully run analyses on this dataset in BASIL with just the m0 and control by just cutting the dummy volume out entirely. So at the very least, it doesn’t appear to be a critical piece of data. Adding a new option to volume_type that ASLprep could be told to ignore (though that’s probably a separate topic for the ASLprep team) might be the best bet here, unless someone more knowledgeable feels otherwise.
Disclaimer: take all of the above with a grain of salt, I am far from an ASL sequence expert, so I may be wrong, though someone with more expertise who I met with recently seemed to also have no issue with the “just remove it” approach.
On Thu, Jul 18, 2024 at 6:37 AM Chris Markiewicz @.***> wrote:
@HenkMutsaerts https://github.com/HenkMutsaerts @patsycle https://github.com/patsycle Do you have any insight here? It would be trivial to add a dummy or similar value to volume_type, but I don't know enough to say whether that's appropriate or whether there's another way to achieve what these posters want to achieve.
— Reply to this email directly, view it on GitHub https://github.com/bids-standard/bids-specification/issues/1762#issuecomment-2236545503, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOVO2M34I3KJX3AIHPP2QULZM7AKFAVCNFSM6AAAAABFYDOEEWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZWGU2DKNJQGM . You are receiving this because you authored the thread.Message ID: @.***>
I don't doubt that you can remove it; I just don't know if there's a better label to apply to such volumes. Today's dummy volume might be tomorrow's diagnostic volume, and annotating data with a description instead of an instruction can allow tools to evolve their behavior without modifying the dataset.
Hi everyone, just wanted to add that I have also encountered this issue in the past. The HCP-A/Siemens 2D MB PCASL sequence consists of 43 label/control pairs (the first 86 volumes), followed by 2 noise images and 2 m0 images for a total of 90 volumes as described here.
I am just speculating because this isn't my area of expertise but I think these noise volumes allow for full relaxation between the label/control volumes and the m0 volumes? Maybe it's related to the fact that the m0 TR can be very long compared to the TR for the rest of the volumes? I know for the 2D MB PCASL sequence the m0 TR is 8s vs. 3.58s for the rest of the acquisition. The noise volumes don't have a contrast, they are just background values (there is no brain in the image).
These noise volumes are not used during preprocessing or the estimation of CBF/other measures. They have no value but it would be convenient to have a discard, noise or dummy volume_type option in the *_aslcontext.tsv instead of having to separately remove these volumes from the NIfTI during BIDS conversion.
I do think noise could be a good label, if that's what people think they're capturing. Or noRF, to match the NORDIC suffix?
Hi all, I just wanted to chime in because I'm also having this problem with the current dataset I'm analyzing. We're using a sequence programmed by a team at USC and this is the order of dicoms:
Volume # | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16Volume Type | M0 | Ctl | Tag | Ctl | Tag | Ctl | Tag | Ctl | Tag | Ctl | Tag | Ctl | Tag | Ctl | Tag | Ctl
@hgrotzin shared her DICOMs with me and I checked the dummy scan. Unfortunately, it looks somewhat like a control volume, rather than a noRF, which I would expect to look like the following:
So is there a reason not to just call these control volumes and let software decide whether they are useful? Or is the software kind of dumb, and users need to encode a bit more intent?
@mharms I realize you're the one who posted the message linked in https://github.com/bids-standard/bids-specification/issues/1762#issuecomment-2237632417. What do you think about calling these additional volumes "control" or "noise"? Or anything else spring to mind?
Yes, it is a software is dumb situation; I actually didn’t know it wasn’t a control volume at first because they look so similar, so I had it coded as control and then spent weeks trying to figure out why my BASIL output looked so weird before reaching out to the sequence developer and being told there was a dummy volume. Leaving a dummy volume coded as control will allow the pipeline to run but messes up the label control subtractions enough to ruin the whole image, so it is super critical that they do not get coded as control. See below for what happens when you label dummy as control vs. when it is correctly excluded from analysis. My personal vote, in the interest of user-friendliness, would be to just code it as "dummy", because that is what people using these sequences will be told that the volume is, but I'd also be fine with @aptinis "discard" proposal.
P.S. @hgrotzin unless there's two ASL development teams at USC, I'm guessing that you're using a Danny Wang sequence like I am? If so, it looks we have a slightly different sequence but I want to flag that yours might also have some other issues to be aware of other than the dummy scans - namely, that there are a couple parameters where info in the sequence PDF is outright false / has misleading artifacts from a base sequence, which can result in the wrong parameters being set for asl analyses. Happy to take a look at the sequence you're using to confirm, feel free to email me - [email protected]
In my case with the Siemens 2D MB PCASL sequence I think they look like noise images and are not just a control image so noise would be more appropriate. I am not familiar with NORDIC but maybe noRF could also apply? Here's an example of one of the noise volumes (axial view).
Maybe we could use discard, dummy or ignore to be more broad to accommodate both use cases? I think it would be good to allow users to encode intent for software given the unique use of the *_aslcontext.tsv file for asl. Creating a new volume type would be helpful so that I don't have to remove volumes during BIDS formatting in order to be BIDS valid (since I can't label it a control volume).
lol it looks like we have multiple image types that were being conflated here.
@nmrotstein @hgrotzin your images look like control volumes. The question then becomes, what is the purpose of these control volumes? If they're just an extra control volume, then that's fine. I think it's totally reasonable to have an unequal number of control and label volumes, and I can modify ASLPrep to account for this, but is there going to be a problem if CBF is calculated using that first "control" image (which might also be a "noise" image)? If so, then I need to know why and BIDS should include a different volume_type value for these volumes. Otherwise, it's just an issue on ASLPrep's end.
@aptinis, your image looks like a noRF volume to me. I'd love to know for sure that the volumes were acquired without an excitation pulse before we commit to the label "noRF", but that's promising.
@tsalo For the kind that me and @hgrotzin have, they are not actually control volumes and cannot be treated as control volumes, they just have a deceptively similar appearance. Not sure if you saw the message I sent or if it got buried by the one @aptinis sent at the same time, but basically, if you treat the dummy volume as a control image in CBF calculation, it ruins the entire output image.
I have no idea why the dummy volume breaks things when included (beyond "it is not a control or label image so the subtraction gets messed up), or why it's included at all. But it does need a different BIDS volume type in my opinion to avoid being misclassified/misused by the pipeline.
Our site uses the 2D MB PCASL sequence on a Siemens Prisma scanner. I think we are using the exact same sequence as HCP Ageing. I am not sure how to verify the 2 noise volumes were acquired without an excitation pulse. @tsalo Is there a DICOM tag I can check? The sequence info can be found here and may give some insight. Or maybe someone from HCP knows?
I agree we're conflating multiple image types here but one of the potential solutions (having a dummy, discard or ignore volume type) could solve both use cases. It looks like regardless of which type of dummy volume it is (control like or noise) it's important that those specific volumes are discarded and not used by ASLprep to calculate CBF. I am also unfamiliar with the reason for these volumes (hopefully we can find an explanation) but I speculated above these dummy volumes may be needed to allow for full relaxation between the label/control volumes and the m0 volumes? These "dummy" volumes are always between the m0 volume and the control/label pairs we use.
I think it might be complex for ASLprep to determine which particular volumes to use within the image given that
- there can be multiple discard volumes and
- they are not always in the same place within the 4D NIfTI
For example:
control, label, control, label .... dummy, dummy, m0m0, dummy, control, label, control, label ...
I think it might be easier to create a new volume type, such as dummy, discard or ignore, for the *_aslcontext.tsv file that solves both use cases.
So is there a reason not to just call these control volumes and let software decide whether they are useful? Or is the software kind of dumb, and users need to encode a bit more intent?
@mharms I realize you're the one who posted the message linked in #1762 (comment). What do you think about calling these additional volumes "control" or "noise"? Or anything else spring to mind?
Sorry, what comment from me are you referring to? I don't see any comment by me in this particular thread.
@mharms, @effigies was referring to the thread from the HCP Google Group (https://groups.google.com/a/humanconnectome.org/g/hcp-users/c/2li3DdK5asc/m/unTp5AjhAQAJ) that was linked to in the comment in this thread.
I found this sentence on p. 171 in http://www.ncbi.nlm.nih.gov/pubmed/25462690:
Additional EPI images could be optionally collected after the pCASL series with all RF pulses turned off for estimating thermal noise and calculating g-factormaps.
So, either noise or noRF would seemingly be fine as labels for those volumes.
FWIW, in that paper, they collected 200 noise volumes, so I'm not sure what you can do robustly with two. I've asked Xiufeng to comment on this thread.
Thanks @mharms. I will open a PR to support noRF in aslcontext files. We can also support separate noRF files, the same way we do for BOLD scans.
@nmrotstein @hgrotzin - @effigies proposed allowing "n/a" as a value, since that is an allowed value for missing/unknown values in TSV files within BIDS. I think that would be a great placeholder for now, but I still want to find out what the actual images mean from someone who has a solid handle on the sequence (e.g., Danny Wang).
I bundled the n/a option into my PR (#1884), so if anyone who's interested in that PR could take a look at my proposed changes, that would be much appreciated.
FWIW, in that paper, they collected 200 noise volumes, so I'm not sure what you can do robustly with two. I've asked Xiufeng to comment on this thread.
@mharms I haven't used NORDIC with ASL before, but in my experience people typically acquire only ~3 noRF volumes for BOLD scans, and the folks who use NORDIC the most seem okay with that, so maybe 2 are sufficient for ASL.
EDIT: I also added the optional "part" entity to ASL data in my PR, since if folks are using NORDIC, they're going to want phase data.
Thanks @tsalo ! This should work for now; will this PR being merged reflect in the BIDS validator? If not, is there some other way for us to test that it works for our data once merged?
@hgrotzin or I can reach out to Danny regarding the purpose of these volumes (we’ve been discussing the sequence in a separate thread), and will let you know if/when we hear back.
On Mon, Aug 5, 2024 at 2:33 PM Taylor Salo @.***> wrote:
I bundled the n/a option into my PR (#1884 https://github.com/bids-standard/bids-specification/pull/1884), so if anyone who's interested in that PR could take a look at my proposed changes, that would be much appreciated.
FWIW, in that paper, they collected 200 noise volumes, so I'm not sure what you can do robustly with two. I've asked Xiufeng to comment on this thread.
@mharms https://github.com/mharms I haven't used NORDIC with ASL before, but in my experience people typically acquire only ~3 noRF volumes for BOLD scans, and the folks who use NORDIC the most seem okay with that, so maybe 2 are sufficient for ASL.
— Reply to this email directly, view it on GitHub https://github.com/bids-standard/bids-specification/issues/1762#issuecomment-2269957030, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOVO2MZT7R6Q3A6THQFV443ZP7VSPAVCNFSM6AAAAABFYDOEEWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRZHE2TOMBTGA . You are receiving this because you were mentioned.Message ID: @.***>
You should actually be able to replace dummy volumes in the aslcontext file with n/a now. It should work without the new PR, since n/a is an allowed value for TSV files already. I might need to make changes on ASLPrep's end, but we can follow up on that in an ASLPrep issue if necessary.
I look forward to hearing how Danny Wang describes these volumes.