[MINC-development] mincpik

[Andrew Janke]

On Thu, 23 Jan 2003, Steve ROBBINS wrote:

> > Peter expressed a (fairly good) reason for this a while back to me.  He thinks
> > it shouldn't be included as it then brings perl into the base minc distro.
>
> I'm not convinced by this argument.  MINC already has a tool (albeit a rather
> obscure one) with nontrivial requirements: mincview uses "xv".

And mincpik would add a dependance on ImageMagick (convert) the "competition" to xv. :)

> > Times have changed, perl is fairly ubiquitous, perhaps it is time to drop
> > that rule... Also, with a couple of eager packagers, the configuration
> > could be made to do the work of figuring out where perl lives (if
> > anywhere) and do the right thing.
>
> Yes, absolutely.  We do this already for mni_autoreg, e.g.

I thought '#! /usr/bin/env perl' was the right thing?  <ducks>

> > On the other hand, perhaps a separate package of minc extras

> I think small scripts like volpik fit well in core MINC, myself.  It's along
> the lines of mincdiff and mincedit (and Andrew's minchistory).  It's much
> easier on someone installing from source to get everything at once.  The
> binary package makers are still free to split things up: Debian's packaging
> has separate "minc-tools" and "libminc-dev" packages, for example.

Fine by if you wish to add it but in that case I should do a bit of work such
that it will work somewhat reliably for 2D/3D/4D data.  Anyone have any thought
on what should happen when one asks for a coronal slice from a minc volume that
consists of a single transverse slice?

What the user asked for? :)

--
Andrew Janke   ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor )
Australia->University of Queensland->Centre for Magnetic Resonance
Work: +61 7 3365 4100 || Home: +61 7 3800 4042