[MINC-development] experiments with EBTKS and N3

Andrew Janke a.janke at gmail.com
Mon Aug 20 09:18:20 EDT 2012


>> Indeed, my approach to this a while ago was to write this:
>>
>>     https://github.com/BIC-MNI/mincfftw
>
> That link seems broken. But I assume you're attempting to write a GPL
> wrapper?

whoops, that should be this:

   https://github.com/BIC-MNI/mincfft

It's a stand alone minc tool to do FFT's and magnitude/phase
calculations. I wrote it to take care of FID reconstructions a while
back. The licence on this code is supposed to be GPL but I note I have
copied in the wrong licence file (std MINC) while copying things from
CVS to GIT.

So no, not a wrapper, but a stand alone GPL tool to do FFT's on MINC volumes.

> Since mincfft really serves no purpose, can we just directly call
> FFTW? Is there still a reason to keep the GPL out of MINC?

The long standing reason to keep GPL out of MINC is to assist with any
possible future use by commercial companies. (Siemens might just one
day decide to export files in MINC). There are also a few ex MINC devs
who have gone on to do commercial development who might comment.
Granted these sort of restrictions have now been shown to be not that
much of an issue with the test of time. Remember that MINC is now a 15
year old project!

Note also that there are GPL MINC packages, most of what Jason Lerch
wrote for example. The hard part is keeping all the licences straight
in metapackages. You will also find de-GPL'ifiying in MINC mincsample
in the develop branch is an example:

   https://github.com/BIC-MNI/minc/tree/develop/progs/mincsample

I originally used the GPL version of this in GSL but switched the
original mt19937 code with a more liberal licence:

   https://github.com/BIC-MNI/minc/blob/develop/progs/mincsample/mt19937ar.h



a


More information about the MINC-development mailing list