[Insight-users] Advices on 3D registration

Tue Jul 10 14:26:43 EDT 2007

Hello Nic,

In my honest opinion, good initialization is critical for your 
registration and registration methods/parameters are irrelevant 
unless they are too bad. LandmarkBasedTransformInitializer might 
help you to find a good initialization. In my case, I modified 
LandmarkInitializedMutualInformationRegistration in InsightApplications 
slightly to use the initializer, and it seemed to work well.

But I couldn't acquire good images. I wander what the "homemade 
setup" is. Could you describe the setup? Two coverslides were not 
rigid enough to hold the sample...
Please reply me directly, as I'm afraid it will be off-topic.

Thanks a lot in advance!

Hideaki Hiraki

At Tue, 10 Jul 2007 17:26:54 +0200, "Nic" wrote:
> Hi Luis,
>     thanks a lot for your reply !
> I could send you a link on a zip, rar or what ever else archive and put it 
> on a website in order you can download the images. My images stacks are 
> 2048x2048, should I resize them before to 512x512 by example ?
> I plan to use later Multi-Resolution registration (8.7)
> 
> ----- Original Message ----- 
> From: "Luis Ibanez" <luis.ibanez at kitware.com>
> To: "Nicolas Fête" <nicolas.fete at epfl.ch>
> Cc: "Insight Users" <insight-users at itk.org>
> Sent: Tuesday, July 10, 2007 4:57 PM
> Subject: Re: Fw: [Insight-users] Advices on 3D registration
> 
> 
> >
> >
> > 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