<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.6000.16525" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=Arial size=2>Hi Luis, Torsten and Vadim,</FONT></DIV>
<DIV><FONT face=Arial size=2> <FONT color=#008000> first of
all: several people asked me for the software I use for the 3D view: it's
Bitplane Imaris (</FONT></FONT><A href="http://www.bitplane.com"><FONT
face=Arial color=#008000 size=2>www.bitplane.com</FONT></A><FONT face=Arial
color=#008000 size=2>), expensive license, was acquired by our
faculty.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>For Luis:</FONT></DIV>
<DIV><FONT face=Arial color=#008000 size=2>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.</FONT></DIV>
<DIV><FONT face=Arial color=#008000 size=2>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) ?</FONT></DIV>
<DIV><FONT face=Arial color=#008000 size=2>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)</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>For Torsten:</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2><FONT color=#0000ff>"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 <BR>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).<BR>So my suggestion would
be to register, say, downsampled 512x512x120 stacks and then apply the resulting
transformation to the full-resolution image(s)."</FONT><BR></FONT></DIV>
<DIV><FONT face=Arial color=#008000 size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial color=#800000 size=2>I identified 5 points for fine
tuning:</FONT></DIV>
<DIV><FONT face=Arial color=#800000 size=2>- finer z-axis rotation initalization
(done)</FONT></DIV>
<DIV><FONT face=Arial color=#800000 size=2>- multiresolution along x and y
dimensions (min 512, max full res)</FONT></DIV>
<DIV><FONT face=Arial color=#800000 size=2>- gaussian
smoothing</FONT></DIV>
<DIV><FONT face=Arial color=#800000 size=2>- finer interpolation (bspline
interpolation, windowed sync), actually using linear interpolation</FONT></DIV>
<DIV><FONT face=Arial color=#800000 size=2>- empirical determination of the
minimal number of images need for having a correct image
registration</FONT></DIV>
<DIV><FONT face=Arial color=#800000 size=2></FONT> </DIV>
<DIV><FONT face=Arial color=#800000 size=2>Would be multiresolution with
</FONT><FONT face=Arial color=#800000 size=2>gaussian smoothing and linear
interpolation at low resolution, and </FONT><FONT face=Arial color=#800000
size=2>finer interpolation at full resolution, </FONT><FONT face=Arial
color=#800000 size=2>a good idea ?</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Best, nic</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>----- Original Message ----- </FONT>
<DIV><FONT face=Arial size=2>From: "Luis Ibanez" <</FONT><A
href="mailto:luis.ibanez@kitware.com"><FONT face=Arial
size=2>luis.ibanez@kitware.com</FONT></A><FONT face=Arial
size=2>></FONT></DIV>
<DIV><FONT face=Arial size=2>To: "Nic" <</FONT><A
href="mailto:itk@fete.ch"><FONT face=Arial size=2>itk@fete.ch</FONT></A><FONT
face=Arial size=2>></FONT></DIV>
<DIV><FONT face=Arial size=2>Cc: "Insight Users" <</FONT><A
href="mailto:insight-users@itk.org"><FONT face=Arial
size=2>insight-users@itk.org</FONT></A><FONT face=Arial size=2>></FONT></DIV>
<DIV><FONT face=Arial size=2>Sent: Sunday, December 09, 2007 10:36
PM</FONT></DIV>
<DIV><FONT face=Arial size=2>Subject: Re: [Insight-users] Sub-volumes
registration</FONT></DIV></DIV>
<DIV><FONT face=Arial><BR><FONT size=2></FONT></FONT></DIV><FONT face=Arial
size=2>> <BR>> Hi Nic,<BR>> <BR>> How are you extracting the
subvolumes from the large volumes ?<BR>> <BR>> If you use the
RegionOfInterestImageFilter, the final transform<BR>> obtained from the
registration of the subvolumes should be *directly*<BR>> applicable to the
larger volumes.<BR>> <BR>> This is because the origin of the subvolumes
would be correctly computed<BR>> so that they are placed in the correct
location in physical space<BR>> with respect to the original larger
volume.<BR>> <BR>> If you compute the origin of your subvolumes correctly,
then you are<BR>> still performing registration in physical coordinates, and
no further<BR>> modification of the transform should be needed once you
complete the<BR>> registration of the subvolumes.<BR>> <BR>> That's the
most consistent way of performing your registration.<BR>> <BR>>
<BR>> Regards,<BR>> <BR>>
<BR>> Luis<BR>> <BR>> <BR>>
-------------<BR>> Nic wrote:<BR>>> Hi
all,<BR>>> I'm a in trouble for the very last step
of my registration program <BR>>> when merging stacks, help would be
greatly appreciated, deadline is <BR>>> coming ! :)<BR>>> My
registration process is actually successful, I get a correct <BR>>>
registration result which can perhaps be refined with a finer <BR>>>
interpolator, but that's another story.<BR>>> Result is here: </FONT><A
href="http://itk.tiboufroulou.com/final.png"><FONT face=Arial
size=2>http://itk.tiboufroulou.com/final.png</FONT></A><FONT face=Arial size=2>
(slice <BR>>> view), </FONT><A
href="http://itk.tiboufroulou.com/final3D.png"><FONT face=Arial
size=2>http://itk.tiboufroulou.com/final3D.png</FONT></A><FONT face=Arial
size=2> (3D view)<BR>>> <BR>>> Actually I registrate two
sub-volumes resulting from two big stacks. <BR>>> Because doing the
registration process with the full stacks loaded is <BR>>> impossible
(avaible memory and time consuming problem), I only load the <BR>>> two
subvolumes for the registration. The problem now is to "translate" <BR>>>
my final transformation for the two subvolumes in a transform for the
<BR>>> two full stacks, I tried to set the rotation center and add
translation <BR>>> to the final parameters, but I don't think it is the
good way and if it <BR>>> is even possible to reach a
solution..<BR>>> On the other hand, back to itk manual, I'm wondering if
there is a <BR>>> possibility to force registration only on subvolume
regions (thinking <BR>>> about set fixedimageregion, setfixedimagemask,
setmovingimagemask), thus <BR>>> loading the full stacks but only doing
registration with subvolume data, <BR>>> final transformation taking into
account the whole stacks..<BR>>> Kind regards, nic<BR>>>
<BR>>> <BR>>> Supplementary informations:<BR>>>
<BR>>> At the beginning, two big volumes of images (2048 x 2048 x min120
<BR>>> images), those volumes have a common volume present in each stack,
<BR>>> always near the top of each stack because the images stacks result
from <BR>>> a two-side scan of a sample, from outside until a little
farther than <BR>>> the middle. The idea is to registrate the stacks on
the two subvolumes: <BR>>> </FONT><A
href="http://itk.tiboufroulou.com/schema.png"><FONT face=Arial
size=2>http://itk.tiboufroulou.com/schema.png</FONT></A><FONT face=Arial
size=2>. Identification of position of <BR>>> subvolumes is made through a
GUI (browsing both images stacks). For <BR>>> initialisation, a 180°
rotation around oy-axis then a rotation around z <BR>>> identified through
superposition view in GUI is made (Superposition <BR>>> view: </FONT><A
href="http://itk.tiboufroulou.com/superposition.png"><FONT face=Arial
size=2>http://itk.tiboufroulou.com/superposition.png</FONT></A><FONT face=Arial
size=2>). Finally, centers <BR>>> of subvolumes are calculated
geometrically, center of moving image have <BR>>> an (x,y) offset added,
offset resulting from a translation visually made <BR>>> on GUI (same view
as above); the offset observed in GUI is transformed <BR>>> by the intial
transformation(the two successive rotations) and then <BR>>> added
to the moving center. Initial transformation is thus initialized <BR>>>
with the two successive rotation and the <BR>>>
translation(movingCenter-fixedCenter calculated above)<BR>>> <BR>>>
<BR>>>
------------------------------------------------------------------------<BR>>>
<BR>>> _______________________________________________<BR>>>
Insight-users mailing list<BR>>> </FONT><A
href="mailto:Insight-users@itk.org"><FONT face=Arial
size=2>Insight-users@itk.org</FONT></A><BR><FONT face=Arial size=2>>>
</FONT><A href="http://www.itk.org/mailman/listinfo/insight-users"><FONT
face=Arial
size=2>http://www.itk.org/mailman/listinfo/insight-users</FONT></A><BR><FONT
face=Arial size=2>></FONT></BODY></HTML>