Fw: [Insight-users] Advices on 3D registration
Luis Ibanez
luis.ibanez at kitware.com
Tue Jul 10 10:57:16 EDT 2007
Hi Nicolas:
Thanks for your clarifications.
1) If you actually acquired the bottom sample by
physically rotating the sample in the microscope,
then you should *NOT* reverse the slice order
when you load the image.
What you want to do is to have a Transform that
represents what manually did to the sample,
namely: flipping it on the acquisition plate
by rotating it 180 around some axis.
(do you remember the axis that you rotate the
sample around ?)
If you just "reverse" the order of the slices
you are making the mistake of reflecting the
slices in the plane, and therefore they will
*NOT* match in the middle of the block.
2) Your "simulation" of acquiring image from
the bottom is not complete unless you include
the flipping that the images will have due
to having the microscope look at the sample
"from the other side". You will find this
clearer if you imagine and asymmetric object
inside the sample. You will see that left/right
should be reverted.
3) Since there are rotations involved in your
registration, you should use a Rigid3D transform,
even if you expect that most of the corrections
will be in the translations components.
Note that for this transform, it is critical
to set up the "center of rotation". a good
choice will be the middle of the "overlapping"
region between the front and back acquisition
blocks.
You *MUST* also initialize the rotation component
to a value of 180 degrees, to represent what you
manually did when you flipped the sample in the
microscope.
Before you start running any registration, please,
just resample the bottom image using the initialized
transform. If the initialization is correct, you should
find a visible match. If the initialization is not
correct, there is not point in running an optimizer.
4) Your synthetic example is not replicating correctly
what will happen to a sample when you flip it.
You must, in addition to read the slices in reverse
order, reflect them across the same axis that you are
simulating the flip.
5) Getting the *CORRECT* interslice physical spacing
is *VERY* important, because when you start including
rotations, translations in X and Y result in translations
on Z, and vice versa. If the spacings are not correct, the
proportions of translation will be miscalculated.
Please estimate the best you can the spacing between the
slices (in microns), and the X,Y pixel size in microns too.
6) Please read the ITK Software Guide for advice on how to
setup the parameter scales. The smaller the number of
the scale, the *MORE* variation will be applied to that
parameter.
7) Is this data that you can share publicly ?
Regards,
Luis
====================
Nicolas Fête wrote:
> Good afternoon,
> ----- Original Message -----
> *From:* Nic <mailto:itk at fete.ch>
> *To:* Luis Ibanez <mailto:luis.ibanez at kitware.com>
> *Sent:* Monday, June 25, 2007 4:45 PM
> *Subject:* Re: [Insight-users] Advices on 3D registration
>
> Hi Luis, really sorry I missed your reply last friday, thanks a lot for
> replying ! :)
>
> > 1) When you acquired the volume from the bottom (in the second
> > acquisition), are the slices organized in such a way that
> > the first slice in your stack is actually the last slice of
> > the sample as view from the direction of the first acquisition.
>
> My two scans begin out of the sample (black images, no light emission)
> and converge to the center of the sample (green nucleus images); I made
> acquisition in this order for a pratical reason and better image result.
> Each scan go a little bit further than the middle thus I can consider
> having 10-20 images in common. I modified the example code in order that
> the second stack ("bottom stack") is loaded in reverse (thanks Julien):
> I consider my final stack as viewed from top to bottom, the top
> stack direction is thus ok but not the bottom stack (bottom to top
> view), and that's the reason I load in reverse.
> The first image of the bottom stack doesn't corresponds to the last one
> of the top stack but corresponds to an image a little bit before the end
> of the top stack, thus the first X images of the bottom stack overlap
> the last X images of the top stack:
>
> Top stack Bottom stack
>
> n° 0 -----
> ...
> ... n° 0 -----
> n° 90 ----- ...
> ...
> n°66 ----
>
> I made a synthetic example from a top stack, splitting it in two stacks,
> one from slice 0 to 90 and the other from slice 70 to 135, having thus
> 20 slices on common. I reversed the order of the the second stack
> (renamed TIFF filenames), in order to simulate a bottom-top scan.
> Finally I downsampled to 512x512 for faster computing (originally
> 2048x2048) and in my modified code, I load the second stack IN REVERSE.
>
> > 2) Were the acquisitions made by actually flipping the sample in
> > the microscope between the two readings ?
>
> 2) Yes, the sample was put on an homemade setup and manually flipped
> betweeen scans (leica inverted confocal microscope). Rotation arround z
> axis could be approximated by simple calculation with scanfield rotation
> information from Leica file (the sample, because of its smalness and
> weakness, is put "as is" on coverslides, I then turn rotation field in
> order to zoom a maximum, with constraint to fit the whole sample. I try
> to satisfy at maximum the deconvolution optimal requirements on voxel
> size. Important: I take care NOT to modify the zoom value between the
> two scans, for a few minor stacks I forgot it when flipping, but the
> zoom difference is really small). I hope rotation around x and y axes
> could be neglected, registration will answer to the question, but
> viewing the images of both stacks, common images seems really the same
>
> > If the answers to (1) and (2) are true, what you may want to do
> > is initialize the rotation as a 180 degrees along the *SAME*
> > axis that you physically rotated the sample in-between the two
> > acquisitions *AND* set the center of rotation to the physical
> > position of the middle of the first stack, *AND* initialize
> > the translation of the registration to the distance between the
> > centers of both stacks.
>
> Ok. I think for my synthetic example it should work, because both stacks
> result from a splitted same stack.
> BUT for the real example we have perhaps to take into account the
> fact that :
>
> z-position_start_scan_value(bottom_stack) !=
> z-position_start_scan_value(top_stack)+step_size*calculated_number_of_slices
>
> In other words, the 20 overlapping images from each stack are not
> perfectly registrated in z, they are "interlaced".
> Perhaps we can approximate the translation between centers of both
> stacks. At least.. for an initialization it is no expected to be exact
> but only as near as possible.. no ?
>
> > From you data, it seems that the thickness of the full sample
> > is about:
> >
> > 80um + 80um - 20um = 140um
> > There for the distance between the physical centers of both
> > acquired blocks is about 60um.
> Yes, normally the tickness is normally comprised between 130 and 160,
> but it is difficult to know it exactly before having a whole 3D
> reconstruction 'cause sometimes the sample is a little bit "crushed"
> between the two coverslides. I doesn't really matter because I'm
> interesting only in counting nucleus, not calculating volume, and
> nucleus remain well-marked. The is no limitation with the distance
> between stacks I think.. ?
>
> > Since you probably were very careful placing the sample in the
> > microscopy, you should set the parameter scaling in such a way
> > that rotations should be minimal, and the optimizer will
> > concentrate mostly on correcting for translations.
> Yes, it is exactly what I though, and I'm actually trying it, but I
> don't exactly understand how to set it correctly, I'm still missing
> something :)
> In order to neglecte a parameter, should be the scale value near 1.0 or
> with a small value like 1.0/100000.0 ? I though that a small value would
> neglect a parameter, but z-value change more when its scale is set to a
> small value. Maybe I'm wrong because my code is not yet correct at the
> moment..
>
> > Once you solve the registration, you can join the two images into
> > a full image by resampling both the FIXED and the MOVING images
> > into an image grid equal aligned with the fixed image, but physically
> > extended downwards in order to include the physical region where the
> > second stack is located.
> I have to think a little bit about it, I'm not yet "fit" with ITK. The
> idea is the one I meant, but I actually don't see how to do it straight
> forwardly. I need a little bit more practice with ITK and check its doc
> again.. :)
>
> So, do you have any comments about what I answered above ?
>
> Thanks a lot ! nic
>
> >
> > Please let us know if you have further questions,
> >
> >
> > Thanks
> >
> >
> > Luis
> >
> >
> > ===========
> > Nic wrote:
> >> Hello,
> >> I would like to register 2 images stacks from one sample (confocal
> >> microscope, 1 channel only, nucleus staining). Each stack
> corresponds to
> >> one side of the sample, one scan was made from the top and the other
> >> from the bottom, each scan was made until a little past the middle of
> >> the sample, in order to have in each stack a small common sub-volume I
> >> could use for registering them (each common volume have around 10-20 µm
> >> deep, each stack can be 60-80 µm deep); the overlapping part is thus at
> >> the bottom of each stack. Nucleus are perfectly stained, well shaped
> and
> >> well separated.
> >> I'm currently adapting the "Rigid transform in 3D" (8.6.4), trying to
> >> initialize the transform with a z translation of the moving stack in
> >> order to have both overlapping sub-volume a little bit registerated;
> I'm
> >> allowing too loading Tiff image stacks, with correct spacing and origin.
> >> According to my acquisition protocol, it is probably possible to
> neglect
> >> rotations, or at least to consider only the rotation in the x-y plane
> >> (and this one could be perhaps approximated with microscope's value on
> >> scanfield rotation, and a mirroring calculation): should be it a
> >> solution to force optimisation for versor with a very small step and
> for
> >> translation a greater step (tuning is on optimizerScales no ?) ? Or is
> >> it possible to use another transform that only make 3D translations ?
> >> The idea is finally to have both stacks merged, one stack unchanged,
> and
> >> increased by a resampled version of the other from the bottom of the
> >> unchanged stack until the top of the resampled other stack; z-stepsize
> >> are same. Is there a way to do it easily ? I think the
> >> ImageRegistration8.cxx (code of Rigid transform in 3D" (8.6.4) example)
> >> do a resampling at end for the moving 3D image, but it seems to me it
> >> only apply transformation to the moving image but don't merge the fixed
> >> and moving images.. Or did I miss something ?
> >> Thanks a lot in advance ! nic
> >> _______________________________________________
> >> Insight-users mailing list
> >> Insight-users at itk.org <mailto:Insight-users at itk.org>
> >> http://www.itk.org/mailman/listinfo/insight-users
More information about the Insight-users
mailing list