[Neuroimaging] JSON-LD and DICOM?

[Bennet Fauber]

With respect to Romain's comment, yes, backward compatibility is
important.  How will this affect NIfTI compatibility with other
software?  Is this proposed change to the NIfTI format going to be
NIfTI-2?  Is there some sort of review process that this is going
through like NIfTI-1?



On Mon, Jul 3, 2017 at 8:00 AM, valabregue <romain.valabregue at upmc.fr> wrote:
>
>
> On 07/03/2017 11:54 AM, Matthew Brett wrote:
>>
>> Hi,
>>
>> On Mon, Jul 3, 2017 at 9:21 AM, valabregue <romain.valabregue at upmc.fr>
>> wrote:
>>>
>>> Hi all,
>>>
>>>
>>>
>>> On 06/30/2017 09:57 PM, Matthew Brett 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?
>>>
>>> Yes we should store the Dicom metadata, this is the less effort, and it
>>> fulfills the needs ... May be I miss the point. What would be the
>>> alternative ? (to define a new ontologie for the metadata ?)
>>>
>>> I am using (since a couple a years) the dcmstack that convert dicom to
>>> nifti
>>> + a json file (with all dicom meta data AND more importantly all private
>>> siemens fields). The nice feature of this conversion is that it
>>> aggregates
>>> field that are identical in all split dicom file (and keep array only
>>> when
>>> it is necessary).
>>>
>>> Why not use this solution ?
>>
>> Actually, the reason I'm interested in this now is because I am
>> thinking about how to integrate dcmstack into nibabel.  So I wanted to
>> fuse the dcmstack metadata analysis into the NIfTI header.
>>
>>> I do not see any clear advantage to have this meta data information
>>> directly
>>> in the nifti file (a naming convention make it easy to keep a link)
>>
>> Well - let's say there are two options:
>>
>> * A NIfTI file with a JSON header, where the JSON header contains the
>> DICOM metadata;
>> * A NIfTI file with a JSON header, where the the DICOM metadata is in
>> a separate JSON file.
>>
>> To me the first seems more obvious than the second.  Surely it also
>> makes things like provenance just a little bit easier - because it is
>> just a little bit harder to lose the relationship between the image
>> and the metadata.
>
> Well may be it is not a big deal to make both possible ... ?
>
> It looks like nifti files extension  img+hdf or .nii
> well I agree with you: all in once is more obvious. ( like for nifti file I
> prefer the .nii files). The only disadvantage I see is that you may loose
> some nifti compatibility with other software that expect only a fix header.
> (345 byte). So depending on what you plan to do, both may be chosen.
>
>
> Romain
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging