[Insight-users] Constructing 3D stack from 2D image series (with registration)

Wed Oct 21 13:35:59 EDT 2009

Hi Kishore,

This thread is prompting some interesting brainstorming on the general
problem.

Perhaps an average transform could be applied in some form of sliding
window.

Say we have images I1:I9, with a sliding window of 3 images (arbitrary group
size), with some overlap between the sliding image groups, e.g.:

I1-I3, I2-I4, I3-I5, I4-I6, I5-I7, I6-I8, I7-I9

Each of these blocks would contain a within-block registration routine.
Given the overlap between blocks, it may be possible to construct suitable
average transforms that can propage through the entire series.

In each group of 3 images, the first and last images could be registered to
the middle image and the middle image could be registered to each of the
outside images (without using an inverse transform).  The intuition is that
some kind of "average" of both forward and backward image registration might
avoid some twisting that could otherwise propagate through a long series of
images.  (It can't be an "average" of inverse transforms, that's a bad
choice of term for the intuition.  It's some kind of "middle" space that
considers both I1 and I2 as moving images that are both transformed to an
imaginary space that encapsulates some kind of "average image" of the
coregistration between {I1,I2} that lies somewhere in between the
registration of I1 to I2 and the registration of I2 to I1.  So that I1 moves
"half-way" toward I2, and I2 moves "half-way" toward I1 and they meet each
other "half-way" in a nice coregistration.  It's not exactly a rigid-target
coregistration, as it's conceived and implemented in ITK at present.  I
don't have the language to explain this idea.)

OK, back to reality and some pressing deadlines to get something working.

Take care,
Darren

On Tue, Oct 20, 2009 at 6:27 PM, Kishore Mosaliganti
<kishoreraom at gmail.com>wrote:

> Hi Darren,
>
> The direction of microtoming gives you some idea of the shear
> direction. That constrains the shear deformation to 1 dimension.
>
> Also, the extent of rigid registration and deformable registration can
> be estimated. In my study, I observed that only 10% of the deformation
> is due to deformable and 90% is take care of rigidly.
>
> Regarding the sliding window registration, I had some ideas that I
> never tried out:
> Let I1, I2, I3, I4, I5 be 5 consecutive images.
>
> Then, using the pairwise registration transforms, say I1-I4 are
> already in the world coordinate space.
>
> Register I5 individually with I1....I4 pairwise to determine its
> pairwise transforms. This is a vector of transforms in the same
> coordinate system.
>
> Since I1, I4 are already in the world coordinate systems, you can now
> average the transform parameters using a weighted kernel.
>
> Kishore
>
> On Tue, Oct 20, 2009 at 8:09 PM, Darren Weber
> <darren.weber.lists at gmail.com> wrote:
> >
> > Hi Kishore,
> >
> > Yes, absolutely right.  In my opinion, this is an "artistic" project
> > (despite the use of advanced microscopy and image processing techniques).
> >
> > Some effort is given to maintain a resemblance to an "original" object,
> but
> > there can be no clear assertion of accuracy in the work.  At the start,
> > there are some distortions due to fixing and microtome sectioning of the
> > samples.  In an ideal world, each section would be a composition of the
> > object of interest with a microscopic or nanoscopic grid that would
> provide
> > a measure for these distortions.  The use of a deformation registration
> is a
> > poor attempt to "undo" these deformations.  Of course, it assumes we
> begin
> > with an object that has no deformations and that's just not possible in
> this
> > project.
> >
> > Even if the input data had perfect mapping to the original object of
> > interest, the image processing would introduce some artifacts that
> propagate
> > through the series.  The order of the Bspline deformation is low (3) in
> an
> > attempt to limit the deformations.
> >
> > It might be ideal to constrain the alignment process within a short
> subset
> > of the image series (maybe 3, 5, 7, or 9 images), with some kind of
> "sliding
> > window" to move through the entire series (where the slide would involve
> > some degree of window overlap).  This may not be a strictly pair-wise
> image
> > registration process (it may be an N-way registration) and it might occur
> > best in a 3D method that was able to maintain a translation between
> > consecutive images to maintain their separation in 3D space (the
> > z-spacing).  AFAIK, this "ambiguous" registration method is outside the
> > design parameters of ITK (where registration puts any TWO images into the
> > "same" space).
> >
> > Any suggestions on how to do some kind of "sliding" window registration
> > would be wondeful.
> >
> > Take care,
> > Darren
> >
> >
> >
> > On Tue, Oct 20, 2009 at 4:51 PM, Kishore Mosaliganti <
> kishoreraom at gmail.com>
> > wrote:
> >>
> >> Hi,
> >>
> >> From some previous experience on working on a similar problem. I
> >> observed that if you compose transforms, you might observe artifacts
> >> such as torsional twisting of geometry.
> >>
> >> This torsional twist happens due to the geometry of the image object
> >> in 3D from which two consecutive slices of a 3D object are drawn. The
> >> slices hold slightly different geometries that cause a very small
> >> rotation. This rotation bias builds up as you compose.
> >>
> >> Kishore
> >>
> >> On Thu, Oct 15, 2009 at 5:20 PM, Darren Weber
> >> <darren.weber.lists at gmail.com> wrote:
> >> >
> >> > We have a series of several thousand 2D microscope images:
> >> >
> >> > img0001 ... imgN
> >> >
> >> > A simple ITK program uses itkImageSeriesReader to stack the sequential
> >> > images into a 3D volume for output to a .vtk file.  Without any
> >> > coregistration of the image series, the result is a mess (as
> expected).
> >> >
> >> > Another ITK program runs registration algorithm(s) on consecutive
> pairs
> >> > of
> >> > images in the 2D image series (each pair of images is registered
> >> > independently of any other images in the series).  It outputs a
> >> > transform
> >> > file for each image registration, using file names something like:
> >> >
> >> > img0002to0001.xfm
> >> > img0003to0002.xfm
> >> > etc.
> >> >
> >> > What is an efficient way to combine and apply these transforms using
> an
> >> > ITK
> >> > pipeline to 'concatenate' the image series into a 3D stack?
> >> >
> >> > My conception of how this might work, in outline, is:
> >> >
> >> > a)  begin with img0001
> >> > apply transform: none
> >> >
> >> > b) add img0002 to the stack
> >> > apply transform: img0002to0001.xfm
> >> >
> >> > c) add img0003 to the stack
> >> > apply transform: img0002to0001.xfm
> >> > apply transform: img0003to0002.xfm
> >> > (How to concatenate transforms without resampling image data?)
> >> >
> >> > d) add img0004 to the stack
> >> > apply transform: img0002to0001.xfm
> >> > apply transform: img0003to0002.xfm
> >> > apply transform: img0004to0003.xfm
> >> > (How to concatenate transforms without resampling image data?)
> >> >
> >> > etc.
> >> >
> >> >
> >> > In this conception of the problem, the pair-wise registration
> transforms
> >> > are
> >> > 'concatenated' to propagate the registration through the entire
> series.
> >> > What is the most efficient way to do that in ITK?
> >> >
> >> > Is it possible (or reasonable) to associate a transform object (or
> file)
> >> > with each 'element' of an itkImageSeriesReader?  If not, is there
> >> > another
> >> > convention for creating an ITK filter pipeline or registration
> pipeline?
> >> >
> >> > TIA and take care,
> >> > Darren
> >> >
> >> >
> >> > _____________________________________
> >> > Powered by www.kitware.com
> >> >
> >> > Visit other Kitware open-source projects at
> >> > http://www.kitware.com/opensource/opensource.html
> >> >
> >> > Please keep messages on-topic and check the ITK FAQ at:
> >> > http://www.itk.org/Wiki/ITK_FAQ
> >> >
> >> > Follow this link to subscribe/unsubscribe:
> >> > http://www.itk.org/mailman/listinfo/insight-users
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20091021/32792ada/attachment-0001.htm>