-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upload manual segmentations #94
Comments
I don't think BIDS has really thought through this use case yet. Derivative works are easier to handle in a separate repository, with a hyperlink between the two, instead of making a giant repo containing everything. That seems like the fundamental source of friction to me. We could handle this with We could also just make it a completely separate repo and put a note I think the datalad philosophy is good to internalize here: so, in this case, I would say the |
Any dataset might be a derivative of any other dataset, recursively, ad infinitum. So a single |
The manuals segmentations generated in
(I can not edit your issue 😕) The reason for I copied the |
Thank you for your feedback @sandrinebedard and @kousu. I agree it is unrealistic to have a single derivatives/ folder that will accommodate all related research for the next 50 years 😅 . So what we should probably do, for the benefits of the community, is "simply" publish the |
It sounds like the big worry here is denormalization. So, can we just not denormalize? Instead of There could still be some sync issues, but we can detect them by comparing the git timestamps of |
There are currently this many overlapping images between the two:
(I cut out .bval, .bvec and .json files because many of them are themselves duplicated within the datasets, and would overestimate the problem) There's already been quite a lot of drift between the two datasets: diff -rq data-multi-subject spine-generic-processed/ | sort | grep -v ".git" | grep "differ"
|
Some files were added or never copied (I can't tell without looking deeper): diff -rq data-multi-subject spine-generic-processed/ | sort | grep -v ".git" | grep "Only in data-multi-subject"
|
and here's the files that are new, from Sandrine et cie.'s work diff -rq data-multi-subject spine-generic-processed/ | sort | grep -v ".git" | grep "Only in spine-generic-processed"
(full set, too large to fit in a comment: right.txt) I don't understand BIDS! Why are some things in the latter set under Anyway I think we could probably replace |
sorry i'm not sure i understand. I think we need to set up a meeting to discuss this-- GH has its limitations when it comes to explaining stuff, especially given that we don't all come from the same background (misunderstandings often happen, and it would be problematic in this case as it could negatively impact research projects down the line). Let's make sure we are all on the same page. |
We should replace |
because doing that achieves https://en.wikipedia.org/wiki/Database_normalization |
A derivatives to this dataset was created for the contrast-agnostic-sofseg project. The derived dataset is called
spine-generic-processed
. It is currently hosted in the internal server at NeuroPoly Lab. However, at some point, we will make it public (tagging @kousu ).From the
spine-generic-processed
derived dataset, the following manual segmentations were created:Also, the following manual segmentations were duplicated from this repository, to the derived internal repository:
*_gmseg-manual.nii.gz
: GM manual segmentations.The problem is that, by having duplicated data at two different locations, if at some point someone wishes to update the manual segmentation on one of the two database, they won't be in sync anymore, causing possible conflicts and unnecessary future efforts (eg: one researcher would manually correct GM of
sub-ubc02
while it has already been done on the other dataset).We should absolutely avoid this situation. Few ideas:
spine-generic-processed/derivatives/labels/sub-amu01/anat/sub-amu01_T2star_seg-manual.nii.gz
The text was updated successfully, but these errors were encountered: