Fw: [Insight-users] Advices on 3D registration
Nic
itk at fete.ch
Tue Jul 10 11:26:54 EDT 2007
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
>> >> _______________________________________________
>> >> Insight-users mailing list
>> >> Insight-users at itk.org <mailto:Insight-users at itk.org>
>> >> http://www.itk.org/mailman/listinfo/insight-users
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
More information about the Insight-users
mailing list