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