From trash001 at odu.edu Sun Aug 4 17:04:31 2013 From: trash001 at odu.edu (Tanweer Rashid) Date: Sun, 4 Aug 2013 17:04:31 -0400 Subject: [MINC-users] Synthetic data with different world and voxel coordinates Message-ID: Hi, I am trying to create some synthetic data (a box within a box) having different voxel and world coordinates. I have tried using miset_world_origin(), but had no effect. Can you tell me what else I need to use? The following is my code: void createCuboidVolume(char f[], int xSize, int ySize, int zSize) { int result; mihandle_t volume; midimhandle_t dim[3]; mivolumeprops_t props; result = minew_volume_props(&props); result = micreate_dimension("xspace", MI_DIMCLASS_SPATIAL, MI_DIMATTR_REGULARLY_SAMPLED, xSize, &dim[0]); if (result == MI_ERROR) cout << "Error creating dimension xspace" << endl; result = micreate_dimension("yspace", MI_DIMCLASS_SPATIAL, MI_DIMATTR_REGULARLY_SAMPLED, ySize, &dim[1]); if (result == MI_ERROR) cout << "Error creating dimension yspace" << endl; result = micreate_dimension("zspace", MI_DIMCLASS_SPATIAL, MI_DIMATTR_REGULARLY_SAMPLED, zSize, &dim[2]); if (result == MI_ERROR) cout << "Error creating dimension zspace" << endl; result = micreate_volume(f, 3, dim, MI_TYPE_DOUBLE, MI_CLASS_REAL, props, &volume); if (result == MI_ERROR) cout << "Error encountered in creating MINC file" << endl; result = micreate_volume_image(volume); if (result == MI_ERROR) cout << "Error encountered in creating volume image" << endl; double worldOrigin[] = {-10, -20, -30}; result = miset_world_origin(volume, worldOrigin); if (result == MI_ERROR) cout << "Error encountered in setting world origin" << endl; unsigned long location[3]; for (int x = 0; x < xSize; x++) { for (int y = 0; y < ySize; y++) { for (int z = 0; z < zSize; z++) { location[0] = x; location[1] = y; location[2] = z; miset_voxel_value(volume, location, 3, 0); if (z >= 1 && z <= zSize - 2 && x >= 1 && x <= xSize - 2 && y >= 1 && y <= ySize - 2) { miset_voxel_value(volume, location, 3, 0.3); } if ((z >= 10 && z < 20) && (x >= 2 && x < 8) && (y >= 7 && y < 17)) { miset_voxel_value(volume, location, 3, 0.7); } } } } return; } -- Tanweer Rashid MSVE Dept. Old Dominion University From pierre.bellec at criugm.qc.ca Tue Aug 6 00:25:21 2013 From: pierre.bellec at criugm.qc.ca (Pierre Bellec) Date: Tue, 6 Aug 2013 00:25:21 -0400 Subject: [MINC-users] slice-based intensity normalization Message-ID: Dear MINC users, I'd like to force a slice-based normalization of image intensity when calling mincreshape. I have found that rawtominc can achieve that with -scan_range, but I couldn't find an equivalent in mincreshape. Did I miss something ? Best, Pierre From a.janke at gmail.com Tue Aug 6 00:28:39 2013 From: a.janke at gmail.com (Andrew Janke) Date: Tue, 6 Aug 2013 14:28:39 +1000 Subject: [MINC-users] slice-based intensity normalization In-Reply-To: References: Message-ID: Hi Pierre, This is the opposite to what people usually request! Are you sure you want slice based normalisation? or the latter? If the latter, then the -normalize option will do what you want. If a file already has slice based scaling then -nonormalize will ensure it stays there. a On 6 August 2013 14:25, Pierre Bellec wrote: > Dear MINC users, > > I'd like to force a slice-based normalization of image intensity when > calling mincreshape. I have found that rawtominc can achieve that with > -scan_range, but I couldn't find an equivalent in mincreshape. Did I miss > something ? Best, > > Pierre > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From francois.tadel at mcgill.ca Tue Aug 6 15:01:47 2013 From: francois.tadel at mcgill.ca (=?ISO-8859-1?Q?Fran=E7ois_Tadel?=) Date: Tue, 6 Aug 2013 15:01:47 -0400 Subject: [MINC-users] MINC support in Brainstorm In-Reply-To: References: <51ED591D.9090508@mcgill.ca> <51F00ADE.3030601@mcgill.ca> Message-ID: <5201481B.3090008@mcgill.ca> Pierre, Andrew, Claude: Thanks for you help. The support for the CIVET pipeline in Brainstorm is almost finished: http://neuroimage.usc.edu/brainstorm/Tutorials/SegCIVET The MINC format is supported thanks to Pierre Bellec's code (Matlab-based, hence cross-platform). For now, the MRI prefix_t1_final.mnc still have to be manually converted to MINC1 because the support for the MINC2 format is not finished. Everything is already available for download as part of the Brainstorm distribution: http://neuroimage.usc.edu/brainstorm3_register/download.php I will post a final note on the CIVET mailing list when it's ready for public use. Cheers, Francois On 25/07/2013 10:40 AM, Pierre Bellec wrote: > Dear Fran?ois, > > > For reading the nifti files, I'm using my own matlab-only function > (attached here) that I wrote a few years ago. It's not supporting > all the extensions of the nifti format, it reads only what we need > in Brainstorm (volume, basic orientation of the cube, voxel size). > So indeed, it's not that the voxel<=>world transformation is not > present in the output of the mnc2nii file, it's just that I'm not > reading it. > > Except for CIVET, all the other programs I know for MRI > segmentation (FreeSurfer, BrainVISA, BrainSuite) are saving their > surface files in MRI coordinates, there is no additional transform > needed to get the correspondence MRI/surface. I guess this is why > I never had to read those transformations properly. > > With these discussions, I realize it probably makes more sense for > me to put efforts into reading correctly the transformation > directly from the MINC format rather than going through the nifti > format. I will try to use Pierre's code to get the information I > need (voxel <=> world transformation). > > > That would be the cleanest approach indeed. > > Apparently, it is also the easiest way for me to get a fully > scripted function, with no compilation involved (easier to > maintain and distribute). Matlab supports natively NetCDF and HDF5 > formats, no need to redistribute additional libraries. > > Agreed, that's why despite all the work involved and the overlap with > some other projects (including NIAK) I still felt it was necessary to > get the MOMINC library done eventually. > > Pierre: Can I distribute your code with the the main Brainstorm > distribution in the "external" folder? > > > Absolutely. > > Do you want to attach a copyright notice on top of what is already > in the code? > > Nope, MIT license in the code is fine. > > I'll try to finish a beta version that works with both MINC1 and MINC2 > by next week. Best, > > Pierre > > Thank you for you help! > Francois > > > > > On 23/07/2013 11:38 PM, Pierre Bellec wrote: > > Dear Fran?ois (and Andrew), > > > 2) The mnc2nii solution is not going to be a valid > long-term solution for > one specific reason: the import of the CIVET output > surfaces in Brainstorm. > By converting to NIfTI, we lose the initial MINC > coordinate system, on > which all the CIVET output is based. If I don't have > access to the origin > of the referential, I don't think I can register correctly > the cortical > envelopes generated by CIVET with the corresponding T1 MRI. > Therefore we will need a different solution for importing > the MINC volumes. > > > As Andrew said, the conversion from minc to nifti should > retain the correct > voxel-to-world transformation. Hopefully this will be fixed > once and for > all by Andrew with niftilib. Great to hear about that very > useful future > development. > > > 3) Since HDF5 and netCDF are formats that are fully > supported in many > platform-independent languages (Java, Matlab, Python), > will there be at > some point a MINC reader available that does not rely on > any external > compiled library? > I looked at Pierre Bellec's Matlab functions > (http://code.google.com/p/** > mominc/ ), but for what > I understood it > > does the reading of the HDF5/netCDF contents and does not > provide any tool > to re-orient the the volume in another standard coordinate > system (such as > NIfTI). > There is probably not much to add to get a Matlab-based > (or Java-based) > version of mnc2nii (that reads the MINC volume into a > NIfTI-oriented volume > but with the full MINC header information). > Are there other solutions readily available to help us > with this MINC > import? > Is anybody working on or interested in those aspects at > the present time? > > > I have put some efforts in mominc from time to time, and I am > confident a > reliable reader can be implemented for minc1 and minc2 in > matlab, and minc1 > for octave. I haven't prototyped the writer, but it should > work. A lot of > what's left to do for the reader is to run some systematic > test (with some > fancy slice-based intensity normalization) and finalize the > fields of the > header to retain compatibility with the reader/writer in NIAK > (which is a > different beast altogether based on system calls to the minc > tools). > Regarding the limitation you mentioned on the re-orientation, > I have added > a few features from NIAK in minc_read (for MINC1 files only > for now, MINC2 > will crash). If you download the head revision of the > code (I'll > > also send it to you by email) and run something like: > > [hdr,vol] = minc_read('test.mnc'); > > you'll get a field hdr.info.mat which is a 4 x 4 > transformation matrix from > voxel coordinates to world coordinates. If you want to get a > list of world > coordinates for each voxel (and assuming vol is 3D): > > ind = find(true(size(vol))); > [x,y,z] = ind2sub(size(vol),ind); > coord_w = minc_voxel2world([x,y,z],hdr.info.mat); > > COORD_W is an array (nb_voxel x 3) where each row is the world > coordinates > of one voxel in the volume. You can use MINC_WORLD2VOXEL to go > the other > way around. If you want to have a volume that has been > resampled such that > the first dimension is "left to right", the second is "caudal > to rostral" > and the third is "ventral to dorsal", and the voxel to world > transformation > has a diagonal matrix for rotation, with diagonal elements > coding only for > voxel size, I can implement that as well. > > Let me know if you think this could solve your problem and, if > so, I'll > help wrap that up. > > Best, > > Pierre > > Those would be very helpful tools for us and probably for the > developers of > > other software packages as well. We would be willing to > help for any new > developments in this direction, and more generally support > the integration > between the different software environments at the Neuro. > > Thanks > Francois > > > -- > Fran?ois Tadel, MSc > MEG / McConnell Brain Imaging Center / MNI / McGill University > 3801 rue University, Montreal, QC H3A2B4, Canada > > -- Fran?ois Tadel, MSc MEG / McConnell Brain Imaging Center / MNI / McGill University 3801 rue University, Montreal, QC H3A2B4, Canada From a.janke at gmail.com Tue Aug 13 17:58:05 2013 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 14 Aug 2013 07:58:05 +1000 Subject: [MINC-users] minc on centos In-Reply-To: <68D113A131EA0242811C7BCB48AD65A831947D00@SKMBXX02.sickkids.ca> References: <68D113A131EA0242811C7BCB48AD65A831947D00@SKMBXX02.sickkids.ca> Message-ID: Hi Omid, As part of a another project there is now a build of MINC2 and mni_autoreg for CentOS/Fedora/RPM here: http://cvlrepo.massive.org.au/repo/ >From my limited knowledge of RPM, this should work! wget http://cvlrepo.massive.org.au/repo/cvl.repo -O /etc/yum.repos.d/cvl.repo yum clean all yum install cvl-minc2 Other MINC packages will be added to this in time. CC'd to minc-users mailing list as others have asked this lately too. a On 14 August 2013 05:11, Omid Gulban wrote: > Hello All, > > > > Can minc be installed on centos 6.4 64bit? If so where are the instructions > for the installation. > > > > > > > > Thanks > > Omid > > > ________________________________ > > This e-mail may contain confidential, personal and/or health > information(information which may be subject to legal restrictions on use, > retention and/or disclosure) for the sole use of the intended recipient. Any > review or distribution by anyone other than the person for whom it was > originally intended is strictly prohibited. If you have received this e-mail > in error, please contact the sender and delete all copies. From andrew at biospective.com Wed Aug 14 15:18:01 2013 From: andrew at biospective.com (Andrew Wood) Date: Wed, 14 Aug 2013 15:18:01 -0400 Subject: [MINC-users] mincresample modifying data Message-ID: Hi all, I've been experiencing some behaviour coming out of mincresample that I can't explain. I've been trolling through the source code and wondering about a number of things that might contribute to my problem, but I've boiled it down to one simple example: Here is a volume in.mnc (a signed float volume): https://www.dropbox.com/s/cyfujyenc4j7h8b/in.mnc $ mincresample in.mnc rsl.mnc Then compare with mincstats: $ mincstats -min in.mnc Min: 0 $ mincstats -min rsl.mnc Min: -5.345658291e-11 And here it is from the header: $ mincinfo -attvalue image:valid_range in.mnc 0 26989.404296875 $ mincinfo -attvalue image:valid_range rsl.mnc -5.3456582910227368188e-11 26989.404296875 I also tried with -keep_real_range, which I gather doesn't make sense on float data anyway, but definitely further mucks things up: $ mincresample in.mnc rsl_krr.mnc $ mincstats -min rsl_krr.mnc *** mincstats - reported min (-5.34566e-11) doesn't equal header (0) *** mincstats - reported max (6.90125e-11) doesn't equal header (1) Min: -5.345658291e-11 Does anyone have any insight into what might be happening? Thanks, Andrew From vladimir.fonov at gmail.com Wed Aug 14 15:30:07 2013 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Wed, 14 Aug 2013 15:30:07 -0400 Subject: [MINC-users] mincresample modifying data In-Reply-To: References: Message-ID: Hello, mincresample -nearest produces expected results, so probably there is something "interesting" in linear interpolation code. On Wed, Aug 14, 2013 at 3:18 PM, Andrew Wood wrote: > Hi all, > > I've been experiencing some behaviour coming out of mincresample that I > can't explain. I've been trolling through the source code and wondering > about a number of things that might contribute to my problem, but I've > boiled it down to one simple example: > > Here is a volume in.mnc (a signed float volume): > https://www.dropbox.com/s/cyfujyenc4j7h8b/in.mnc > > $ mincresample in.mnc rsl.mnc > > Then compare with mincstats: > > $ mincstats -min in.mnc > Min: 0 > $ mincstats -min rsl.mnc > Min: -5.345658291e-11 > > And here it is from the header: > > $ mincinfo -attvalue image:valid_range in.mnc > 0 26989.404296875 > $ mincinfo -attvalue image:valid_range rsl.mnc > -5.3456582910227368188e-11 26989.404296875 > > > I also tried with -keep_real_range, which I gather doesn't make sense on > float data anyway, but definitely further mucks things up: > > $ mincresample in.mnc rsl_krr.mnc > $ mincstats -min rsl_krr.mnc > *** mincstats - reported min (-5.34566e-11) doesn't equal header (0) > *** mincstats - reported max (6.90125e-11) doesn't equal header (1) > Min: -5.345658291e-11 > > Does anyone have any insight into what might be happening? > > Thanks, > Andrew > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users -- Best regards, Vladimir S. Fonov ~ vladimir fonov gmail com From a.janke at gmail.com Wed Aug 14 20:20:05 2013 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 15 Aug 2013 10:20:05 +1000 Subject: [MINC-users] mincresample modifying data In-Reply-To: References: Message-ID: Hi Andrew, On 15 August 2013 05:18, Andrew Wood wrote: > I've been experiencing some behaviour coming out of mincresample that I > can't explain. I've been trolling through the source code and wondering > about a number of things that might contribute to my problem, but I've > boiled it down to one simple example: > > Here is a volume in.mnc (a signed float volume): > https://www.dropbox.com/s/cyfujyenc4j7h8b/in.mnc > > $ mincresample in.mnc rsl.mnc > > Then compare with mincstats: > > $ mincstats -min in.mnc > Min: 0 > $ mincstats -min rsl.mnc > Min: -5.345658291e-11 My guess is that there is something afoot (NaN perhaps?) in zslice 12. $ mincheader rsl.mnc ... data: image-min = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -5.34565829102274e-11, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, If you then do this: mincreshape -dimrange zspace=0,10 in.mnc z.mnc mincresample z.mnc rslz.mnc mincdiff z.mnc rslz.mnc There are some rounding errors (e-36) but the image data itself is identical. A bit of digging reveals this: mincreshape -dimrange zspace=12,0 in.mnc z.mnc mincresample z.mnc rslz.mnc -clobber mincdump z.mnc > z.dat mincdump rslz.mnc > rslz.dat diff z.dat rslz.dat 1c1 < hdf5 z { --- > hdf5 rslz { 12c12 < image:valid_range = 0.f, 26989.4f ; --- > image:valid_range = -5.345658e-11f, 9456.072f ; 24c24 < double xspace ; --- > int xspace ; 31a32,33 > xspace:step = 0.06 ; > xspace:start = -6.33 ; 35,37c37 < xspace:step = 0.06 ; < xspace:start = -6.33 ; < double yspace ; --- > int yspace ; 44a45,46 > yspace:step = 0.06 ; > yspace:start = -9.663 ; 48,50c50 < yspace:step = 0.06 ; < yspace:start = -9.663 ; < double zspace ; --- > int zspace ; 57a58,59 > zspace:step = 0.06 ; > zspace:start = -4.08 ; 61,62d62 < zspace:step = 0.06 ; < zspace:start = -4.08 ; 68c68 < :ident = "rotor:cai-harold.cai.uq.edu.au:2013.08.15.10.06.37:22297:1" ; --- > :ident = "rotor:cai-harold.cai.uq.edu.au:2013.08.15.10.07.58:23195:1" ; 70a71 > "Thu Aug 15 10:07:58 2013>>> mincresample z.mnc rslz.mnc -clobber\n", 1878,1907c1879,1908 < 0, 3761.673, 3887.281, 3472.979, 3282.3, 3688.367, 4092.374, 4016.597, < 3932.583, 3795.031, 3634.005, 3617.12, 3808.21, 3992.71, 4135.204, < 4278.11, 4130.262, 3923.935, 3872.867, 3951.939, 3999.3, 3952.763, < 3906.637, 3985.709, 4068.488, 4096.492, 4098.139, 4105.552, 4124.085, < 4122.438, 3948.644, 3773.616, 2756.803, 1558.372, 1236.731, 1678.215, < 2236.659, 3150.926, 4064.781, 3755.083, 3395.554, 3867.513, 4738.95, < 4939.512, 4081.254, 3305.775, 3250.177, 3194.168, 3290.537, 3423.559, < 3542.99, 3647.595, 3690.014, 3533.518, 3379.905, 3450.74, 3532.282, < 3569.759, 3585.821, 3615.061, 3665.716, 3697.839, 3541.343, 3386.082, < 3501.395, 3683.425, 3729.138, 3646.771, 3590.351, 3619.179, 3646.36, < 3553.698, 3454.034, 3452.387, 3503.454, 3524.046, 3492.746, 3438.796, < 3092.858, 2746.095, 2904.239, 3197.463, 3329.661, 3303.304, 3302.068, < 3386.906, 3469.272, 3465.154, 3454.858, 3486.157, 3541.343, 3549.991, < 3474.626, 3430.56, 3829.213, 4224.572, 4589.867, 4949.808, 5077.064, < 4960.104, 4894.622, 5021.878, 5146.251, 5205.967, 5258.682, 5258.27, < 5228.206, 5159.43, 5014.054, 4871.148, 4755.835, 4640.522, 4571.334, < 4514.913, 4481.143, 4472.906, 4364.595, 3829.213, 3294.655, 3419.44, < 3613.413, 3629.063, 3533.106, 3496.041, 3581.702, 3662.421, 3624.533, < 3587.056, 3603.941, 3638.947, 3580.878, 3415.734, 3268.298, 3206.111, < 3145.16, 3293.42, 3468.037, 3582.526, 3656.244, 3714.312, 3739.022, < 3766.203, 3888.105, 4010.007, 3852.276, 3599.823, 3569.759, 3804.915, < 3978.296, 3854.335, 3731.609, 3865.454, 4033.07, 4059.427, 3989.828, < 3970.471, 4066.428, 4159.502, 4147.971, 4136.852, 4094.021, 4039.659, < 3951.115, 3819.329, 3687.131, 3555.757, 3426.03, 3770.733, 4186.683, < 4351.828, 4337.826, 4180.506, 3680.542, 3187.579, 3587.056, 3982.003, < 3392.671, 2423.219, 1788.998, 1593.378, 1591.318, 2714.796, 3837.862, < 4080.019, 4178.858, 4173.093, 4088.255, 4043.366, 4097.728, 4153.325, < 4130.674, 4107.611, 4013.302, 3890.576, 3850.217, 3923.523, 4001.359, < 4099.787, 4196.979, 4229.514, 4250.517, 4208.51, 4115.024, 4032.658, < 3982.003, 3932.995, 3992.299, 4051.602, 4024.421, 3962.647, --- > -5.345658e-11, 3761.673, 3887.281, 3472.979, 3282.3, 3688.367, 4092.374, > 4016.597, 3932.583, 3795.031, 3634.005, 3617.12, 3808.21, 3992.71, > 4135.204, 4278.11, 4130.262, 3923.935, 3872.867, 3951.939, 3999.3, > 3952.763, 3906.637, 3985.709, 4068.488, 4096.492, 4098.139, 4105.552, > 4124.085, 4122.438, 3948.644, 3773.616, 2756.803, 1558.372, 1236.731, > 1678.215, 2236.659, 3150.926, 4064.781, 3755.083, 3395.554, 3867.513, > 4738.95, 4939.512, 4081.254, 3305.775, 3250.177, 3194.168, 3290.537, > 3423.559, 3542.99, 3647.595, 3690.014, 3533.518, 3379.905, 3450.74, > 3532.282, 3569.759, 3585.821, 3615.061, 3665.716, 3697.839, 3541.343, > 3386.082, 3501.395, 3683.425, 3729.138, 3646.771, 3590.351, 3619.179, > 3646.36, 3553.698, 3454.034, 3452.387, 3503.454, 3524.046, 3492.746, > 3438.796, 3092.858, 2746.095, 2904.239, 3197.463, 3329.661, 3303.304, > 3302.068, 3386.906, 3469.272, 3465.154, 3454.858, 3486.157, 3541.343, > 3549.991, 3474.626, 3430.56, 3829.213, 4224.572, 4589.867, 4949.808, > 5077.064, 4960.104, 4894.622, 5021.878, 5146.251, 5205.967, 5258.682, > 5258.27, 5228.206, 5159.43, 5014.054, 4871.148, 4755.835, 4640.522, > 4571.334, 4514.913, 4481.143, 4472.906, 4364.595, 3829.213, 3294.655, > 3419.44, 3613.413, 3629.063, 3533.106, 3496.041, 3581.702, 3662.421, > 3624.533, 3587.056, 3603.941, 3638.947, 3580.878, 3415.734, 3268.298, > 3206.111, 3145.16, 3293.42, 3468.037, 3582.526, 3656.244, 3714.312, > 3739.022, 3766.203, 3888.105, 4010.007, 3852.276, 3599.823, 3569.759, > 3804.915, 3978.296, 3854.335, 3731.609, 3865.454, 4033.07, 4059.427, > 3989.828, 3970.471, 4066.428, 4159.502, 4147.971, 4136.852, 4094.021, > 4039.659, 3951.115, 3819.329, 3687.131, 3555.757, 3426.03, 3770.733, > 4186.683, 4351.828, 4337.826, 4180.506, 3680.542, 3187.579, 3587.056, > 3982.003, 3392.671, 2423.219, 1788.998, 1593.378, 1591.318, 2714.796, > 3837.862, 4080.019, 4178.858, 4173.093, 4088.255, 4043.366, 4097.728, > 4153.325, 4130.674, 4107.611, 4013.302, 3890.576, 3850.217, 3923.523, > 4001.359, 4099.787, 4196.979, 4229.514, 4250.517, 4208.51, 4115.024, > 4032.658, 3982.003, 3932.995, 3992.299, 4051.602, 4024.421, 3962.647, 4789c4790 < image-min = 0 ; --- > image-min = -5.34565829102274e-11 ; 4791c4792 < image-max = 26989.4044242532 ; --- > image-max = 9456.07226562497 ; So, it's either something up with that value of zero or this might well be within the discretisation range a value of around 5000 for the way mincresample does linear interpolation. (Macros, IIRC). If you use -tricubic or -sinc you also get differences (the most with sinc), given that the difference is also in the first voxel (corner) there might also be small edge effects in some cases. As Vlad mentions, -nearest does what you'd expect and there is no inherrent blur (from the resampling) in this. At this point I wouldn't call this a bug, I wouldn't expect two volumes to be identical after resampling as there is always some form of blurring in this unless you use -nearest_neighbour for an identity transform. a From eskild at gmail.com Thu Aug 15 08:44:45 2013 From: eskild at gmail.com (Simon Eskildsen) Date: Thu, 15 Aug 2013 14:44:45 +0200 Subject: [MINC-users] Installing RMINC Message-ID: Hi all, I just upgraded R to the latest version - 3.0.1 (2013-05-16) on a linux mint distro and wanted to install RMINC. However, I run into trouble: $ R CMD INSTALL RMINC_0.5.tar.gz --configure-args='--with-build-path=/home/fristed/pack LIBS=-ldl' * installing to library ?/home/fristed/pack/lib64/R/library? * installing *source* package ?RMINC? ... checking for gcc... gcc -std=gnu99 checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc -std=gnu99 accepts -g... yes checking for gcc -std=gnu99 option to accept ISO C89... none needed checking for library m... yes checking for library netcdf... yes checking for library z... yes checking for library hdf5... yes checking for library minc2... yes configure: creating ./config.status config.status: creating src/Makevars ERROR: a 'NAMESPACE' file is required * removing ?/home/fristed/pack/lib64/R/library/RMINC? Well, this new version of R does not create the missing namespace file. Luckily the latest RMINC code on github has the namespace file. So: $ git clone https://github.com/mcvaneede/RMINC.git RMINC --snip-- $ R CMD INSTALL RMINC --configure-args='--with-build-path=/home/fristed/pack LIBS=-ldl' * installing to library ?/home/fristed/pack/lib64/R/library? * installing *source* package ?RMINC? ... checking for gcc... gcc -std=gnu99 checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc -std=gnu99 accepts -g... yes checking for gcc -std=gnu99 option to accept ISO C89... none needed checking for library m... yes checking for library netcdf... yes checking for library z... yes checking for library hdf5... yes checking for library minc2... yes configure: creating ./config.status config.status: creating src/Makevars ** libs make: Nothing to be done for `all'. installing to /home/fristed/pack/lib64/R/library/RMINC/libs ** R ** inst ** preparing package for lazy loading ** help *** installing help indices ** building package indices ** installing vignettes ?RMINC-userGuide.Rnw? ?VBMstats.Rnw? ?mincIO-userGuide.Rnw? ** testing if installed package can be loaded Error in dyn.load(file, DLLpath = DLLpath, ...) : unable to load shared object '/home/fristed/pack/lib64/R/library/RMINC/libs/RMINC.so': /home/fristed/pack/lib64/R/library/RMINC/libs/RMINC.so: undefined symbol: ch2inv_ Error: loading failed Execution halted ERROR: loading failed * removing ?/home/fristed/pack/lib64/R/library/RMINC? Got further, but now there seems to be a linker problem. Running ldd on RMINC.so (before it's removed) reveals no library lookup issues. Any idea why this happens and/or where to find ch2inv_ ? Simon From jason at mouseimaging.ca Thu Aug 15 08:56:19 2013 From: jason at mouseimaging.ca (Jason Lerch) Date: Thu, 15 Aug 2013 08:56:19 -0400 Subject: [MINC-users] Installing RMINC In-Reply-To: References: Message-ID: <2A674DBB-2D6D-42A9-BC19-29E8A82EDC53@mouseimaging.ca> Hi Simon, mincLm uses one of the Fortran linear algebra routines that came with R back in the 1.x series - they have removed it from the 3.x series, unfortunately, hence this error. We've been meaning to replace that code with something that works with R 3.x, but have not yet got around to it. Hopefully we'll have an update which compiles with R 3.x in the next few weeks. (R 2.x still works with RMINC). Sorry about that. Jason On 2013-08-15, at 8:44 AM, Simon Eskildsen wrote: > Hi all, > > I just upgraded R to the latest version - 3.0.1 (2013-05-16) on a linux > mint distro and wanted to install RMINC. However, I run into trouble: > > $ R CMD INSTALL RMINC_0.5.tar.gz > --configure-args='--with-build-path=/home/fristed/pack LIBS=-ldl' > * installing to library ?/home/fristed/pack/lib64/R/library? > * installing *source* package ?RMINC? ... > checking for gcc... gcc -std=gnu99 > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc -std=gnu99 accepts -g... yes > checking for gcc -std=gnu99 option to accept ISO C89... none needed > checking for library m... yes > checking for library netcdf... yes > checking for library z... yes > checking for library hdf5... yes > checking for library minc2... yes > configure: creating ./config.status > config.status: creating src/Makevars > ERROR: a 'NAMESPACE' file is required > * removing ?/home/fristed/pack/lib64/R/library/RMINC? > > Well, this new version of R does not create the missing namespace file. > Luckily the latest RMINC code on github has the namespace file. So: > > $ git clone https://github.com/mcvaneede/RMINC.git RMINC > --snip-- > $ R CMD INSTALL RMINC > --configure-args='--with-build-path=/home/fristed/pack LIBS=-ldl' > * installing to library ?/home/fristed/pack/lib64/R/library? > * installing *source* package ?RMINC? ... > checking for gcc... gcc -std=gnu99 > checking whether the C compiler works... yes > checking for C compiler default output file name... a.out > checking for suffix of executables... > checking whether we are cross compiling... no > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc -std=gnu99 accepts -g... yes > checking for gcc -std=gnu99 option to accept ISO C89... none needed > checking for library m... yes > checking for library netcdf... yes > checking for library z... yes > checking for library hdf5... yes > checking for library minc2... yes > configure: creating ./config.status > config.status: creating src/Makevars > ** libs > make: Nothing to be done for `all'. > installing to /home/fristed/pack/lib64/R/library/RMINC/libs > ** R > ** inst > ** preparing package for lazy loading > ** help > *** installing help indices > ** building package indices > ** installing vignettes > ?RMINC-userGuide.Rnw? > ?VBMstats.Rnw? > ?mincIO-userGuide.Rnw? > ** testing if installed package can be loaded > Error in dyn.load(file, DLLpath = DLLpath, ...) : > unable to load shared object > '/home/fristed/pack/lib64/R/library/RMINC/libs/RMINC.so': > /home/fristed/pack/lib64/R/library/RMINC/libs/RMINC.so: undefined symbol: > ch2inv_ > Error: loading failed > Execution halted > ERROR: loading failed > * removing ?/home/fristed/pack/lib64/R/library/RMINC? > > Got further, but now there seems to be a linker problem. Running ldd on > RMINC.so (before it's removed) reveals no library lookup issues. > > Any idea why this happens and/or where to find ch2inv_ ? > > Simon > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From eskild at gmail.com Thu Aug 15 09:42:26 2013 From: eskild at gmail.com (Simon Eskildsen) Date: Thu, 15 Aug 2013 15:42:26 +0200 Subject: [MINC-users] Installing RMINC In-Reply-To: <2A674DBB-2D6D-42A9-BC19-29E8A82EDC53@mouseimaging.ca> References: <2A674DBB-2D6D-42A9-BC19-29E8A82EDC53@mouseimaging.ca> Message-ID: Hi Jason, No worries. I'll revert to the newest 2.x for now. Thanks, Simon On Thu, Aug 15, 2013 at 2:56 PM, Jason Lerch wrote: > Hi Simon, > > mincLm uses one of the Fortran linear algebra routines that came with R > back in the 1.x series - they have removed it from the 3.x series, > unfortunately, hence this error. We've been meaning to replace that code > with something that works with R 3.x, but have not yet got around to it. > Hopefully we'll have an update which compiles with R 3.x in the next few > weeks. (R 2.x still works with RMINC). > > Sorry about that. > > Jason > > On 2013-08-15, at 8:44 AM, Simon Eskildsen wrote: > > > Hi all, > > > > I just upgraded R to the latest version - 3.0.1 (2013-05-16) on a linux > > mint distro and wanted to install RMINC. However, I run into trouble: > > > > $ R CMD INSTALL RMINC_0.5.tar.gz > > --configure-args='--with-build-path=/home/fristed/pack LIBS=-ldl' > > * installing to library ?/home/fristed/pack/lib64/R/library? > > * installing *source* package ?RMINC? ... > > checking for gcc... gcc -std=gnu99 > > checking for C compiler default output file name... a.out > > checking whether the C compiler works... yes > > checking whether we are cross compiling... no > > checking for suffix of executables... > > checking for suffix of object files... o > > checking whether we are using the GNU C compiler... yes > > checking whether gcc -std=gnu99 accepts -g... yes > > checking for gcc -std=gnu99 option to accept ISO C89... none needed > > checking for library m... yes > > checking for library netcdf... yes > > checking for library z... yes > > checking for library hdf5... yes > > checking for library minc2... yes > > configure: creating ./config.status > > config.status: creating src/Makevars > > ERROR: a 'NAMESPACE' file is required > > * removing ?/home/fristed/pack/lib64/R/library/RMINC? > > > > Well, this new version of R does not create the missing namespace file. > > Luckily the latest RMINC code on github has the namespace file. So: > > > > $ git clone https://github.com/mcvaneede/RMINC.git RMINC > > --snip-- > > $ R CMD INSTALL RMINC > > --configure-args='--with-build-path=/home/fristed/pack LIBS=-ldl' > > * installing to library ?/home/fristed/pack/lib64/R/library? > > * installing *source* package ?RMINC? ... > > checking for gcc... gcc -std=gnu99 > > checking whether the C compiler works... yes > > checking for C compiler default output file name... a.out > > checking for suffix of executables... > > checking whether we are cross compiling... no > > checking for suffix of object files... o > > checking whether we are using the GNU C compiler... yes > > checking whether gcc -std=gnu99 accepts -g... yes > > checking for gcc -std=gnu99 option to accept ISO C89... none needed > > checking for library m... yes > > checking for library netcdf... yes > > checking for library z... yes > > checking for library hdf5... yes > > checking for library minc2... yes > > configure: creating ./config.status > > config.status: creating src/Makevars > > ** libs > > make: Nothing to be done for `all'. > > installing to /home/fristed/pack/lib64/R/library/RMINC/libs > > ** R > > ** inst > > ** preparing package for lazy loading > > ** help > > *** installing help indices > > ** building package indices > > ** installing vignettes > > ?RMINC-userGuide.Rnw? > > ?VBMstats.Rnw? > > ?mincIO-userGuide.Rnw? > > ** testing if installed package can be loaded > > Error in dyn.load(file, DLLpath = DLLpath, ...) : > > unable to load shared object > > '/home/fristed/pack/lib64/R/library/RMINC/libs/RMINC.so': > > /home/fristed/pack/lib64/R/library/RMINC/libs/RMINC.so: undefined > symbol: > > ch2inv_ > > Error: loading failed > > Execution halted > > ERROR: loading failed > > * removing ?/home/fristed/pack/lib64/R/library/RMINC? > > > > Got further, but now there seems to be a linker problem. Running ldd on > > RMINC.so (before it's removed) reveals no library lookup issues. > > > > Any idea why this happens and/or where to find ch2inv_ ? > > > > Simon > > _______________________________________________ > > MINC-users at bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From andrew at biospective.com Thu Aug 15 10:41:37 2013 From: andrew at biospective.com (Andrew Wood) Date: Thu, 15 Aug 2013 10:41:37 -0400 Subject: [MINC-users] mincresample modifying data In-Reply-To: References: Message-ID: Hi all, I looked in the linear interpolation code, as Vladamir suggested, and it looks to me like there are edge cases that actually get extrapolated. Values that fall off the edge of the input volume, but inside a small epsilon, are extrapolated. I tried removing the epsilon from linear interpolation code and it seems to fix this case. I tried another couple of things comparing the official mincresample with my patched version, using short and ushort input ( data available https://www.dropbox.com/sh/kzziqemv3ro855q/0hkYHLKmzF ) $ mincresample in_short.mnc res_short.mnc $ mincresample -clobber in_ushort.mnc res_ushort.mnc $ mincresample_patched in_short.mnc res_short_PATCH.mnc $ mincresample_patched -clobber in_ushort.mnc res_ushort_PATCH.mnc $ mincstats -min res_short.mnc Min: -5.36601874e-11 $ mincstats -min res_ushort.mnc Min: -5.36601874e-11 $ mincstats -min res_short_PATCH.mnc Min: 0 $ mincstats -min res_ushort_PATCH.mnc Min: 0 With both data types, the official mincresample results in small negative mins, and my patched version results in zero mins. I think this is encouraging, and it makes me wonder if the epsilon in the out-of-volume test condition should be removed. I noticed that the corresponding test condition in the tricubic interpolation code doesn't have any epsilon wiggle room. To continue the experiment, I added a small linear transform and things get weirder. $ mincresample -transormation linear.xfm -like like.mnc in_short.mnc res_short_xfm.mnc $ mincresample -transormation linear.xfm -like like.mnc in_ushort.mnc res_ushort_xfm.mnc $ mincresample_patched -transormation linear.xfm -like like.mnc in_short.mnc res_short_xfm_PATCH.mnc $ mincresample_patched -transormation linear.xfm -like like.mnc in_ushort.mnc res_ushort_xfm_PATCH.mnc $ mincstats -min res_short_xfm.mnc *** mincstats - reported min (-0.010563) doesn't equal header (-0.010563) Min: -0.01056300123 $ mincstats -min res_ushort_xfm.mnc Min: -0.01056300123 $ mincstats -min res_short_xfm_PATCH.mnc Min: -3.637978807e-12 $ mincstats -min res_ushort_xfm_PATCH.mnc Min: 0 It looks like both runs using the official mincresample ended up extrapolating a minimum of -0.01056300123. I'm not sure what to make of the difference in the patched runs. It looks like the numerical stability of some expressions in the linear interpolation code might depend on the magnitude of voxel values they're given. The the following lines, the v*** variables are voxel values from the input image. *result = r0 * (volume->scale[slcind] * (r1r2 * v000 + r1f2 * v001 + f1r2 * v010 + f1f2 * v011) + volume->offset[slcind]); *result += f0 * (volume->scale[slcind+1] * (r1r2 * v100 + r1f2 * v101 + f1r2 * v110 + f1f2 * v111) + volume->offset[slcind+1]); - Andrew On Wed, Aug 14, 2013 at 8:20 PM, Andrew Janke wrote: > Hi Andrew, > > On 15 August 2013 05:18, Andrew Wood wrote: > > I've been experiencing some behaviour coming out of mincresample that I > > can't explain. I've been trolling through the source code and wondering > > about a number of things that might contribute to my problem, but I've > > boiled it down to one simple example: > > > > Here is a volume in.mnc (a signed float volume): > > https://www.dropbox.com/s/cyfujyenc4j7h8b/in.mnc > > > > $ mincresample in.mnc rsl.mnc > > > > Then compare with mincstats: > > > > $ mincstats -min in.mnc > > Min: 0 > > $ mincstats -min rsl.mnc > > Min: -5.345658291e-11 > > My guess is that there is something afoot (NaN perhaps?) in zslice 12. > > $ mincheader rsl.mnc > ... > data: > > image-min = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -5.34565829102274e-11, > 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, > > If you then do this: > > mincreshape -dimrange zspace=0,10 in.mnc z.mnc > mincresample z.mnc rslz.mnc > mincdiff z.mnc rslz.mnc > > There are some rounding errors (e-36) but the image data itself is > identical. > > A bit of digging reveals this: > > mincreshape -dimrange zspace=12,0 in.mnc z.mnc > mincresample z.mnc rslz.mnc -clobber > > mincdump z.mnc > z.dat > mincdump rslz.mnc > rslz.dat > > diff z.dat rslz.dat > > 1c1 > < hdf5 z { > --- > > hdf5 rslz { > 12c12 > < image:valid_range = 0.f, 26989.4f ; > --- > > image:valid_range = -5.345658e-11f, 9456.072f ; > 24c24 > < double xspace ; > --- > > int xspace ; > 31a32,33 > > xspace:step = 0.06 ; > > xspace:start = -6.33 ; > 35,37c37 > < xspace:step = 0.06 ; > < xspace:start = -6.33 ; > < double yspace ; > --- > > int yspace ; > 44a45,46 > > yspace:step = 0.06 ; > > yspace:start = -9.663 ; > 48,50c50 > < yspace:step = 0.06 ; > < yspace:start = -9.663 ; > < double zspace ; > --- > > int zspace ; > 57a58,59 > > zspace:step = 0.06 ; > > zspace:start = -4.08 ; > 61,62d62 > < zspace:step = 0.06 ; > < zspace:start = -4.08 ; > 68c68 > < :ident = "rotor:cai-harold.cai.uq.edu.au:2013.08.15.10.06.37:22297:1" > ; > --- > > :ident = "rotor:cai-harold.cai.uq.edu.au:2013.08.15.10.07.58:23195:1" > ; > 70a71 > > "Thu Aug 15 10:07:58 2013>>> mincresample z.mnc > rslz.mnc -clobber\n", > 1878,1907c1879,1908 > < 0, 3761.673, 3887.281, 3472.979, 3282.3, 3688.367, 4092.374, 4016.597, > < 3932.583, 3795.031, 3634.005, 3617.12, 3808.21, 3992.71, 4135.204, > < 4278.11, 4130.262, 3923.935, 3872.867, 3951.939, 3999.3, 3952.763, > < 3906.637, 3985.709, 4068.488, 4096.492, 4098.139, 4105.552, 4124.085, > < 4122.438, 3948.644, 3773.616, 2756.803, 1558.372, 1236.731, 1678.215, > < 2236.659, 3150.926, 4064.781, 3755.083, 3395.554, 3867.513, 4738.95, > < 4939.512, 4081.254, 3305.775, 3250.177, 3194.168, 3290.537, 3423.559, > < 3542.99, 3647.595, 3690.014, 3533.518, 3379.905, 3450.74, 3532.282, > < 3569.759, 3585.821, 3615.061, 3665.716, 3697.839, 3541.343, 3386.082, > < 3501.395, 3683.425, 3729.138, 3646.771, 3590.351, 3619.179, 3646.36, > < 3553.698, 3454.034, 3452.387, 3503.454, 3524.046, 3492.746, 3438.796, > < 3092.858, 2746.095, 2904.239, 3197.463, 3329.661, 3303.304, 3302.068, > < 3386.906, 3469.272, 3465.154, 3454.858, 3486.157, 3541.343, 3549.991, > < 3474.626, 3430.56, 3829.213, 4224.572, 4589.867, 4949.808, 5077.064, > < 4960.104, 4894.622, 5021.878, 5146.251, 5205.967, 5258.682, 5258.27, > < 5228.206, 5159.43, 5014.054, 4871.148, 4755.835, 4640.522, 4571.334, > < 4514.913, 4481.143, 4472.906, 4364.595, 3829.213, 3294.655, 3419.44, > < 3613.413, 3629.063, 3533.106, 3496.041, 3581.702, 3662.421, 3624.533, > < 3587.056, 3603.941, 3638.947, 3580.878, 3415.734, 3268.298, 3206.111, > < 3145.16, 3293.42, 3468.037, 3582.526, 3656.244, 3714.312, 3739.022, > < 3766.203, 3888.105, 4010.007, 3852.276, 3599.823, 3569.759, 3804.915, > < 3978.296, 3854.335, 3731.609, 3865.454, 4033.07, 4059.427, 3989.828, > < 3970.471, 4066.428, 4159.502, 4147.971, 4136.852, 4094.021, 4039.659, > < 3951.115, 3819.329, 3687.131, 3555.757, 3426.03, 3770.733, 4186.683, > < 4351.828, 4337.826, 4180.506, 3680.542, 3187.579, 3587.056, 3982.003, > < 3392.671, 2423.219, 1788.998, 1593.378, 1591.318, 2714.796, 3837.862, > < 4080.019, 4178.858, 4173.093, 4088.255, 4043.366, 4097.728, 4153.325, > < 4130.674, 4107.611, 4013.302, 3890.576, 3850.217, 3923.523, 4001.359, > < 4099.787, 4196.979, 4229.514, 4250.517, 4208.51, 4115.024, 4032.658, > < 3982.003, 3932.995, 3992.299, 4051.602, 4024.421, 3962.647, > --- > > -5.345658e-11, 3761.673, 3887.281, 3472.979, 3282.3, 3688.367, > 4092.374, > > 4016.597, 3932.583, 3795.031, 3634.005, 3617.12, 3808.21, 3992.71, > > 4135.204, 4278.11, 4130.262, 3923.935, 3872.867, 3951.939, 3999.3, > > 3952.763, 3906.637, 3985.709, 4068.488, 4096.492, 4098.139, 4105.552, > > 4124.085, 4122.438, 3948.644, 3773.616, 2756.803, 1558.372, 1236.731, > > 1678.215, 2236.659, 3150.926, 4064.781, 3755.083, 3395.554, 3867.513, > > 4738.95, 4939.512, 4081.254, 3305.775, 3250.177, 3194.168, 3290.537, > > 3423.559, 3542.99, 3647.595, 3690.014, 3533.518, 3379.905, 3450.74, > > 3532.282, 3569.759, 3585.821, 3615.061, 3665.716, 3697.839, 3541.343, > > 3386.082, 3501.395, 3683.425, 3729.138, 3646.771, 3590.351, 3619.179, > > 3646.36, 3553.698, 3454.034, 3452.387, 3503.454, 3524.046, 3492.746, > > 3438.796, 3092.858, 2746.095, 2904.239, 3197.463, 3329.661, 3303.304, > > 3302.068, 3386.906, 3469.272, 3465.154, 3454.858, 3486.157, 3541.343, > > 3549.991, 3474.626, 3430.56, 3829.213, 4224.572, 4589.867, 4949.808, > > 5077.064, 4960.104, 4894.622, 5021.878, 5146.251, 5205.967, 5258.682, > > 5258.27, 5228.206, 5159.43, 5014.054, 4871.148, 4755.835, 4640.522, > > 4571.334, 4514.913, 4481.143, 4472.906, 4364.595, 3829.213, 3294.655, > > 3419.44, 3613.413, 3629.063, 3533.106, 3496.041, 3581.702, 3662.421, > > 3624.533, 3587.056, 3603.941, 3638.947, 3580.878, 3415.734, 3268.298, > > 3206.111, 3145.16, 3293.42, 3468.037, 3582.526, 3656.244, 3714.312, > > 3739.022, 3766.203, 3888.105, 4010.007, 3852.276, 3599.823, 3569.759, > > 3804.915, 3978.296, 3854.335, 3731.609, 3865.454, 4033.07, 4059.427, > > 3989.828, 3970.471, 4066.428, 4159.502, 4147.971, 4136.852, 4094.021, > > 4039.659, 3951.115, 3819.329, 3687.131, 3555.757, 3426.03, 3770.733, > > 4186.683, 4351.828, 4337.826, 4180.506, 3680.542, 3187.579, 3587.056, > > 3982.003, 3392.671, 2423.219, 1788.998, 1593.378, 1591.318, 2714.796, > > 3837.862, 4080.019, 4178.858, 4173.093, 4088.255, 4043.366, 4097.728, > > 4153.325, 4130.674, 4107.611, 4013.302, 3890.576, 3850.217, 3923.523, > > 4001.359, 4099.787, 4196.979, 4229.514, 4250.517, 4208.51, 4115.024, > > 4032.658, 3982.003, 3932.995, 3992.299, 4051.602, 4024.421, 3962.647, > 4789c4790 > < image-min = 0 ; > --- > > image-min = -5.34565829102274e-11 ; > 4791c4792 > < image-max = 26989.4044242532 ; > --- > > image-max = 9456.07226562497 ; > > So, it's either something up with that value of zero or this might > well be within the discretisation range a value of around 5000 for the > way mincresample does linear interpolation. (Macros, IIRC). > > If you use -tricubic or -sinc you also get differences (the most with > sinc), given that the difference is also in the first voxel (corner) > there might also be small edge effects in some cases. As Vlad > mentions, -nearest does what you'd expect and there is no inherrent > blur (from the resampling) in this. > > At this point I wouldn't call this a bug, I wouldn't expect two > volumes to be identical after resampling as there is always some form > of blurring in this unless you use -nearest_neighbour for an identity > transform. > > > a > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From vladimir.fonov at gmail.com Tue Aug 27 11:35:05 2013 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Tue, 27 Aug 2013 11:35:05 -0400 Subject: [MINC-users] new release 0.3.19 of minc-toolkit is available Message-ID: Hello Everybody, I have created new release of minc-toolkit , binary packages and source archive available at http://www.bic.mni.mcgill.ca/ServicesSoftware/ServicesSoftwareMincToolKit , there are numerous bug fixes and also I added binary packages for Debian 7.1 and CentOS 6.4 (very experimental at the moment). This release is based on latest version of libminc - soon to be released under version 2.3 P.S. This version of minc-toolkit is installed in /ipl/quarantine/experimental/0.3.19 on the BIC systems --- Best regards, Vladimir S. FONOV ~ vladimir.fonov gmail.com From pierre.bellec at criugm.qc.ca Tue Aug 27 13:15:29 2013 From: pierre.bellec at criugm.qc.ca (Pierre Bellec) Date: Tue, 27 Aug 2013 10:15:29 -0700 Subject: [MINC-users] new release 0.3.19 of minc-toolkit is available In-Reply-To: References: Message-ID: Dear Vlad, Thanks again for the fantastic work. Do you know if this has been tested with the latest version of ubuntu 13.04 ? Best, Pierre Le mardi 27 ao?t 2013, Vladimir S. FONOV a ?crit : > Hello Everybody, > > > I have created new release of minc-toolkit , binary packages and source > archive available at > http://www.bic.mni.mcgill.ca/ServicesSoftware/ServicesSoftwareMincToolKit, there are numerous bug fixes and also I added binary packages for Debian > 7.1 and CentOS 6.4 (very experimental at the moment). > > This release is based on latest version of libminc - soon to be released > under version 2.3 > > P.S. This version of minc-toolkit is installed in > /ipl/quarantine/experimental/0.3.19 on the BIC systems > > --- > Best regards, > > Vladimir S. FONOV ~ vladimir.fonov gmail.com > > > > > > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > -- Pierre Bellec, PhD Researcher / Chercheur, Research Centre of the Montreal Geriatric Institute Professeur adjoint sous octroi, Department of Computer Science and Operations Research University of Montreal, Qu?bec, Canada 1 514 340 3540 #3367 http://simexp-lab.org/brainwiki/doku.php?id=pierrebellec From vladimir.fonov at gmail.com Tue Aug 27 13:21:52 2013 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Tue, 27 Aug 2013 13:21:52 -0400 Subject: [MINC-users] new release 0.3.19 of minc-toolkit is available In-Reply-To: References: Message-ID: I haven't tested it , but it might just work? Try Ubuntu 12.04 version or Debian 7.1 On 2013-08-27, at 1:15 PM, Pierre Bellec wrote: > Dear Vlad, > > Thanks again for the fantastic work. Do you know if this has been tested > with the latest version of ubuntu 13.04 ? > > Best, > > Pierre > > Le mardi 27 ao?t 2013, Vladimir S. FONOV a ?crit : > >> Hello Everybody, >> >> >> I have created new release of minc-toolkit , binary packages and source >> archive available at >> http://www.bic.mni.mcgill.ca/ServicesSoftware/ServicesSoftwareMincToolKit, there are numerous bug fixes and also I added binary packages for Debian >> 7.1 and CentOS 6.4 (very experimental at the moment). >> >> This release is based on latest version of libminc - soon to be released >> under version 2.3 >> >> P.S. This version of minc-toolkit is installed in >> /ipl/quarantine/experimental/0.3.19 on the BIC systems >> >> --- >> Best regards, >> >> Vladimir S. FONOV ~ vladimir.fonov gmail.com >> >> >> >> >> >> _______________________________________________ >> MINC-users at bic.mni.mcgill.ca >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users >> > > > -- > Pierre Bellec, PhD > Researcher / Chercheur, Research Centre of the Montreal Geriatric Institute > Professeur adjoint sous octroi, Department of Computer Science and > Operations Research > University of Montreal, Qu?bec, Canada > 1 514 340 3540 #3367 > http://simexp-lab.org/brainwiki/doku.php?id=pierrebellec > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users --- Best regards, Vladimir S. FONOV ~ v.s.fonov ilmarin.info