[MINC-users] MINC to DICOM

Fri Oct 3 00:21:26 EDT 2008

:) well my subjective truth is more of a half-full nature: the vast
majority of users that ask me about a minc-to-dicom conversion, simply
want to be able to load a minc volume in their favorite dicom viewer
(and don't want to bother with building and learning Display - who
could blame them?). As such, 90% of these would be perfectly happy
with having a way to turn a minc volume into valid dicom.

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
back-and-forth conversion with nii2mnc/mnc2nii and expect to get the
same result either - but I could be wrong).

In any event, I agree completely that the root of the problem is
expectation, but I don't think that should be a reason for not
providing a relatively simple tool, provided with sufficient
disclaimers, that I think a fairly large number of people would find
very useful. Essentially, a 'proper' minc implementation of the hacks
that Andrew and you are suggesting.

But if nobody is interested or has done it already; I hope to find
time or $$ to take care of this, because in my mind it is one of the
largest 'holes' in minc (this and the fact that the minc2 internal
compression isn't working as well as one might hope).

-- A

On Thu, Oct 2, 2008 at 11:10 PM, Jonathan Harlap
<jharlap at bic.mni.mcgill.ca> wrote:
> <reposted from the right account - sorry if it shows up twice>
>
> While this has been talked about many times, I have yet to see someone
> do it reliably.  I've had this discussion a few times too many by now,
> and so I think it's time to summarize my experiences here, where
> future seekers of such info might find it, with the caveat that all of
> this should be considered my subjective truth rather than a universal
> truth.
>
> The root of the issue seems to be one of expectation: If all you
> expect is a set of DICOM files each containing one slice with the
> header containing only the most basic of coordinate space definition
> info, then this conversion is relatively simple and you can hack it
> together with a combination of minctoraw and your DICOM package of
> choice (dicom3tools, dcmtk, etc...).  However, in my experience people
> seem to have this interesting notion that they should be able to take
> some DICOM data off a scanner, run it through dcm2mnc and then back
> through a fictional mnc2dcm and that the resultant files will be
> identical to the input files, or that they can take a minc file
> produced by some processing pipeline and convert them to DICOM while
> retaining all the information that was in the source minc.  As the
> header structures of the two formats are entirely different,
> specifically where the minc header can store fairly arbitrary data
> with user-defined keys while DICOM has a much more regimented [and
> restricted] header structure, it is fairly obvious to anyone who looks
> at this problem in detail that the fictitious ideal mnc2dcm cannot
> exist.  If that is agreed upon, noting that I have yet to meet the
> DICOM user who is willing to agree to this, then the question of what
> DICOM header info to populate given the very flexible minc header can
> be discussed and, in my experience, is unlikely to be resolved - at
> least not in a manner that would allow for one tool to satisfy the
> needs of the larger set of possible users.  The most often outcome
> seems to be that a group who only uses minc in one particular way
> defines their own way of mapping the minc header attributes that they
> care about into DICOM private elements and consequently writes a
> conversion script that other groups will find of little use.
>
> Sorry to have to paint such a dark picture of this process - but this
> is simply my observation of the issue.  If you want to give another
> group's bad hack converter a try (where LONI Debabeler was your first
> bad hack converter attempt), you can try NIH's MIPAV, but I'm guessing
> you'll find it differently unsuccessful.  I'm not well informed about
> NIFTI-1 tools out there, but I'd guess that there are also hack
> nii2dcm-type tools out there which you could chain onto mnc2nii.
>
> Cheers,
> J
>
> On Thu, Oct 2, 2008 at 10:50 PM, Alex Zijdenbos <alex at bic.mni.mcgill.ca> wrote:
>> <soapbox>
>> While I understand Andrew's reluctance towards a minc-to-dicom
>> converter and I also understand some of the technical issues
>> surrounding that type of conversion, it is undeniably a need that
>> exists and if we (the minc community) are somewhat serious about
>> wanting people to use minc, I think we have little choice but to
>> provide such a converter sooner or later. I myself get requests for
>> this on a weekly basis (twice just today in fact).
>>
>> There are a few efforts out there that claim to be able to do this
>> (MIPAV, LONI debabeler, ...), but as far as I know they are all flawed
>> in some way or another - and mostly in that they are obviously not
>> part of minc 'proper'. IMHO, a minc-to-dicom converter *should* really
>> come from the makers of minc; and as a community, at some point we
>> should get off our high horse and accept that - well - perhaps we
>> should actually make it easy for people to interact with minc...
>>
>> Just my $0.02... and yes, I know that does not answer the most
>> important question: "who?" ... Any takers to do it (or fund it)?
>> </soapbox>
>>
>> -- A
>>
>> On Thu, Oct 2, 2008 at 10:10 AM, Andrew Janke <a.janke at gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Fri, Oct 3, 2008 at 12:03 AM, Simon Fristed Eskildsen <se at hst.aau.dk> wrote:
>>>> Yes, I know this has been an issue previously discussed. Did anyone ever solve the conversion?
>>>
>>> Well for myself I am still sticking well away from such heinous
>>> conversions. I would suggest that you take a look at david clunies
>>> dc3tools software. I seem to remember that they can read a RAW/Tiff
>>> file which you can certainly make with the MINC tools.
>>>
>>> Failing that surely ITK can write a DICOM file?  it can read MINC via
>>> leila's extensions so that might be your saviour.
>>>
>>> --
>>> Andrew Janke - andrew.janke at anu.edu.au
>>> Department of Geriatric Medicine, ANU
>>> (a.janke at gmail.com || http://a.janke.googlepages.com/)
>>> Canberra->Australia    +61 (402) 700 883
>>> _______________________________________________
>>> MINC-users at bic.mni.mcgill.ca
>>> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>>
>>>
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>