[MINC-users] MINC to DICOM

[Alexandre CARMEL-VEILLEUX]

On Fri, Oct 03, 2008 at 10:02:37AM -0400, Jonathan Harlap wrote:
> 
> That I described what a user group wanted doesn't mean that I agreed
> that their desire was reasonable or feasible...  And if you are
> instead referring to my counterarguments when discussing a particular
> US-gov't-employed Italian's insanity, then you'll recall that what I
> said might be feasible would be:
> 
> minc = dcm2mnc (dicom1)
> dicom2 = mnc2dcm (minc)
> minc2 = dcm2mnc (dicom2)
> 
> dicom2 = mnc2dcm ( dcm2mnc( dicom2 ) )
> and
> minc2 = dcm2mnc ( mnc2dcm ( minc2 ) )
> 
> The distinction is pretty important - it states that the first
> conversion you do is lossy, but that afterwards you could back and
> forth happily, given properly written converters.

This is not necessarily so. MINC can be used to encode all group/element pairs
in the original DICOM files (some converters already do this) and given that
information, it is possible to essentially spit out dicom1.

Now, given any amount of processing whatsoever, the value of the original
DICOM headers decreases rapidly, but using them as baseline and then using
the more standard MINC properties (that probably refelect the processing)
to override some of the DICOM header, you could end up with an acceptable
DICOM image for processed data... To a point.

Couple of extra thoughts:

1) After some processing has been done to an image, there's no valid reason
to keep any odd-numbered DICOM groups. We can't tell what they mean so we can't
ascertain in any way their validity.

2) Most minc (1.x) tools don't seem to preserve headers consistently. No idea how
this applies to MINC 2.x. I haven't looked at this much in the last 3 years however
so this point isn't so valid, but if someone actually makes that mnc2dcm, that person
will have to think about that.

3) Most DICOM code I've seen in converters was awfully crude and fails on at least
some input files (we've converted DICOMS from hundreds of sites and many many thousand
scans). Usual culprit being either PixelData encoding or variable sized DICOM elements
(i.e.: anything with a length attribute of -1).

Rather funny to see the amount of activity this mnc2dcm thread generates seeing as
no-one actually wants to do it (for good reason).

Alex