[MINC-users] MINC to DICOM

[Jonathan Harlap]

Your view seems to coincide with Alex's, where you assume that what
you're trying to do is take a minc produced by dcm2mnc and then run it
straight back through mnc2dcm, whereas almost every user I've
interacted with who wanted mnc2dcm actually wanted to convert some
processed result so they could load those results into a non-minc
software package (which may be a PACS system).  In that case, using
the original DICOM headers from something further up the processing
chain doesn't make sense.

As an aside, if you want a dcm2X (dicom) => image + headers, your X =
analyze.  One of the selling points of minc is that you keep all this
info together in one file that's easy to manage, and that its header
structure is very freely extensible to store arbitrary (user-defined)
attributes.

J


On Fri, Oct 3, 2008 at 9:46 AM, Burt Crépeault
<burt.crepeault at crulrg.ulaval.ca> wrote:
> Here's how I see this particular issue.
>
> I don't think that anybody will ever ask for a magical mnc2dcm that figures
> out all the proper DICOM headers to include in the files, other than the
> spatial data. However, a much more realistic and useful feature for
> successful dcm2mnc and mnc2dcm conversions could look like this:
>
> dcm2mnc (<dicom>) => <minc> + <headers>
>
> (the original DICOM headers are extracted and saved in a standard file
> format -- a carefully crafted XML schema comes to mind)
>
> mnc2dcm (<minc> [, <headers>]) => <dicom>
>
> (the mnc2dcm function requires an external header file to reproduce the
> original dicoms, otherwise the header info is simply lost)
>
> That way, whatever transformations happen to the MINC file are independent
> to those happening at the header level. In other words, it entirely up to
> your application logic to track, transform and reinject the headers at
> reconversion time.
>
> Burt.
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>