From a.janke at gmail.com Wed Dec 21 20:46:38 2016 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 22 Dec 2016 11:46:38 +1000 Subject: [MINC-development] Grid transforms Message-ID: Hi all, I understand that a while back the precision of grid transforms went from short to double. This was probably around the -50 -> + 50 wierdness that used to happen within minctracc. Perhaps there were also other rationales. Were there also other changes to libminc/volume_io to support this? I ask as I'm getting wierdness with xfmconcat when I feed in a zero grid transform. ie: mincresample -xstep 32 -ystep 32 -zstep 32 \ -xnelements 10 -ynelements 10 -znelements 10 \ /opt/minc/share/icbm152_model_09c/mni_icbm152_t1_tal_nlin_sym_09c.mnc /tmp/like.mnc minclookup -signed -short -lut_string '0 0 0 0;1 0 0 0' /tmp/like.mnc /tmp/like_vector.mnc mincreshape -dimorder vector_dimension,zspace,yspace,xspace \ /tmp/like_vector.mnc /tmp/zero_grid_0.mnc echo "MNI Transform File" > /tmp/zero.xfm echo "Transform_Type = Grid_Transform;" >> /tmp/zero.xfm echo "Displacement_Volume = zero_grid_0.mnc;" >> /tmp/zero.xfm xfmconcat /tmp/zero.xfm /tmp/z.xfm mincstats /tmp/z.xfm cai-zeep:tmp$ mincstats z_grid_0.mnc *** mincstats - reported max (-32768) doesn't equal header (32767) File: z_grid_0.mnc Mask file: (null) Total voxels: 3000 # voxels: 3000 % of total: 100 Volume (mm3): 98304000 Min: -32768 Max: -32768 Note the messed up min and max. This will work however if you make an unsigned short volume at the minclookup stage. If I then use this transform things of course go awry instead of it being a zero xfm. So, is this defined or unexpected behaviour? If I use a double, I get a more interesting error instead of a failure. xfmconcat ident-32.xfm /tmp/d.xfm Volume has invalid min and max voxel value ta a From vladimir.fonov at gmail.com Wed Dec 21 20:54:35 2016 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Wed, 21 Dec 2016 20:54:35 -0500 Subject: [MINC-development] Grid transforms In-Reply-To: References: Message-ID: Try specifying -image_range 0 1 -valid_range 0 1 in mincreshape On Dec 21, 2016 8:47 PM, "Andrew Janke" wrote: > Hi all, > > I understand that a while back the precision of grid transforms went > from short to double. This was probably around the -50 -> + 50 > wierdness that used to happen within minctracc. Perhaps there were > also other rationales. > > Were there also other changes to libminc/volume_io to support this? I > ask as I'm getting wierdness with xfmconcat when I feed in a zero grid > transform. ie: > > mincresample -xstep 32 -ystep 32 -zstep 32 \ > -xnelements 10 -ynelements 10 -znelements 10 \ > /opt/minc/share/icbm152_model_09c/mni_icbm152_t1_tal_nlin_sym_09c.mnc > /tmp/like.mnc > > minclookup -signed -short -lut_string '0 0 0 0;1 0 0 0' /tmp/like.mnc > /tmp/like_vector.mnc > > mincreshape -dimorder vector_dimension,zspace,yspace,xspace \ > /tmp/like_vector.mnc /tmp/zero_grid_0.mnc > > echo "MNI Transform File" > /tmp/zero.xfm > echo "Transform_Type = Grid_Transform;" >> /tmp/zero.xfm > echo "Displacement_Volume = zero_grid_0.mnc;" >> /tmp/zero.xfm > > xfmconcat /tmp/zero.xfm /tmp/z.xfm > > mincstats /tmp/z.xfm > > cai-zeep:tmp$ mincstats z_grid_0.mnc > *** mincstats - reported max (-32768) doesn't equal header (32767) > File: z_grid_0.mnc > Mask file: (null) > Total voxels: 3000 > # voxels: 3000 > % of total: 100 > Volume (mm3): 98304000 > Min: -32768 > Max: -32768 > > Note the messed up min and max. This will work however if you make an > unsigned short volume at the minclookup stage. If I then use this > transform things of course go awry instead of it being a zero xfm. > > So, is this defined or unexpected behaviour? If I use a double, I get > a more interesting error instead of a failure. > > xfmconcat ident-32.xfm /tmp/d.xfm > Volume has invalid min and max voxel value > > > ta > > > a > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.janke at gmail.com Wed Dec 21 22:59:59 2016 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 22 Dec 2016 13:59:59 +1000 Subject: [MINC-development] Grid transforms In-Reply-To: References: Message-ID: Yup, this does work, (along with using anything other than a signed type). The problem is that this only goes awry when you pass the file as part of an xfm to xfmconcat, not during routine mincreshape/mincmath games. So, I'd argue it's a bug in volume_io (concatenate_general_transforms) but it comes down to what is defined behaviour in MINC with grid transforms. As far as I am aware this isn't defined and largely "whatever minctracc puts out". If this is the case should we: a) Warn the user if an input grid file is given which isn't either unsigned short or double (currently used options by minctracc) b) Convert it to something that will work. ta a On 22 December 2016 at 11:54, Vladimir S. FONOV wrote: > Try specifying -image_range 0 1 -valid_range 0 1 in mincreshape > > On Dec 21, 2016 8:47 PM, "Andrew Janke" wrote: >> >> Hi all, >> >> I understand that a while back the precision of grid transforms went >> from short to double. This was probably around the -50 -> + 50 >> wierdness that used to happen within minctracc. Perhaps there were >> also other rationales. >> >> Were there also other changes to libminc/volume_io to support this? I >> ask as I'm getting wierdness with xfmconcat when I feed in a zero grid >> transform. ie: >> >> mincresample -xstep 32 -ystep 32 -zstep 32 \ >> -xnelements 10 -ynelements 10 -znelements 10 \ >> /opt/minc/share/icbm152_model_09c/mni_icbm152_t1_tal_nlin_sym_09c.mnc >> /tmp/like.mnc >> >> minclookup -signed -short -lut_string '0 0 0 0;1 0 0 0' /tmp/like.mnc >> /tmp/like_vector.mnc >> >> mincreshape -dimorder vector_dimension,zspace,yspace,xspace \ >> /tmp/like_vector.mnc /tmp/zero_grid_0.mnc >> >> echo "MNI Transform File" > /tmp/zero.xfm >> echo "Transform_Type = Grid_Transform;" >> /tmp/zero.xfm >> echo "Displacement_Volume = zero_grid_0.mnc;" >> /tmp/zero.xfm >> >> xfmconcat /tmp/zero.xfm /tmp/z.xfm >> >> mincstats /tmp/z.xfm >> >> cai-zeep:tmp$ mincstats z_grid_0.mnc >> *** mincstats - reported max (-32768) doesn't equal header (32767) >> File: z_grid_0.mnc >> Mask file: (null) >> Total voxels: 3000 >> # voxels: 3000 >> % of total: 100 >> Volume (mm3): 98304000 >> Min: -32768 >> Max: -32768 >> >> Note the messed up min and max. This will work however if you make an >> unsigned short volume at the minclookup stage. If I then use this >> transform things of course go awry instead of it being a zero xfm. >> >> So, is this defined or unexpected behaviour? If I use a double, I get >> a more interesting error instead of a failure. >> >> xfmconcat ident-32.xfm /tmp/d.xfm >> Volume has invalid min and max voxel value >> >> >> ta >> >> >> a >> _______________________________________________ >> MINC-development mailing list >> MINC-development at bic.mni.mcgill.ca >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > > > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > From vladimir.fonov at gmail.com Thu Dec 22 07:21:25 2016 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Thu, 22 Dec 2016 07:21:25 -0500 Subject: [MINC-development] Grid transforms In-Reply-To: References: Message-ID: That's usual MINC wired behavior with zero dynamic range volume. Have nothing to do with representing a transform. On Dec 21, 2016 11:01 PM, "Andrew Janke" wrote: > Yup, this does work, (along with using anything other than a signed type). > > The problem is that this only goes awry when you pass the file as part > of an xfm to xfmconcat, not during routine mincreshape/mincmath games. > > So, I'd argue it's a bug in volume_io (concatenate_general_transforms) > but it comes down to what is defined behaviour in MINC with grid > transforms. As far as I am aware this isn't defined and largely > "whatever minctracc puts out". > > If this is the case should we: > > a) Warn the user if an input grid file is given which isn't either > unsigned short or double (currently used options by minctracc) > > b) Convert it to something that will work. > > > ta > > a > > > > On 22 December 2016 at 11:54, Vladimir S. FONOV > wrote: > > Try specifying -image_range 0 1 -valid_range 0 1 in mincreshape > > > > On Dec 21, 2016 8:47 PM, "Andrew Janke" wrote: > >> > >> Hi all, > >> > >> I understand that a while back the precision of grid transforms went > >> from short to double. This was probably around the -50 -> + 50 > >> wierdness that used to happen within minctracc. Perhaps there were > >> also other rationales. > >> > >> Were there also other changes to libminc/volume_io to support this? I > >> ask as I'm getting wierdness with xfmconcat when I feed in a zero grid > >> transform. ie: > >> > >> mincresample -xstep 32 -ystep 32 -zstep 32 \ > >> -xnelements 10 -ynelements 10 -znelements 10 \ > >> /opt/minc/share/icbm152_model_09c/mni_icbm152_t1_tal_nlin_ > sym_09c.mnc > >> /tmp/like.mnc > >> > >> minclookup -signed -short -lut_string '0 0 0 0;1 0 0 0' /tmp/like.mnc > >> /tmp/like_vector.mnc > >> > >> mincreshape -dimorder vector_dimension,zspace,yspace,xspace \ > >> /tmp/like_vector.mnc /tmp/zero_grid_0.mnc > >> > >> echo "MNI Transform File" > /tmp/zero.xfm > >> echo "Transform_Type = Grid_Transform;" >> /tmp/zero.xfm > >> echo "Displacement_Volume = zero_grid_0.mnc;" >> /tmp/zero.xfm > >> > >> xfmconcat /tmp/zero.xfm /tmp/z.xfm > >> > >> mincstats /tmp/z.xfm > >> > >> cai-zeep:tmp$ mincstats z_grid_0.mnc > >> *** mincstats - reported max (-32768) doesn't equal header (32767) > >> File: z_grid_0.mnc > >> Mask file: (null) > >> Total voxels: 3000 > >> # voxels: 3000 > >> % of total: 100 > >> Volume (mm3): 98304000 > >> Min: -32768 > >> Max: -32768 > >> > >> Note the messed up min and max. This will work however if you make an > >> unsigned short volume at the minclookup stage. If I then use this > >> transform things of course go awry instead of it being a zero xfm. > >> > >> So, is this defined or unexpected behaviour? If I use a double, I get > >> a more interesting error instead of a failure. > >> > >> xfmconcat ident-32.xfm /tmp/d.xfm > >> Volume has invalid min and max voxel value > >> > >> > >> ta > >> > >> > >> a > >> _______________________________________________ > >> MINC-development mailing list > >> MINC-development at bic.mni.mcgill.ca > >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > > > > > > _______________________________________________ > > MINC-development mailing list > > MINC-development at bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > > > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: