OSIPI ASL pipelines overview
ExploreASL is a pipeline and toolbox for image processing and statistics of arterial spin labeling perfusion MR images. It is designed as a multi-OS, open source, collaborative framework that facilitates cross-pollination between image processing method developers and clinical investigators.
The software provides a complete head-to-tail approach that runs fully automatically, encompassing all necessary tasks from data import and structural segmentation, registration and normalization, up to CBF quantification. In addition, the software package includes and quality control (QC) procedures and region-of-interest (ROI) as well as voxel-wise analysis on the extracted data. To-date, ExploreASL has been used for processing ~10000 ASL datasets from all major MRI vendors and ASL sequences, and a variety of patient populations, representing ~30 studies. The ultimate goal of Explore ASL is to combine data from multiple studies to identify disease related perfusion patterns that may prove crucial in using ASL as a diagnostic took and enhance our understanding of the interplay of perfusion and structural changes in neurodegenerative pathophysiology.
Additionally, this (semi-)automatic pipeline allows us to minimize manual intervention, which increases the reproducibility of studies.
More info coming soon! This website is preliminary, and will be improved soon. Don't forget to check the contents of this website (there is a content button in the upper right or left corner). Pleased to mention that our ExploreASL paper is in print at Neuroimage! Latest releases are available for download HERE and in continuous development on GitHub. Please contact the co-creators for more information:
Also: please don't hesitate to contribute to ASL BIDS
Nice processing reproducibility we got when testing this release between Matlab versions, OSes and machines
From these results with 10 heterogeneous test datasets, it seems that we have fixed the reproducibility between Matlab versions, and Unix-type OS/machine differences are small. However, still Windows vs Unix-system differences remain, which could be due to JavaVM architecture differences. We could test this by running these tests but disabling the JavaVM.