[Insight-users] Advices on 3D registration

[Nic]

Hi Luis,
    I answered you directly two weeks ago, but it seems that my email have 
some problems with antispam filters (I sent through a mail server that have 
a domain name different than the email I used, and I get a high spam score).
I post again to the mailing list, hoping you'll ge it now :)
Here is my answer:

----- Original Message ----- 
From: Nic
To: Luis Ibanez
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.


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
>> http://www.itk.org/mailman/listinfo/insight-users