[Neuroimaging] JSON-LD and DICOM?

[Chris Gorgolewski]

Hi,

I don't think that nibabel should impose any schema on the JSON data stored
in the header extension, but for what it's worth most fields in BIDS JSON
sidecars have one to one correspondence to DICOM tags (and even use the
same names). There are some exceptions - for example SliceTiming or
PhaseEncodingDirection.

There are some ongoing conversation about dropping the sidecar JSON files
in BIDS 2.0 and storing all metadata in a header of the binary image file
(which could be NIFTI, DICOM, MINC... time will tell!)

Best,
Chris

On Fri, Jun 30, 2017 at 1:07 PM, Bennet Fauber <bennet at umich.edu> wrote:

> Pardon my ignorance, but what is the relationship between the proposed
> extension to the NIfTI and proposed data storage/metadata standards
> like BIDS?
>
> I am not intimately familiar with the BIDS format, but that specifies
> metadata in files external to the images.  Is the intent of the JSON
> extension to the NIfTI format going to replace, supplement, or
> replicate information that might be stored elsewhere?
>
>
>
>
> On Fri, Jun 30, 2017 at 3:57 PM, Matthew Brett <matthew.brett at gmail.com>
> wrote:
> > Hi,
> >
> > On Fri, Jun 30, 2017 at 5:35 PM, Jasper van den Bosch <japsai at gmail.com>
> wrote:
> >> Hi all,
> >> I have to agree with Andrey on the yet another format argument. Also,
> tools
> >> will have to convert it to other formats anyway, so if you do end up
> storing
> >> something in the header, as long as you document it, just like you would
> >> other nibabel properties, I'd go for the simplest solution.
> >
> > There is going to be a JSON header extension quite soon, so it's not
> > really another format, but another way of storing metadata in NIfTI.
> > Then the question is - should we also store DICOM metadata there?
> >
> >> I did a little survey among niprov users and it turns out they usually
> don't
> >> end up using the header to store the metadata, because the "central"
> storage
> >> can more easily keep track of the relationships between files.
> >> And if the file is overwritten, or moved, the metadata remains.
> >
> > I think the DICOM / NIfTI thing is partly cultural.  If you're a C++ /
> > cluster sort of person, you tend to prefer DICOM, because there are
> > C(++) libraries to read the DICOMs, and setting up the libraries /
> > compiling isn't much of an issue, because everything you need can
> > easily be set up on the cluster.  If you're a Python / laptop sort of
> > person, then you tend to prefer NIfTI because it's such a simple
> > format that it's easy to write your own code to manipulate it, and the
> > code remains fairly readable, and no extra setup is needed other than
> > a `pip install pydicom`.
> >
> > The JSON header extension is also an extremely obvious idea, that we
> > need to store just a little bit more metadata than we have now.  So -
> > why not store a lot more metadata than we have now?
> >
> > Cheers,
> >
> > Matthew
> > _______________________________________________
> > Neuroimaging mailing list
> > Neuroimaging at python.org
> > https://mail.python.org/mailman/listinfo/neuroimaging
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20170630/716fa9e1/attachment.html>