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

[Kishore Mosaliganti]

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
>> >
>> >
>
>