[01acheru]

Well, I really hope you succeed on your experiments, but right now it seems to me that ML introduces an error factor we still cannot precisely account for.

It looks like you are proposing some kind of mixed approach, not a simple “less data, faster scan, ML to the rescue”. I understand how MRI works but you are surely and obviously much more knowledgeable than me, so I simply wish you luck!

My problem with the article comes from reading that someone telling about using generative models on health data, I don’t think is time for this yet.

[notarandomer]

Thanks! I agree taht generative models on their own are definitely more risky than methods that combine ML for regularization along with data consistency terms that force the reconstructions to be consistent with the acquired data.

[01acheru]

My opinion is pretty much worthless but I think this is a much more sensible approach, using the strengths of ML but putting constraints on the outputs.

Just a simple question: to achieve a guarantee that those results are at least equal or better than the ones we have now on our battle tested setups, shouldn’t we use the same sampling we use on a “default” MRI? I mean… using those reconstruction algorithms to try to achieve a better result, without downsampling so that a standard reconstruction can still be performed to be checked against?

[notarandomer]

"Default MRI" (i.e. fully sampled) should definitely be acquired when possible when testing this out to compare to gold standard. But the benefit of using ML methods in the fully sampled case would be minimal (maybe some denoising), whereas they have a much larger effect when acquiring highly undersampled data that traditional reconstruction methods fail at. It's also not always possible to get fully sampled reference data. For example in functional MRI you might not be able to get matched fully sampled data because the benefit of undersampling is in improving the temporal resolution. These cases are definitely more researchy and less clinical though, and in my work we add a 2 minute highly undersampled scan to current standard protocols and compare what we can reconstruct from our 2 minute scan compared with the fully sampled (but often lower resolution) standard scans.

[lostlogin]

> "Default MRI" (i.e. fully sampled) should definitely be acquired when possible when testing

It seems unlikely you wouldn’t appreciate this already, but clinical MRI has not fully sampled in a long time. Between the old and the new - reduced phase resolution (image plane and slice plane) parallel imaging, compressed sense (or sensing), reduced frequency resolution with partial echo techniques, high reconstruction max trim with low acquisition matrix, the list is quite long.

The changes in resulting artefacts as acceleration techniques change (eg high compressed sense values) is a bit of a change to how people work. Very digital looking artefacts are just gross.

Thanks for your work! We need more speed.

[notarandomer]

Thanks for the comment! You're right, I was oversimplifying saying that default MRI would be fully sampled. My main point still stands, you can't just chuck ML onto current protocols to do a direct comparison with ML and more conventional reconstruction methods to give clinicians access to both and expect an improvement (beyond potentially denoising) because the conventional scans are already very good at what they do. Where ML can help is in cases where we can't produce conventional scans (e.g. with very short scan times or high temporal resolution).

[lostlogin]

Those striving for shorter scan times (eg functional) go to such massive lengths that it blew my mind when I encountered it on a research magnet. Every millisecond counted.

Watching the mental gymnastics used to deal with multi band/simultaneous multi slice (or whatever vendors call it) with functional MRI was impressive to me.

Using ML to work out voxel results in such low spacial resolution scans has got to be scary.