[Insight-users] Sub-volumes registration

[Nic]

Hi Luis, Torsten and Vadim,
    first of all: several people asked me for the software I use for the 3D view: it's Bitplane Imaris (www.bitplane.com), expensive license, was acquired by our faculty.

For Luis:
Thanks again for your reply ! In fact, actually I don't use the RegionOfInterestImageFilter yet - I didn't know about it in fact -, I load only the images I need for my registration, i.e 20 images pro stack. Regarding my "sub-volumes to full stacks transformation transposition", I found a simple solution: my registration is made with origin of loaded subvolumes @ 0, then in my "fusionprogram", I load the full stacks with origins set relative to subvolumes and merge the volumes: it's the inverse thinking of what you said below.
Thinking about it, it's quite logic in fact: when rotation is made relative to the subvolumes (i.e subvolume origin = 0), the rest of the two stacks, because they are "pasted" with the subvolumes, naturally turns with the subvolumes; registration final transformation can thus be directly applied ! I don't know yet how works the RegionOfInterestImageFilter, I think it automatically makes the "subvolume to full stack origin distance computation", perhaps my way of doing use less memory because I avoid loading full stacks for registration ? Would be nevertheless better to use this filter (just a question of doing things nicely and cleanly) ?
I have have opened questions for fine tuning and improve my registration accuracy, I would be interested in your comments (short marron text block below)

For Torsten:

"Have you considered registering downsampled (potentially smoothed) versions of your image stacks? I find it highly unlikely that 6, 9, or even 12 degrees of freedom in a rigid (or affine) registration can make full use of the type of image resolution that you are talking about. In other words -- a rigid registration problem is so highly constrained 
that you should not need anywhere near 2k times 2k times 120 pixels to get it "right". (Chances are, it may even be harder to register using the full image resolution because the excessively fine image texture may create many local minima in the registration cost function).
So my suggestion would be to register, say, downsampled 512x512x120 stacks and then apply the resulting transformation to the full-resolution image(s)."

Thanks for your suggestion. Yes, in fact I tried before to use multiresolution registration. Even if I get good registration results at the end on some real examples, I'm a bit annoied ot the fact that I can use exactly the same parameteres values (parameters weight, min/max step) for each stacks registrations, because I especially have to modify a bit the parameters scales in order to avoid diverging. I'm considering now about downsampling subvolumes images on x-y dimensions, before working on full res images at end; I should study the metric for a variation of two parameters with or without gaussian smoothing too. I changed my GUI in order to able to do finer z-axis rotation (delta(RotZ) = 0.1° ), I think it improve a lot the registration accuracy because by setting x-y translation and z-axis rotation very close to the solution, it can put more stress on other parameters, especially z translation.

I identified 5 points for fine tuning:
- finer z-axis rotation initalization (done)
- multiresolution along x and y dimensions (min 512, max full res)
- gaussian smoothing
- finer interpolation (bspline interpolation, windowed sync), actually using linear interpolation
- empirical determination of the minimal number of images need for having a correct image registration

Would be multiresolution with gaussian smoothing and linear interpolation at low resolution, and finer interpolation at full resolution, a good idea ?

Best, nic



----- Original Message ----- 
From: "Luis Ibanez" <luis.ibanez at kitware.com>
To: "Nic" <itk at fete.ch>
Cc: "Insight Users" <insight-users at itk.org>
Sent: Sunday, December 09, 2007 10:36 PM
Subject: Re: [Insight-users] Sub-volumes registration


> 
> Hi Nic,
> 
> How are you extracting the subvolumes from the large volumes ?
> 
> If you use the RegionOfInterestImageFilter, the final transform
> obtained from the registration of the subvolumes should be *directly*
> applicable to the larger volumes.
> 
> This is because the origin of the subvolumes would be correctly computed
> so that they are placed in the correct location in physical space
> with respect to the original larger volume.
> 
> If you compute the origin of your subvolumes correctly, then you are
> still performing registration in physical coordinates, and no further
> modification of the transform should be needed once you complete the
> registration of the subvolumes.
> 
> That's the most consistent way of performing your registration.
> 
> 
>   Regards,
> 
> 
>       Luis
> 
> 
> -------------
> Nic wrote:
>> Hi all,
>>     I'm a in trouble for the very last step of my registration program 
>> when merging stacks, help would be greatly appreciated, deadline is 
>> coming ! :)
>> My registration process is actually successful, I get a correct 
>> registration result which can perhaps be refined with a finer 
>> interpolator, but that's another story.
>> Result is here: http://itk.tiboufroulou.com/final.png (slice 
>> view), http://itk.tiboufroulou.com/final3D.png (3D view)
>>  
>> Actually I registrate two sub-volumes resulting from two big stacks. 
>> Because doing the registration process with the full stacks loaded is 
>> impossible (avaible memory and time consuming problem), I only load the 
>> two subvolumes for the registration. The problem now is to "translate" 
>> my final transformation for the two subvolumes in a transform for the 
>> two full stacks, I tried to set the rotation center and add translation 
>> to the final parameters, but I don't think it is the good way and if it 
>> is even possible to reach a solution..
>> On the other hand, back to itk manual, I'm wondering if there is a 
>> possibility to force registration only on subvolume regions (thinking 
>> about set fixedimageregion, setfixedimagemask, setmovingimagemask), thus 
>> loading the full stacks but only doing registration with subvolume data, 
>> final transformation taking into account the whole stacks..
>> Kind regards, nic
>>  
>>  
>> Supplementary informations:
>>  
>> At the beginning, two big volumes of images (2048 x 2048 x min120 
>> images), those volumes have a common volume present in each stack, 
>> always near the top of each stack because the images stacks result from 
>> a two-side scan of a sample, from outside until a little farther than 
>> the middle. The idea is to registrate the stacks on the two subvolumes: 
>> http://itk.tiboufroulou.com/schema.png. Identification of position of 
>> subvolumes is made through a GUI (browsing both images stacks). For 
>> initialisation, a 180° rotation around oy-axis then a rotation around z 
>> identified through superposition view in GUI is made (Superposition 
>> view: http://itk.tiboufroulou.com/superposition.png). Finally, centers 
>> of subvolumes are calculated geometrically, center of moving image have 
>> an (x,y) offset added, offset resulting from a translation visually made 
>> on GUI (same view as above); the offset observed in GUI is transformed 
>> by the intial transformation(the two successive rotations)  and then 
>> added to the moving center. Initial transformation is thus initialized 
>> with the two successive rotation and the 
>> translation(movingCenter-fixedCenter calculated above)
>> 
>> 
>> ------------------------------------------------------------------------
>> 
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users at itk.org
>> http://www.itk.org/mailman/listinfo/insight-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/insight-users/attachments/20071210/d5e955cd/attachment-0001.htm