Luis Ibanez | 1 Feb 03:40 2008

Re: [Insight-developers] bug report on DeformableModelSimplexMesh application


Hi Defeng,

Can you please post in a public web site the image that
you are using as input, and the full set of parameters
that you are using for running this application ?

Otherwise it is very hard for us to figure out how far
from the edge of the image you are seeing the final
contour stopping.

Please give use a very clear sequence of step that we
could follow to reproduce your experience here.

   Thanks

      Luis

-------------------
Defeng WANG wrote:
> Hi, Leila,
> 
> Thanks for your reply. It seems that the parameters in the UI of
> DeformableModelSimplexMesh are not related to the gradient calculation. I
> read the source code involved in DeformableModelSimplexMesh. As for the
> gradient calculation, three filters are used successively as follows,
> 
>  m_GradientMagnitude->SetInput(m_CastImage->GetOutput() );
>  m_GradientMagnitude->SetSigma(0.5);
> 
(Continue reading)

Luis Ibanez | 1 Feb 03:45 2008

Re: Compiling itk 3.4 with Borland C++ v5.5


Hi Walter,

The Borland C++ 5.6 compiler is not supported in ITK.

Borland C++ 5.6 has *less compliance* with the C++ standard
than the version 5.5.  Borland displayed a strange concept
of "progress" with this compiler. The result is that Bcc 5.6
is not capable of compiling ITK code.

Please use bcc 5.5.

or... use Cygwin with gcc,
or... use MinGW with gcc.

    Regards,

       Luis

---------------------
Walter Cabrera wrote:
> Now I am compiling itk package with borland c + + 5.6 and gives me the
> following errors: 
> 
> Borland C++ 5.6 for Win32 Copyright (c) 1993, 2002 Borland
> C:\ITK_original\Code\Common\itkSpatialOrientationAdapter.cxx:
> Error E2316 C:\ITK_original\Code\Common\itkImageRegion.txx 178:
> 'ImageRegion<VImageDimension>::Slice(const unsigned long) const' is not a
> member of 'ImageRegion<VImageDimension>'
> Error E2027 C:\ITK_original\Code\Common\itkConceptChecking.h 142: Must take
(Continue reading)

Luis Ibanez | 1 Feb 03:49 2008

insight-users@...


Hi Iratxe,

Please write a MetaImage header for your raw image.

Then load the image in SNAP by opening the MetaImage header.

You will find instructions on how to create the MetaImage
header in the following web page:

          http://www.itk.org/HTML/Data.htm

*Writing a MetaImage header for raw data*

One of the formats for which a reader is already available in the 
toolkit is the MetaImage file format. This is a fairly simple yet 
powerful format consisting of a text header and a binary data section. 
The following instructions describe how you can write a MetaImage header 
for the data that you download from the BrainWeb page.

The minimal structure of the MetaImage header is the following:

     NDims = 3
     DimSize = 181 217 181
     ElementType = MET_UCHAR
     ElementSpacing = 1.2   1.2   3.4
     Offset = 13.4  27.5  43.2
     ElementByteOrderMSB = False
     ElementDataFile = brainweb1.raw

(Continue reading)

Defeng WANG | 1 Feb 05:01 2008
Picon

Re: [Insight-developers] bug report on DeformableModelSimplexMesh application

Hi, Luis,

The dataset I used is "sphere.zip", which can be downloaded from http://appsrv.cse.cuhk.edu.hk/~dfwang/tmp/sphere.zip (the size is about 30K). By uncompressing this file, you will see Analyze file of "sphere.hdr" and "sphere.img".

The parameters I used are listed as follows,

Internal Forces (Alpha): 0.8
External Forces (Beta): 0.8
Damping Forces (Gamma): 0.35
Range of Search: 2
Rigidity (Regularizing): 0.5
Number of Iterations: 1

The parameters involved in the gradient calculation of
DeformableModelSimplexMesh are keep unchanged. That is, I did not make any
change to the source code of DeformableModelSimplexMesh.

The steps to reproduce my results are listed as follows,

1. "File/Load File", select "sphere.hdr";
2. left click the center point of the upper left image, then click
"File/Create Mesh", you will see a simplex spherical mesh in the window;
3. "File/Preprocess Image", wait about two minutes to finish the preprocess;
4. Click "Settings/Deform Mesh" about 25 times. Each time after your click,
you will see that the simplex mesh deform. In this process, you can see the
problem I described in my last email.

By the way, if I set the parameter of "Number of Iterations: 1" to 25, and
click "Settings/Deform Mesh" only once. The result I got seems quite
similiar to the initial mesh, and is not like the one got by seting "Number
of Iterations: 1" to 1 and click "Settings/Deform Mesh" 25 times. I think
this is another bug in this program.

If any part in the above desription is not clear enough, please let me know
and I will try to provide more details.

Best wishes,
Defeng


----- Original Message -----
From: "Luis Ibanez" <luis.ibanez-5opLkZggLXlBDgjK7y7TUQ@public.gmane.org>
To: "Defeng WANG" <dfwang-zYqom8TFGCeYwlIiWXL0Uw@public.gmane.org>
Cc: "Leila Baghdadi" <baghdadi-R4eML03dpU13h0zPYw+Emw@public.gmane.org>;
<insight-developers-RyaoCGfWeh4@public.gmane.org>; <insight-users-RyaoCGfWeh4@public.gmane.org>
Sent: Friday, February 01, 2008 10:40 AM
Subject: Re: [Insight-developers] bug report on DeformableModelSimplexMesh
application


>
> Hi Defeng,
>
> Can you please post in a public web site the image that
> you are using as input, and the full set of parameters
> that you are using for running this application ?
>
> Otherwise it is very hard for us to figure out how far
> from the edge of the image you are seeing the final
> contour stopping.
>
> Please give use a very clear sequence of step that we
> could follow to reproduce your experience here.
>
>
>
>   Thanks
>
>
>      Luis
>
>
> -------------------
> Defeng WANG wrote:
>> Hi, Leila,
>>
>> Thanks for your reply. It seems that the parameters in the UI of
>> DeformableModelSimplexMesh are not related to the gradient calculation. I
>> read the source code involved in DeformableModelSimplexMesh. As for the
>> gradient calculation, three filters are used successively as follows,
>>
>>  m_GradientMagnitude->SetInput(m_CastImage->GetOutput() );
>>  m_GradientMagnitude->SetSigma(0.5);
>>
>>  m_SigmoidImage->SetInput( m_GradientMagnitude->GetOutput());
>>  m_SigmoidImage->SetOutputMinimum(0);
>>  m_SigmoidImage->SetOutputMaximum(1);
>>  m_SigmoidImage->SetAlpha(230);
>>  m_SigmoidImage->SetBeta(1300);
>>
>>  m_GradientFilter->SetInput( m_SigmoidImage->GetOutput());
>>  m_GradientFilter->SetSigma( 0.5);
>>
>>
>> I have taken a look at the final gradent image. It seems that it is good
>> enough to describe the
>> edge or boundary of a sphere. So what do you think of this problem
>> existing
>> in this simple example?
>>
>>
>> Look forard to your response.
>>
>> Best wishes,
>> Defeng
>>
>> ----- Original Message ----- From: "Leila Baghdadi"
>> <baghdadi-R4eML03dpU13h0zPYw+Emw@public.gmane.org>
>> To: "Defeng WANG" <dfwang-zYqom8TFGCeYwlIiWXL0Uw@public.gmane.org>
>> Cc: <insight-developers-RyaoCGfWeh4@public.gmane.org>; <insight-users-RyaoCGfWeh4@public.gmane.org>
>> Sent: Thursday, January 31, 2008 10:54 PM
>> Subject: Re: [Insight-developers] bug report on
>> DeformableModelSimplexMesh application
>>
>>
>>> Hi Defeng,
>>>
>>> Yes I have used that code many a times. I am not sure if I understand
>>> what you mean by "it does not converge".
>>>
>>> My understanding of deformable models is
>>>
>>> 1. you must make sure your gradient image is created properly. Use
>>> paraview to look at the vector image
>>>
>>> 2. you must play with the parameters to get the model to converge,
>>>
>>> This is a specific type of deformable models which uses simplex mesh.
>>> I suggest you read about this algorithm first. This is developed based
>>> on the paper by Herve Delingette of INRIA france.
>>>
>>>
>>> Leila
>>>
>>> On Thu, 2008-31-01 at 22:29 +0800, Defeng WANG wrote:
>>>
>>>> Hello, ITK users and developers,
>>>>
>>>> I found that DeformableModelSimplexMesh, provided in
>>>> InsightApplications-3.4.0, does not converge. It seems that the
>>>> deformable mesh will not stop near the boundary of one object to be
>>>> segmented. I tried a very simple volume data set containing a sphere
>>>> only. The initial mesh I used is a spherical simplex mesh inside it.
>>>> However, by increasing the number of iterations, the mesh will
>>>> continue to expand until it reaches outside of the image and the
>>>> program reports error.
>>>>
>>>> Is there anybody tried this program successfully before? Or anybody
>>>> knows how to adjust the parameters properly to get right segmentation?
>>>>
>>>> Best wishes,
>>>> Defeng
>>>> _______________________________________________
>>>> Insight-developers mailing list
>>>> Insight-developers-RyaoCGfWeh4@public.gmane.org
>>>> http://www.itk.org/mailman/listinfo/insight-developers
>>
>>
>> _______________________________________________
>> Insight-developers mailing list
>> Insight-developers-RyaoCGfWeh4@public.gmane.org
>> http://www.itk.org/mailman/listinfo/insight-developers
>>
_______________________________________________
Insight-users mailing list
Insight-users@...
http://www.itk.org/mailman/listinfo/insight-users
Thees, Sebastian | 1 Feb 09:49 2008
Picon

image orientation and registration, current status ?

Dear itk developer,

 

I am a new user of itk - so first at all, thanks for this fantastic library and for providing it open source ! I was really surprised to found such a comprehensive tool for image registration (and segmentation of course) on the web.

 

However, from the medical-image-analysis point of view, there is one thing I could absolutely not understood. Why do you ignore image orientation in image registration ?!?!? It so extremely limits the easy use of the toolkit. Even an option to use the orientation cosines should be present.

 

My question: Is there an example implementation of  the solution outlined in http://public.kitware.com/Bug/view.php?id=5081 by Luis Ibanez, so that I can continue with that for other metrics ? Or does a patch exsists ? Hints, code snippets (i am not too much familiar with itk and template techniques), etc are welcome ...

 

best regards,

Sebastian

 

_______________________________________________
Insight-users mailing list
Insight-users@...
http://www.itk.org/mailman/listinfo/insight-users
J.S.Wijnhout | 1 Feb 10:02 2008
Picon

RE: image orientation and registration, current status ?

Hi,

 

I have faced (or am facing actually) the same problem. I found it espacially confusing that the itk::Image has a GetDirection and GetOrigin method, however these are apparently not used in the TransformContinuousIndexToPhysicalPoint method. If you want that, you should use the itk::OrientedImage. But be warned, in the calculation of the metric the orientation is ignored while computing the gradient. I concluded that it is best to resample your image such that both images, fixed and moving, have the same orientation. It is a bit cumbersome, but it works and the results should not be too different from the results you would get if the registration would properly using the image orientation. Still I would like that orientation and origin are consistently used within ITK (at the very least this behavior should  be properly documented!).

 

best,

Jeroen

 

From: insight-users-bounces+j.s.wijnhout=lumc.nl-RyaoCGfWeh4@public.gmane.org [mailto:insight-users-bounces+j.s.wijnhout=lumc.nl-RyaoCGfWeh4@public.gmane.org] On Behalf Of Thees, Sebastian
Sent: Friday, February 01, 2008 9:50 AM
To: insight-users-RyaoCGfWeh4@public.gmane.org
Subject: [Insight-users] image orientation and registration, current status ?

 

Dear itk developer,

 

I am a new user of itk - so first at all, thanks for this fantastic library and for providing it open source ! I was really surprised to found such a comprehensive tool for image registration (and segmentation of course) on the web.

 

However, from the medical-image-analysis point of view, there is one thing I could absolutely not understood. Why do you ignore image orientation in image registration ?!?!? It so extremely limits the easy use of the toolkit. Even an option to use the orientation cosines should be present.

 

My question: Is there an example implementation of  the solution outlined in http://public.kitware.com/Bug/view.php?id=5081 by Luis Ibanez, so that I can continue with that for other metrics ? Or does a patch exsists ? Hints, code snippets (i am not too much familiar with itk and template techniques), etc are welcome ...

 

best regards,

Sebastian

 

_______________________________________________
Insight-users mailing list
Insight-users@...
http://www.itk.org/mailman/listinfo/insight-users
Suryakant Patidar | 1 Feb 10:09 2008
Picon

QtImageviewer CMake Error


Hi folks,
            This might have real quick solution as I could not find
anything about it on the web.

I am using Visual Studio 2005, Qt 4.3.3, ITK 3.4, CMake 2.4

I was successfully able to build Qt and ITK with Visual Studio
and all the ITK-Applications. Although when I try to produce
Makefiles using CMake for one of the Advanced Applications
: QImageViewer, I encounter the following error from CMake

"CMake Error : Cannot find source file "F:\.....\QtSlicer_SRCS for target "QtSlicer"

Thanking you in advance


===============
Suryakant Patidar
http://skp.co.in
===============
_______________________________________________
Insight-users mailing list
Insight-users@...
http://www.itk.org/mailman/listinfo/insight-users
Stefan Klein | 1 Feb 10:18 2008
Picon

Re: image orientation and registration, current status ?

Hi,

Jeroen: the Origin IS taken into account. The Direction indeed not. I agree 
with it that this should be emphasised somewhere in the documentation. It's 
very easy to make a mistake with that.

Kind regards,
Stefan.

At 10:02 1-2-2008, J.S.Wijnhout@... wrote:

>Hi,
>
>
>
>I have faced (or am facing actually) the same problem. I found it 
>espacially confusing that the itk::Image has a GetDirection and GetOrigin 
>method, however these are apparently not used in the 
>TransformContinuousIndexToPhysicalPoint method. If you want that, you 
>should use the itk::OrientedImage. But be warned, in the calculation of 
>the metric the orientation is ignored while computing the gradient. I 
>concluded that it is best to resample your image such that both images, 
>fixed and moving, have the same orientation. It is a bit cumbersome, but 
>it works and the results should not be too different from the results you 
>would get if the registration would properly using the image orientation. 
>Still I would like that orientation and origin are consistently used 
>within ITK (at the very least this behavior should  be properly documented!).
>
>
>
>best,
>
>Jeroen
>
>
>
>From: insight-users-bounces+j.s.wijnhout=lumc.nl@... 
>[mailto:insight-users-bounces+j.s.wijnhout=lumc.nl@...] On Behalf
Of 
>Thees, Sebastian
>Sent: Friday, February 01, 2008 9:50 AM
>To: insight-users@...
>Subject: [Insight-users] image orientation and registration, current status ?
>
>
>
>Dear itk developer,
>
>
>
>I am a new user of itk - so first at all, thanks for this fantastic 
>library and for providing it open source ! I was really surprised to found 
>such a comprehensive tool for image registration (and segmentation of 
>course) on the web.
>
>
>
>However, from the medical-image-analysis point of view, there is one thing 
>I could absolutely not understood. Why do you ignore image orientation in 
>image registration ?!?!? It so extremely limits the easy use of the 
>toolkit. Even an option to use the orientation cosines should be present.
>
>
>
>My question: Is there an example implementation of  the solution outlined 
>in http://public.kitware.com/Bug/view.php?id=5081 by Luis Ibanez, so that 
>I can continue with that for other metrics ? Or does a patch exsists ? 
>Hints, code snippets (i am not too much familiar with itk and template 
>techniques), etc are welcome ...
>
>
>
>best regards,
>
>Sebastian
>
>
>_______________________________________________
>Insight-users mailing list
>Insight-users@...
>http://www.itk.org/mailman/listinfo/insight-users
Stefan Klein | 1 Feb 10:23 2008
Picon

methods in Image to ImageBase

Hi,

There seems to be some methods in itk::Image which could be moved to itk::ImageBase, since they do not depend on the pixel type:

TransformPhysicalPointToContinuousIndex()
TransformPhysicalPointToIndex()
TransformContinuousIndexToPhysicalPoint()
TransformIndexToPhysicalPoint()
void SetRegions(RegionType region)
void SetRegions(SizeType size)

Is there any reason for keeping them in itk::Image?
In some situations it could be useful to have the methods available without having to specify the pixel type.

Kind regards,
Stefan.

_______________________________________________
Insight-users mailing list
Insight-users@...
http://www.itk.org/mailman/listinfo/insight-users
Bill Lorensen | 1 Feb 14:17 2008
Picon

Re: image orientation and registration, current status ?

The gradient problem is being corrected for itkOrientedImage. See:
 
If you need to take into account orientation, you should use itkOrientedImage. Another option is to use itkImage and reorient the series with itkOrientImageFilter so that both series have the same orientation.
 
Bill
On Fri, Feb 1, 2008 at 4:18 AM, Stefan Klein <stefan-iDu9vKRet71mR6Xm/wNWPw@public.gmane.org> wrote:
Hi,

Jeroen: the Origin IS taken into account. The Direction indeed not. I agree
with it that this should be emphasised somewhere in the documentation. It's
very easy to make a mistake with that.

Kind regards,
Stefan.



At 10:02 1-2-2008, J.S.Wijnhout-CvNLE8ToD7g@public.gmane.org wrote:

>Hi,
>
>
>
>I have faced (or am facing actually) the same problem. I found it
>espacially confusing that the itk::Image has a GetDirection and GetOrigin
>method, however these are apparently not used in the
>TransformContinuousIndexToPhysicalPoint method. If you want that, you
>should use the itk::OrientedImage. But be warned, in the calculation of
>the metric the orientation is ignored while computing the gradient. I
>concluded that it is best to resample your image such that both images,
>fixed and moving, have the same orientation. It is a bit cumbersome, but
>it works and the results should not be too different from the results you
>would get if the registration would properly using the image orientation.
>Still I would like that orientation and origin are consistently used
>within ITK (at the very least this behavior should  be properly documented!).
>
>
>
>best,
>
>Jeroen
>
>
>
>From: insight-users-bounces+j.s.wijnhout=lumc.nl-RyaoCGfWeh4@public.gmane.org
>[mailto:insight-users-bounces+j.s.wijnhout=lumc.nl-RyaoCGfWeh4@public.gmane.org] On Behalf Of
>Thees, Sebastian
>Sent: Friday, February 01, 2008 9:50 AM
>To: insight-users-RyaoCGfWeh4@public.gmane.org
>Subject: [Insight-users] image orientation and registration, current status ?
>
>
>
>Dear itk developer,
>
>
>
>I am a new user of itk - so first at all, thanks for this fantastic
>library and for providing it open source ! I was really surprised to found
>such a comprehensive tool for image registration (and segmentation of
>course) on the web.
>
>
>
>However, from the medical-image-analysis point of view, there is one thing
>I could absolutely not understood. Why do you ignore image orientation in
>image registration ?!?!? It so extremely limits the easy use of the
>toolkit. Even an option to use the orientation cosines should be present.
>
>
>
>My question: Is there an example implementation of  the solution outlined
>in http://public.kitware.com/Bug/view.php?id=5081 by Luis Ibanez, so that
>I can continue with that for other metrics ? Or does a patch exsists ?
>Hints, code snippets (i am not too much familiar with itk and template
>techniques), etc are welcome ...
>
>
>
>best regards,
>
>Sebastian
>
>
>_______________________________________________
>Insight-users mailing list
>Insight-users-RyaoCGfWeh4@public.gmane.org
>http://www.itk.org/mailman/listinfo/insight-users


_______________________________________________
Insight-users mailing list
Insight-users-RyaoCGfWeh4@public.gmane.org
http://www.itk.org/mailman/listinfo/insight-users

_______________________________________________
Insight-users mailing list
Insight-users@...
http://www.itk.org/mailman/listinfo/insight-users

Gmane