[MINC-users] MINC to DICOM

[Burt Crépeault]

On Fri, Oct 3, 2008 at 9:55 AM, Jonathan Harlap
<jharlap at bic.mni.mcgill.ca>wrote:

> 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,


Of course! In a research environment, the requirements for the back
conversion are perhaps a little less important, but if you are ever going to
write a minc-based application that re-inserts images in a PACS, you cannot
afford to lose any information. No matter where the header information comes
from, it's gotta find its way back into the DICOM series.


> 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.


Some of the DICOM headers are not going to change (patient, study headers),
others will change according to image transformations (such as you describe
above), the rest may be calculated by your application logic (I'm thinking
about UIDs for instance). In the end, everything must converge back into
DICOM.

>
>
> 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.


I can't argue with that. The important point is, if a mnc2dcm utility is
ever to be written, it has to allow re-insertion of some external header
content. I agree this would break the symmetry of the dcm2mnc/mnc2dcm
diptych but in my view, it's a must-have feature.

As an interesting side-effect to this model, it would allow the calculation
of header content to be outside the mnc2dcm tool. The difficult ones could
be omitted from mnc2dcm altogether while still be possible for those wanting
to dig in to the problem. Eventually, some of those would find their way
into future iterations of mnc2dcm.

my 2¢

Burt.