<div dir="ltr"><div>To avoid repetition, I'll just point to my comments 3 years ago on this topic [1].  Since then we've continued to work on DICOM in research contexts [2] and we still think it's a neat idea.  The software is coming along nicely too [3].</div><div><br></div><div>Cheers,</div><div>-Steve</div><div><br></div><div>[1] <a href="https://mail.scipy.org/pipermail/nipy-devel/2014-July/010143.html">https://mail.scipy.org/pipermail/nipy-devel/2014-July/010143.html</a><br></div><div><br></div><div>[2] <a href="https://peerj.com/articles/2057/">https://peerj.com/articles/2057/</a><br></div><div><br></div><div>[3] <a href="https://github.com/QIICR/dcmqi">https://github.com/QIICR/dcmqi</a><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 3, 2017 at 8:40 AM, Bennet Fauber <span dir="ltr"><<a href="mailto:bennet@umich.edu" target="_blank">bennet@umich.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So, presumably, compatibility will be maintained if other software<br>
reads and uses vox_offset.<br>
<br>
It looks, from a brief scan, that the size of the JSON extension is<br>
not fixed, as it can accommodate multiple scanner vendors' versions of<br>
DICOM?<br>
<br>
Sorry for the naive questions.<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, Jul 3, 2017 at 8:29 AM, Matthew Brett <<a href="mailto:matthew.brett@gmail.com">matthew.brett@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> On Mon, Jul 3, 2017 at 1:19 PM, Bennet Fauber <<a href="mailto:bennet@umich.edu">bennet@umich.edu</a>> wrote:<br>
>> With respect to Romain's comment, yes, backward compatibility is<br>
>> important.  How will this affect NIfTI compatibility with other<br>
>> software?  Is this proposed change to the NIfTI format going to be<br>
>> NIfTI-2?  Is there some sort of review process that this is going<br>
>> through like NIfTI-1?<br>
><br>
> I think we're OK with backwards compatibility, because the JSON header<br>
> extension would be a "header extension" in this sense:<br>
><br>
> <a href="https://nifti.nimh.nih.gov/nifti-1/documentation/faq#Q21" rel="noreferrer" target="_blank">https://nifti.nimh.nih.gov/<wbr>nifti-1/documentation/faq#Q21</a><br>
><br>
> Any compatible NIfTI1 reader should happily skip over the header<br>
> extension data it does not recognize - and I think that's true of the<br>
> major packages.<br>
><br>
> As for the review process, that's what we're doing in these<br>
> discussions - I drafted up a spec a while ago, that is here:<br>
><br>
> <a href="https://github.com/nipy/nibabel/wiki/json-header-extension" rel="noreferrer" target="_blank">https://github.com/nipy/<wbr>nibabel/wiki/json-header-<wbr>extension</a><br>
><br>
> That was the first pass.  See this thread for the initial discussion:<br>
><br>
> <a href="https://mail.scipy.org/pipermail/nipy-devel/2014-July/010087.html" rel="noreferrer" target="_blank">https://mail.scipy.org/<wbr>pipermail/nipy-devel/2014-<wbr>July/010087.html</a><br>
><br>
> I'm just in the process of finishing up a second pass. When I've done<br>
> that, and we've done another pass at discussion here, I'll email out<br>
> to the AFNI / SPM / FSL mailing lists to see if they've got any<br>
> thoughts.   Can you think of anywhere else the discussion should go?<br>
><br>
> Cheers,<br>
><br>
> Matthew<br>
> ______________________________<wbr>_________________<br>
> Neuroimaging mailing list<br>
> <a href="mailto:Neuroimaging@python.org">Neuroimaging@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/neuroimaging" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/neuroimaging</a><br>
______________________________<wbr>_________________<br>
Neuroimaging mailing list<br>
<a href="mailto:Neuroimaging@python.org">Neuroimaging@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/neuroimaging" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/neuroimaging</a><br>
</div></div></blockquote></div><br></div>