Skip to content
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

Dicom to nifti conversion usecase #150

Open
cmaumet opened this issue Nov 25, 2024 · 1 comment
Open

Dicom to nifti conversion usecase #150

cmaumet opened this issue Nov 25, 2024 · 1 comment

Comments

@cmaumet
Copy link
Collaborator

cmaumet commented Nov 25, 2024

by @yarikoptic in #146

develop good set of examples for already present common use-cases e.g.
conversion software(s) version specification -- e.g. for dcm2niix and heudiconv
additional manual annotation

See "Examples" in the spec, I think we have a good set of examples... In particular the SPM ones (AFNI and FSL will require more work): https://github.com/bids-standard/BEP028_BIDSprov/tree/master/examples/from_parsers/spm Note that "BIDS-Prov is [...] limited to the capture of data processing, future considerations including other types of provenance are listed in section "Future perspectives" so I think "additional manual annotation" may be out of scope (depending on what this means sorry if I misunderstood). We'll focus on a DICOM to Nifti conversion example when we can with @bclenet

@yarikoptic
Copy link
Contributor

Indeed, this one is a very pragmatic target to example ATM. I wonder how do you see it to look in a current BEP028 form @cmaumet for any particular dataset on openneuro which already has those ConversionSoftwareVersion json attributes added by dcm2niix ?

If I got it right -- then it would be really wasteful to encode identical metadata across a multitude of .jsonld files at files level, and it would be otherwise tedious to maintain some top level .jsonld listing all identical records for multiple files . Tedious in part because renaming or removing a file down the hierarchy would require lookup/changes to .jsonld file "upstairs". I think it is one of the reasons why IntendedFor is also being deprecated where such dependencies via explicit file names mentioning are really hard to maintain (see e.g our abominable helper to rename a file we had to come up with: https://github.com/spatialtopology/ds005256/blob/master/code/rename_file#L88 and think on how would be to extend it in case of .jsonld files as well).

That is why I was looking at .json file level description as discussed in

and initially "example"ed for dcm2niix in bids-standard/bids-specification#1970 (comment) which

  • comes along with data file already - no additional inodes etc
  • could even then be inherited from the top level .json files thus providing very concise record.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants