users > Some oddities with the groupwise set of tools
Showing 1-6 of 6 posts
Display:
Results per page:
Jun 13, 2012  10:06 AM | Torsten Rohlfing - Google LLC
Some oddities with the groupwise set of tools
Hi Aaron -



A. The reason for the isotropic output is that after alignment the
relative orientation of the images will no longer coincide with grid
dimensions, so say you have one input image at a 45 degree angle, then
there is no reason to sample it coarsely along what used to be the slice
direction but no longer is.



B The reason for the infinite values is that these mark areas where none
of the input images have any valid data, so there is no valid average value.





As for solutions, there are quite a few, and you can take your pick:



A1 - The groupwise registration tools all accept an optional command
line parameter, "--template", which you can use to provide a
user-defined template grid. In your case, that cpuld simply be one of
the input images. That image will not be used for registration, but its
grid will be used for sampling the other input images during
registration, and it will also provide the grid for the average image.



A2 - In general, the average images created by the groupwise tools are
not necessarily meant to be what you use for further processing. That's
why te tools provide very limited options to configure these, e.g., only
linear and cubic interpolation. To have more control over the average
image (including the exact grid) you should use the "reformatx" tool to
reformat each of the input images using its computed transformation to
groupwise space. This way, you can use any (possibly multiple different)
sampling grids, better interpolation, other moving images (e.g., label
maps that go with the aligned greylevel images). For averaging, you
would then use "imagemath" ("--average" for intensity images, "--vote"
or "--mstaple" for labels) or any of the label combination tools ("sba",
"lsba", "lvote").



B1 - you cannot prevent the groupwise tools from writing infinite values
to mark padded areas, but you can use the "convertx" tools to remove
these after the fact, e.g., like that:



  convertx --replace-inf-nan 0 avg.nrrd avg.nrrd



will overwrite avg.nrrd with the same image, but after replacing all
infinite and not-a-number values with zero (pick any other value if you
prefer).



B2 - as in A2, I would suggest you look into whether it makes more sense
to use "reformatx" and "imagemath" for the reformating and averaging, in
which case you could use zero for padding non-existing pixels. Note,
however, that this would affect the averaging stage, because you would
then consider "0" a valid value and include it in the averaging at each
pixel, whereas Inf will be disregarded during averaging (thus reducing
the denominator in the mean intensity fraction at these pixels).





Hope this helps.



  Torsten



On 06/13/2012 10:16 AM, Aaron Ostrovsky wrote:

Hi Torsten,



 I've been attempting to use the various groupwise registration tools
and I've encountered a couple of things that Greg and I thought would
be asking you about. First, the groupwise_init (and subsequently the
groupwise_affine) tool seems to resample the starting images so that
they contain isotropic voxels, and it does this so that they are of
the smallest possible dimension. So if my images were .3um x .3um x
1um to start with, after the _init has finished they are .3 x .3 x
.3um, about 3 times larger than they started. Is it possible to change
this?



Second, I've noticed that after the tools run, at the margins of each
image there are regions that are reported as containing infinite
values. I remember encountering something similar to this when using
the avg_adm tool in the past, and we sorted it out by using
the --pad-out option and setting it to 0, but I don't see such an
option for groupwise_init. Is there something similar I could be
using, or some other way of removing the infinities?



For what it's worth, here are the commands that I've used to run the
tools.



groupwise_init --output-average average.nrrd --align-centers-of-mass
--init-scales ../../images/female/[/i]*.nrrd



groupwise_affine --rmi --dofs 6,9 --output-average
average-affine-Female.nrrd --zero-sum --downsample-from 8 --accuracy
0.2 ../init/groupwise.xforms



groupwise_warp --output-average average-warp-Female.nrrd --accuracy
0.2 --downsample-from 8 --congeal --match-histograms
--zero-sum-no-affine ../affine/groupwise.xforms



Many thanks for any help,

Aaron



-- 
Aaron Ostrovsky, PhD

Jefferis Group

Rm 1041

MRC - Laboratory of Molecular Biology

Hills Road

Cambridge, CB2 0QH

+44 (0)1223 252943





-- 
Torsten Rohlfing, PhD          SRI International, Neuroscience Program

 Senior Research Scientist      333 Ravenswood Ave, Menlo Park, CA 94025

  Phone: ++1 (650) 859-3379      Fax: ++1 (650) 859-2743

   [url=mailto:torsten@synapse.sri.com]torsten@synapse.sri.com[/url]        [url=http://www.stanford.edu/%7Erohlfing/]http://www.stanford.edu/~rohlfing/[/url]



     "Though this be madness, yet there is a method in't"
Jun 14, 2012  06:06 PM | Greg Jefferis
RE: Some oddities with the groupwise set of tools
Hi Torsten,

We've looked at the first round of output from 1x1x1um resampled images (~ 600x300x100 pixels)

Commands:
groupwise_affine --rmi --dofs 6,9 --output-average average-affine-Female.nrrd --zero-sum --downsample-from 8 --accuracy 0.2 ../init/groupwise.xforms
groupwise_warp --output-average average-warp-Female.nrrd --accuracy 0.2 --downsample-from 8 --congeal --match-histograms --zero-sum-no-affine ../affine/groupwise.xforms
The main point so far is that we have not implemented any multi-resolution grids etc for warp and we find that there is not enough happening – things still look blurry at the final warp. If we want to match this parameter set that we regularly use for affine/warp registrations and have used in conjunction with avg_adm:
registration -i -v --dofs 6 --dofs 9 --accuracy 0.4
warp -v --registration-metric nmi --jacobian-weight 0 --fast -e 26 --grid-spacing 80 --energy-weight 1e-1 --refine 4 --coarsest 8 --output-intermediate --accuracy 0.4 
can you give any specific advice to translate to groupwise_*.

One other point - this is all taking a long time! The full resolution jobs (0.3x0.3x1 um have been going for >24h). We are running one job / 8 core cluster node. Should we be trying to get mpi running so that we can run 50 or 100 cores?

Thanks a lot!

Greg.


PS For comparison I also note this from the CMTK user guide:--sampling-density 0.05?


# Affine groupwise registration with zero-sum transformation parameters # over all images. Use 20% stochastic sampling density for speed. # Use ‘‘RMI’’-based similarity measure; sometimes more robust for affine. groupwise_affine --rmi -O groupwise/affine -v --match-histograms \

--dofs 6 --dofs 9 --zero-sum \

--downsample-from 8 --downsample-to 1 --exploration 8 -a 0.5 \

--sampling-density 0.05 --force-background 0 \

groupwise/initial/groupwise_init.xforms


# Nonrigid (B-spline) groupwise registration using ‘‘congealing’’ criterion. # Start with approx. 40mm control point grid (fitted to image FOV), refine 5 # times, and force displacements to be zero-sum over all images (not # considering the global affine transformation component). groupwise_warp --congeal -O groupwise/warp -v --match-histograms --histogram-bins 32 \

--grid-spacing 40 --grid-spacing-fit --refine-grid 5 --zero-sum-no-affine \

--downsample-from 8 --downsample-to 1 --exploration 6.4 --accuracy 0.1 \

--force-background 0 groupwise/affine/groupwise_rmi.xforms

Jun 15, 2012  11:06 AM | Torsten Rohlfing - Google LLC
RE: Some oddities with the groupwise set of tools
Hi Greg.

Originally posted by Greg Jefferis:
warp -v --registration-metric nmi --jacobian-weight 0 --fast -e 26 --grid-spacing 80 --energy-weight 1e-1 --refine 4 --coarsest 8 --output-intermediate --accuracy 0.4 can you give any specific advice to translate to groupwise_*.

I think you pretty much have the affine registration taken care of. If anything, you might want to add "12" as an additional DOF to also cover shears at that stage.

For the nonrigid, you could add the following to groupwise_warp to match your pairwise warp:
--grid-spacing 80 --grid-spacing-fit --refine-grid 4 --smooth-pixels 1 --downsample-to 0 --bending-energy-weight 1e-1 --exploration 26 --accuracy 0.1

In particular specifying a grid spacing should speed things up, and setting "exploration" to something other than the 0.25 default should make things happen.

And, yes, you could use probablistic downsampling with --sampling-density, but you would of course be giving up reproducibility or your results.

Regarding MPI - I am afraid I actually retired that code a couple of releases ago. It was becoming a pain in the neck to maintain, was not tested, rarely used by anyone including myself, and just generally in the way. You can still go back to CMTK 2.1.0 of course (MPI was ditched in 2.1.1), but it is a pain. If there's cash, maybe you should get a 24-core box? Those aren't really that expensive these days.

As a bit of consolation, remember also that some of the speedup of more cores using MPI is eaten up by communication between the nodes, and the per-node code in the MPI version was less optimized than the single-node code, simply because you cannot re-arrange computations as easily if they go on remotely. So you wouldn't be seeing anywhere near linear speedup from adding nodes compared with adding cores on the same node.

One other point - this is all taking a long time! The full resolution jobs (0.3x0.3x1 um have been going for >24h). We are running one job / 8 core cluster node. Should we be trying to get mpi running so that we can run 50 or 100 cores?

Thanks a lot!

Greg.
Jun 15, 2012  02:06 PM | Greg Jefferis
RE: Some oddities with the groupwise set of tools
Hi Torste,

Thanks a lot for the suggestions.

--grid-spacing-fit --smooth-pixels 1 --downsample-to 0

What do these do for me?!

Re MPI and its demise, fair enough. There are a couple of 24 cpu boxes at the head of our cluster but even on the weekend more than 12 is prob impolite!

Is any of this CUDAable?

Thanks again,

Greg.
Jun 15, 2012  02:06 PM | Torsten Rohlfing - Google LLC
RE: Some oddities with the groupwise set of tools
Originally posted by Greg Jefferis:

--grid-spacing-fit --smooth-pixels 1 --downsample-to 0

What do these do for me?!

--grid-spacing-fit adjusts (increases) the user-provided grid spacing so that the image field of view in each dimension is exactly covered by an integral number of control points. So if you ask for 40mm spacing but your FOV is 100mm, using this option you will end up with 50mm actual spacing.
Re MPI and its demise, fair enough. There are a couple of 24 cpu boxes at the head of our cluster but even on the weekend more than 12 is prob impolite!

Is any of this CUDAable?

It was planned for a while, but it turned out that any problems of interesting size would not nearly fit into the memory available for GPUs at the time, so the plan was shelved.
Jun 15, 2012  02:06 PM | Torsten Rohlfing - Google LLC
RE: Some oddities with the groupwise set of tools
Sorry, forgot to comment on the other two.
Originally posted by Greg Jefferis:

 --smooth-pixels 1 --downsample-to 0

"--smooth-pixels 1" smoothes the image data with a Guassian kernel, and sigma is 1x the pixel size at any given level.

Related, using "--downsample-to 0" means to add one additional level of computation after full resolution (default "downsample to 1"), but with smoothing disabled. So you would get smoothing at all levels of resolution including full resolution, but then another level is added with full resolution and no smoothing. That means you can use a rather wide kernel and still ultimately take full advantage of the original data.