[MINC-users] MINC to DICOM

[Jonathan Harlap]

On Fri, Oct 3, 2008 at 12:21 AM, Alex Zijdenbos <alex at bic.mni.mcgill.ca> wrote:

> I think we can all agree that expecting
>
>   <dicom> == mnc2dcm( dcm2mnc( <dicom> ) )
>
> is simply not realistic. However, I suspect that a mnc2dcm that would attain
>
>  <minc> == dcm2mnc( mnc2dcm( <minc> ) )
>
> is much more feasible (by the way, I don't believe that you can do the

Not as feasible as you seem to think, IMO:

Givens:
(A) A minc file can store as attributes virtually any user-defined
data with the attribute name (the datum's key) being entirely up to
the user.
(B) DICOM files are actually just a stream of elements recorded on
disk, where each element is identified with a group and element
number, each 16 bits.
(C) DICOM group numbers that are even are publicly defined and so
cannot be used for arbitrary data whereas odd group numbers are
private and so can be used for anything but only the creator
application can be expected to use such data.

Now consider the statement "<minc> == dcm2mnc (mnc2dcm( <minc> ) )".
We have two approaches:
(1) Designate a single private element to contain a very long string
which contains some serialization of the minc header in its entirety,
and modify dcm2mnc to look for this private element, confirm that the
creator application was mnc2dcm, and then use that single value to
populate the entire header.
(2) Create a mapping function such that each minc attribute is
assigned to a unique private element in the output DICOM file.  This
must be a consistent and reliable mapping in order for dcm2mnc to know
about it and be able to reconstruct the original attributes without
additional user input.

I think we can trivially agree that approach (1) is completely
useless, as it doesn't produce useful DICOM files, it only produces a
hack by which a hacked dcm2mnc could satisfy the stated requirement.
In other words, your test case will pass but the unstated test case
that demonstrates that the produced DICOM is useful would fail.

Approach (2) seems, at first blush, more interesting, and certainly
would support both your test and the usefulness test.  However, if we
combine givens (B) and (C), we can show that only 2^15 private
elements can be defined in the universal mapping function before we
run out of elements in which to store the attribute values.  As we
have to deal with given (A), which implies that there is no limit on
the number of possible minc attributes in use over the universe of
minc files, it becomes clear that approach (2) will fail.  This is, of
course, putting aside issues about how you are going to add new
elements to the universal mapping function in such a way that no
private element is given to two different attributes, which could
technically be solved with distributed transactions, but is fairly
complicated and really doesn't belong in a simple file format
converter.

So, now we know that you cannot take an arbitrary DICOM or minc
dataset and circularly convert it via the other back to itself,
regardless of which one you start with.  We are back to my original
statement that it all has to do with expectation, and that while
complete conversion is impossible (as just demonstrated, I think) a
partial conversion is possible.  The worst case, as originally stated,
retains only slice position info.  Obviously an intermediate case
exists, and it is only a question of defining which elements and
attributes are used in the mapping - but this "only" is an ugly job
fraught with disagreement - as was also my original statement.


Defense rests ;)

Cheers,
J