With nl_subject04_grid_0.mnc being the output of minctracc in nonlinear mode:

file: nl_subject04_grid_0.mnc
image: signed__ double -1.7976931348623157081e+308 to 1.7976931348623157081e+308
image dimensions: vector_dimension zspace yspace xspace
    dimension name         length         step        start
    --------------         ------         ----        -----
    vector_dimension            3      unknown      unknown
    zspace                    166            2         -163
    yspace                    166            2         -183
    xspace                    144            2         -143

> mincstats -min -max nl_subject04_grid_0.mnc 
*** mincstats - reported min (-11.2532) doesn't equal header (-1.79769e+308)
*** mincstats - reported max (8.93648) doesn't equal header (1.79769e+308)
Min:               -11.25319685
Max:               8.936475648

Running mincreshape, 1st case (doesn't work):

> mincstats -min -max nl_subject04_grid_0_short_1.mnc
*** mincstats - reported min (1.79769e+308) doesn't equal header (-1.79769e+308)
*** mincstats - reported max (-1.79769e+308) doesn't equal header (1.79769e+308)
Min:               1.797693135e+308
Max:               -1.797693135e+308

Running mincrshape, 2nd case: setting arbitrary limited image range (works):

> mincstats -min -max nl_subject04_grid_0_short_2.mnc
*** mincstats - reported min (-11.2535) doesn't equal header (-100)
*** mincstats - reported max (8.93721) doesn't equal header (100)
Min:               -11.25352865
Max:               8.937209125

Running mincreshape with -normalize (doesn't work) :

> mincstats -min -max nl_subject04_grid_0_short_3.mnc 
*** mincstats - reported min (1.79769e+308) doesn't equal header (-1.79769e+308)
*** mincstats - reported max (-1.79769e+308) doesn't equal header (1.79769e+308)
Min:               1.797693135e+308
Max:               -1.797693135e+308

Hi,
We are getting mosaic dicoms in a form that dcm2mnc doesn't cope with. ITK utilities appear to deal with them OK. Do you want some examples? Let me know the best way to send.

Trying the following on a directory of DICOMS:

dcm2mnc -anon -usecoordinates -dname ''  -fname 512IMG_%A 512IMG_20131129_105350928 minc/

Things start off okay:

> ls minc/
512IMG_1.mnc  512IMG_2.mnc

But then:

> ls minc/
512IMG_1.mnc  512IMG_2.mnc  512IMG_3.mnc  512img_20131129_101659_2e2a_mri.mnc  512img_20131129_101659_2e3a_mri.mnc  512img_20131129_101659_2e4a_mri.mnc  512img_20131129_101659_3e2a_mri.mnc  512img_20131129_101659_3e3a_mri.mnc

Not quite sure what's happening there, but my naming scheme has been overridden.

Hi @andrewjanke

I've a problem with spm_realign. I'm trying to obtain movement parameters using the mean image. I've tried all (flags.rtm equal 1, 0 or [ ]) and always obtain the same result respect the first volume.

This is my code:

 flags.rtm=1;
 spm_realign(P,flags);

What I'm doing wrong?

Thanks and best regards.

I'm trying to install minc-tools but unfortunately the configuration process fails. The FL_LIBRARY variable is NOTFOUND, even if the configure script says that it found Flex on the system:

-- Found BISON: /usr/bin/bison (found version "2.3") 
-- Found FLEX: /usr/bin/flex (found version "2.5.35") 
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
FL_LIBRARY (ADVANCED)
    linked by target "minccalc" in directory /Volumes/Mac/Utilisateurs/pmougel/tmp/minc-tools/progs
    linked by target "mincgen" in directory /Volumes/Mac/Utilisateurs/pmougel/tmp/minc-tools/progs

You can find the full log in this gist, including the commands I ran on the terminal.

I'm on a Mac, and FLEX was installed using homebrew, while libminc was installed from source without any issue.

I am not very experienced with CMake, does anyone have debugging clues? (cc-ing @AldoMarzullo who has the same issue on Fedora).

Something very nice about modern dcm2nii converters is the output files can be named with the sequence information from the DICOMs.

Right now dcm2mnc only offers the acquisition number as a naming option. Sadly, if the sequence was done out-of-order at the scanner this number is unreliable.

Currently I rely on parsing the mincheader output to rename the resulting files to something more useful, since I commonly encounter scanning sessions with many sequences.

mincmorph does not propagate the direction_cosines attributes, if they are the identity transform (1 0 0; 0 1 0; 0 0 1). It seems to me that if the input volume has these attributes, they should be propagated - regardless of their value?

Here is my non default config for cmake:

set(BUILD_TESTING ON CACHE BOOL "")
set(CMAKE_BUILD_TYPE Release CACHE STRING "")
set(CMAKE_INSTALL_PREFIX /usr/local CACHE PATH "")
set(MT_BUILD_ANTS ON CACHE BOOL "")
set(MT_BUILD_ITK_TOOLS ON CACHE BOOL "")
set(MT_BUILD_LITE OFF CACHE BOOL "")
set(MT_BUILD_SHARED_LIBS ON CACHE BOOL "")
set(MT_BUILD_VISUAL_TOOLS ON CACHE BOOL "")
set(MT_USE_OPENMP ON CACHE BOOL "")
set(USE_SYSTEM_FFTW3D OFF CACHE BOOL "")
set(USE_SYSTEM_FFTW3F OFF CACHE BOOL "")
set(USE_SYSTEM_GLUT OFF CACHE BOOL "")
set(USE_SYSTEM_GSL OFF CACHE BOOL "")
set(USE_SYSTEM_HDF5 OFF CACHE BOOL "")
set(USE_SYSTEM_ITK OFF CACHE BOOL "")
set(USE_SYSTEM_NETCDF OFF CACHE BOOL "")
set(USE_SYSTEM_PCRE OFF CACHE BOOL "")
set(USE_SYSTEM_ZLIB OFF CACHE BOOL "") 

I also used zlib on for good mesure

set(USE_SYSTEM_ZLIB OFF CACHE BOOL "") 

But got the following on the make:

[ 24%] Building C object minctools/conversion/CMakeFiles/mnc2nii.dir/nifti1/mnc2nii.c.o
[ 24%] Linking C executable mnc2nii
../../external//usr/local/lib/libznz.a(znzlib.o): In function `znzopen':
znzlib.c:(.text+0x7d): undefined reference to `gzopen'
../../external//usr/local/lib/libznz.a(znzlib.o): In function `znzdopen':
znzlib.c:(.text+0x11d): undefined reference to `gzdopen'
../../external//usr/local/lib/libznz.a(znzlib.o): In function `Xznzclose':
znzlib.c:(.text+0x17d): undefined reference to `gzclose'
../../external//usr/local/lib/libznz.a(znzlib.o): In function `znzread':
znzlib.c:(.text+0x24c): undefined reference to `gzread'
../../external//usr/local/lib/libznz.a(znzlib.o): In function `znzwrite':
znzlib.c:(.text+0x37c): undefined reference to `gzwrite'
../../external//usr/local/lib/libznz.a(znzlib.o): In function `znzrewind':
znzlib.c:(.text+0x47a): undefined reference to `gzseek'
../../external//usr/local/lib/libznz.a(znzlib.o): In function `znzprintf':
znzlib.c:(.text+0x78f): undefined reference to `gzprintf'
../../external//usr/local/lib/libznz.a(znzlib.o): In function `znzseek':
znzlib.c:(.text+0x432): undefined reference to `gzseek'
../../external//usr/local/lib/libznz.a(znzlib.o): In function `znztell':
znzlib.c:(.text+0x4c2): undefined reference to `gztell'
../../external//usr/local/lib/libznz.a(znzlib.o): In function `znzputs':
znzlib.c:(.text+0x505): undefined reference to `gzputs'
../../external//usr/local/lib/libznz.a(znzlib.o): In function `znzgets':
znzlib.c:(.text+0x547): undefined reference to `gzgets'
../../external//usr/local/lib/libznz.a(znzlib.o): In function `znzflush':
znzlib.c:(.text+0x587): undefined reference to `gzflush'
../../external//usr/local/lib/libznz.a(znzlib.o): In function `znzeof':
znzlib.c:(.text+0x5c2): undefined reference to `gzeof'
../../external//usr/local/lib/libznz.a(znzlib.o): In function `znzputc':
znzlib.c:(.text+0x604): undefined reference to `gzputc'
../../external//usr/local/lib/libznz.a(znzlib.o): In function `znzgetc':
znzlib.c:(.text+0x664): undefined reference to `gzgetc'
collect2: error: ld returned 1 exit status
minctools/conversion/CMakeFiles/mnc2nii.dir/build.make:105: recipe for target 'minctools/conversion/mnc2nii' failed
make[2]: *** [minctools/conversion/mnc2nii] Error 1
CMakeFiles/Makefile2:5129: recipe for target 'minctools/conversion/CMakeFiles/mnc2nii.dir/all' failed
make[1]: *** [minctools/conversion/CMakeFiles/mnc2nii.dir/all] Error 2
Makefile:160: recipe for target 'all' failed
make: *** [all] Error 2

I have tied adding the -lz option in the cmake flags for compilation but to no effect.

In this line:
https://github.com/BIC-MNI/minc-tools/blob/master/progs/mincmath/mincmath.c#L689

the percent difference is calculated as:
100.0 * (value1 - value2) / value1;

should that not be:
100.0 * (value2 - value1) / value1;

?

The change log shows release numbers, but this is not reflected as tags in the git repo. Tags would help people who want to get a snapshot of a specific minc-tools release. Please do this for (at least) the significant recent releases ... and going forward.

Andrew requested to have -floor and -ceil synonyms to -ignore_below and -ignore_above

CMake install conversion/ is missing ana2mnc and such.

Since these are uncompiled, I'm not sure how to add them to the install since I can't copy the dcm2nc stanzas in CMake, otherwise, I'd do a PR.

Hi
After i installed the minc library and tools i can use some of the tools like mincinfo and mincpik but i can't use other like Display, mincnlm and nu_correct.
Do I need some extra configuration to use these?

From the MINC mailing list.

Hello,
I am running across some unexpected behaviour for mincaverage using
-normalize and I'm not sure if it's a bug or not.
Description:
mincaverage -normalize in1.mnc in2.mnc in3.mnc out.mnc
results in out.mnc with all zeros if the input files have a mean less
than zero.
I can reproduce this every time.
At the moment I am able to 'hack' my minc files by adding a constant so
that they all have means > 0.
I think perhaps the issue might lie in lines 533-561 here:
[1]https://github.com/BIC-MNI/minc-tools/blob/master/progs/mincaverage/mincaverage.c
Where vol_mean[ifile] is included in the determination of vol_total and
global_mean (lines 537 and 554), but the value of
average_data.norm_factor[ifile] is conditional upon the vol_mean[ifile]
being > 0 (otherwise, the norm_factor[ifile] is set to 0.0).
Any ideas if this is a bug (though perhaps not in the lines that I am
suggesting) or a design decision? If it's a design decision, can I ask
the reasoning? (Maybe I'm not understanding the meaning of world values
in minc files?)

Thanks
Johnathon

Johnathon R. Walls, PhD
Scientist - Therapeutic Target Discovery
Regeneron Pharmaceuticals
777 Old Saw Mill River Road
Tarrytown, NY USA 10591-6707
Phone: 914.847.3006 Fax: 914.847.7544
Email: [email protected]

I think perl got stricter about formatting between the writing of this code and now.

Paging @andrewjanke is this tool more reliable than ana2mnc for handling SPM files?

/home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl -help
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 60.
syntax error at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 61, near "$h"
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 61.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 62.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 63.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 65.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 66.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 67.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 68.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 69.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 70.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 71.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 72.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 73.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 74.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 75.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 76.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 77.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 78.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 79.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 80.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 81.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 82.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 84.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 85.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 86.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 87.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 88.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 89.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 90.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 91.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 92.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 93.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 94.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 95.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 96.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 97.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 98.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 99.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 100.
Global symbol "$h" requires explicit package name at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 101.
syntax error at /home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl line 102, near "}"
/home/cic/devgab/projects/src/minc-tools/conversion/ana2mnc/ana2mnc_xfm_reduce.pl has too many errors.

In writing my MINC2 conversion, I noticed that I think mnc2nii is getting the image scaling wrong. For example, if I do this:

mincstats mincex_pd.mnc

on an example file given to me by Andrew Janke, I get this:

Min:               0
Max:               102.5024482
Sum:               102940629.4
Sum^2:             5570867979
Mean:              23.82625718

among other stuff. But, when I do this:

mnc2nii mincex_pd.mnc converted_pd.nii

and load the data in nibabel or SPM, I get:

python -c 'import nibabel; img = nibabel.load("converted_pd.nii");
print(img.get_data().mean())'

51.2892728726

So - I think the scaling is incorrect for the generated nifti files.

I was wondering if it might be a good idea to add something that could reorder dimensions like a reference volume (e.g. a step needed before passing a zxy volume and an xyz volume to mincmath). Of course this would only work if the volumes have the same sampling and are just stored in a different order.

I wondered if a natural place for this would be adding a "-like" option to mincreshape?

I thin a small tweak to cmake is needed to install these tools.

Test:

• mincinfo -attvalue zspace:spacing PreventAD_424640_lego_phantom_MTL_20160621_greT2star_001.mnc
regular__

• mincreshape -dimrange zspace=0,10 PreventAD_424640_lego_phantom_MTL_20160621_greT2star_001.mnc test.mnc
mincinfo -attvalue zspace:spacing test.mnc
irregular

• mincinfo -varvalues zspace PreventAD_424640_lego_phantom_MTL_20160621_greT2star_001.mnc
-60.799999237061001622 .... 41.200000762938998378

I'm trying to install libminc and minc-tools on a ubuntu 12.04 virtual machine

cmake .

CMake Error at CMakeLists.txt:42 (FIND_PACKAGE):
Could not find module FindLIBMINC.cmake or a configuration file for package
LIBMINC.

Adjust CMAKE_MODULE_PATH to find FindLIBMINC.cmake or set LIBMINC_DIR to
the directory containing a CMake configuration file for LIBMINC. The file
will have one of the following names:

LIBMINCConfig.cmake
libminc-config.cmake

CMake Error at CMakeLists.txt:46 (INCLUDE):
include called with wrong number of arguments. Include only takes one
file.

so I tried (after removing CMakeCache)
cmake . -DLIBMINC_DIR=$HOME/libminc/ # where LIBMINCConfig lives
and
cmake . -DLIBMINC_DIR=/usr/local/lib # the install path

both of which configure, but then make fails in both cases with

/usr/bin/ld: cannot open output file minc_modify_header: Is a directory
collect2: ld returned 1 exit status
make[2]: *** [progs/minc_modify_header] Error 1

minccomplete doesn't seem to be installed with minc-toolkit-v2

reported by francois hebert on the minc-users list.

In the help of minccmp it is explained that minccmp will calculate simple
statistical measures between two minc files or more by comparing all
subsequent files to the first. but when I try to compare one file to
several minccmp just return the comparison of the 2 first files.

The problem is a missing loop here:

https://github.com/BIC-MNI/minc-tools/blob/master/progs/minccmp/minccmp.c#L275

Original command was:

> minclookup -lut_string "201 201" -discrete brain1_jg_label.mnc brain1_jg_201.mnc -clobber

But history shows:

> minclookup -lut_string 201 201 -discrete \
     brain1_jg_label.mnc brain1_jg_201.mnc -clobber

With the quotes missing the command is "broken"

From Alex z on list
Hello all,

The -normalize option ("Normalize images to real minimum and maximum for
the entire input file") appears to disregard the fill value (if provided).
For example, if volume in.mnc has a range [5,100], this call:

mincreshape [-start ... ] -normalize -fillvalue 0 in.mnc out.mnc

actually fills with 5, not 0. I would consider that a bug, and say that
-normalize should include any out-of-current-range fill values in the final
range of the volume. Or?

cmake fails with the following error:

CMake Error at progs/CMakeLists.txt:191 (INSTALL):
install FILES given directory "/home/jason/git/minctools/progs/minchistory"
to install.

CMake Error at progs/CMakeLists.txt:196 (INSTALL):
install PROGRAMS given directory "/home/jason/git/minctools/progs/mincpik"
to install.

-- Configuring incomplete, errors occurred!

I installed libminc, then tried to build minc-tools, but get this error:

make
[ 1%] Built target invert_raw_image
Linking C executable minc_modify_header
Undefined symbols for architecture x86_64:
"_MI2attdel", referenced from:
_main in minc_modify_header.c.o
"_MI2attget", referenced from:
_main in minc_modify_header.c.o
"_MI2attinq", referenced from:
_main in minc_modify_header.c.o
"_MI2attput", referenced from:
_main in minc_modify_header.c.o
"_MI2redef", referenced from:
_main in minc_modify_header.c.o
"_MI2sync", referenced from:
_main in minc_modify_header.c.o
"_MI2typelen", referenced from:
_main in minc_modify_header.c.o
"_MI2vardef", referenced from:
_main in minc_modify_header.c.o
"_MI2varid", referenced from:
_main in minc_modify_header.c.o
"_miclose", referenced from:
_main in minc_modify_header.c.o
"_micreate_group_variable", referenced from:
_main in minc_modify_header.c.o
"_miexpand_file", referenced from:
_main in minc_modify_header.c.o
"_miopen", referenced from:
_main in minc_modify_header.c.o
"_ncopts", referenced from:
_main in minc_modify_header.c.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [progs/minc_modify_header] Error 1
make[1]: *** [progs/CMakeFiles/minc_modify_header.dir/all] Error 2
make: *** [all] Error 2

Any idea what the problem is?

We need nii2mnc to convert Nifti files for processing in the Minc file format. But for about half of the files, the start values are miscalculated. It seems that the image orientation is correct (the cosines are ok), but the start values are wrong.

We are running on Ubuntu Server 64-bit 14.04 LTS and the code is from master.

$nii2mnc -version
program: 2.3.00
libminc: 2.3.00
netcdf : 4.3.3.1 of Dec 27 2015 17:18:07 $
HDF5   : 1.8.15

We have verified that the Nifti files are placed correct compared to the input Dicom files. If we use the dcm2mnc program, the minc files are OK!

$dcm2mnc -version
program: 2.01.01 built Dec 28 2015 15:25:58
libminc: 2.3.00
netcdf : 4.3.3.1 of Dec 27 2015 17:18:07 $
HDF5   : 1.8.15

We have tested on a number of Nifti files with Axial, Sagittal and Coronal orientation, and the conversion seems to fails primarily on Sagittal and Coronal oriented Nifti files.

From the list, Alex Z
Hi all,

I realized that mincresample happily accepts multiple of these options
simultaneously:

-like <model.mnc>
-tfm_input_sampling
-use_input_sampling

I would think that these three options should be mutually exclusive, and
that mincresample should check for that? I believe at the moment, -like
silently takes precedence between these three.

Not sure if this is a bug or a missing feature:

With a minc header such as:

<CLIP>
zspace = -39.3054472522805 ;

 acquisition = 0 ;

 dicom_0x0008 = 0 ;

 dicom_0x0009 = 0 ;

 dicom_0x0010 = 0 ;

 dicom_0x0018 = 0 ;

 dicom_0x0019 = 0 ;

 dicom_0x0020 = 0 ;

 dicom_0x0021 = 0 ;

 dicom_0x0023 = 0 ;

 dicom_0x0025 = 0 ;

 dicom_0x0027 = 0 ;

 dicom_0x0028 = 0 ;

 dicom_0x0029 = 0 ;

 dicom_0x0040 = 0 ;

 dicom_0x0043 = 0 ;

 dicom_0x0054 = 0 ;

 dicom_groups = 0 ;

 dicominfo = 0 ;

 patient = 0 ;

 study = 0 ;
}

I'd like to be able to delete these top-level dicom variables.

minc_modify_header -delete dicom_0x0018 17.mnc
-delete option requires argument <var>:<attr>

minc_modify_header -delete dicom_0x0018: 17.mnc
<no output, but variable still exists>

Is it possible to do this?

Probably belongs as a libminc issue, but:

$ cat whatever.xfm 
MNI Transform File
Transform_Type = Grid_Transform;
Displacement_Volume = whatever_grid_0.mnc;
Transform_Type = Linear;
Linear_Transform =
1 0 0 0
0 1 0 0
0 0 1 0;
$ mincinfo whatever_grid_0.mnc 
file: whatever_grid_0.mnc
image: signed__ float -0.24282121658325195312 to 0.45105218887329101562
image dimensions: vector_dimension xspace yspace zspace
    dimension name         length         step        start
    --------------         ------         ----        -----
    vector_dimension            3      unknown      unknown
    xspace                     29        0.448        -6.27
    yspace                     43        0.448        -8.19
    zspace                     22        0.448         -4.2
$ xfminvert whatever.xfm whatever_inverted.xfm
$ mincinfo whatever_inverted_grid_0.mnc 
file: whatever_inverted_grid_0.mnc
image: signed__ float -0.24282121658325195312 to 0.45105218887329101562
image dimensions: vector_dimension zspace yspace xspace
    dimension name         length         step        start
    --------------         ------         ----        -----
    vector_dimension            3      unknown      unknown
    zspace                     22        0.448         -4.2
    yspace                     43        0.448        -8.19
    xspace                     29        0.448        -6.27

Slices steps for -dimsize are attempted to be parsed as integers, so you can never use non-integer slicing

https://github.com/BIC-MNI/minc-tools/blob/master/progs/mincreshape/mincreshape.c#L601-L609

I have run into the following problem on many occasions:

1. Receive from collaborator some kind of nifti file, which has been "processed" by SPM or FSL (aka has sform/qform data)
2. Convert said file to minc using nii2mnc which properly handles sform/qform and provides me with a reasonably oriented minc file
3. Process said file (for example, produce label files for it using magetbrain)
4. Convert label files back to nifti using mnc2nii
5. Problem arises -> resulting nifti file is not in the space of the original nifti file, due to not having any transforms applied.

Proposed solution:
Provide an option for mnc2nii which reads from a given "reference" NIFTI file the sform/qform information, and applies it during conversion so that the resulting file is in the right space.

I occasionally bump into the fact that the mincreshape *direction
options operate on image dimensions (the two fastest varying
dimensions, i.e., a slice) only. Things like this:

$ mincreshape -xdirection test.mnc test-x.mnc
Copying chunks:..................................................................................................................................................................................................................Done.

$ mincinfo test.mnc test-x.mnc
file: test.mnc
image: unsigned byte 0 to 165
image dimensions: xspace yspace zspace
dimension name length step start
-------------- ------ ---- -----
xspace 210 0.06 -6.33
yspace 274 0.06 -9.663
zspace 141 0.06 -4.8

file: test-x.mnc
image: unsigned byte 0 to 255
image dimensions: xspace yspace zspace
dimension name length step start
-------------- ------ ---- -----
xspace 210 0.06 -6.33
yspace 274 0.06 -9.663
zspace 141 0.06 -4.8

So I told mincreshape to force the step in x to be negative; but my
volume comes out unchanged. The explanation lives in the man page
under the +direction option:

+direction
Flip images to give positive step value for spatial
axes. Note that the flipping of spatial axes only applies to "image
dimensions". These are the two fastest varying (non-vector) dimensions
in the file. If you want to flip a non-image dimension, you can
convert it to an image dimension with -dimsize dimname=-1 (the -1
means don't really change the size). Check out the examples.

However, this is at best very confusing, if not just wrong. It seems
to me that a very specific instruction like -xdirection should "just
work" regardless of whether or not xspace happens to be an image
dimension. I have seen several posts over the years where people
scratch their heads over this (myself included :)

I can think of a few ways to address this:

• modify mincreshape to "just work" for [+-][xyz]direction
• throw a warning or error when [+-][xyz]direction is used while the
  corresponding [xyz]space is not an image dimension
• make this rather counterintuitive behaviour abundantly clear (e.g.,
  description with every such option in the man page/help)

Hi
There's any way i can register one image using autoreg without changing the image intensities? I'm trying register one file that contain the left and right hippocampus labels (two different labels) and after registration i can't separate them.

Thanks
Patrick

In the Pyminc test suite (such as it is) we generate a random MINC file roughly as follows:

rawtominc /tmp/test_vector.mnc -input /dev/urandom 3 100 150 125 -dimorder vector_dimension,xspace,yspace,zspace

This didn't used to crash, but after compiling minc-toolkit-v2 with gcc-4.9.1 produces a segfault. The problem seems to be here: if the dimname isn't standard, index doesn't seem to get updated, hence will be an incorrect (possibly uninitialized) value ...

xfm2def is broken unless it's given -float or -double. To reproduce:

$ param2xfm -rotations 30 30 30 ./rot.xfm
$ xfm2def ./rot.xfm ./def_default.mnc
$ xfm2def ./rot.xfm -float ./def_float.mnc
$ minccmp ./def_default.mnc ./def_float.mnc

It also needs a VIO_ prefix added here and there, plus an entry inserted to CMakeLists.txt.

Another from the dark recesses of minc-users, not sure of this ones veracity as a test dataset wasn't provided.

I am gettign a strange error from mincreshape when downsampling a dataset.
This is what I have:

mincinfo T320.mnc
file: T320.mnc
image: signed__ short -2048 to 3062
image dimensions: time zspace yspace xspace
dimension name length step start
-------------- ------ ---- -----
time 12 1 0
zspace 320 0.5 -539.75
yspace 512 -0.461 107.894
xspace 512 -0.461 117.894

And I do:

mincreshape -clobber -dimsize xspace=128 -dimsize yspace=128 -dimsize
zspace=128 T320.mnc t.mnc
Copying chunks:.(from miicv_get): Can't allocate 135168 bytes
(and I have several gigs of RAM free)

But it works with 16 slices:

mincreshape -clobber -dimsize xspace=128 -dimsize yspace=128 -dimsize
zspace=16 T320.mnc t.mnc
(OK)

Googling "Can't allocate 135168 bytes" leads to some results, but not
nothing that is an obvious fix to me.

I am on Fedora 17 with
mincreshape -version
program: 2.1.20
libminc: 2.1.20
netcdf : 4.2 of Sep 5 2012 22:51:46 $
HDF5 : 1.8.8

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.0/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla--enable-bootstrap
--enable-shared --enable-threads=posix
--enable-checking=release --disable-build-with-cxx
--disable-build-poststage1-with-cxx --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto
--enable-plugin --enable-initfini-array --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.7.0 20120507 (Red Hat 4.7.0-5) (GCC)

minc-toolkit/1.9.11 successfully converts Philips dicoms, HEAD currently segfaults:

#Version minc-toolkit/git
dcm2mnc -debug -verbose achd_002/DICOM/* .
Checking file types...
File achd_002/DICOM/DICOMDIR appears to be DICOM (CD/Export).
WARNING: Failed to find image position
WARNING: Can't find Philips slice index
Segmentation fault

Example data available.

mincreshape (and a few other tools) can be a bit picky about their input arguments, as an example:

$ mincreshape -dimrange zspace=0001,0 ...

Will fail as it doesn't understand 0001 as 1. This can be a pain when calling mincreshape and friends from within scripts. What's the consensus on what the behaviour should be for this?

I'm trying to average overlapping but ever-so-slightly different dimensioned (off by 2 vox) scans:

mincaverage *.mnc test.mnc
Files OAS1_0001_MR1_mpr-4_anon.mnc and OAS1_0001_MR1_mpr-1_anon.mnc have different sizes of dimensions

mincaverage -nocheck_dimensions *.mnc test.mnc
Files OAS1_0001_MR1_mpr-4_anon.mnc and OAS1_0001_MR1_mpr-1_anon.mnc have different sizes of dimensions

Since diffusion gradients can be stored in the minc header in acquisition:direction_[xyz] and acquisition:bvalues, I was wondering if the core minc tools could be made to interpret them, where appropriate.

The first tools that come to mind are:

1. mincresample -transform lin.xfm
   Transform the directions along with the data

2. mincconcat -concat_dimension zspace slice1.mnc slice2.mnc slice3.mnc ... volume.mnc
   Refuse to concatenate slice that don't share a common direction and bvalue

From minc-users (Alex Zijdenbos) - a minimal test dataset was never provided so I can't vouch as to its veracity. If it does turn out to be true my first guess is that it is related to a decision of Peter Neelins to convert the symbol table from local to global when I originally submitted minccalc. This made a few assumptions about the way the let calculus was implemented that may turn out to be
always correct.

Peter replied to this on minc-users somewhere IIRC, but I can't find it now.

I think something that I think can be legitimately called a bug in
minccalc. It seems that the for construct somehow modifies a variable
that determines its range. Specifically, this construct:

n=len(A);
for {i in [0,len(A))} { stuff }
n;

results in a volume that contains the number of input volumes at every
voxel (as one would expect). However, this one:

n=len(A);
for {i in [0:n)} { stuff }
n;

returns a volume that contains len(A) - 1

So somehow, the for construct modifies n?!

Hello,

For some select filetypes, the intensity range is not identically maintained between mnc to nii.

Example files:

ftp://bigbrain.loris.ca/BigBrainRelease.2015/3D_Volumes/MNI-ICBM152_Space/mni_icbm152_t1_tal_nlin_sym_09b_hires.mnc
ftp://bigbrain.loris.ca/BigBrainRelease.2015/3D_Volumes/MNI-ICBM152_Space/full8_400um_2009b_sym.mnc

mni_icbm152_t1_tal_nlin_sym_09b_hires.mnc is unsigned short 0-65535 with intensity 0-96. mnc2nii outputs .nii with intensity 0-65535 (scaled up):

mnc2nii mni_icbm152_t1_tal_nlin_sym_09b_hires.mnc -unsigned -short mni_icbm152_t1_tal_nlin_sym_09b_hires.nii

full8_400um_2009b_sym.mnc is unsigned byte 0-255 with intensity 0-65535. mnc2nii outputs .nii with intensity 0-255 (scaled down):

mnc2nii full8_400um_2009b_sym.mnc -unsigned -byte full8_400um_2009b_sym.nii

Currently puts timeseries on Z axis

Can provide a variety of sample data (structural and timeseries) via private link

Allow users to input a list of range/floor/ceil values.

Currently the range only applies to the first input volume.

https://github.com/BIC-MNI/minc/blob/master/progs/minccmp/minccmp.c#L333

Code for doing this is already in mincstats so copying that over should be straight forward.

If either one is missing, the configure step fails such as this:

-- Looking for include file pwd.h - found
-- Could NOT find BISON (missing: BISON_EXECUTABLE)
-- Found FLEX: /usr/bin/flex (found version "2.5.39")
CMake Error at Testing/CMakeLists.txt:45 (GET_PROPERTY):
get_property could not find TARGET minccalc. Perhaps it has not yet been
created.

The issue is that progs/CMakeLists.txt will simply omit building minccalc if bison or flex is not found. However, Testing/CMakeLists.txt is not so flexible and fails trying to get properties of "minccalc".

So you could make Testing flexible enough to omit testing minccalc if the latter is not built. Alternatively, you could simply require bison/flex and remove the conditional in progs/CMakeLists.

Reported by Alex Zijdenbos:

It appears that running mincresample on a float volume while using -keep_real_range, fails. A simple
example:

$ mincreshape -float /usr/local/bic/share/mni-models/icbm_avg_152_t1_tal_lin.mnc float.mnc
$ mincstats -quiet -min -max float.mnc
236.8016205
439776.2188

$ mincresample -keep_real_range float.mnc float_res.mnc
$ mincstats -quiet -min -max float_res.mnc
1.797693135e+308
-1.797693135e+308

Leaving aside why you'd want to use that option on a float volume
(happened buried in a script in my case); what should the correct behaviour be?
Ignore the -keep_real_range option for float volumes I'd imagine?

The proposal is for a -json flag for these tools:

mincinfo, mincextract, mincstats, minccmp

Such that output is provided in JSON format for easier parsing by other things.

runnung mincinfo -help fills the screen with spaces and contienues untill killed.