[MINC-users] MINC to DICOM

[Alex Zijdenbos]

>>  <minc> == dcm2mnc( mnc2dcm( <minc> ) )
>
> I doubt it.  Header info will certainly be lost unless we add our own
> custom dicom tags for history patient name, acquisition, etc.

What does MINC add to a header that wasn't in original dicom? Other
than the history (added) and the explicit slice #/position information
(lost), everything else once came from source dicom data, so why would
it be difficult to put things like patient name back where they came
from, in pretty standard dicom fields?

>> I don't believe that you can do the
>> back-and-forth conversion with nii2mnc/mnc2nii and expect to get the
>> same result either - but I could be wrong).
>
> Wrong.  (Well at least for Nifti-1 if you use it correctly and the
> programs you use on the Nifti-1 file conform to the Nifti-1 spec).

Are you talking about producing an output file in format X and that
output being valid following the spec of X; or of being able to run a
forward conversion followed by a backward conversion and getting the
same result you started with? I was talking about the latter, which
the minc<-> nifti converters definitely don't do. For the fun of it,
try

$ mnc2nii /usr/local/bic/share/mni_autoreg/icbm_avg_152_t1_tal_lin.mnc test.nii
$ nii2mnc test.nii
$ mincdiff  /usr/local/bic/share/mni_autoreg/icbm_avg_152_t1_tal_lin.mnc
test.mnc

and see how identical they are :) And what is worse, on my box (with a
fresh install of mincbundle of this morning), register doesn't even
want to load 'test,mnc'....

Anyways, I don't want to beat a dead (high?) horse but (a) I am still
not convinced that - with some reasonable assumptions - it is really
so untractable, and (b) we are already providing converters that don't
live up to the forward/backward conversion (what's the work -
idempotent? bijective?) expectation.

Yes, I know the answer is "if it is so easy, why don't you do it".
Touche' on that one :)

-- A