From matthijs.vaneede at sickkids.ca Tue Oct 4 15:50:04 2016 From: matthijs.vaneede at sickkids.ca (Matthijs van Eede) Date: Tue, 4 Oct 2016 19:50:04 +0000 Subject: [MINC-users] register (and tagtoxfm) can produce reflections in the output transformations Message-ID: <960852518D084247B51C83A707C3EF3E53D14C6F@SKMBXX03.sickkids.ca> Greetings, We were trying to align two brains and found that using register it's possible to get two kinds of transforms. If you pick the right tag points, you get a proper transformation file. If you happen to flip left and right in one of the tag points, a transformation is produced that flips one of the axes. The question is whether this is expected behaviour for register. Flipping axes is rarely something you want when estimating a transformation (In this case, the user that had produced these transformations with register ran a registration pipeline where all brains were left-right flipped without realizing it). Should there be an additional check in register to ensure that the determinant of a rotation matrix is positive? Here's an example of tag points that produces a transformation with a negative determinant: ###################### MNI Tag Point File Volumes = 2; %VIO_Volume: model.mnc %VIO_Volume: source.mnc Points = -0.366219818592072 7.60433340072632 2.30845427513123 1.40657377243042 -4.23010206222534 17.1643028259277 "" 0.120084546506405 -0.405666679143906 2.30845427513123 0.545454323291779 -4.9874153137207 25.2130146026611 "" 0.174118369817734 -5.15316677093506 1.66004836559296 0.592638909816742 -4.23246097564697 30.2041149139404 "" -3.39211368560791 -3.08416676521301 -0.879541099071503 -3.08776211738586 -1.92041432857513 28.3605556488037 ""; ###################### Cheers Matthijs & Ben ________________________________ 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 a.janke at gmail.com Tue Oct 4 20:47:03 2016 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 5 Oct 2016 10:47:03 +1000 Subject: [MINC-users] register (and tagtoxfm) can produce reflections in the output transformations In-Reply-To: <960852518D084247B51C83A707C3EF3E53D14C6F@SKMBXX03.sickkids.ca> References: <960852518D084247B51C83A707C3EF3E53D14C6F@SKMBXX03.sickkids.ca> Message-ID: Hi Matthijs, This is expected behaviour. I often use register and tag points to resolve rotation/inversion issues in data. Thanks a On 5 October 2016 at 05:50, Matthijs van Eede wrote: > Greetings, > > We were trying to align two brains and found that using register it's possible to get two kinds of transforms. If you pick the right tag points, you get a proper transformation file. If you happen to flip left and right in one of the tag points, a transformation is produced that flips one of the axes. The question is whether this is expected behaviour for register. Flipping axes is rarely something you want when estimating a transformation (In this case, the user that had produced these transformations with register ran a registration pipeline where all brains were left-right flipped without realizing it). Should there be an additional check in register to ensure that the determinant of a rotation matrix is positive? > > Here's an example of tag points that produces a transformation with a negative determinant: > > ###################### > MNI Tag Point File > Volumes = 2; > %VIO_Volume: model.mnc > %VIO_Volume: source.mnc > > Points = > -0.366219818592072 7.60433340072632 2.30845427513123 1.40657377243042 -4.23010206222534 17.1643028259277 "" > 0.120084546506405 -0.405666679143906 2.30845427513123 0.545454323291779 -4.9874153137207 25.2130146026611 "" > 0.174118369817734 -5.15316677093506 1.66004836559296 0.592638909816742 -4.23246097564697 30.2041149139404 "" > -3.39211368560791 -3.08416676521301 -0.879541099071503 -3.08776211738586 -1.92041432857513 28.3605556488037 ""; > ###################### > > Cheers > Matthijs & Ben > > ________________________________ > > 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. > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From robert.d.vincent at mcgill.ca Wed Oct 5 07:02:24 2016 From: robert.d.vincent at mcgill.ca (Robert D. Vincent) Date: Wed, 5 Oct 2016 07:02:24 -0400 Subject: [MINC-users] register (and tagtoxfm) can produce reflections in the output transformations In-Reply-To: References: <960852518D084247B51C83A707C3EF3E53D14C6F@SKMBXX03.sickkids.ca> Message-ID: If it's helpful, we could have register simply indicate the sign of the determinant as a warning... On Tue, Oct 4, 2016 at 8:47 PM, Andrew Janke wrote: > Hi Matthijs, > > This is expected behaviour. I often use register and tag points to > resolve rotation/inversion issues in data. > > Thanks > > a > > > On 5 October 2016 at 05:50, Matthijs van Eede > wrote: > > Greetings, > > > > We were trying to align two brains and found that using register it's > possible to get two kinds of transforms. If you pick the right tag points, > you get a proper transformation file. If you happen to flip left and right > in one of the tag points, a transformation is produced that flips one of > the axes. The question is whether this is expected behaviour for register. > Flipping axes is rarely something you want when estimating a transformation > (In this case, the user that had produced these transformations with > register ran a registration pipeline where all brains were left-right > flipped without realizing it). Should there be an additional check in > register to ensure that the determinant of a rotation matrix is positive? > > > > Here's an example of tag points that produces a transformation with a > negative determinant: > > > > ###################### > > MNI Tag Point File > > Volumes = 2; > > %VIO_Volume: model.mnc > > %VIO_Volume: source.mnc > > > > Points = > > -0.366219818592072 7.60433340072632 2.30845427513123 1.40657377243042 > -4.23010206222534 17.1643028259277 "" > > 0.120084546506405 -0.405666679143906 2.30845427513123 0.545454323291779 > -4.9874153137207 25.2130146026611 "" > > 0.174118369817734 -5.15316677093506 1.66004836559296 0.592638909816742 > -4.23246097564697 30.2041149139404 "" > > -3.39211368560791 -3.08416676521301 -0.879541099071503 > -3.08776211738586 -1.92041432857513 28.3605556488037 ""; > > ###################### > > > > Cheers > > Matthijs & Ben > > > > ________________________________ > > > > 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. > > _______________________________________________ > > 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 matthijs.vaneede at sickkids.ca Wed Oct 5 11:30:33 2016 From: matthijs.vaneede at sickkids.ca (Matthijs van Eede) Date: Wed, 5 Oct 2016 15:30:33 +0000 Subject: [MINC-users] register (and tagtoxfm) can produce reflections in the output transformations In-Reply-To: References: <960852518D084247B51C83A707C3EF3E53D14C6F@SKMBXX03.sickkids.ca> , , Message-ID: <960852518D084247B51C83A707C3EF3E53D15509@SKMBXX03.sickkids.ca> Hi Andrew, I think I wasn't specific enough in the example. Using register for rotations/inversions is okay when creating a 12 parameter transformation, but when you've selected 6 parameters, shouldn't you only get translations and rotations? That should not be able to give you reflections? On the other hand, Bert's suggestion of adding a warning message sounds good. Indicating the sign of the determinant and potentially an additional message when it's negative that there is a reflection as part of the transformation (in case users don't know what a negative determinant implies). Cheers, Matthijs ________________________________________ From: minc-users-bounces at bic.mni.mcgill.ca [minc-users-bounces at bic.mni.mcgill.ca] on behalf of Robert D. Vincent [robert.d.vincent at mcgill.ca] Sent: October 5, 2016 7:02 AM To: MINC users mailing list Subject: Re: [MINC-users] register (and tagtoxfm) can produce reflections in the output transformations If it's helpful, we could have register simply indicate the sign of the determinant as a warning... On Tue, Oct 4, 2016 at 8:47 PM, Andrew Janke wrote: > Hi Matthijs, > > This is expected behaviour. I often use register and tag points to > resolve rotation/inversion issues in data. > > Thanks > > a > > > On 5 October 2016 at 05:50, Matthijs van Eede > wrote: > > Greetings, > > > > We were trying to align two brains and found that using register it's > possible to get two kinds of transforms. If you pick the right tag points, > you get a proper transformation file. If you happen to flip left and right > in one of the tag points, a transformation is produced that flips one of > the axes. The question is whether this is expected behaviour for register. > Flipping axes is rarely something you want when estimating a transformation > (In this case, the user that had produced these transformations with > register ran a registration pipeline where all brains were left-right > flipped without realizing it). Should there be an additional check in > register to ensure that the determinant of a rotation matrix is positive? > > > > Here's an example of tag points that produces a transformation with a > negative determinant: > > > > ###################### > > MNI Tag Point File > > Volumes = 2; > > %VIO_Volume: model.mnc > > %VIO_Volume: source.mnc > > > > Points = > > -0.366219818592072 7.60433340072632 2.30845427513123 1.40657377243042 > -4.23010206222534 17.1643028259277 "" > > 0.120084546506405 -0.405666679143906 2.30845427513123 0.545454323291779 > -4.9874153137207 25.2130146026611 "" > > 0.174118369817734 -5.15316677093506 1.66004836559296 0.592638909816742 > -4.23246097564697 30.2041149139404 "" > > -3.39211368560791 -3.08416676521301 -0.879541099071503 > -3.08776211738586 -1.92041432857513 28.3605556488037 ""; > > ###################### > > > > Cheers > > Matthijs & Ben > > > > ________________________________ > > > > 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. > > _______________________________________________ > > 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 > _______________________________________________ MINC-users at bic.mni.mcgill.ca http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users ________________________________ 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 a.janke at gmail.com Wed Oct 5 16:52:51 2016 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 6 Oct 2016 06:52:51 +1000 Subject: [MINC-users] register (and tagtoxfm) can produce reflections in the output transformations In-Reply-To: <960852518D084247B51C83A707C3EF3E53D15509@SKMBXX03.sickkids.ca> References: <960852518D084247B51C83A707C3EF3E53D14C6F@SKMBXX03.sickkids.ca> <960852518D084247B51C83A707C3EF3E53D15509@SKMBXX03.sickkids.ca> Message-ID: In the case of a 6 parameter xfm you are right, there shouldn't be an inversion. Bert's suggestion of a warning should handle this. a On 6 October 2016 at 01:30, Matthijs van Eede wrote: > Hi Andrew, > > I think I wasn't specific enough in the example. Using register for rotations/inversions is okay when creating a 12 parameter transformation, but when you've selected 6 parameters, shouldn't you only get translations and rotations? That should not be able to give you reflections? > > On the other hand, Bert's suggestion of adding a warning message sounds good. Indicating the sign of the determinant and potentially an additional message when it's negative that there is a reflection as part of the transformation (in case users don't know what a negative determinant implies). > > Cheers, > Matthijs > > ________________________________________ > From: minc-users-bounces at bic.mni.mcgill.ca [minc-users-bounces at bic.mni.mcgill.ca] on behalf of Robert D. Vincent [robert.d.vincent at mcgill.ca] > Sent: October 5, 2016 7:02 AM > To: MINC users mailing list > Subject: Re: [MINC-users] register (and tagtoxfm) can produce reflections in the output transformations > > If it's helpful, we could have register simply indicate the sign of the > determinant as a warning... > > On Tue, Oct 4, 2016 at 8:47 PM, Andrew Janke wrote: > >> Hi Matthijs, >> >> This is expected behaviour. I often use register and tag points to >> resolve rotation/inversion issues in data. >> >> Thanks >> >> a >> >> >> On 5 October 2016 at 05:50, Matthijs van Eede >> wrote: >> > Greetings, >> > >> > We were trying to align two brains and found that using register it's >> possible to get two kinds of transforms. If you pick the right tag points, >> you get a proper transformation file. If you happen to flip left and right >> in one of the tag points, a transformation is produced that flips one of >> the axes. The question is whether this is expected behaviour for register. >> Flipping axes is rarely something you want when estimating a transformation >> (In this case, the user that had produced these transformations with >> register ran a registration pipeline where all brains were left-right >> flipped without realizing it). Should there be an additional check in >> register to ensure that the determinant of a rotation matrix is positive? >> > >> > Here's an example of tag points that produces a transformation with a >> negative determinant: >> > >> > ###################### >> > MNI Tag Point File >> > Volumes = 2; >> > %VIO_Volume: model.mnc >> > %VIO_Volume: source.mnc >> > >> > Points = >> > -0.366219818592072 7.60433340072632 2.30845427513123 1.40657377243042 >> -4.23010206222534 17.1643028259277 "" >> > 0.120084546506405 -0.405666679143906 2.30845427513123 0.545454323291779 >> -4.9874153137207 25.2130146026611 "" >> > 0.174118369817734 -5.15316677093506 1.66004836559296 0.592638909816742 >> -4.23246097564697 30.2041149139404 "" >> > -3.39211368560791 -3.08416676521301 -0.879541099071503 >> -3.08776211738586 -1.92041432857513 28.3605556488037 ""; >> > ###################### >> > >> > Cheers >> > Matthijs & Ben >> > >> > ________________________________ >> > >> > 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. >> > _______________________________________________ >> > 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 >> > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > ________________________________ > > 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. > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From benjamin.darwin at sickkids.ca Thu Oct 6 13:49:17 2016 From: benjamin.darwin at sickkids.ca (Benjamin Darwin) Date: Thu, 6 Oct 2016 17:49:17 +0000 Subject: [MINC-users] program to compute determinants of xfm files? Message-ID: Does such a thing exist? It'd be easy to write one for the case of a file containing a single linear transformation ... just wondering if there's possibly already something around that might handle more general cases? ________________________________ 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 a.janke at gmail.com Thu Oct 6 16:41:28 2016 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 7 Oct 2016 06:41:28 +1000 Subject: [MINC-users] program to compute determinants of xfm files? In-Reply-To: References: Message-ID: If you mean of grid xfms then look at mincblob. A On 7 Oct 2016 03:50, "Benjamin Darwin" wrote: > Does such a thing exist? It'd be easy to write one for the case of a file > containing a single linear transformation ... just wondering if there's > possibly already something around that might handle more general cases? > > > > ________________________________ > > 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. > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From claude at bic.mni.mcgill.ca Thu Oct 6 17:11:08 2016 From: claude at bic.mni.mcgill.ca (Claude LEPAGE) Date: Thu, 6 Oct 2016 17:11:08 -0400 Subject: [MINC-users] program to compute determinants of xfm files? In-Reply-To: Message-ID: <201610062111.u96LB8at029824@login1.bic.mni.mcgill.ca> > > Does such a thing exist? It'd be easy to write one for the case of a file containing a single linear transformation ... just wondering if there's possibly already something around that might handle more general cases? > I wrote some little script a long time ago to compute the magnitude of the Jacobian from a non-linear xfm transformation. I think it's correct. Here it is, cut-and-paste (in perl): #! /usr/bin/env perl # # Evaluate the magnitude of the Jacobian from a non-linear transformation. # # Note: All of this can be replaced by mincblob -determinant on the grid # file after resampling it in z,y,x order. You must add 1 to the # mincblob result. # use strict; use warnings "all"; use File::Temp qw/ tempdir /; # --- set the help & usage strings --- my $help = < 1, CLEANUP => 1 ); # Extract x-, y-, z- displacements from grid file. my $gridX = "${tmpdir}/gridX.mnc"; my $gridY = "${tmpdir}/gridY.mnc"; my $gridZ = "${tmpdir}/gridZ.mnc"; &run( 'mincreshape', '-quiet', '-clobber', '-dimrange', 'vector_dimension=0', $grid, $gridX ); &run( 'mincreshape', '-quiet', '-clobber', '-dimrange', 'vector_dimension=1', $grid, $gridY ); &run( 'mincreshape', '-quiet', '-clobber', '-dimrange', 'vector_dimension=2', $grid, $gridZ ); # Define kernels for gradients. my $kerndx="${tmpdir}/dx.kern"; my $kerndy="${tmpdir}/dy.kern"; my $kerndz="${tmpdir}/dz.kern"; &CreateKernelFiles; my $dudx = "${tmpdir}/dudx.mnc"; my $dudy = "${tmpdir}/dudy.mnc"; my $dudz = "${tmpdir}/dudz.mnc"; my $dvdx = "${tmpdir}/dvdx.mnc"; my $dvdy = "${tmpdir}/dvdy.mnc"; my $dvdz = "${tmpdir}/dvdz.mnc"; my $dwdx = "${tmpdir}/dwdx.mnc"; my $dwdy = "${tmpdir}/dwdy.mnc"; my $dwdz = "${tmpdir}/dwdz.mnc"; # compute gradient volume &run( "mincmorph", "-clobber", "-convolve", "-kernel", $kerndx, $gridX, $dudx ); &run( "mincmorph", "-clobber", "-convolve", "-kernel", $kerndy, $gridX, $dudy ); &run( "mincmorph", "-clobber", "-convolve", "-kernel", $kerndz, $gridX, $dudz ); &run( "mincmorph", "-clobber", "-convolve", "-kernel", $kerndx, $gridY, $dvdx ); &run( "mincmorph", "-clobber", "-convolve", "-kernel", $kerndy, $gridY, $dvdy ); &run( "mincmorph", "-clobber", "-convolve", "-kernel", $kerndz, $gridY, $dvdz ); &run( "mincmorph", "-clobber", "-convolve", "-kernel", $kerndx, $gridZ, $dwdx ); &run( "mincmorph", "-clobber", "-convolve", "-kernel", $kerndy, $gridZ, $dwdy ); &run( "mincmorph", "-clobber", "-convolve", "-kernel", $kerndz, $gridZ, $dwdz ); unlink( $kerndx ); unlink( $kerndy ); unlink( $kerndz ); unlink( $gridX ); unlink( $gridY ); unlink( $gridZ ); my $dx = `mincinfo -attvalue xspace:step $grid`; chomp( $dx ); $dx += 0; my $dy = `mincinfo -attvalue yspace:step $grid`; chomp( $dy ); $dy += 0; my $dz = `mincinfo -attvalue zspace:step $grid`; chomp( $dz ); $dz += 0; my $expr = "(($dx+A[0])*(($dy+A[4])*($dz+A[8])-A[5]*A[7])+" . "A[1]*(A[5]*A[6]-A[3]*($dz+A[8]))+" . "A[2]*(A[3]*A[7]-A[6]*($dy+A[4])))/($dx*$dy*$dz)"; &run( 'minccalc', '-quiet', '-clobber', '-expression', $expr, $dudx, $dudy, $dudz, $dvdx, $dvdy, $dvdz, $dwdx, $dwdy, $dwdz, $out ); unlink( $dudx ); unlink( $dudy ); unlink( $dudz ); unlink( $dvdx ); unlink( $dvdy ); unlink( $dvdz ); unlink( $dwdx ); unlink( $dwdy ); unlink( $dwdz ); # -- done -- #Create the kernel files used in taking the image derivative sub CreateKernelFiles { open DXFILE, "> $kerndx"; print DXFILE "MNI Morphology Kernel File\n"; print DXFILE "Kernel_Type = Normal_Kernel;\n"; print DXFILE "Kernel =\n"; print DXFILE " -1.0 0.0 0.0 0.0 0.0 -0.5\n"; print DXFILE " 1.0 0.0 0.0 0.0 0.0 0.5;\n"; close DXFILE; open DYFILE, "> $kerndy"; print DYFILE "MNI Morphology Kernel File\n"; print DYFILE "Kernel_Type = Normal_Kernel;\n"; print DYFILE "Kernel =\n"; print DYFILE " 0.0 -1.0 0.0 0.0 0.0 -0.5\n"; print DYFILE " 0.0 1.0 0.0 0.0 0.0 0.5;\n"; close DYFILE; open DZFILE, "> $kerndz"; print DZFILE "MNI Morphology Kernel File\n"; print DZFILE "Kernel_Type = Normal_Kernel;\n"; print DZFILE "Kernel =\n"; print DZFILE " 0.0 0.0 -1.0 0.0 0.0 -0.5\n"; print DZFILE " 0.0 0.0 1.0 0.0 0.0 0.5;\n"; close DZFILE; } # Execute a system call. sub run { print "@_\n"; system(@_)==0 or die "Command @_ failed with status: $?"; } From ptcougopinto at gmail.com Fri Oct 7 12:51:39 2016 From: ptcougopinto at gmail.com (Pedro) Date: Fri, 7 Oct 2016 13:51:39 -0300 Subject: [MINC-users] classify: bg and csf Message-ID: <98054BD3-E02A-4A40-9192-6F63C80FBE50@gmail.com> Hi, I?m getting background and CSF to have the same label value with classify. Is it possible to avoid this? I tried using -mask -mask_source brain_mask.mnc, still with background labels as ?1?. Thanks Pedro From zijdenbos at gmail.com Fri Oct 7 21:27:21 2016 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Fri, 7 Oct 2016 21:27:21 -0400 Subject: [MINC-users] classify: bg and csf In-Reply-To: <98054BD3-E02A-4A40-9192-6F63C80FBE50@gmail.com> References: <98054BD3-E02A-4A40-9192-6F63C80FBE50@gmail.com> Message-ID: <8FFBD8A4-3F6C-4758-90DE-60ED3C0AD634@gmail.com> Hi Pedro, My guess would be that you are not providing classify with (a) sample(s) of 'bg'. Exactly how are you invoking it? -- A Sent from mobile > On Oct 7, 2016, at 12:51, Pedro wrote: > > Hi, > > I?m getting background and CSF to have the same label value with classify. Is it possible to avoid this? I tried using -mask -mask_source brain_mask.mnc, still with background labels as ?1?. > > Thanks > Pedro > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From ptcougopinto at gmail.com Mon Oct 10 09:06:50 2016 From: ptcougopinto at gmail.com (Pedro) Date: Mon, 10 Oct 2016 10:06:50 -0300 Subject: [MINC-users] classify: bg and csf In-Reply-To: <8FFBD8A4-3F6C-4758-90DE-60ED3C0AD634@gmail.com> References: <98054BD3-E02A-4A40-9192-6F63C80FBE50@gmail.com> <8FFBD8A4-3F6C-4758-90DE-60ED3C0AD634@gmail.com> Message-ID: Hi Alex $ classify_clean -tag_transform t1_2talnlin.xfm -mask mask.mnc -mask_source t1.mnc t1_class.mnc Shouldn?t classify_clean be using background tags from /opt/minc/share/classify/ntags_1000_bg.tag by default? > Em 7 de out de 2016, ?(s) 22:27, Alex Zijdenbos escreveu: > > Hi Pedro, > > My guess would be that you are not providing classify with (a) sample(s) of 'bg'. Exactly how are you invoking it? > > -- A > > > Sent from mobile > >> On Oct 7, 2016, at 12:51, Pedro wrote: >> >> Hi, >> >> I?m getting background and CSF to have the same label value with classify. Is it possible to avoid this? I tried using -mask -mask_source brain_mask.mnc, still with background labels as ?1?. >> >> Thanks >> Pedro >> _______________________________________________ >> 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 zijdenbos at gmail.com Mon Oct 10 09:45:04 2016 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Mon, 10 Oct 2016 09:45:04 -0400 Subject: [MINC-users] classify: bg and csf In-Reply-To: References: <98054BD3-E02A-4A40-9192-6F63C80FBE50@gmail.com> <8FFBD8A4-3F6C-4758-90DE-60ED3C0AD634@gmail.com> Message-ID: Hi Pedro, Is it possible that your transform is mapping the tags into oblivion? The standard set of tags are in ICBM stx space, and the argument to -tag_transform should be an xfm that maps those standard tags to the subject image. Just from the file name of the xfm you are using, I'd say you may need to invert it first? -- A On Mon, Oct 10, 2016 at 9:06 AM, Pedro wrote: > Hi Alex > > $ classify_clean -tag_transform t1_2talnlin.xfm -mask mask.mnc > -mask_source t1.mnc t1_class.mnc > > Shouldn?t classify_clean be using background tags from > /opt/minc/share/classify/ntags_1000_bg.tag by default? > > > > Em 7 de out de 2016, ?(s) 22:27, Alex Zijdenbos > escreveu: > > > > Hi Pedro, > > > > My guess would be that you are not providing classify with (a) sample(s) > of 'bg'. Exactly how are you invoking it? > > > > -- A > > > > > > Sent from mobile > > > >> On Oct 7, 2016, at 12:51, Pedro wrote: > >> > >> Hi, > >> > >> I?m getting background and CSF to have the same label value with > classify. Is it possible to avoid this? I tried using -mask -mask_source > brain_mask.mnc, still with background labels as ?1?. > >> > >> Thanks > >> Pedro > >> _______________________________________________ > >> 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 > > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From ptcougopinto at gmail.com Mon Oct 10 09:57:04 2016 From: ptcougopinto at gmail.com (Pedro) Date: Mon, 10 Oct 2016 10:57:04 -0300 Subject: [MINC-users] classify: bg and csf In-Reply-To: References: <98054BD3-E02A-4A40-9192-6F63C80FBE50@gmail.com> <8FFBD8A4-3F6C-4758-90DE-60ED3C0AD634@gmail.com> Message-ID: I had understood that the .xfm file was from native to ICBM. I think this transformation is inverted before transforming the tags. Quoting a prior email thread: is a tranform from your native data space (input.mnc) to the space of the tags. If you are using the ones in the standard package this will be a transform from native space to the icbm152 model. > Em 10 de out de 2016, ?(s) 10:45, Alex Zijdenbos escreveu: > > Hi Pedro, > > Is it possible that your transform is mapping the tags into oblivion? The > standard set of tags are in ICBM stx space, and the argument to > -tag_transform should be an xfm that maps those standard tags to the > subject image. Just from the file name of the xfm you are using, I'd say > you may need to invert it first? > > -- A > > On Mon, Oct 10, 2016 at 9:06 AM, Pedro wrote: > >> Hi Alex >> >> $ classify_clean -tag_transform t1_2talnlin.xfm -mask mask.mnc >> -mask_source t1.mnc t1_class.mnc >> >> Shouldn?t classify_clean be using background tags from >> /opt/minc/share/classify/ntags_1000_bg.tag by default? >> >> >>> Em 7 de out de 2016, ?(s) 22:27, Alex Zijdenbos >> escreveu: >>> >>> Hi Pedro, >>> >>> My guess would be that you are not providing classify with (a) sample(s) >> of 'bg'. Exactly how are you invoking it? >>> >>> -- A >>> >>> >>> Sent from mobile >>> >>>> On Oct 7, 2016, at 12:51, Pedro wrote: >>>> >>>> Hi, >>>> >>>> I?m getting background and CSF to have the same label value with >> classify. Is it possible to avoid this? I tried using -mask -mask_source >> brain_mask.mnc, still with background labels as ?1?. >>>> >>>> Thanks >>>> Pedro >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 zijdenbos at gmail.com Mon Oct 10 10:18:09 2016 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Mon, 10 Oct 2016 10:18:09 -0400 Subject: [MINC-users] classify: bg and csf In-Reply-To: References: <98054BD3-E02A-4A40-9192-6F63C80FBE50@gmail.com> <8FFBD8A4-3F6C-4758-90DE-60ED3C0AD634@gmail.com> Message-ID: Hi Pedro, Hrm - you are right - so that is a bug in the documentation: 'classify_clean -help' clearly states "non-linear transformation to map the tags from stereotaxic space to subject", which is wrong in a few ways (the xfm is in fact inverted, and it doesn't need to be a non-linear transformation either). I would suggest you double-check (using the log file and -tmpdir and -keeptmp) whether the tags that are provided to classify itself, are still good (contain all classes, and actually match the image). If that doesn't clarify it, send the mnc and xfm files and I can take a look. -- A On Mon, Oct 10, 2016 at 9:57 AM, Pedro wrote: > I had understood that the .xfm file was from native to ICBM. I think this > transformation is inverted before transforming the tags. Quoting a prior > email thread: > > is a tranform from your native data space > (input.mnc) to the space of the tags. If you are using the ones in the > standard package this will be a transform from native space to the > icbm152 model. > > > Em 10 de out de 2016, ?(s) 10:45, Alex Zijdenbos > escreveu: > > > > Hi Pedro, > > > > Is it possible that your transform is mapping the tags into oblivion? The > > standard set of tags are in ICBM stx space, and the argument to > > -tag_transform should be an xfm that maps those standard tags to the > > subject image. Just from the file name of the xfm you are using, I'd say > > you may need to invert it first? > > > > -- A > > > > On Mon, Oct 10, 2016 at 9:06 AM, Pedro wrote: > > > >> Hi Alex > >> > >> $ classify_clean -tag_transform t1_2talnlin.xfm -mask mask.mnc > >> -mask_source t1.mnc t1_class.mnc > >> > >> Shouldn?t classify_clean be using background tags from > >> /opt/minc/share/classify/ntags_1000_bg.tag by default? > >> > >> > >>> Em 7 de out de 2016, ?(s) 22:27, Alex Zijdenbos > >> escreveu: > >>> > >>> Hi Pedro, > >>> > >>> My guess would be that you are not providing classify with (a) > sample(s) > >> of 'bg'. Exactly how are you invoking it? > >>> > >>> -- A > >>> > >>> > >>> Sent from mobile > >>> > >>>> On Oct 7, 2016, at 12:51, Pedro wrote: > >>>> > >>>> Hi, > >>>> > >>>> I?m getting background and CSF to have the same label value with > >> classify. Is it possible to avoid this? I tried using -mask -mask_source > >> brain_mask.mnc, still with background labels as ?1?. > >>>> > >>>> Thanks > >>>> Pedro > >>>> _______________________________________________ > >>>> 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 > >> > >> _______________________________________________ > >> 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 > > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From ptcougopinto at gmail.com Mon Oct 10 10:29:57 2016 From: ptcougopinto at gmail.com (Pedro) Date: Mon, 10 Oct 2016 11:29:57 -0300 Subject: [MINC-users] classify: bg and csf In-Reply-To: References: <98054BD3-E02A-4A40-9192-6F63C80FBE50@gmail.com> <8FFBD8A4-3F6C-4758-90DE-60ED3C0AD634@gmail.com> Message-ID: Transformed tags seem fine. I will send you the files. Thanks Pedro > Em 10 de out de 2016, ?(s) 11:18, Alex Zijdenbos escreveu: > > Hi Pedro, > > Hrm - you are right - so that is a bug in the documentation: > 'classify_clean -help' clearly states "non-linear transformation to map the > tags from stereotaxic space to subject", which is wrong in a few ways (the > xfm is in fact inverted, and it doesn't need to be a non-linear > transformation either). > > I would suggest you double-check (using the log file and -tmpdir and > -keeptmp) whether the tags that are provided to classify itself, are still > good (contain all classes, and actually match the image). If that doesn't > clarify it, send the mnc and xfm files and I can take a look. > > -- A > > On Mon, Oct 10, 2016 at 9:57 AM, Pedro wrote: > >> I had understood that the .xfm file was from native to ICBM. I think this >> transformation is inverted before transforming the tags. Quoting a prior >> email thread: >> >> is a tranform from your native data space >> (input.mnc) to the space of the tags. If you are using the ones in the >> standard package this will be a transform from native space to the >> icbm152 model. >> >>> Em 10 de out de 2016, ?(s) 10:45, Alex Zijdenbos >> escreveu: >>> >>> Hi Pedro, >>> >>> Is it possible that your transform is mapping the tags into oblivion? The >>> standard set of tags are in ICBM stx space, and the argument to >>> -tag_transform should be an xfm that maps those standard tags to the >>> subject image. Just from the file name of the xfm you are using, I'd say >>> you may need to invert it first? >>> >>> -- A >>> >>> On Mon, Oct 10, 2016 at 9:06 AM, Pedro wrote: >>> >>>> Hi Alex >>>> >>>> $ classify_clean -tag_transform t1_2talnlin.xfm -mask mask.mnc >>>> -mask_source t1.mnc t1_class.mnc >>>> >>>> Shouldn?t classify_clean be using background tags from >>>> /opt/minc/share/classify/ntags_1000_bg.tag by default? >>>> >>>> >>>>> Em 7 de out de 2016, ?(s) 22:27, Alex Zijdenbos >>>> escreveu: >>>>> >>>>> Hi Pedro, >>>>> >>>>> My guess would be that you are not providing classify with (a) >> sample(s) >>>> of 'bg'. Exactly how are you invoking it? >>>>> >>>>> -- A >>>>> >>>>> >>>>> Sent from mobile >>>>> >>>>>> On Oct 7, 2016, at 12:51, Pedro wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I?m getting background and CSF to have the same label value with >>>> classify. Is it possible to avoid this? I tried using -mask -mask_source >>>> brain_mask.mnc, still with background labels as ?1?. >>>>>> >>>>>> Thanks >>>>>> Pedro >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 zijdenbos at gmail.com Mon Oct 10 16:52:01 2016 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Mon, 10 Oct 2016 16:52:01 -0400 Subject: [MINC-users] classify: bg and csf In-Reply-To: References: <98054BD3-E02A-4A40-9192-6F63C80FBE50@gmail.com> <8FFBD8A4-3F6C-4758-90DE-60ED3C0AD634@gmail.com> Message-ID: Hi Pedro, It looks like the background tags are not used at all. I think the immediate solution for you would be to add -mask_classified to the classify_clean invocation; that will force '0' everywhere outside the mask. Although I don't recall at the moment, this was probably a design decision somewhere along the way; if you train a classifier on background, you are actually likely to introduce 'holes' in the classified image. The current approach, which is to only assign '0' to voxels outside the mask, essentially forces all voxels inside the mask to end up in one of the 3 tissue classes. Clearly classify_clean could use some updating and clarifications. Also, on your image, the tag cleaning step (if you add -clean_tags) actually crashes, which it also should not do. -- A On Mon, Oct 10, 2016 at 10:29 AM, Pedro wrote: > Transformed tags seem fine. I will send you the files. > Thanks > Pedro > > > Em 10 de out de 2016, ?(s) 11:18, Alex Zijdenbos > escreveu: > > > > Hi Pedro, > > > > Hrm - you are right - so that is a bug in the documentation: > > 'classify_clean -help' clearly states "non-linear transformation to map > the > > tags from stereotaxic space to subject", which is wrong in a few ways > (the > > xfm is in fact inverted, and it doesn't need to be a non-linear > > transformation either). > > > > I would suggest you double-check (using the log file and -tmpdir and > > -keeptmp) whether the tags that are provided to classify itself, are > still > > good (contain all classes, and actually match the image). If that doesn't > > clarify it, send the mnc and xfm files and I can take a look. > > > > -- A > > > > On Mon, Oct 10, 2016 at 9:57 AM, Pedro wrote: > > > >> I had understood that the .xfm file was from native to ICBM. I think > this > >> transformation is inverted before transforming the tags. Quoting a prior > >> email thread: > >> > >> is a tranform from your native data space > >> (input.mnc) to the space of the tags. If you are using the ones in the > >> standard package this will be a transform from native space to the > >> icbm152 model. > >> > >>> Em 10 de out de 2016, ?(s) 10:45, Alex Zijdenbos > >> escreveu: > >>> > >>> Hi Pedro, > >>> > >>> Is it possible that your transform is mapping the tags into oblivion? > The > >>> standard set of tags are in ICBM stx space, and the argument to > >>> -tag_transform should be an xfm that maps those standard tags to the > >>> subject image. Just from the file name of the xfm you are using, I'd > say > >>> you may need to invert it first? > >>> > >>> -- A > >>> > >>> On Mon, Oct 10, 2016 at 9:06 AM, Pedro wrote: > >>> > >>>> Hi Alex > >>>> > >>>> $ classify_clean -tag_transform t1_2talnlin.xfm -mask mask.mnc > >>>> -mask_source t1.mnc t1_class.mnc > >>>> > >>>> Shouldn?t classify_clean be using background tags from > >>>> /opt/minc/share/classify/ntags_1000_bg.tag by default? > >>>> > >>>> > >>>>> Em 7 de out de 2016, ?(s) 22:27, Alex Zijdenbos > > >>>> escreveu: > >>>>> > >>>>> Hi Pedro, > >>>>> > >>>>> My guess would be that you are not providing classify with (a) > >> sample(s) > >>>> of 'bg'. Exactly how are you invoking it? > >>>>> > >>>>> -- A > >>>>> > >>>>> > >>>>> Sent from mobile > >>>>> > >>>>>> On Oct 7, 2016, at 12:51, Pedro wrote: > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> I?m getting background and CSF to have the same label value with > >>>> classify. Is it possible to avoid this? I tried using -mask > -mask_source > >>>> brain_mask.mnc, still with background labels as ?1?. > >>>>>> > >>>>>> Thanks > >>>>>> Pedro > >>>>>> _______________________________________________ > >>>>>> 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 > >>>> > >>>> _______________________________________________ > >>>> 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 > >> > >> _______________________________________________ > >> 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 > > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From caroline.paquette at mcgill.ca Wed Oct 12 22:23:48 2016 From: caroline.paquette at mcgill.ca (Caroline Paquette) Date: Wed, 12 Oct 2016 22:23:48 -0400 Subject: [MINC-users] nii2mnc conversion offset Message-ID: Hi, We're having trouble converting images from nifti to minc (drawn roi with t1). As seen in these images, when images are in nii, alignment is fine but when converting to mnc (using nii2mnc), there is a large offset. Any idea on what we're doing wrong? I had tried deleting the orientation in nii with success in the past but it does not solve the problem here. Thanks! Caroline From robert.d.vincent at mcgill.ca Wed Oct 12 23:12:35 2016 From: robert.d.vincent at mcgill.ca (Robert D. Vincent) Date: Wed, 12 Oct 2016 23:12:35 -0400 Subject: [MINC-users] nii2mnc conversion offset In-Reply-To: References: Message-ID: Hi, There are some known problems with the nii2mnc transform conversion, there is a new version that should address it. Contact me directly if you'd like to get a binary copy. -bert On Wed, Oct 12, 2016 at 10:23 PM, Caroline Paquette < caroline.paquette at mcgill.ca> wrote: > Hi, > > We're having trouble converting images from nifti to minc (drawn roi with > t1). As seen in these images, when images are in nii, alignment is fine but > when converting to mnc (using nii2mnc), there is a large offset. > > Any idea on what we're doing wrong? I had tried deleting the orientation > in nii with success in the past but it does not solve the problem here. > > Thanks! > > Caroline > > > > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From eskild at gmail.com Fri Oct 14 12:54:17 2016 From: eskild at gmail.com (Simon Eskildsen) Date: Fri, 14 Oct 2016 18:54:17 +0200 Subject: [MINC-users] nii2mnc conversion offset In-Reply-To: References: Message-ID: Hi Bert, Does this resolve the issue we have been discussing on github? https://github.com/BIC-MNI/minc-tools/issues/32 If so, did you commit the code? Thanks, Simon On Thu, Oct 13, 2016 at 5:12 AM, Robert D. Vincent < robert.d.vincent at mcgill.ca> wrote: > Hi, > > There are some known problems with the nii2mnc transform conversion, there > is a new version that should address it. > > Contact me directly if you'd like to get a binary copy. > > -bert > > On Wed, Oct 12, 2016 at 10:23 PM, Caroline Paquette < > caroline.paquette at mcgill.ca> wrote: > > > Hi, > > > > We're having trouble converting images from nifti to minc (drawn roi with > > t1). As seen in these images, when images are in nii, alignment is fine > but > > when converting to mnc (using nii2mnc), there is a large offset. > > > > Any idea on what we're doing wrong? I had tried deleting the orientation > > in nii with success in the past but it does not solve the problem here. > > > > Thanks! > > > > Caroline > > > > > > > > _______________________________________________ > > 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 zijdenbos at gmail.com Thu Oct 20 10:44:32 2016 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Thu, 20 Oct 2016 10:44:32 -0400 Subject: [MINC-users] mincreshape sets start/step on vector_dimension Message-ID: Hi all, Using mincreshape to manipulate the spatial dimensions of a deformation field, I notice two things (example below): 1) It complains about 'vector_dimension' being a non-standard dimension. Given the ubiquitous minctracc-generated deformation fields, shouldn't 'vector_dimension' be a 'standard' dimension by now? 2) it arbitrarily sets start=0 and step=1 for that dimension. If a dimension is untouched and doesn't/shouldn't have start or step values to begin with, I'd say that mincreshape shouldn't 'invent' a start and step for it, but leave these undefined. Thoughts? -- A $ mincreshape -dimorder zspace,yspace,xspace in_grid_0.mnc out_grid_0.mnc (from micreate_std_variable): Variable 'vector_dimension' is not a standard MINC variable Copying chunks:...............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................Done. $ mincinfo in_grid_0.mnc out_grid_0.mnc file: in_grid_0.mnc image: signed__ float -11.107932090759277344 to 11.2635040283203125 image dimensions: vector_dimension zspace yspace xspace dimension name length step start -------------- ------ ---- ----- vector_dimension 3 unknown unknown zspace 181 1 -72 yspace 217 1 -126 xspace 181 1 -90 file: out_grid_0.mnc image: signed__ float -11.107932090759277344 to 11.2635040283203125 image dimensions: vector_dimension zspace yspace xspace dimension name length step start -------------- ------ ---- ----- vector_dimension 3 1 0 zspace 181 1 -72 yspace 217 1 -126 xspace 181 1 -90 From robert.d.vincent at mcgill.ca Thu Oct 20 10:47:32 2016 From: robert.d.vincent at mcgill.ca (Robert D. Vincent) Date: Thu, 20 Oct 2016 10:47:32 -0400 Subject: [MINC-users] mincreshape sets start/step on vector_dimension In-Reply-To: References: Message-ID: Hi Alex, I think Vlad may have fixed this a while back - I don't know if it's in a release yet. -bert On Thu, Oct 20, 2016 at 10:44 AM, Alex Zijdenbos wrote: > Hi all, > > Using mincreshape to manipulate the spatial dimensions of a deformation > field, I notice two things (example below): > > 1) It complains about 'vector_dimension' being a non-standard dimension. > Given the ubiquitous minctracc-generated deformation fields, shouldn't > 'vector_dimension' be a 'standard' dimension by now? > > 2) it arbitrarily sets start=0 and step=1 for that dimension. If a > dimension is untouched and doesn't/shouldn't have start or step values to > begin with, I'd say that mincreshape shouldn't 'invent' a start and step > for it, but leave these undefined. > > Thoughts? > > -- A > > > $ mincreshape -dimorder zspace,yspace,xspace in_grid_0.mnc out_grid_0.mnc > (from micreate_std_variable): Variable 'vector_dimension' is not a standard > MINC variable > Copying > chunks:..................................................... > ............................................................ > ............................................................ > ............................................................ > ............................................................ > ............................................................ > ............................................................ > ............................................................ > ............................................................ > ..........Done. > $ mincinfo in_grid_0.mnc out_grid_0.mnc > file: in_grid_0.mnc > image: signed__ float -11.107932090759277344 to 11.2635040283203125 > image dimensions: vector_dimension zspace yspace xspace > dimension name length step start > -------------- ------ ---- ----- > vector_dimension 3 unknown unknown > zspace 181 1 -72 > yspace 217 1 -126 > xspace 181 1 -90 > > > file: out_grid_0.mnc > image: signed__ float -11.107932090759277344 to 11.2635040283203125 > image dimensions: vector_dimension zspace yspace xspace > dimension name length step start > -------------- ------ ---- ----- > vector_dimension 3 1 0 > zspace 181 1 -72 > yspace 217 1 -126 > xspace 181 1 -90 > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From vladimir.fonov at gmail.com Thu Oct 20 10:56:33 2016 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Thu, 20 Oct 2016 10:56:33 -0400 Subject: [MINC-users] mincreshape sets start/step on vector_dimension In-Reply-To: References: Message-ID: <58ce0e4f-4755-0dfa-8001-a394b1680003@gmail.com> Yes,definitely commented out here: https://github.com/BIC-MNI/libminc/blob/develop/libsrc/minc_convenience.c#L863 On 2016-10-20 10:47 AM, Robert D. Vincent wrote: > Hi Alex, > > I think Vlad may have fixed this a while back - I don't know if it's in a > release yet. > > -bert > > On Thu, Oct 20, 2016 at 10:44 AM, Alex Zijdenbos > wrote: > >> Hi all, >> >> Using mincreshape to manipulate the spatial dimensions of a deformation >> field, I notice two things (example below): >> >> 1) It complains about 'vector_dimension' being a non-standard dimension. >> Given the ubiquitous minctracc-generated deformation fields, shouldn't >> 'vector_dimension' be a 'standard' dimension by now? >> >> 2) it arbitrarily sets start=0 and step=1 for that dimension. If a >> dimension is untouched and doesn't/shouldn't have start or step values to >> begin with, I'd say that mincreshape shouldn't 'invent' a start and step >> for it, but leave these undefined. >> >> Thoughts? >> >> -- A >> >> >> $ mincreshape -dimorder zspace,yspace,xspace in_grid_0.mnc out_grid_0.mnc >> (from micreate_std_variable): Variable 'vector_dimension' is not a standard >> MINC variable >> Copying >> chunks:..................................................... >> ............................................................ >> ............................................................ >> ............................................................ >> ............................................................ >> ............................................................ >> ............................................................ >> ............................................................ >> ............................................................ >> ..........Done. >> $ mincinfo in_grid_0.mnc out_grid_0.mnc >> file: in_grid_0.mnc >> image: signed__ float -11.107932090759277344 to 11.2635040283203125 >> image dimensions: vector_dimension zspace yspace xspace >> dimension name length step start >> -------------- ------ ---- ----- >> vector_dimension 3 unknown unknown >> zspace 181 1 -72 >> yspace 217 1 -126 >> xspace 181 1 -90 >> >> >> file: out_grid_0.mnc >> image: signed__ float -11.107932090759277344 to 11.2635040283203125 >> image dimensions: vector_dimension zspace yspace xspace >> dimension name length step start >> -------------- ------ ---- ----- >> vector_dimension 3 1 0 >> zspace 181 1 -72 >> yspace 217 1 -126 >> xspace 181 1 -90 >> _______________________________________________ >> 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 > -- Best regards, Vladimir S. FONOV ~ vladimir.fonov gmail.com From gabriel.devenyi at mcgill.ca Mon Oct 24 13:29:27 2016 From: gabriel.devenyi at mcgill.ca (Gabriel A. Devenyi) Date: Mon, 24 Oct 2016 13:29:27 -0400 Subject: [MINC-users] Blurring with noise and/or sharp edges Message-ID: Hi all, I have some data I'd like to blur which has "nonsense" voxels outside the brain (MP2RAGE maps). I want to exclude these voxels from the blur. If I zero out these voxels I get an edge effect, the apodizing doesn't help as much as I'd like it to. Is anyone aware of an alternate blurring method which can avoid these issues? Thanks. -- Gabriel A. Devenyi B.Eng. Ph.D. Research Computing Associate Computational Brain Anatomy Laboratory Cerebral Imaging Center Douglas Mental Health University Institute McGill University t: 514.761.6131x4781 e: gabriel.devenyi at mcgill.ca From louis.collins at mcgill.ca Mon Oct 24 13:33:43 2016 From: louis.collins at mcgill.ca (Louis Collins, Dr.) Date: Mon, 24 Oct 2016 17:33:43 +0000 Subject: [MINC-users] Blurring with noise and/or sharp edges In-Reply-To: <13586_1477330300_580E4577_13586_11_10_CAFQOoOrehT0Vru3S=VNxOSri7Oc2X4E-d+-f5190fxPF7VXr5A@mail.gmail.com> References: <13586_1477330300_580E4577_13586_11_10_CAFQOoOrehT0Vru3S=VNxOSri7Oc2X4E-d+-f5190fxPF7VXr5A@mail.gmail.com> Message-ID: <45CA7456-E584-4400-820F-D734DBBF1ECE@mcgill.ca> Gabriel, How about denoising first, then blurring? -Louis > On Oct 24, 2016, at 1:29 PM, Gabriel A. Devenyi wrote: > > Hi all, > > I have some data I'd like to blur which has "nonsense" voxels outside the > brain (MP2RAGE maps). I want to exclude these voxels from the blur. If I > zero out these voxels I get an edge effect, the apodizing doesn't help as > much as I'd like it to. > > Is anyone aware of an alternate blurring method which can avoid these > issues? > > Thanks. > > -- > Gabriel A. Devenyi B.Eng. Ph.D. > Research Computing Associate > Computational Brain Anatomy Laboratory > Cerebral Imaging Center > Douglas Mental Health University Institute > McGill University > t: 514.761.6131x4781 > e: gabriel.devenyi at mcgill.ca > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From dswack at buffalo.edu Mon Oct 24 14:02:59 2016 From: dswack at buffalo.edu (David Wack) Date: Mon, 24 Oct 2016 14:02:59 -0400 Subject: [MINC-users] Blurring with noise and/or sharp edges In-Reply-To: <45CA7456-E584-4400-820F-D734DBBF1ECE@mcgill.ca> References: <13586_1477330300_580E4577_13586_11_10_CAFQOoOrehT0Vru3S=VNxOSri7Oc2X4E-d+-f5190fxPF7VXr5A@mail.gmail.com> <45CA7456-E584-4400-820F-D734DBBF1ECE@mcgill.ca> Message-ID: You might try what I call masked smoothing. http://bmcmedimaging.biomedcentral.com/articles/10.1186/1471-2342-14-28 I used it to smooth separately vessels and tissue in CT, but it works just as well for any mask. If I remember correctly you just need to mask the image, then smooth, then correct using the same smoothing applied to the mask. d On Mon, Oct 24, 2016 at 1:33 PM, Louis Collins, Dr. wrote: > Gabriel, > How about denoising first, then blurring? > -Louis > > > On Oct 24, 2016, at 1:29 PM, Gabriel A. Devenyi < > gabriel.devenyi at mcgill.ca> wrote: > > > > Hi all, > > > > I have some data I'd like to blur which has "nonsense" voxels outside the > > brain (MP2RAGE maps). I want to exclude these voxels from the blur. If I > > zero out these voxels I get an edge effect, the apodizing doesn't help as > > much as I'd like it to. > > > > Is anyone aware of an alternate blurring method which can avoid these > > issues? > > > > Thanks. > > > > -- > > Gabriel A. Devenyi B.Eng. Ph.D. > > Research Computing Associate > > Computational Brain Anatomy Laboratory > > Cerebral Imaging Center > > Douglas Mental Health University Institute > > McGill University > > t: 514.761.6131x4781 > > e: gabriel.devenyi at mcgill.ca > > _______________________________________________ > > 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 > -- David S. Wack, PhD Research Associate Professor Dept. of Nuclear Medicine University at Buffalo tel: 716 838-5889 ext 152 cell: 716 319-4853 email: dswack at buffalo.edu or : dswack at gmail.com