search

faskowit / app-multiAtlasTT

brainlife.io version of maTT
MIT License
0 stars 4 forks source link

Can we drop ".label" from the key.txt output? #6

Open soichih opened 5 years ago

soichih commented 5 years ago

Right now, this App generates (or copies from somewhere else?) something like the following content of key.txt

1001    ->  1   == lh.???.label 
1002    ->  2   == lh.L_V1_ROI.label 
1003    ->  3   == lh.L_MST_ROI.label 
1004    ->  4   == lh.L_V6_ROI.label 
1005    ->  5   == lh.L_V2_ROI.label 
1006    ->  6   == lh.L_V3_ROI.label 
1007    ->  7   == lh.L_V4_ROI.label 
1008    ->  8   == lh.L_V8_ROI.label 
1009    ->  9   == lh.L_4_ROI.label

This information is used to construct labels.json for neuro/conmat datatype, which will be used for visualization purpose eventually. To keep the visualization tool to display cleaner label, I am wondering if we can update so that key.txt will contain a bit more condensed labels.

1003    ->  3   == L_MST 
1004    ->  4   == L_V6 
1005    ->  5   == L_V2 
1006    ->  6   == L_V3

lh.L or rh.R seems redundant, and _ROI.label can be stripped because it doesn't really add new information. Basically the same way this paper outputs them

https://www.biorxiv.org/content/biorxiv/early/2018/09/19/350876.full.pdf image

There are other Apps that generate key.txt. We might need to update all of them if we do update the way key.txt is generated.

faskowit commented 5 years ago

we can drop the .label ... but I don't think we can drop the lh.L ... because there is no guarantee that the label names will have and "L" or and "R" in the name that is read from the atlas. Same goes for _ROI.... you are seeing this in just one atlas, but it's not the same across atlases/parcellations.

faskowit commented 5 years ago

but don't you think this should be handled later on, like at the cm generation?