From zijdenbos at gmail.com Tue May 7 23:28:22 2013 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Tue, 7 May 2013 23:28:22 -0400 Subject: [MINC-users] minctracc/masking bug? Message-ID: Hello all, I have been chasing some strange behaviour of minctracc, and finally narrowed it down to something that I would say is a bug in the way minctracc deals with masks. I have generated symmetric (about x=0), blurred source- and target images, and a mask derived from the target image by a simple threshold (and thus also symmetric). If I run minctracc to register these two without masks, I end up with a deformation field that is by and large symmetric as well. However if I add the symmetric mask via the -model_mask option to an otherwise identical minctracc call, the resulting deformation becomes highly asymmetric, and drags the source image out. I am using mni_autoreg 0.99.6, libminc 2.1 Summarized in this image: https://dl.dropboxusercontent.com/u/5709165/test_minctracc.jpg Row 1: source image Row 2: target image Row 3: target mask Row 4: deformation field magnitude without using mask Row 5: resampled source image with target mask outline Row 6/7: as rows 4/5, but after adding the target mask to minctracc Clearly the addition of the mask has a strong negative (and asymmetric) impact on the registration, while it seems it shouldn't have much of an effect at all. I have actually seen this behaviour before but was never able to pinpoint it so clearly. What appears to be happening is that masked registrations have a tendency to 'flow out' in a particular direction (towards the top right in coronal sections). Thoughts/suggestions, anyone? Thanks, -- Alex From claude at bic.mni.mcgill.ca Wed May 8 09:04:05 2013 From: claude at bic.mni.mcgill.ca (Claude LEPAGE) Date: Wed, 8 May 2013 09:04:05 -0400 Subject: [MINC-users] minctracc/masking bug? In-Reply-To: Message-ID: <201305081304.r48D45vN001678@agrippa.bic.mni.mcgill.ca> Hi Alex, This is a strange behaviour indeed. Can you tell me which line of code to change? :-) One thought: is the resulting grid symmetric with respect to the field of view? If the grid is asymmetric, the support of the masked image may be insufficient for some grid points lying very near the border of the masked image. I dealt with this in the old N3 where the control points for the splines were defined from the bottom-left corner. I made them centered from version 1.11.0. Maybe we can try the same in minctracc if it's not already the case. Also, what happens when you reduce the grid size? Does the error go away? Have you looked at the masked blurred (or blurred masked) images? Claude > Hello all, > > I have been chasing some strange behaviour of minctracc, and finally > narrowed it down to something that I would say is a bug in the way > minctracc deals with masks. > > I have generated symmetric (about x=0), blurred source- and target images, > and a mask derived from the target image by a simple threshold (and thus > also symmetric). If I run minctracc to register these two without masks, I > end up with a deformation field that is by and large symmetric as well. > However if I add the symmetric mask via the -model_mask option to an > otherwise identical minctracc call, the resulting deformation becomes > highly asymmetric, and drags the source image out. I am using mni_autoreg > 0.99.6, libminc 2.1 > > Summarized in this image: > > https://dl.dropboxusercontent.com/u/5709165/test_minctracc.jpg > > Row 1: source image > Row 2: target image > Row 3: target mask > Row 4: deformation field magnitude without using mask > Row 5: resampled source image with target mask outline > Row 6/7: as rows 4/5, but after adding the target mask to minctracc > > Clearly the addition of the mask has a strong negative (and asymmetric) > impact on the registration, while it seems it shouldn't have much of an > effect at all. > > I have actually seen this behaviour before but was never able to pinpoint > it so clearly. What appears to be happening is that masked registrations > have a tendency to 'flow out' in a particular direction (towards the top > right in coronal sections). > > Thoughts/suggestions, anyone? > > Thanks, > > -- Alex > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From zijdenbos at gmail.com Wed May 8 17:08:28 2013 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Wed, 8 May 2013 17:08:28 -0400 Subject: [MINC-users] minctracc/masking bug? In-Reply-To: <201305081304.r48D45vN001678@agrippa.bic.mni.mcgill.ca> References: <201305081304.r48D45vN001678@agrippa.bic.mni.mcgill.ca> Message-ID: Thanks, Claude! > This is a strange behaviour indeed. > > Can you tell me which line of code to change? :-) I wish :-) > One thought: is the resulting grid symmetric with respect to > the field of view? If the grid is asymmetric, the support of > the masked image may be insufficient for some grid points > lying very near the border of the masked image. I dealt with > this in the old N3 where the control points for the splines > were defined from the bottom-left corner. I made them centered > from version 1.11.0. Maybe we can try the same in minctracc > if it's not already the case. Also, what happens when you > reduce the grid size? Does the error go away? Have you looked > at the masked blurred (or blurred masked) images? I'm running experiments to look at all of the above. It turns out that in my initial tests, the source- and target images did not have a symmetric x-extent. Fixing that by changing the image lattice to be symmetric about x=0, it turned out that a) the change in image lattice (2 yz slices removed from the left) did change the resulting deformation field; but it still has roughly the same pattern (in other words, the final grid is affected by the extent of the lattice, but it doesn't fix the problem). The resulting grid is symmetric about x=0 though, so minctracc does seem to to the right thing in terms of deciding on the grid lattice. To be continued. -- A From a.janke at gmail.com Wed May 8 22:41:12 2013 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 9 May 2013 12:41:12 +1000 Subject: [MINC-users] minctracc/masking bug? In-Reply-To: References: Message-ID: Hi Alex, To add to Claudes suggestions. I see you are using mouse data, have you scaled the mouse data to "human" size (~ x30) or have you modified all the parameters of minctracc? If the second any problem you see will be exacerbated by constants. >From all the tests I have done over the years, minctracc does have a very small undershoot and consistent bias. This is an artifact of the way the minimisation works but is usually very very small and not a problem. (thus my comments on scale). I think your mask is too tight to use as a fit mask as you loose all the nice edge information. Once the data starts heading off the edge of the mask, minctracc has no idea where it is as it's no longer factored into the minimsation function. Perhaps pre-mask your data (with a blurred edge) and then fit using an expanded mask (5 or so voxels? with mincmorph) such that minctracc can benefit from the edge information. a On 8 May 2013 13:28, Alex Zijdenbos wrote: > Hello all, > > I have been chasing some strange behaviour of minctracc, and finally > narrowed it down to something that I would say is a bug in the way > minctracc deals with masks. > > I have generated symmetric (about x=0), blurred source- and target images, > and a mask derived from the target image by a simple threshold (and thus > also symmetric). If I run minctracc to register these two without masks, I > end up with a deformation field that is by and large symmetric as well. > However if I add the symmetric mask via the -model_mask option to an > otherwise identical minctracc call, the resulting deformation becomes > highly asymmetric, and drags the source image out. I am using mni_autoreg > 0.99.6, libminc 2.1 > > Summarized in this image: > > https://dl.dropboxusercontent.com/u/5709165/test_minctracc.jpg > > Row 1: source image > Row 2: target image > Row 3: target mask > Row 4: deformation field magnitude without using mask > Row 5: resampled source image with target mask outline > Row 6/7: as rows 4/5, but after adding the target mask to minctracc > > Clearly the addition of the mask has a strong negative (and asymmetric) > impact on the registration, while it seems it shouldn't have much of an > effect at all. > > I have actually seen this behaviour before but was never able to pinpoint > it so clearly. What appears to be happening is that masked registrations > have a tendency to 'flow out' in a particular direction (towards the top > right in coronal sections). > > Thoughts/suggestions, anyone? > > Thanks, > > -- Alex > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From zijdenbos at gmail.com Thu May 9 22:36:51 2013 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Thu, 9 May 2013 22:36:51 -0400 Subject: [MINC-users] minctracc/masking bug? In-Reply-To: References: Message-ID: Hi Andrew, In this particular set of tests I had adapted the minctracc parameters, but I also usually scale the brains up to roughly human size (by the way, the mice down under must be really tiny, or the humans very large - I always use a scale of ~12x for mouse-growing (in each dimension)). However I tried the same registration after scaling using a vanilla nlfit series, and got very similar results. The mask size definitely has an impact here; if I grow the mask, at some point the problem will by-and-large go away. There also appears to be a strong dependency on the grid step size; various experiments still running. When you mention a bias, are you talking about a directional bias? Because that is what I see coming back in all my experiments - and it has me rather concerned as a consistent directional bias in image deformation would likely cause bias in population analyses, especially for anybody looking at L/R differences. I suppose one solution to this would be to run all deformations twice, once 'normal' and once 'flipped'; but ideally this wouldn't be necessary (and I suspect not many people are actually doing this). -- A On Wed, May 8, 2013 at 10:41 PM, Andrew Janke wrote: > Hi Alex, > > To add to Claudes suggestions. > > I see you are using mouse data, have you scaled the mouse data to > "human" size (~ x30) or have you modified all the parameters of > minctracc? If the second any problem you see will be exacerbated by > constants. > > From all the tests I have done over the years, minctracc does have a > very small undershoot and consistent bias. This is an artifact of the > way the minimisation works but is usually very very small and not a > problem. (thus my comments on scale). > > I think your mask is too tight to use as a fit mask as you loose all > the nice edge information. Once the data starts heading off the edge > of the mask, minctracc has no idea where it is as it's no longer > factored into the minimsation function. Perhaps pre-mask your data > (with a blurred edge) and then fit using an expanded mask (5 or so > voxels? with mincmorph) such that minctracc can benefit from the edge > information. > > > a > > > On 8 May 2013 13:28, Alex Zijdenbos wrote: >> Hello all, >> >> I have been chasing some strange behaviour of minctracc, and finally >> narrowed it down to something that I would say is a bug in the way >> minctracc deals with masks. >> >> I have generated symmetric (about x=0), blurred source- and target images, >> and a mask derived from the target image by a simple threshold (and thus >> also symmetric). If I run minctracc to register these two without masks, I >> end up with a deformation field that is by and large symmetric as well. >> However if I add the symmetric mask via the -model_mask option to an >> otherwise identical minctracc call, the resulting deformation becomes >> highly asymmetric, and drags the source image out. I am using mni_autoreg >> 0.99.6, libminc 2.1 >> >> Summarized in this image: >> >> https://dl.dropboxusercontent.com/u/5709165/test_minctracc.jpg >> >> Row 1: source image >> Row 2: target image >> Row 3: target mask >> Row 4: deformation field magnitude without using mask >> Row 5: resampled source image with target mask outline >> Row 6/7: as rows 4/5, but after adding the target mask to minctracc >> >> Clearly the addition of the mask has a strong negative (and asymmetric) >> impact on the registration, while it seems it shouldn't have much of an >> effect at all. >> >> I have actually seen this behaviour before but was never able to pinpoint >> it so clearly. What appears to be happening is that masked registrations >> have a tendency to 'flow out' in a particular direction (towards the top >> right in coronal sections). >> >> Thoughts/suggestions, anyone? >> >> Thanks, >> >> -- Alex >> _______________________________________________ >> 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 claude at bic.mni.mcgill.ca Thu May 9 23:31:50 2013 From: claude at bic.mni.mcgill.ca (Claude LEPAGE) Date: Thu, 9 May 2013 23:31:50 -0400 Subject: [MINC-users] minctracc/masking bug? In-Reply-To: Message-ID: <201305100331.r4A3VoW9022823@agrippa.bic.mni.mcgill.ca> Alex, You got me curious here. If you mirror your image in x (param2xfm -scales -1 1 1) and perform the registration to the (symmetric) model, do you still observe the same bias? Has the bias been mirrored? Mirror the mask as well. I don't know if this can be related, but autocrop causes a shift in world coordinates. If this shift can be in autocrop, it can be in other minc tools. To keep it simple, use autocrop -isostep 0.5 on a file of labels. You will see that the xspace:start position is the same before and after. However, the start position is centroid based in voxel space. If the new voxel is 0.5mm instead of 1mm, its centroid will be shifted 0.25mm to the left. The formula to preserve world coordinates is: new_start = old_start - 0.5*old_voxel_size + 0.5*new_voxel_size Now, let's say you are resampling a displacement field from a 4mm grid to a 2mm grid... For my work on the bigbrain (histology at 10 microns), I have the following notes in my alignment script for non-linear registration: # 5 - Non-linear alignment of current histo_mid to average position # avg_id.mnc of id_prev and id_next. NEVER use a mask because # it will cause misregistration near borders where the target # mask differs from the source slice. # 7 - Full non-linear transform from original histo_mid to avg in previous step. # NOTE: Do NOT use a mask here with -init_xfm. There is a BUG in minctracc. Here, the slices are pre-masked, but I don't use a mask during registration. minctracc evaluates the displacement field everywhere in the field of view. In the rare cases I use a mask, I use only the target mask (without source mask) and I activate the mask only on the smallest grid. I don't remember the details for this approach, but I do remember that I had to do this for minctracc to be reliable. Claude > Hi Andrew, > > In this particular set of tests I had adapted the minctracc > parameters, but I also usually scale the brains up to roughly human > size (by the way, the mice down under must be really tiny, or the > humans very large - I always use a scale of ~12x for mouse-growing (in > each dimension)). However I tried the same registration after scaling > using a vanilla nlfit series, and got very similar results. > > The mask size definitely has an impact here; if I grow the mask, at > some point the problem will by-and-large go away. There also appears > to be a strong dependency on the grid step size; various experiments > still running. > > When you mention a bias, are you talking about a directional bias? > Because that is what I see coming back in all my experiments - and it > has me rather concerned as a consistent directional bias in image > deformation would likely cause bias in population analyses, especially > for anybody looking at L/R differences. I suppose one solution to this > would be to run all deformations twice, once 'normal' and once > 'flipped'; but ideally this wouldn't be necessary (and I suspect not > many people are actually doing this). > > -- A > > > On Wed, May 8, 2013 at 10:41 PM, Andrew Janke wrote: > > Hi Alex, > > > > To add to Claudes suggestions. > > > > I see you are using mouse data, have you scaled the mouse data to > > "human" size (~ x30) or have you modified all the parameters of > > minctracc? If the second any problem you see will be exacerbated by > > constants. > > > > From all the tests I have done over the years, minctracc does have a > > very small undershoot and consistent bias. This is an artifact of the > > way the minimisation works but is usually very very small and not a > > problem. (thus my comments on scale). > > > > I think your mask is too tight to use as a fit mask as you loose all > > the nice edge information. Once the data starts heading off the edge > > of the mask, minctracc has no idea where it is as it's no longer > > factored into the minimsation function. Perhaps pre-mask your data > > (with a blurred edge) and then fit using an expanded mask (5 or so > > voxels? with mincmorph) such that minctracc can benefit from the edge > > information. > > > > > > a > > > > > > On 8 May 2013 13:28, Alex Zijdenbos wrote: > >> Hello all, > >> > >> I have been chasing some strange behaviour of minctracc, and finally > >> narrowed it down to something that I would say is a bug in the way > >> minctracc deals with masks. > >> > >> I have generated symmetric (about x=0), blurred source- and target images, > >> and a mask derived from the target image by a simple threshold (and thus > >> also symmetric). If I run minctracc to register these two without masks, I > >> end up with a deformation field that is by and large symmetric as well. > >> However if I add the symmetric mask via the -model_mask option to an > >> otherwise identical minctracc call, the resulting deformation becomes > >> highly asymmetric, and drags the source image out. I am using mni_autoreg > >> 0.99.6, libminc 2.1 > >> > >> Summarized in this image: > >> > >> https://dl.dropboxusercontent.com/u/5709165/test_minctracc.jpg > >> > >> Row 1: source image > >> Row 2: target image > >> Row 3: target mask > >> Row 4: deformation field magnitude without using mask > >> Row 5: resampled source image with target mask outline > >> Row 6/7: as rows 4/5, but after adding the target mask to minctracc > >> > >> Clearly the addition of the mask has a strong negative (and asymmetric) > >> impact on the registration, while it seems it shouldn't have much of an > >> effect at all. > >> > >> I have actually seen this behaviour before but was never able to pinpoint > >> it so clearly. What appears to be happening is that masked registrations > >> have a tendency to 'flow out' in a particular direction (towards the top > >> right in coronal sections). > >> > >> Thoughts/suggestions, anyone? > >> > >> Thanks, > >> > >> -- Alex > >> _______________________________________________ > >> 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 a.janke at gmail.com Fri May 10 01:54:42 2013 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 10 May 2013 15:54:42 +1000 Subject: [MINC-users] minctracc/masking bug? In-Reply-To: References: Message-ID: > In this particular set of tests I had adapted the minctracc > parameters, but I also usually scale the brains up to roughly human > size ok. I know the phenogenomics crowd don't scale data and modify minctracc parameters. > (by the way, the mice down under must be really tiny, or the > humans very large - I always use a scale of ~12x for mouse-growing (in > each dimension)). Guess I should mention that these are ex-vivo mouse brains imaged at 16.4T 30um isotropic. > The mask size definitely has an impact here; if I grow the mask, at > some point the problem will by-and-large go away. There also appears > to be a strong dependency on the grid step size; various experiments > still running. My gut feeling is that your step size is too small. > When you mention a bias, are you talking about a directional bias? > Because that is what I see coming back in all my experiments - and it > has me rather concerned as a consistent directional bias in image > deformation would likely cause bias in population analyses, especially > for anybody looking at L/R differences. I suppose one solution to this > would be to run all deformations twice, once 'normal' and once > 'flipped'; but ideally this wouldn't be necessary (and I suspect not > many people are actually doing this). The bias is directional but is very small. Within the noise floor and also very likely well within the voxel discretisation and as such will probably never be seen when using tools like minctracc. The differences you are seeing are much larger than anything I have seen before. a From zijdenbos at gmail.com Fri May 10 12:07:00 2013 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Fri, 10 May 2013 12:07:00 -0400 Subject: [MINC-users] minctracc/masking bug? In-Reply-To: <201305100331.r4A3VoW9022823@agrippa.bic.mni.mcgill.ca> References: <201305100331.r4A3VoW9022823@agrippa.bic.mni.mcgill.ca> Message-ID: Hi Claude, Thanks for the tips. The data I am working on are also histology data; unfortunately I need to work with masks as the histology doesn't always have full coverage, and without the use of a mask the deformation will just stretch things to fit the target. In any event I am less concerned about the fact that there are tricks to be played with the mask, as you suggest; and I can understand how different masks could cause uncontrolled deformations. However I am very concerned about the asymmetry of the deformation; to answer your first question: the source-, -target, and -mask images I am using are all perfectly symmetric, both in terms of FoV (voxel extent) as well as in world coordinates (about x=0); all have the same resolution as well. If I flip them about x=0, I get exactly the same result. The image I posted is the result of a single call to minctracc by the way, so no iterative process or autocrop was involved. In fact if I run a series of registration steps (some 'usual' scale-space series), the effect compounds at every step, and I get things like what you see in this image: https://dl.dropboxusercontent.com/u/5709165/test_minctracc2.jpg Top row is the final resampled source image; 2nd (and last) row is the target; the rows going down are a series of steps with reducing FHWM/etc. Regardless of the quality of the warp itself, it shouldn't be asymmetric like this, given that the input data are symmetric. By the way, another interesting tidbit: if I reverse the direction (swap source and target), the deformation behaves much better. So far the only explanation I can think of, is that the optimizer follows a particular/fixed trajectory through the parameter space, implicitly generating an "expansion force" in a particular direction that can go unchecked given the right set of circumstances (a particular mask being one of them). Anyways, still testing different parameters, will report on what I find. -- A On Thu, May 9, 2013 at 11:31 PM, Claude LEPAGE wrote: > Alex, > > You got me curious here. > > If you mirror your image in x (param2xfm -scales -1 1 1) and perform > the registration to the (symmetric) model, do you still observe the > same bias? Has the bias been mirrored? Mirror the mask as well. > > I don't know if this can be related, but autocrop causes a shift in > world coordinates. If this shift can be in autocrop, it can be in > other minc tools. To keep it simple, use autocrop -isostep 0.5 > on a file of labels. You will see that the xspace:start position is > the same before and after. However, the start position is centroid > based in voxel space. If the new voxel is 0.5mm instead of 1mm, its > centroid will be shifted 0.25mm to the left. The formula to preserve > world coordinates is: > new_start = old_start - 0.5*old_voxel_size + 0.5*new_voxel_size > > Now, let's say you are resampling a displacement field from a 4mm grid > to a 2mm grid... > > For my work on the bigbrain (histology at 10 microns), I have the > following notes in my alignment script for non-linear registration: > > # 5 - Non-linear alignment of current histo_mid to average position > # avg_id.mnc of id_prev and id_next. NEVER use a mask because > # it will cause misregistration near borders where the target > # mask differs from the source slice. > > # 7 - Full non-linear transform from original histo_mid to avg in previous step. > # NOTE: Do NOT use a mask here with -init_xfm. There is a BUG in minctracc. > > Here, the slices are pre-masked, but I don't use a mask during > registration. minctracc evaluates the displacement field everywhere > in the field of view. In the rare cases I use a mask, I use only the > target mask (without source mask) and I activate the mask only on > the smallest grid. I don't remember the details for this approach, > but I do remember that I had to do this for minctracc to be reliable. > > Claude > >> Hi Andrew, >> >> In this particular set of tests I had adapted the minctracc >> parameters, but I also usually scale the brains up to roughly human >> size (by the way, the mice down under must be really tiny, or the >> humans very large - I always use a scale of ~12x for mouse-growing (in >> each dimension)). However I tried the same registration after scaling >> using a vanilla nlfit series, and got very similar results. >> >> The mask size definitely has an impact here; if I grow the mask, at >> some point the problem will by-and-large go away. There also appears >> to be a strong dependency on the grid step size; various experiments >> still running. >> >> When you mention a bias, are you talking about a directional bias? >> Because that is what I see coming back in all my experiments - and it >> has me rather concerned as a consistent directional bias in image >> deformation would likely cause bias in population analyses, especially >> for anybody looking at L/R differences. I suppose one solution to this >> would be to run all deformations twice, once 'normal' and once >> 'flipped'; but ideally this wouldn't be necessary (and I suspect not >> many people are actually doing this). >> >> -- A >> >> >> On Wed, May 8, 2013 at 10:41 PM, Andrew Janke wrote: >> > Hi Alex, >> > >> > To add to Claudes suggestions. >> > >> > I see you are using mouse data, have you scaled the mouse data to >> > "human" size (~ x30) or have you modified all the parameters of >> > minctracc? If the second any problem you see will be exacerbated by >> > constants. >> > >> > From all the tests I have done over the years, minctracc does have a >> > very small undershoot and consistent bias. This is an artifact of the >> > way the minimisation works but is usually very very small and not a >> > problem. (thus my comments on scale). >> > >> > I think your mask is too tight to use as a fit mask as you loose all >> > the nice edge information. Once the data starts heading off the edge >> > of the mask, minctracc has no idea where it is as it's no longer >> > factored into the minimsation function. Perhaps pre-mask your data >> > (with a blurred edge) and then fit using an expanded mask (5 or so >> > voxels? with mincmorph) such that minctracc can benefit from the edge >> > information. >> > >> > >> > a >> > >> > >> > On 8 May 2013 13:28, Alex Zijdenbos wrote: >> >> Hello all, >> >> >> >> I have been chasing some strange behaviour of minctracc, and finally >> >> narrowed it down to something that I would say is a bug in the way >> >> minctracc deals with masks. >> >> >> >> I have generated symmetric (about x=0), blurred source- and target images, >> >> and a mask derived from the target image by a simple threshold (and thus >> >> also symmetric). If I run minctracc to register these two without masks, I >> >> end up with a deformation field that is by and large symmetric as well. >> >> However if I add the symmetric mask via the -model_mask option to an >> >> otherwise identical minctracc call, the resulting deformation becomes >> >> highly asymmetric, and drags the source image out. I am using mni_autoreg >> >> 0.99.6, libminc 2.1 >> >> >> >> Summarized in this image: >> >> >> >> https://dl.dropboxusercontent.com/u/5709165/test_minctracc.jpg >> >> >> >> Row 1: source image >> >> Row 2: target image >> >> Row 3: target mask >> >> Row 4: deformation field magnitude without using mask >> >> Row 5: resampled source image with target mask outline >> >> Row 6/7: as rows 4/5, but after adding the target mask to minctracc >> >> >> >> Clearly the addition of the mask has a strong negative (and asymmetric) >> >> impact on the registration, while it seems it shouldn't have much of an >> >> effect at all. >> >> >> >> I have actually seen this behaviour before but was never able to pinpoint >> >> it so clearly. What appears to be happening is that masked registrations >> >> have a tendency to 'flow out' in a particular direction (towards the top >> >> right in coronal sections). >> >> >> >> Thoughts/suggestions, anyone? >> >> >> >> Thanks, >> >> >> >> -- Alex >> >> _______________________________________________ >> >> 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 claude at bic.mni.mcgill.ca Fri May 10 14:00:51 2013 From: claude at bic.mni.mcgill.ca (Claude LEPAGE) Date: Fri, 10 May 2013 14:00:51 -0400 Subject: [MINC-users] minctracc/masking bug? In-Reply-To: Message-ID: <201305101800.r4AI0pIH014948@agrippa.bic.mni.mcgill.ca> Alex, > So far the only explanation I can think of, is that the optimizer > follows a particular/fixed trajectory through the parameter space, > implicitly generating an "expansion force" in a particular direction > that can go unchecked given the right set of circumstances (a > particular mask being one of them). Anyways, still testing different > parameters, will report on what I find. Can you do only 1 iteration of minctracc? Is symmetry preserved? Try this 1 iteration with and without smoothing (set smoothing weight to zero). Still symmetric? Your suggestion above sounds like the result could be influenced by the order of the loops. This is a common mistake in numerical analysis. For example: vec[i] = some_function( vec[i-1], vec[i], vec[i+1] ); When you process vec[i+1], the value of its previous neighbour has changed, so running the loop forward/backward gives a different answer. You can check the code for something like this (good luck). Have you tried minctracc 0.99.3? Have you tried mincreshape to change the x,y,z ordering? I doubt this will have an impact on the results. Claude From trash001 at odu.edu Wed May 15 15:40:48 2013 From: trash001 at odu.edu (Tanweer Rashid) Date: Wed, 15 May 2013 15:40:48 -0400 Subject: [MINC-users] Coordinates of the 8 corners of an arbitrary voxel Message-ID: Hi, Is there any way that I can get the (x, y, z) coordinates of the 8 corners of an arbitrary voxel? -- Tanweer Rashid MSVE Dept. Old Dominion University From sorench at gmail.com Wed May 15 16:09:29 2013 From: sorench at gmail.com (Soren Christensen) Date: Wed, 15 May 2013 13:09:29 -0700 Subject: [MINC-users] Coordinates of the 8 corners of an arbitrary voxel In-Reply-To: References: Message-ID: voxel2world should do this for you. It accepts fractional voxel sizes so offsetting the values by 0.5 should give you the corners. If you have gaps you'd need to account for that of course. Soren On Wed, May 15, 2013 at 12:40 PM, Tanweer Rashid wrote: > Hi, > > Is there any way that I can get the (x, y, z) coordinates of the 8 corners > of an arbitrary voxel? > > -- > Tanweer Rashid > MSVE Dept. > Old Dominion University > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From nicolas.cordier at inria.fr Sat May 18 12:45:04 2013 From: nicolas.cordier at inria.fr (Nicolas Cordier) Date: Sat, 18 May 2013 18:45:04 +0200 (CEST) Subject: [MINC-users] Building minc-toolkit from github: MD5 sums differ for HDF5 In-Reply-To: <867399468.1175139.1368791654477.JavaMail.root@inria.fr> Message-ID: <2047968206.1549038.1368895504782.JavaMail.root@inria.fr> Hello, I am trying to build minc-toolkit by following the installation steps given in: ??https://github.com/BIC-MNI/minc-toolkit I recall them briefly: ??git clone --recursive git://github.com/BIC-MNI/minc-toolkit.git minc-toolkit ??cd minc-toolkit ??mkdir build && cd build ??ccmake .. # Enter the location of all dependencies, if not detected automatically ... ??make && make test && make install My problem arises at the very beginning of the last step: for HDF5 downloads, expected and actual MD5 sums differ. ??CMake Error at HDF5-prefix/src/HDF5-stamp/download-HDF5.cmake:6 (file): ?? ?file FILE(DOWNLOAD ) error; expected and actual MD5 sums differ ?? ? ?for file: [/home/ncordier/Softwares/BIC-MNI/minc-toolkit/build/HDF5-prefix/src/hdf5-1.8.10-patch1.tar.gz] ?? ? ? ?expected MD5 sum: [2147a289fb33c887464ad2b6c5a8ae4c] ?? ? ? ? ?actual MD5 sum: [497cde3ee8a59c2c224f476e99591947] I have tried to bypass this problem by commenting out the two following lines: ??HDF5-prefix/src/HDF5-stamp/download-HDF5.cmake:6 ??HDF5-prefix/src/HDF5-stamp/verify-HDF5.cmake:24 However, another error arises, which is likely tied to the previous one: ??CMake Error at HDF5-prefix/src/HDF5-stamp/extract-HDF5.cmake:33 (message): ?? ?error: extract of ?? ?'/home/ncordier/Softwares/BIC-MNI/minc-toolkit/build/HDF5-prefix/src/hdf5-1.8.10-patch1.tar.gz' ?? ?failed I believe the tar archive is corrupted. Is there a fix or another simple way to build minc-toolkit? Yours faithfully, -- Nicolas CORDIER From nicolas.cordier at inria.fr Sat May 18 12:57:45 2013 From: nicolas.cordier at inria.fr (Nicolas Cordier) Date: Sat, 18 May 2013 18:57:45 +0200 (CEST) Subject: [MINC-users] Building libMINC from github: too many arguments to a function of HDF5 In-Reply-To: <380640111.1218649.1368797329298.JavaMail.root@inria.fr> Message-ID: <720101737.1550734.1368896265327.JavaMail.root@inria.fr> Hello again, I am trying to build the branch minc_lite of libMINC, which I have found here: https://github.com/BIC-MNI/libminc/tree/minc_lite In the README, I have found two pieces of information: 1) "libMINC requires that HDF5 and optionally NetCDF to be installed." 2) "HDF5 must be installed before MINC can be built. The latest version of HDF5 is 1.6.2." I have therefore installed netcdf-4.0.1, and for a better compatibility, I have chosen to install hdf5-1.6.2, although the most recent version is hdf5-1.8.11. However, after using ccmake for libminc, I encounter a problem at the first step of the make step: [ 1%] Building C object CMakeFiles/minc2.dir/libsrc/hdf_convenience.c.o There are several error messages, which are similar to the following one: /home/ncordier/Softwares/BIC-MNI/libminc/src/libsrc/hdf_convenience.c: In function ?hdf_put_dimorder?: /home/ncordier/Softwares/BIC-MNI/libminc/src/libsrc/hdf_convenience.c:621:5: error: too many arguments to function ?H5Acreate? /home/ncordier/Softwares/BIC-MNI/hdf5-1.6.2/src/hdf5/include/H5Apublic.h:32:8: note: declared here I have tried to check the files, and it is true the number of arguments differs. Would you have any suggestion for a version of HDF5? ncordier $ grep -C 1 H5Acreate /home/ncordier/Softwares/BIC-MNI/hdf5-1.6.2/src/hdf5/include/H5Apublic.h /* Public function prototypes */ H5_DLL hid_t H5Acreate(hid_t loc_id, const char *name, hid_t type_id, hid_t space_id, hid_t plist_id); ncordier $ grep -C 1 H5Acreate /home/ncordier/Softwares/BIC-MNI/libminc/src/libsrc/hdf_convenience.c att_id = H5Acreate(dst_id, MI2_DIMORDER, typ_id, spc_id, H5P_DEFAULT, H5P_DEFAULT); -- */ att_id = H5Acreate(dst_id, MI2_LENGTH, H5T_STD_U32LE, aspc_id, H5P_DEFAULT, H5P_DEFAULT); -- */ att_id = H5Acreate(loc_id, attnm, ftyp_id, spc_id, H5P_DEFAULT, H5P_DEFAULT); } H5E_END_TRY; -- outatt_id = H5Acreate(out_id, attr_name, typ_id, spc_id, H5P_DEFAULT, H5P_DEFAULT); if (outatt_id < 0) { Yours faithfully, -- Nicolas CORDIER From andrew at biospective.com Sun May 19 12:54:24 2013 From: andrew at biospective.com (Andrew Wood) Date: Sun, 19 May 2013 12:54:24 -0400 Subject: [MINC-users] Building libMINC from github: too many arguments to a function of HDF5 In-Reply-To: <720101737.1550734.1368896265327.JavaMail.root@inria.fr> References: <380640111.1218649.1368797329298.JavaMail.root@inria.fr> <720101737.1550734.1368896265327.JavaMail.root@inria.fr> Message-ID: Hi Nicolas, I build libminc against hdf5-1.8.5, so you might try using that. Hope that helps, Andrew On Sat, May 18, 2013 at 12:57 PM, Nicolas Cordier wrote: > Hello again, > > > > I am trying to build the branch minc_lite of libMINC, which I have found > here: > https://github.com/BIC-MNI/libminc/tree/minc_lite > > In the README, I have found two pieces of information: > 1) "libMINC requires that HDF5 and optionally NetCDF to be installed." > 2) "HDF5 must be installed before MINC can be built. The latest version of > HDF5 is 1.6.2." > > I have therefore installed netcdf-4.0.1, and for a better compatibility, I > have chosen to install hdf5-1.6.2, although the most recent version is > hdf5-1.8.11. > > > > However, after using ccmake for libminc, I encounter a problem at the > first step of the make step: > [ 1%] Building C object CMakeFiles/minc2.dir/libsrc/hdf_convenience.c.o > > There are several error messages, which are similar to the following one: > /home/ncordier/Softwares/BIC-MNI/libminc/src/libsrc/hdf_convenience.c: > In function ?hdf_put_dimorder?: > > /home/ncordier/Softwares/BIC-MNI/libminc/src/libsrc/hdf_convenience.c:621:5: > error: too many arguments to function ?H5Acreate? > > /home/ncordier/Softwares/BIC-MNI/hdf5-1.6.2/src/hdf5/include/H5Apublic.h:32:8: > note: declared here > > > > I have tried to check the files, and it is true the number of arguments > differs. Would you have any suggestion for a version of HDF5? > > > > ncordier $ grep -C 1 H5Acreate > /home/ncordier/Softwares/BIC-MNI/hdf5-1.6.2/src/hdf5/include/H5Apublic.h > /* Public function prototypes */ > H5_DLL hid_t H5Acreate(hid_t loc_id, const char *name, hid_t type_id, > hid_t space_id, hid_t plist_id); > > > > ncordier $ grep -C 1 H5Acreate > /home/ncordier/Softwares/BIC-MNI/libminc/src/libsrc/hdf_convenience.c > > att_id = H5Acreate(dst_id, MI2_DIMORDER, typ_id, spc_id, H5P_DEFAULT, > H5P_DEFAULT); > > -- > */ > att_id = H5Acreate(dst_id, MI2_LENGTH, H5T_STD_U32LE, aspc_id, > H5P_DEFAULT, H5P_DEFAULT); > -- > */ > att_id = H5Acreate(loc_id, attnm, ftyp_id, spc_id, H5P_DEFAULT, > H5P_DEFAULT); > } H5E_END_TRY; > -- > > outatt_id = H5Acreate(out_id, attr_name, typ_id, spc_id, H5P_DEFAULT, > H5P_DEFAULT); > if (outatt_id < 0) { > > > > Yours faithfully, > > -- > Nicolas CORDIER > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From zijdenbos at gmail.com Tue May 21 00:07:49 2013 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Tue, 21 May 2013 00:07:49 -0400 Subject: [MINC-users] minctracc/masking bug? In-Reply-To: <201305101800.r4AI0pIH014948@agrippa.bic.mni.mcgill.ca> References: <201305101800.r4AI0pIH014948@agrippa.bic.mni.mcgill.ca> Message-ID: Thanks, Claude - looking at your suggestions (and at the minctracc source code). In the mean time, I performed some phenomenological experiments that I thought would be interesting to share. Here's what I did: - take 100 subjects, already in linear template (stx) space - register these with an nlfit*-like process, up to 4mm grid step size, to a symmetric template+mask - flip the subject image and its mask about x=0, repeat the registration - flip the resampled image and the grid from the registration again about x=0 - calculate the magnitude of the difference between the 'normal' and '2xflipped' grid (per subject) - average the 'normal' and '2xflipped' grid files across subjects - calculate the magnitude of the difference between the average 'normal' and average '2xflipped' grid files In the end, what I am left with is the asymmetry in the deformation field(s) due solely to the registration process; if minctracc were unbiased, these difference images would be 0. This image: https://dl.dropboxusercontent.com/u/5709165/def_diff_mag.jpeg shows the average of the non-linearly registered images over these 100 subjects; and the magnitude of the difference of the average deformation estimated 'normally' and '2xflipped'. Note that the in these population averages, the maximum deformation magnitude is 2.86; in individual subjects, the max magnitude of the deformation difference is typically in the 10-20 range. In other words, the asymmetry in the estimated deformation field purely caused by the methodology, can be as high as 20mm. I'd be very happy if somebody could run a similar experiment, if anything on a single subject; just to confirm that I didn't do anything fundamentally wrong somewhere (which would be great). -- A On Fri, May 10, 2013 at 2:00 PM, Claude LEPAGE wrote: > Alex, > >> So far the only explanation I can think of, is that the optimizer >> follows a particular/fixed trajectory through the parameter space, >> implicitly generating an "expansion force" in a particular direction >> that can go unchecked given the right set of circumstances (a >> particular mask being one of them). Anyways, still testing different >> parameters, will report on what I find. > > Can you do only 1 iteration of minctracc? Is symmetry preserved? > Try this 1 iteration with and without smoothing (set smoothing weight > to zero). Still symmetric? > > Your suggestion above sounds like the result could be influenced by > the order of the loops. This is a common mistake in numerical analysis. > For example: > vec[i] = some_function( vec[i-1], vec[i], vec[i+1] ); > When you process vec[i+1], the value of its previous neighbour has > changed, so running the loop forward/backward gives a different answer. > You can check the code for something like this (good luck). > > Have you tried minctracc 0.99.3? Have you tried mincreshape to change > the x,y,z ordering? I doubt this will have an impact on the results. > > Claude > > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From a.janke at gmail.com Tue May 21 00:44:56 2013 From: a.janke at gmail.com (Andrew Janke) Date: Tue, 21 May 2013 14:44:56 +1000 Subject: [MINC-users] minctracc/masking bug? In-Reply-To: References: <201305101800.r4AI0pIH014948@agrippa.bic.mni.mcgill.ca> Message-ID: Hi Alex, > - take 100 subjects, already in linear template (stx) space > - register these with an nlfit*-like process, up to 4mm grid step > size, to a symmetric template+mask > - flip the subject image and its mask about x=0, repeat the registration > - flip the resampled image and the grid from the registration again about x=0 > - calculate the magnitude of the difference between the 'normal' and > '2xflipped' grid (per subject) > > - average the 'normal' and '2xflipped' grid files across subjects > - calculate the magnitude of the difference between the average > 'normal' and average '2xflipped' grid files > > In the end, what I am left with is the asymmetry in the deformation > field(s) due solely to the registration process; if minctracc were > unbiased, these difference images would be 0. This image: > > https://dl.dropboxusercontent.com/u/5709165/def_diff_mag.jpeg > > shows the average of the non-linearly registered images over these 100 > subjects; and the magnitude of the difference of the average > deformation estimated 'normally' and '2xflipped'. Note that the in > these population averages, the maximum deformation magnitude is 2.86; > in individual subjects, the max magnitude of the deformation > difference is typically in the 10-20 range. In other words, the > asymmetry in the estimated deformation field purely caused by the > methodology, can be as high as 20mm. Something seems off. The previous tests I ran along this line didn't find such large differences. What I found for for human sized heads were typically differences of 0.1mm and less. The differences also didn't show any similarity to underlying structures like what you have. I had a go at finding this analysis just then but drew a blank, what I do remember is that I (like Claude) wasn't using masks. Is there any chance than you can put the code up somewhere for what you are doing in a more distilled test case? My suggestion would be to keep this very simple, drop the masks and flip both the source and target image to avoid issues of grid sampling. minctracc goes through some interesting logic to ensure that the grid aligns properly with the data. Is it possible that your twin grid images (one flipped) aren't aligned which can cause a resampling error? One trick I have often employed here is to seed minctracc with an initial transform which includes an identity grid transform with the exact sampling I want. There is a perl script here to do this: http://packages.bic.mni.mcgill.ca/scripts/gennlxfm a From vladimir.fonov at gmail.com Tue May 21 10:28:48 2013 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Tue, 21 May 2013 10:28:48 -0400 Subject: [MINC-users] minctracc/masking bug? In-Reply-To: References: <201305101800.r4AI0pIH014948@agrippa.bic.mni.mcgill.ca> Message-ID: What is the procedure that you are using for flipping the grid file ? The way how I am doing it in my symmetric model building script ( https://github.com/vfonov/build_average_model ) : nlfit_s $input $model $tempdir/left_nl.xfm -source_mask $input_mask -target_mask $model_mask -level $level nlfit_s $input_flip $model $tempdir/right_nl.xfm -source_mask $input_flip_mask -target_mask $model_mask \ -level $level -work_dir $tempdir xfm_normalize.pl $tempdir/left_nl.xfm $tempdir/output_left.xfm -like $model --step $level xfmconcat $flip $tempdir/right_nl.xfm $flip $tempdir/right_nl_flip.xfm #make nonlinear only xfm_normalize.pl $tempdir/right_nl_flip.xfm $tempdir/output_right_flip.xfm -like $model --step $level #average left and right flipped xfmavg $tempdir/output_left.xfm $tempdir/output_right_flip.xfm $output On Tue, May 21, 2013 at 12:07 AM, Alex Zijdenbos wrote: > Thanks, Claude - looking at your suggestions (and at the minctracc > source code). In the mean time, I performed some phenomenological > experiments that I thought would be interesting to share. Here's what > I did: > > - take 100 subjects, already in linear template (stx) space > - register these with an nlfit*-like process, up to 4mm grid step > size, to a symmetric template+mask > - flip the subject image and its mask about x=0, repeat the registration > - flip the resampled image and the grid from the registration again about x=0 > - calculate the magnitude of the difference between the 'normal' and > '2xflipped' grid (per subject) > > - average the 'normal' and '2xflipped' grid files across subjects > - calculate the magnitude of the difference between the average > 'normal' and average '2xflipped' grid files > > In the end, what I am left with is the asymmetry in the deformation > field(s) due solely to the registration process; if minctracc were > unbiased, these difference images would be 0. This image: > > https://dl.dropboxusercontent.com/u/5709165/def_diff_mag.jpeg > > shows the average of the non-linearly registered images over these 100 > subjects; and the magnitude of the difference of the average > deformation estimated 'normally' and '2xflipped'. Note that the in > these population averages, the maximum deformation magnitude is 2.86; > in individual subjects, the max magnitude of the deformation > difference is typically in the 10-20 range. In other words, the > asymmetry in the estimated deformation field purely caused by the > methodology, can be as high as 20mm. > > I'd be very happy if somebody could run a similar experiment, if > anything on a single subject; just to confirm that I didn't do > anything fundamentally wrong somewhere (which would be great). > > -- A > > > > > > On Fri, May 10, 2013 at 2:00 PM, Claude LEPAGE wrote: >> Alex, >> >>> So far the only explanation I can think of, is that the optimizer >>> follows a particular/fixed trajectory through the parameter space, >>> implicitly generating an "expansion force" in a particular direction >>> that can go unchecked given the right set of circumstances (a >>> particular mask being one of them). Anyways, still testing different >>> parameters, will report on what I find. >> >> Can you do only 1 iteration of minctracc? Is symmetry preserved? >> Try this 1 iteration with and without smoothing (set smoothing weight >> to zero). Still symmetric? >> >> Your suggestion above sounds like the result could be influenced by >> the order of the loops. This is a common mistake in numerical analysis. >> For example: >> vec[i] = some_function( vec[i-1], vec[i], vec[i+1] ); >> When you process vec[i+1], the value of its previous neighbour has >> changed, so running the loop forward/backward gives a different answer. >> You can check the code for something like this (good luck). >> >> Have you tried minctracc 0.99.3? Have you tried mincreshape to change >> the x,y,z ordering? I doubt this will have an impact on the results. >> >> Claude >> >> _______________________________________________ >> 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 zijdenbos at gmail.com Tue May 21 12:05:21 2013 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Tue, 21 May 2013 12:05:21 -0400 Subject: [MINC-users] minctracc/masking bug? In-Reply-To: References: <201305101800.r4AI0pIH014948@agrippa.bic.mni.mcgill.ca> Message-ID: Hi Vlad, I simply flipped the grid file itself (resample it with $flip, essentially), so without going through xfmconcat and xfm2def. Just to be sure I just tested this on one case, and the results of your process and simply flipping the grid file are identical. As for the asymmetry, I will pursue this further following Andrew's suggestions as well; I'll try to narrow it down to something simple that I can easily share. -- A On Tue, May 21, 2013 at 10:28 AM, Vladimir S. FONOV wrote: > What is the procedure that you are using for flipping the grid file ? > > The way how I am doing it in my symmetric model building script ( > https://github.com/vfonov/build_average_model ) : > > nlfit_s $input $model $tempdir/left_nl.xfm -source_mask $input_mask > -target_mask $model_mask -level $level > > nlfit_s $input_flip $model $tempdir/right_nl.xfm -source_mask > $input_flip_mask -target_mask $model_mask \ > -level $level -work_dir $tempdir > > xfm_normalize.pl $tempdir/left_nl.xfm $tempdir/output_left.xfm -like > $model --step $level > > xfmconcat $flip $tempdir/right_nl.xfm $flip $tempdir/right_nl_flip.xfm > > #make nonlinear only > xfm_normalize.pl $tempdir/right_nl_flip.xfm > $tempdir/output_right_flip.xfm -like $model --step $level > > #average left and right flipped > xfmavg $tempdir/output_left.xfm $tempdir/output_right_flip.xfm $output > > On Tue, May 21, 2013 at 12:07 AM, Alex Zijdenbos wrote: >> Thanks, Claude - looking at your suggestions (and at the minctracc >> source code). In the mean time, I performed some phenomenological >> experiments that I thought would be interesting to share. Here's what >> I did: >> >> - take 100 subjects, already in linear template (stx) space >> - register these with an nlfit*-like process, up to 4mm grid step >> size, to a symmetric template+mask >> - flip the subject image and its mask about x=0, repeat the registration >> - flip the resampled image and the grid from the registration again about x=0 >> - calculate the magnitude of the difference between the 'normal' and >> '2xflipped' grid (per subject) >> >> - average the 'normal' and '2xflipped' grid files across subjects >> - calculate the magnitude of the difference between the average >> 'normal' and average '2xflipped' grid files >> >> In the end, what I am left with is the asymmetry in the deformation >> field(s) due solely to the registration process; if minctracc were >> unbiased, these difference images would be 0. This image: >> >> https://dl.dropboxusercontent.com/u/5709165/def_diff_mag.jpeg >> >> shows the average of the non-linearly registered images over these 100 >> subjects; and the magnitude of the difference of the average >> deformation estimated 'normally' and '2xflipped'. Note that the in >> these population averages, the maximum deformation magnitude is 2.86; >> in individual subjects, the max magnitude of the deformation >> difference is typically in the 10-20 range. In other words, the >> asymmetry in the estimated deformation field purely caused by the >> methodology, can be as high as 20mm. >> >> I'd be very happy if somebody could run a similar experiment, if >> anything on a single subject; just to confirm that I didn't do >> anything fundamentally wrong somewhere (which would be great). >> >> -- A >> >> >> >> >> >> On Fri, May 10, 2013 at 2:00 PM, Claude LEPAGE wrote: >>> Alex, >>> >>>> So far the only explanation I can think of, is that the optimizer >>>> follows a particular/fixed trajectory through the parameter space, >>>> implicitly generating an "expansion force" in a particular direction >>>> that can go unchecked given the right set of circumstances (a >>>> particular mask being one of them). Anyways, still testing different >>>> parameters, will report on what I find. >>> >>> Can you do only 1 iteration of minctracc? Is symmetry preserved? >>> Try this 1 iteration with and without smoothing (set smoothing weight >>> to zero). Still symmetric? >>> >>> Your suggestion above sounds like the result could be influenced by >>> the order of the loops. This is a common mistake in numerical analysis. >>> For example: >>> vec[i] = some_function( vec[i-1], vec[i], vec[i+1] ); >>> When you process vec[i+1], the value of its previous neighbour has >>> changed, so running the loop forward/backward gives a different answer. >>> You can check the code for something like this (good luck). >>> >>> Have you tried minctracc 0.99.3? Have you tried mincreshape to change >>> the x,y,z ordering? I doubt this will have an impact on the results. >>> >>> Claude >>> >>> _______________________________________________ >>> 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 > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From zijdenbos at gmail.com Wed May 22 00:11:59 2013 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Wed, 22 May 2013 00:11:59 -0400 Subject: [MINC-users] minctracc/masking bug? In-Reply-To: References: <201305101800.r4AI0pIH014948@agrippa.bic.mni.mcgill.ca> Message-ID: OK, by popular demand, I generated some data and wrote a simple script that illustrates the issue discussed here. Although I have already seen that masking can have a drastic impact on the deformation asymmetry, this example keeps it simple by not using masks, nor blurring; it uses a simple and single minctracc call, with 1 iteration. Here is the tarball: https://dl.dropboxusercontent.com/u/5709165/MINC/SymTestDist.tar.gz To run the experiment: tar zxvf /home/alex/pchome/Scratch/SymTestDist.tar.gz cd SymTestDist/ ./run_sym_test.pl -tmpdir tmp image.mnc model.mnc resdiff.mnc defdiffmag.mnc | tee sym_test.log This will: - register image.mnc (asymmetric) to model.mnc (symmetric) - register them again after flipping both image.mnc and model.mnc about x=0 - flip the flipped resampled image and the flipped deformation field back - generate the subtraction of the two resampled files (resdiff.mnc) - generate the magnitude of the difference between the two deformation fields (defdiffmag.mnc). In an ideal situation, both output files would be 0; any non-zero values in these two output files indicate a methodological asymmetry in the deformation field that minctracc generates. You can in fact obtain "perfect" (0, barring some slice scaling) output by registering model.mnc to itself. However, as another test, use model_0.99.mnc as the source image; this is model.mnc shrunk a small amount by scaling it by 0.99 in all dimensions. You will see that the asymmetric behaviour immediately shows up even in this case. -- A On Tue, May 21, 2013 at 12:05 PM, Alex Zijdenbos wrote: > Hi Vlad, > > I simply flipped the grid file itself (resample it with $flip, > essentially), so without going through xfmconcat and xfm2def. Just to > be sure I just tested this on one case, and the results of your > process and simply flipping the grid file are identical. > > As for the asymmetry, I will pursue this further following Andrew's > suggestions as well; I'll try to narrow it down to something simple > that I can easily share. > > -- A > > On Tue, May 21, 2013 at 10:28 AM, Vladimir S. FONOV > wrote: >> What is the procedure that you are using for flipping the grid file ? >> >> The way how I am doing it in my symmetric model building script ( >> https://github.com/vfonov/build_average_model ) : >> >> nlfit_s $input $model $tempdir/left_nl.xfm -source_mask $input_mask >> -target_mask $model_mask -level $level >> >> nlfit_s $input_flip $model $tempdir/right_nl.xfm -source_mask >> $input_flip_mask -target_mask $model_mask \ >> -level $level -work_dir $tempdir >> >> xfm_normalize.pl $tempdir/left_nl.xfm $tempdir/output_left.xfm -like >> $model --step $level >> >> xfmconcat $flip $tempdir/right_nl.xfm $flip $tempdir/right_nl_flip.xfm >> >> #make nonlinear only >> xfm_normalize.pl $tempdir/right_nl_flip.xfm >> $tempdir/output_right_flip.xfm -like $model --step $level >> >> #average left and right flipped >> xfmavg $tempdir/output_left.xfm $tempdir/output_right_flip.xfm $output >> >> On Tue, May 21, 2013 at 12:07 AM, Alex Zijdenbos wrote: >>> Thanks, Claude - looking at your suggestions (and at the minctracc >>> source code). In the mean time, I performed some phenomenological >>> experiments that I thought would be interesting to share. Here's what >>> I did: >>> >>> - take 100 subjects, already in linear template (stx) space >>> - register these with an nlfit*-like process, up to 4mm grid step >>> size, to a symmetric template+mask >>> - flip the subject image and its mask about x=0, repeat the registration >>> - flip the resampled image and the grid from the registration again about x=0 >>> - calculate the magnitude of the difference between the 'normal' and >>> '2xflipped' grid (per subject) >>> >>> - average the 'normal' and '2xflipped' grid files across subjects >>> - calculate the magnitude of the difference between the average >>> 'normal' and average '2xflipped' grid files >>> >>> In the end, what I am left with is the asymmetry in the deformation >>> field(s) due solely to the registration process; if minctracc were >>> unbiased, these difference images would be 0. This image: >>> >>> https://dl.dropboxusercontent.com/u/5709165/def_diff_mag.jpeg >>> >>> shows the average of the non-linearly registered images over these 100 >>> subjects; and the magnitude of the difference of the average >>> deformation estimated 'normally' and '2xflipped'. Note that the in >>> these population averages, the maximum deformation magnitude is 2.86; >>> in individual subjects, the max magnitude of the deformation >>> difference is typically in the 10-20 range. In other words, the >>> asymmetry in the estimated deformation field purely caused by the >>> methodology, can be as high as 20mm. >>> >>> I'd be very happy if somebody could run a similar experiment, if >>> anything on a single subject; just to confirm that I didn't do >>> anything fundamentally wrong somewhere (which would be great). >>> >>> -- A >>> >>> >>> >>> >>> >>> On Fri, May 10, 2013 at 2:00 PM, Claude LEPAGE wrote: >>>> Alex, >>>> >>>>> So far the only explanation I can think of, is that the optimizer >>>>> follows a particular/fixed trajectory through the parameter space, >>>>> implicitly generating an "expansion force" in a particular direction >>>>> that can go unchecked given the right set of circumstances (a >>>>> particular mask being one of them). Anyways, still testing different >>>>> parameters, will report on what I find. >>>> >>>> Can you do only 1 iteration of minctracc? Is symmetry preserved? >>>> Try this 1 iteration with and without smoothing (set smoothing weight >>>> to zero). Still symmetric? >>>> >>>> Your suggestion above sounds like the result could be influenced by >>>> the order of the loops. This is a common mistake in numerical analysis. >>>> For example: >>>> vec[i] = some_function( vec[i-1], vec[i], vec[i+1] ); >>>> When you process vec[i+1], the value of its previous neighbour has >>>> changed, so running the loop forward/backward gives a different answer. >>>> You can check the code for something like this (good luck). >>>> >>>> Have you tried minctracc 0.99.3? Have you tried mincreshape to change >>>> the x,y,z ordering? I doubt this will have an impact on the results. >>>> >>>> Claude >>>> >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> MINC-users at bic.mni.mcgill.ca >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users >> From sorench at gmail.com Wed May 22 16:19:15 2013 From: sorench at gmail.com (Soren Christensen) Date: Wed, 22 May 2013 13:19:15 -0700 Subject: [MINC-users] Display and color mapping of floats Message-ID: Hi, I've noticed that float images with range 0-1 appear "binary" in Display. I have an object with values 0-1 but it appears 0-<1.0 is mapped to black and >=1.00 as white. I can see with the cursor that the pixel values of 0.77 for example are just mapped to black. The mapping on the color bar is set to 0-1 of course. If I multiply the values with 1000 I can see the intermediate values. This seems like unintended behavior? Is there something special going on with color mapping in Display in the range 0-1? Soren From jared.rowley at gmail.com Wed May 22 16:37:51 2013 From: jared.rowley at gmail.com (Jared Rowley) Date: Wed, 22 May 2013 16:37:51 -0400 Subject: [MINC-users] Display and color mapping of floats In-Reply-To: References: Message-ID: Hi, I have encountered this problem will using images between 0-1 in register. I solve it by converting to short. mincresape -short in.mnc out.mnc See if that helps. Jared On Wed, May 22, 2013 at 4:19 PM, Soren Christensen wrote: > Hi, > I've noticed that float images with range 0-1 appear "binary" in Display. > I have an object with values 0-1 but it appears 0-<1.0 is mapped to black > and >=1.00 as white. > I can see with the cursor that the pixel values of 0.77 for example are > just mapped to black. The mapping on the color bar is set to 0-1 of course. > If I multiply the values with 1000 I can see the intermediate values. > > This seems like unintended behavior? Is there something special going on > with color mapping in Display in the range 0-1? > > Soren > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > -- Jared Rowley Translational Neuroimaging Laboratory McGill Centre for Studies in Aging Douglas Hospital Research Center McGill University 6825 LaSalle Blvd. Montreal, QC Canada H4H 1R3 From sorench at gmail.com Wed May 22 19:25:13 2013 From: sorench at gmail.com (Soren Christensen) Date: Wed, 22 May 2013 16:25:13 -0700 Subject: [MINC-users] Display and color mapping of floats In-Reply-To: References: Message-ID: Hi Jared, I was just about to write I wold not expect that to work (it did)... The the real range is still 0-1 but not stored over the full range of a short and the color mapping works. It seems there's an issue with converting 0-1 floats to the internal display byte type storage. Thanks Soren On Wed, May 22, 2013 at 1:37 PM, Jared Rowley wrote: > Hi, > I have encountered this problem will using images between 0-1 in register. > I solve it by converting to short. > > mincresape -short in.mnc out.mnc > > See if that helps. > > Jared > > > On Wed, May 22, 2013 at 4:19 PM, Soren Christensen >wrote: > > > Hi, > > I've noticed that float images with range 0-1 appear "binary" in > Display. > > I have an object with values 0-1 but it appears 0-<1.0 is mapped to black > > and >=1.00 as white. > > I can see with the cursor that the pixel values of 0.77 for example are > > just mapped to black. The mapping on the color bar is set to 0-1 of > course. > > If I multiply the values with 1000 I can see the intermediate values. > > > > This seems like unintended behavior? Is there something special going on > > with color mapping in Display in the range 0-1? > > > > Soren > > _______________________________________________ > > MINC-users at bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > > > -- > Jared Rowley > Translational Neuroimaging Laboratory > McGill Centre for Studies in Aging > Douglas Hospital Research Center > McGill University > 6825 LaSalle Blvd. > Montreal, QC Canada > H4H 1R3 > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From pierre.bellec at gmail.com Thu May 23 01:12:57 2013 From: pierre.bellec at gmail.com (Pierre Bellec) Date: Thu, 23 May 2013 01:12:57 -0400 Subject: [MINC-users] temporary folder for minc tools Message-ID: Dear Minc users, I am trying to configure the minc tools on a series of machines where using /tmp for temporary files is not possible. I need to use an alternative non-standard folder instead. Some minc tools have an option to specify the temporary folder but some others look like they don't (mincblur, for example). Is anybody know a work-around ? Best, Pierre Bellec From zijdenbos at gmail.com Thu May 23 07:11:26 2013 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Thu, 23 May 2013 07:11:26 -0400 Subject: [MINC-users] temporary folder for minc tools In-Reply-To: References: Message-ID: Hi Pierre, I haven't checked, but my assumption is that most tools should listen to the TMPDIR environment variable, if it is set? -- A On Thu, May 23, 2013 at 1:12 AM, Pierre Bellec wrote: > Dear Minc users, > > I am trying to configure the minc tools on a series of machines where using > /tmp for temporary files is not possible. I need to use an alternative > non-standard folder instead. Some minc tools have an option to specify the > temporary folder but some others look like they don't (mincblur, for > example). Is anybody know a work-around ? > > Best, > > Pierre Bellec > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From pgravel at bic.mni.mcgill.ca Mon May 27 10:22:20 2013 From: pgravel at bic.mni.mcgill.ca (Paul GRAVEL) Date: Mon, 27 May 2013 10:22:20 -0400 (EDT) Subject: [MINC-users] MEX version of mincresample? In-Reply-To: References: Message-ID: Dear All, Out of curiosity, apart from the EMMA tools, has anyone created Matlab executables (aka mex files) for the MINC tools, such as mincresample? The reason I'm asking is that I need to do multiple resampling of an image (for now using mincresample) within a matlab script, and the file IO creates a considerable overhead in terms of execution time (especially since the IO is done on NFS disks). So I was hoping to save time by eliminating this file IO by using a mex version of mincresample (or any other alternatives). Any suggestion would be greatly appreciated! Best Regards, Paul From vladimir.fonov at gmail.com Mon May 27 10:29:05 2013 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Mon, 27 May 2013 10:29:05 -0400 Subject: [MINC-users] MEX version of mincresample? In-Reply-To: References: Message-ID: <51A36DB1.1080802@gmail.com> Hello, Robb Brown was working on making some minctools accessible as library, but from Python to reduce disk IO. On 13-05-27 10:22 AM, Paul GRAVEL wrote: > Out of curiosity, apart from the EMMA tools, has anyone created Matlab > executables (aka mex files) for the MINC tools, such as mincresample? > > The reason I'm asking is that I need to do multiple resampling of an > image (for now using mincresample) within a matlab script, and the file > IO creates a considerable overhead in terms of execution time > (especially since the IO is done on NFS disks). So I was hoping to save > time by eliminating this file IO by using a mex version of mincresample > (or any other alternatives). > > Any suggestion would be greatly appreciated! -- Best regards, Vladimir S. FONOV ~ vladimir.fonov gmail.com From waveflux at gmail.com Mon May 27 14:34:51 2013 From: waveflux at gmail.com (Tom Beaudry) Date: Mon, 27 May 2013 14:34:51 -0400 Subject: [MINC-users] RMINC - Calculating p-value for the Wilcoxon test Message-ID: Hi, I am using RMINC to calculate the W value for an analysis with group sizes of 6 and 19. I then get some W values (from 1-114), but how can I calculate the associated p-value from the W-Value? This is the R code that I am using: rm(list=ls(all=TRUE)) library(RMINC) gf1 <- read.csv("input.csv") vs1 <- minc.model(gf1$FA, gf1$group, "wilcoxon") vs1[is.na(vs1)] <- 0 mincWriteVolume(vs1, "output.mnc", gf1$FA) thanks for the help! Thomas Beaudry From a.janke at gmail.com Mon May 27 16:15:04 2013 From: a.janke at gmail.com (Andrew Janke) Date: Tue, 28 May 2013 06:15:04 +1000 Subject: [MINC-users] MEX version of mincresample? In-Reply-To: References: Message-ID: Hi Paul, On 28 May 2013 00:22, Paul GRAVEL wrote: > Out of curiosity, apart from the EMMA tools, has anyone created Matlab > executables (aka mex files) for the MINC tools, such as mincresample? Not that I know of. a From pgravel at bic.mni.mcgill.ca Mon May 27 16:25:24 2013 From: pgravel at bic.mni.mcgill.ca (Paul GRAVEL) Date: Mon, 27 May 2013 16:25:24 -0400 (EDT) Subject: [MINC-users] MEX version of mincresample? In-Reply-To: References: Message-ID: Thanks Andrew and Vladimir! I may then look into it... Best, Paul On Tue, 28 May 2013, Andrew Janke wrote: > Hi Paul, > > On 28 May 2013 00:22, Paul GRAVEL wrote: >> Out of curiosity, apart from the EMMA tools, has anyone created Matlab >> executables (aka mex files) for the MINC tools, such as mincresample? > > Not that I know of. > > > a > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From mishkind at gmail.com Mon May 27 16:26:48 2013 From: mishkind at gmail.com (Mishkin Derakhshan) Date: Mon, 27 May 2013 16:26:48 -0400 Subject: [MINC-users] MEX version of mincresample? In-Reply-To: References: Message-ID: I think most (if not all minctools) already copy things to /tmp/, but we found performance increased considerably by first copying our minc files to a location that is local (ie /tmp), and then doing all of our intermediate processing steps in /tmp, and then just copying back our final output file to the NFS disk. On Mon, May 27, 2013 at 4:15 PM, Andrew Janke wrote: > Hi Paul, > > On 28 May 2013 00:22, Paul GRAVEL wrote: >> Out of curiosity, apart from the EMMA tools, has anyone created Matlab >> executables (aka mex files) for the MINC tools, such as mincresample? > > Not that I know of. > > > a > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From a.janke at gmail.com Mon May 27 16:27:26 2013 From: a.janke at gmail.com (Andrew Janke) Date: Tue, 28 May 2013 06:27:26 +1000 Subject: [MINC-users] MEX version of mincresample? In-Reply-To: References: Message-ID: On 28 May 2013 06:25, Paul GRAVEL wrote: > I may then look into it... If you do, I'd suggest you talk to Pierre Bellec first (if you haven't already) so that what you do can fit into his NIAK framework and thus allow your code to work on both Octave and MATLAB. a From vladimir.fonov at gmail.com Mon May 27 16:34:46 2013 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Mon, 27 May 2013 16:34:46 -0400 Subject: [MINC-users] MEX version of mincresample? In-Reply-To: References: Message-ID: <51A3C366.8030008@gmail.com> Or event better, convert it to Python with SimpleITK + SciPy On 13-05-27 04:27 PM, Andrew Janke wrote: > On 28 May 2013 06:25, Paul GRAVEL wrote: >> I may then look into it... > > If you do, I'd suggest you talk to Pierre Bellec first (if you haven't > already) so that what you do can fit into his NIAK framework and thus > allow your code to work on both Octave and MATLAB. > -- Best regards, Vladimir S. FONOV ~ vladimir.fonov gmail.com From pierre.bellec at criugm.qc.ca Mon May 27 16:40:06 2013 From: pierre.bellec at criugm.qc.ca (Pierre Bellec) Date: Mon, 27 May 2013 16:40:06 -0400 Subject: [MINC-users] MEX version of mincresample? In-Reply-To: References: Message-ID: I would be very interested by using this type of mex files, to boost the speed of some of the NIAK tools. I should be able to wrap up a mex version of mincresample in NIAK without problem, whatever the selected syntax is. As of the compatibility with octave, a simple matlab mex should compile directly with octave as well. I'd be happy to give it a try. Best, Pierre PS: @Vladimir I have stopped commenting on the "better" Python route, so I am not going to comment. Argh, I did it. 2013/5/27 Andrew Janke > On 28 May 2013 06:25, Paul GRAVEL wrote: > > I may then look into it... > > If you do, I'd suggest you talk to Pierre Bellec first (if you haven't > already) so that what you do can fit into his NIAK framework and thus > allow your code to work on both Octave and MATLAB. > > > a > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From vladimir.fonov at gmail.com Mon May 27 16:51:42 2013 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Mon, 27 May 2013 16:51:42 -0400 Subject: [MINC-users] MEX version of mincresample? In-Reply-To: References: Message-ID: Well, I think the fact that we actually had ITK workshop at the BIC ( http://www.rbiq-qbin.qc.ca/en/event/1388 ) last week might be an influence. But if somebody want to reinvent the bicycle yet another time - I will applaud their efforts. On Mon, May 27, 2013 at 4:40 PM, Pierre Bellec wrote: > I would be very interested by using this type of mex files, to boost the > speed of some of the NIAK tools. I should be able to wrap up a mex version > of mincresample in NIAK without problem, whatever the selected syntax is. > As of the compatibility with octave, a simple matlab mex should compile > directly with octave as well. I'd be happy to give it a try. > > Best, > > Pierre > > PS: @Vladimir I have stopped commenting on the "better" Python route, so I > am not going to comment. Argh, I did it. > > 2013/5/27 Andrew Janke > >> On 28 May 2013 06:25, Paul GRAVEL wrote: >> > I may then look into it... >> >> If you do, I'd suggest you talk to Pierre Bellec first (if you haven't >> already) so that what you do can fit into his NIAK framework and thus >> allow your code to work on both Octave and MATLAB. >> >> >> a >> _______________________________________________ >> 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 pgravel at bic.mni.mcgill.ca Mon May 27 17:13:56 2013 From: pgravel at bic.mni.mcgill.ca (Paul GRAVEL) Date: Mon, 27 May 2013 17:13:56 -0400 (EDT) Subject: [MINC-users] MEX version of mincresample? In-Reply-To: References: Message-ID: Thanks Guys! And yes Vlad, in part because of the ITK seminar (which was great!), it gave me the push I needed to look more closely into this. The only thing is that before adventuring myself in converting mincresample for mex, I am now looking into the MATITK toolkit (http://matitk.cs.sfu.ca/) mentioned during the seminar; before reinventing the bicycle as you mentioned below ;-)! @Pierre: I can keep you posted on the MATITK package if you want. I am currently waiting for my account to be created which "will typically be approved in 48 hours", as stated on their website. Best, Paul On Mon, 27 May 2013, Vladimir S. FONOV wrote: > Well, > > I think the fact that we actually had ITK workshop at the BIC ( > http://www.rbiq-qbin.qc.ca/en/event/1388 ) last week might be an > influence. > > But if somebody want to reinvent the bicycle yet another time - I will > applaud their efforts. > > On Mon, May 27, 2013 at 4:40 PM, Pierre Bellec > wrote: >> I would be very interested by using this type of mex files, to boost the >> speed of some of the NIAK tools. I should be able to wrap up a mex version >> of mincresample in NIAK without problem, whatever the selected syntax is. >> As of the compatibility with octave, a simple matlab mex should compile >> directly with octave as well. I'd be happy to give it a try. >> >> Best, >> >> Pierre >> >> PS: @Vladimir I have stopped commenting on the "better" Python route, so I >> am not going to comment. Argh, I did it. >> >> 2013/5/27 Andrew Janke >> >>> On 28 May 2013 06:25, Paul GRAVEL wrote: >>>> I may then look into it... >>> >>> If you do, I'd suggest you talk to Pierre Bellec first (if you haven't >>> already) so that what you do can fit into his NIAK framework and thus >>> allow your code to work on both Octave and MATLAB. >>> >>> >>> a >>> _______________________________________________ >>> 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 > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users >