search

bids-apps / MRtrix3_connectome

Generate subject connectomes from raw BIDS data & perform inter-subject connection density normalisation, using the MRtrix3 software package.
http://www.mrtrix.org/
Apache License 2.0
50 stars 26 forks source link

Craddock200 and Craddock400 not labeled in ascending order #66

Closed paul-triebkorn closed 4 years ago

paul-triebkorn commented 5 years ago

Hi developers,

I was experiencing an issue when running the BIDS app with the settings "--parcellation craddock200 --output_verbosity 3" The pipeline crashed when trying to generate node meshes via the command

run.command('label2mesh parc.mif nodes.obj')

with

"[ERROR] Error allocating memory for scratch buffer"

Couldn't find a reason why it wouldn't work, enough memory was available.

I proceeded to run the pipeline with "--output_verbosity 2" and then noted "0" rows/columns in the resulting structural connectome.

Upon checking for unique values in "ADHD200_parcellate_400.nii.gz" and "ADHD200_parcellate_200.nii.gz" I only find 352 and 191. The maximum intensity in the image is 400, 200 respectively.

So there are values missing inbetween.

I assume that is the reason for label2mesh to fail ?

Should one add another labelconvert step for these 2 parcellations ?

best Paul

Lestropie commented 5 years ago

Hi developers

:rofl:

Just me... :wave:

Yup, you're right; there's skipped values all over the place...

@ccraddock: Is this a known / documented limitation of these data?

It wouldn't surprise me if label2mesh bugs out on such data and doesn't give very informative feedback. Indeed I'm not even sure if it can work: it writes a multi-object .obj file where the objects are just indexed and not referenced by any kind of unique identifier, meaning that there would need to be empty objects corresponding to the absent parcels, and I won't know whether or not the .obj format permits that until I try it (which needs to happen at the MRtrix3 end).

It also sounds like there is a problem in the structural connectome construction that is not tied specifically to label2mesh; I would have expected that tck2connectome would generate a warning regarding the non-existent parcels (though this warning would be hidden unless running with elevated terminal verbosity), but should still run to completion nonetheless. I'll add it to my list of issues to reproduce and resolve for an update (seems to be a lot all of a sudden!).

Thanks for the report!

Rob

ccraddock commented 5 years ago

Hey Robert,

Sorry if I missed this somewhere.

As far as the labelling, there are several reasons why some of the parcels could be empty, including transforming the data between spaces and resolutions. Is it too difficult to just ignore the numbers that do not exist in the atlas? The number is arbitrary and you could just renumber as needed too.

Regards, Cameron

On Sun, Sep 29, 2019 at 10:07 PM Robert Smith notifications@github.com wrote:

Hi developers

🤣

Just me... 👋

Yup, you're right; there's skipped values all over the place...

@ccraddock https://github.com/ccraddock: Is this a known / documented limitation of these data?

It wouldn't surprise me if label2mesh bugs out on such data and doesn't give very informative feedback. Indeed I'm not even sure if it can work: it writes a multi-object .obj file where the objects are just indexed and not referenced by any kind of unique identifier, meaning that there would need to be empty objects corresponding to the absent parcels, and I won't know whether or not the .obj format permits that until I try it (which needs to happen at the MRtrix3 end).

It also sounds like there is a problem in the structural connectome construction that is not tied specifically to label2mesh; I would have expected that tck2connectome would generate a warning regarding the non-existent parcels (though this warning would be hidden unless running with elevated terminal verbosity), but should still run to completion nonetheless. I'll add it to my list of issues to reproduce and resolve for an update (seems to be a lot all of a sudden!).

Thanks for the report!

Rob

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/BIDS-Apps/MRtrix3_connectome/issues/66?email_source=notifications&email_token=AANFGWBUH3MX6SMVTOKKJDTQMFUO3A5CNFSM4I2WVXD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD74IZBI#issuecomment-536382597, or mute the thread https://github.com/notifications/unsubscribe-auth/AANFGWHTQ6FIMV6MDKECSATQMFUO3ANCNFSM4I2WVXDQ .

-- Associate Professor of Diagnostic Medicine, Dell Medical School at the University of Texas at Austin Director, Computational NeuroImaging Lab http://computational-neuroimaging-lab.org/ Founding Chair, Organization for Human Brain Mapping Open Science Special Interest Group Co-Founder, The Neuro Bureau http://neurobureau.org/ Impact Story https://impactstory.org/CameronCraddock Google Scholar Citations http://scholar.google.com/citations?user=lZ9hwSsAAAAJ&hl=en GitHub https://github.com/ccraddock SlideShare http://www.slideshare.net/CameronCraddock

Check out my blog Open Science Resources for Contributing to Brain Imaging Research http://blogs.biomedcentral.com/gigablog/2016/03/15/open-science-resources-contributing-brain-imaging-research-guest-blog-cameron-craddock/ Share that Brain @ the International Neuroimaging Datasharing Initiative http://fcon_1000.projects.nitrc.org/! The GigaScience Brainhack Thematic Series http://brainhack.org/brainhack-thematic-series-call-for-papers/ is open for your submission. Submit a paper to the Neuroimage Special Issue on Brain Segmentation and Parcellation http://www.journals.elsevier.com/neuroimage/call-for-papers/brain-segmentation-and-parcellation/ ! The Preprocessed Connectomes Project http://preprocessed-connectomes-project.org/ is now sharing preprocessed versions of the ABIDE and ADHD200 neuroimaging datasets.

Join me at upcoming Brainhack http://brainhack.org/ Events: 2019.07.11 - 2019.13.11 Brainhack Global http://www.brainhack.org/global2019

Lestropie commented 5 years ago

Is it too difficult to just ignore the numbers that do not exist in the atlas?

I'll try to make the requisite changes at my end such that data with missing parcels still process without error; my main concern is:

including transforming the data between spaces and resolutions.

This observation was made in the raw downloaded data, without any transformation or change in resolution; hence why I would have considered it likely that somebody else would have made the same observation at some point.

Rob

Lestropie commented 4 years ago

App should run with these data as of #62. It will however continue to report that some parcels are absent, as they are missing from the original parcellation. It would be possible to provide a lookup table dedicated to these parcellations that would re-map the integer labels in order to remove the gaps, but this would remove correspondence between the resulting connectome and the parcellation in its raw form. So for now I think I'll accept the presence of the warning message.