aslcontext.tsv dummy volumes #1762
Comments
|
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 |
|
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 |
|
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
<#1762 (comment)>,
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 |
|
I do think |
|
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 #1762 (comment). 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 - NRotstein@mednet.ucla.edu |
|
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 
Maybe we could use |
|
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 @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 I think it might be complex for ASLprep to determine which particular volumes to use within the image given that
I think it might be easier to create a new volume type, such as |
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:
So, either 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 @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
@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
<#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
<#1762 (comment)>,
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 I look forward to hearing how Danny Wang describes these 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!
The text was updated successfully, but these errors were encountered: