[Insight-users] Deformable registration using Multilevel B-Spline
Ni Dong
dni at cse.cuhk.edu.hk
Sun Jul 6 23:07:21 EDT 2008
Dear Luis and others,
Thank you very much for your good suggestion and kind help. I will try and
test the code provided by Nick. Thanks again.
Best Regards
Ni Dong
Computer Science and Engineering Dept., The Chinese University of Hong Kong
----- Original Message -----
From: <insight-users-request at itk.org>
To: <insight-users at itk.org>
Sent: Sunday, July 06, 2008 10:47 PM
Subject: Insight-users Digest, Vol 51, Issue 19
> Send Insight-users mailing list submissions to
> insight-users at itk.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.itk.org/mailman/listinfo/insight-users
> or, via email, send a message with subject or body 'help' to
> insight-users-request at itk.org
>
> You can reach the person managing the list at
> insight-users-owner at itk.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Insight-users digest..."
>
>
> Today's Topics:
>
> 1. Re: Deformable registration using Multilevel B-Spline
> (Luis Ibanez)
> 2. Re: Kappa Sigma Clipping typedef error (Luis Ibanez)
> 3. Re: Internal pixel type (Luis Ibanez)
> 4. Re: crashes N-D Linear Time Exact Signed Euclidean Distance
> Transform (Ga?tan Lehmann)
> 5. LevelSetFunction / CurvesLevelSetFunction and minimal
> curvature (Michael Schmidt)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 05 Jul 2008 12:07:07 -0400
> From: Luis Ibanez <luis.ibanez at kitware.com>
> Subject: Re: [Insight-users] Deformable registration using Multilevel
> B-Spline
> To: Ni Dong <dni at cse.cuhk.edu.hk>
> Cc: insight-users at itk.org
> Message-ID: <486F9C2B.2020803 at kitware.com>
> Content-Type: text/plain; charset=GB2312
>
>
> Hi Ni,
>
> The class that Nick Tustison contributed to the Insight Journal paper
>
> http://hdl.handle.net/1926/140
>
> is now available in the Insgight/Code/Review directory.
>
>
> Please rerun CMake, go to the Advanced variables, and enable
>
> ITK_USE_REVIEW
>
> This will make the class available to you.
>
>
> Please give it a try and let us know if you find any problems.
>
>
> Thanks
>
>
> Luis
>
>
> -------------------
> Ni Dong wrote:
>> Dear all,
>>
>> My goal is to deformably register two volumes based on two sets of
>> already correlated landmarks. These landmarks are irregularly localized
>> in the volume. Multilelvel B-Splines algorithm by Lee(" Scattered Data
>> Interpolation with Multilevel B-Splines") can get a smooth interpolation
>> for scattered data. I have searched the ITK files and examples. But I
>> just can find basic B-spline interpolation or transform, which commonly
>> need the regular control point.
>>
>> Do you have any idea about the implementation of multilevel B-Splines?
>> Thank you very much.
>>
>>
>> Best Regards
>> Ni Dong
>> Computer Science and Engineering Dept., The Chinese University of Hong
>> Kong
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users at itk.org
>> http://www.itk.org/mailman/listinfo/insight-users
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 05 Jul 2008 13:25:51 -0400
> From: Luis Ibanez <luis.ibanez at kitware.com>
> Subject: Re: [Insight-users] Kappa Sigma Clipping typedef error
> To: Oleksandr Dzyubak <adzyubak at gmail.com>
> Cc: Insight-users at itk.org
> Message-ID: <486FAE9F.7040407 at kitware.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
> Hi Olkesandr,
>
> This classes contributeed by Gaetan Lehmann have now been included
> in the Insight/Code/Review directory in the main CVS trunk of ITK.
>
> If you want to try the new versions, please do the following:
>
> 1) Update your cvs Checkout
> 2) Rerun CMake on the binary directory of ITK
> 3) go to Advanced
> 4) enable the variable ITK_USE_REVIEW
> 5) configure and generate with CMake
>
>
> You will find a test under
>
>
> Insight/Testing/Code/Review
>
>
> that illustrates how you can set up the type of the output image.
>
>
>
> Please give it a try and let us know if you find any problems,
>
>
> Thanks
>
>
> Luis
>
>
> ------------------------
> Oleksandr Dzyubak wrote:
>> Dear ITKers,
>>
>> Some while ago I decided to test the Kappa Sigma Clipping algorithm which
>> I downloaded from the Insight-journal web page.
>>
>> http://insight-journal.org/midas/handle.php?handle=1926/367
>>
>> In the paper which comes with an archive there is an explanation
>> how to use it and, in particular, the lines describing the types of
>> input/output images.
>>
>> ***********Begin code snippet*********
>> const int dim = 3;
>>
>> typedef unsigned char PType;
>> typedef itk::Image< PType, dim > IType;
>> typedef itk::ImageFileReader< IType > ReaderType;
>>
>> typedef itk::ImageFileWriter< IType > WriterType;
>> ***********End code snippet*********
>>
>> Of cousre, that is quite natural to keep an output segmented binary
>> image as an unsigned char type
>> but what about an input image. In my case I have input images in a
>> signed short format and
>> if I change the typedef for the input to signed short, I get an error
>> below.
>>
>> ******* Begin Error ************
>>
>> dzyubak at debian: /BUILD$ make
>> Scanning dependencies of target check
>> [100%] Building CXX object CMakeFiles/check.dir/check.cxx.o
>> /mnt/Public/ITK_Test/Kappa_Sigma_Clipping/Src/check.cxx: In function
>> 'int main(int, char**)':
>> /mnt/Public/ITK_Test/Kappa_Sigma_Clipping/Src/check.cxx:42: error: no
>> matching function for call to 'itk::ImageFileWriter<itk::Image<unsigned
>> char, 3u> >::SetInput(itk::Image<short int, 3u>*)'
>> /usr/local/include/InsightToolkit/IO/itkImageFileWriter.txx:56: note:
>> candidates are: void itk::ImageFileWriter<TInputImage>::SetInput(const
>> TInputImage*) [with TInputImage = itk::Image<unsigned char, 3u>]
>> make[2]: *** [CMakeFiles/check.dir/check.cxx.o] Error 1
>> make[1]: *** [CMakeFiles/check.dir/all] Error 2
>> make: *** [all] Error 2
>> dzyubak at debian: /BUILD$
>>
>> ******* End Error ************
>>
>>
>> Does this mean that the algorithm can only work if the input type
>> matches the output?
>> If it does, then I have to extend the pipeline so to include the
>> rescaler, right?
>>
>> I would appreciate any help on this matter.
>>
>> Thanks,
>>
>> Alex
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users at itk.org
>> http://www.itk.org/mailman/listinfo/insight-users
>>
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 05 Jul 2008 13:30:15 -0400
> From: Luis Ibanez <luis.ibanez at kitware.com>
> Subject: Re: [Insight-users] Internal pixel type
> To: Paolo <img-registration at live.com>
> Cc: insight-users at itk.org
> Message-ID: <486FAFA7.60002 at kitware.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
> Hi Paolo,
>
> Thanks for you precise question.
>
> When you use the NormalizedCorrelation metric, you don't need to
> convert the images to float. It should be fine to keep your images
> as unsigned short, since this metric internally uses the NumericTraits
> in order to find the types that appropriate for accumulating
> and for performing floating point operations.
>
>
> Regards,
>
>
> Luis
>
>
> ---------------
> Paolo wrote:
>> Dear all,
>> I have to registrate two stacks of 16-bit gray level images stacks.
>> Accordingly, I choosed an unsigned short pixel type.
>> I would like to use the normalized correlation metric as metric for my
>> registration, and I was wondering if I would have to convert to a float
>> internal pixel type, like in example 8.5.1 which use mutual information ?
>> Paolo
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users at itk.org
>> http://www.itk.org/mailman/listinfo/insight-users
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 6 Jul 2008 10:17:34 +0200
> From: Ga?tan Lehmann <gaetan.lehmann at jouy.inra.fr>
> Subject: Re: [Insight-users] crashes N-D Linear Time Exact Signed
> Euclidean Distance Transform
> To: Oleksandr Dzyubak <adzyubak at gmail.com>
> Cc: "insight-users at itk.org" <insight-users at itk.org>, kent williams
> <norman-k-williams at uiowa.edu>
> Message-ID: <49D25E50-FA28-422C-B0A9-F64DC323F5BF at jouy.inra.fr>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed";
> DelSp="yes"
>
> Hi,
>
> I finally fixed that bug. It was caused by a wrong boundary test.
> I have commited the fix both in ITK cvs and in the watershed
> repository (for the multithreaded version).
>
> Please let us know if it works for you.
>
> Thanks for the report, and for your patience.
>
> Regards,
>
> Ga?tan
>
>
> Le 30 juin 08 ? 17:18, Oleksandr Dzyubak a ?crit :
>
>> Hi Ga?tan,
>>
>> Please let me know if any progress.
>>
>> Thanks for your help,
>> Alex
>>
>> Ga?tan Lehmann wrote:
>>>
>>> Hi Alex,
>>>
>>> I have reproduced your problem and I'm searching what is causing it
>>> currently.
>>> I'll let you know if I found the problem.
>>>
>>> Regards,
>>>
>>> Ga?tan
>>>
>>> Le 19 juin 08 ? 23:24, Oleksandr Dzyubak a ?crit :
>>>
>>>> Hi Ga?tan,
>>>>
>>>> Thanks for your help.
>>>> I am still getting the error below.
>>>>
>>>> ******** Begin Error********
>>>> dzyubak at debian: /Lehmann$ ./SignedMaurerDistanceMapImageFilterTest
>>>> smallDataset.hdr out.hdr
>>>> SignedMaurerDistanceMapImageFilterTest: /usr/local/include/
>>>> InsightToolkit/Utilities/vxl/core/vnl/vnl_vector.h:168: T&
>>>> vnl_vector<T>::operator()(unsigned int) [with T = double]:
>>>> Assertion `i<size()' failed.
>>>> Aborted
>>>>
>>>> *******End Error*******
>>>>
>>>> And I still want to make it work. In an attachment you can find
>>>> the archived source tree dm.tar.gz
>>>> which I downloaded from the link you provided.
>>>> To the directory I also added the images I tried to work with.
>>>> I am using Debian Etch with gcc "version 4.1.2 20061115
>>>> (prerelease) (Debian 4.1.1-21)",
>>>> "cmake version 2.6-patch 0", and "Insight_CVS_Jun_03_2008.tar.gz".
>>>>
>>>> I would be more than happy if you could give me a hint on how to
>>>> proceed.
>>>>
>>>> Alex
>>>>
>>>>
>>>> Ga?tan Lehmann wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm afraid I can't reproduce any of the problems you have.
>>>>> Can you send me your source tree? You seem to have put everything
>>>>> in a ?Lehmann? directory ? maybe with it, I would be able to
>>>>> reproduce them.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Ga?tan
>>>>>
>>>>>
>>>>>
>>>>> Le 3 juin 08 ? 21:36, Oleksandr Dzyubak a ?crit :
>>>>>
>>>>>> Hi Ga?tan,
>>>>>>
>>>>>> Thanks for your help.
>>>>>>
>>>>>> I have rebuilt ITK to include all the changes made recently.
>>>>>> Following the link you provided, I downloaded your version of
>>>>>> the filter.
>>>>>> During the compilation I got some warnings but was able to get
>>>>>> an executable (see below).
>>>>>> However when I ran the executable, the program crashed again
>>>>>> with a different error message though (before it was malloc()
>>>>>> from AnalyzeIO).
>>>>>>
>>>>>> **************** Begin Error Message *********
>>>>>> dzyubak at debian: /Lehmann$ ./
>>>>>> SignedMaurerDistanceMapImageFilterTest SquareBinary201.hdr
>>>>>> test.hdr
>>>>>> SignedMaurerDistanceMapImageFilterTest: /usr/local/include/
>>>>>> InsightToolkit/Utilities/vxl/core/vnl/vnl_vector.h:168: T&
>>>>>> vnl_vector<T>::operator()(unsigned int) [with T = double]:
>>>>>> Assertion `i<size()' failed.
>>>>>> Aborted
>>>>>> ************** End Error Message ********
>>>>>>
>>>>>>
>>>>>> *********** Begin Compilation Warnings ****
>>>>>> dzyubak at debian: /BUILD$ make
>>>>>> Scanning dependencies of target
>>>>>> SignedMaurerDistanceMapImageFilterTest
>>>>>> [100%] Building CXX object CMakeFiles/
>>>>>> SignedMaurerDistanceMapImageFilterTest.dir/
>>>>>> itkSignedMaurerDistanceMapImageFilterTest.cxx.o
>>>>>> /home/dzyubak/Test/N-
>>>>>> D_Linear_Time_Exact_Signed_Euclidean_Distance_Transform/Lehmann/
>>>>>> itkBinaryBorderImageFilter.txx: In member function 'void
>>>>>> itk::BinaryBorderImageFilter<TInputImage,
>>>>>> TOutputImage
>>>>>> >
>>>>>> ::CompareLines
>>>>>> (std::vector<itk::BinaryBorderImageFilter<TInputImage,
>>>>>> TOutputImage>::runLength,
>>>>>> std::allocator<itk::BinaryBorderImageFilter<TInputImage,
>>>>>> TOutputImage>::runLength> >&, const
>>>>>> std::vector<itk::BinaryBorderImageFilter<TInputImage,
>>>>>> TOutputImage>::runLength,
>>>>>> std::allocator<itk::BinaryBorderImageFilter<TInputImage,
>>>>>> TOutputImage>::runLength> >&) [with TInputImage =
>>>>>> itk::Image<double, 3u>, TOutputImage = itk::Image<double, 3u>]':
>>>>>> /home/dzyubak/Test/N-
>>>>>> D_Linear_Time_Exact_Signed_Euclidean_Distance_Transform/Lehmann/
>>>>>> itkBinaryBorderImageFilter.txx:250: instantiated from 'void
>>>>>> itk::BinaryBorderImageFilter<TInputImage,
>>>>>> TOutputImage>::ThreadedGenerateData(const typename
>>>>>> TOutputImage::RegionType&, int) [with TInputImage =
>>>>>> itk::Image<double, 3u>, TOutputImage = itk::Image<double, 3u>]'
>>>>>> /home/dzyubak/Test/N-
>>>>>> D_Linear_Time_Exact_Signed_Euclidean_Distance_Transform/Lehmann/
>>>>>> itkSignedMaurerDistanceMapImageFilterTest.cxx:69: instantiated
>>>>>> from here
>>>>>> /home/dzyubak/Test/N-
>>>>>> D_Linear_Time_Exact_Signed_Euclidean_Distance_Transform/Lehmann/
>>>>>> itkBinaryBorderImageFilter.txx:405: warning: unused variable 'ee1'
>>>>>> Linking CXX executable SignedMaurerDistanceMapImageFilterTest
>>>>>> [100%] Built target SignedMaurerDistanceMapImageFilterTest
>>>>>>
>>>>>> ********* End Compilation Warnings *******
>>>>>>
>>>>>> Ga?tan Lehmann wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> The SignedMaurerDistanceMapImageFilter won't work when the
>>>>>>> input image is 2D but the filter is 3D ? the size is 1 on one
>>>>>>> dimension.
>>>>>>> I have fixed that in an external repository, with some other
>>>>>>> changes to
>>>>>>>
>>>>>>> a. avoid spending so much time in the border detection
>>>>>>> b. multithread it
>>>>>>> c. make it work with any sizes on all the dimensions
>>>>>>>
>>>>>>> That work is available at
>>>>>>>
>>>>>>> http://voxel.jouy.inra.fr/darcs/contrib-itk/watershed
>>>>>>>
>>>>>>> You'll have to take the classes
>>>>>>> SignedMaurerDistanceMapImageFilter and BinaryBorderImageFilter.
>>>>>>>
>>>>>>> I'll try to put b. and c. in ITK before the next release.
>>>>>>> a. has to pass through the process of the peer review in the
>>>>>>> insight journal before being integrated in ITK.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Ga?tan
>>>>>>>
>>>>>>>
>>>>>>> Le 2 juin 08 ? 21:18, Oleksandr Dzyubak a ?crit :
>>>>>>>
>>>>>>>> Hi Bill,
>>>>>>>>
>>>>>>>> Now I am a bit confused by what you are saying.
>>>>>>>>
>>>>>>>> 1) You say that it works for 3D but does not for 2D.
>>>>>>>> I cannot understand that since 2D dimensionality is a
>>>>>>>> particular case of 3D.
>>>>>>>> Lets say 2D is a 3D with just one z-component. From my
>>>>>>>> prospective, it has to work
>>>>>>>> for 2D if it does for 3D. Opposite is not necessary true though.
>>>>>>>>
>>>>>>>> 2) If I comment the writer out, the program still crashes with
>>>>>>>> the same error.
>>>>>>>>
>>>>>>>> 3) All my images are in the Analyze75 format
>>>>>>>> and while using the other ITK filters I have not had any
>>>>>>>> problems so far.
>>>>>>>> (I mean with ITK Analyze reader/writer, except orientations,
>>>>>>>> of course).
>>>>>>>>
>>>>>>>> Do you mean that even though my executables did not complain,
>>>>>>>> the results I was getting could be wrong since I used ITK
>>>>>>>> Analyze reader/writer?
>>>>>>>>
>>>>>>>> If so, in what fashion could the final results be wrong?
>>>>>>>>
>>>>>>>> Is it error-prone for some particular platform/compiler
>>>>>>>> (Linux Debian with gcc 4.1.2 in my case) or it is more general
>>>>>>>> case?
>>>>>>>>
>>>>>>>> How severe does it affect the final results?
>>>>>>>>
>>>>>>>> Thanks for your help,
>>>>>>>>
>>>>>>>> Alex
>>>>>>>>
>>>>>>>>
>>>>>>>> Bill Lorensen wrote:
>>>>>>>>> Oleksandr,
>>>>>>>>>
>>>>>>>>> There are some known problems in the ITK Analyze reader/
>>>>>>>>> writer when
>>>>>>>>> the images are 2D and not 3D. I think the read part has been
>>>>>>>>> fixed
>>>>>>>>> recently. However, the write part still has problems. If your
>>>>>>>>> images
>>>>>>>>> are 3D, then all should be fine. Until we fix this 2D Analyze
>>>>>>>>> image
>>>>>>>>> problem, I'm afraid you cannot run the filters.
>>>>>>>>>
>>>>>>>>> Bill
>>>>>>>>>
>>>>>>>>> On Sun, Jun 1, 2008 at 1:07 PM, Oleksandr Dzyubak
>>>>>>>>> <adzyubak at gmail.com
>>>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>>> Hi Bill,
>>>>>>>>>>
>>>>>>>>>> This time I try to be more accurate.
>>>>>>>>>>
>>>>>>>>>> 1) I downloaded ITK from CVS, compiled with the RelWithDeb
>>>>>>>>>> flag, and
>>>>>>>>>> installed on my Linux box.
>>>>>>>>>> 2) I have Debian Etch with gcc 4.1.2
>>>>>>>>>> 3) The example itkSignedMaurerDistanceMapImageFilterTest.cxx
>>>>>>>>>> was taken
>>>>>>>>>> from ITK distro and not from IJ.
>>>>>>>>>>
>>>>>>>>>> Insight/Testing/Code/BasicFilters/
>>>>>>>>>> itkSignedMaurerDistanceMapImageFilterTest.cxx
>>>>>>>>>>
>>>>>>>>>> 4) Example was compiled in debug mode.
>>>>>>>>>> 5) As you advised, the example was run on both
>>>>>>>>>> SquareBinary201.png and
>>>>>>>>>> SquareBinary201.hdr.
>>>>>>>>>>
>>>>>>>>>> Results.
>>>>>>>>>> As you predicted, the example has processed the *.png image
>>>>>>>>>> taken from ITK
>>>>>>>>>> distro resulting
>>>>>>>>>> in a nice looking map.
>>>>>>>>>>
>>>>>>>>>> dzyubak at debian: /BUILD$ ./
>>>>>>>>>> SignedMaurerDistanceMapImageFilterTest
>>>>>>>>>> SquareBinary201.png test_png.hdr
>>>>>>>>>> WARNING: In /root/Insight/Code/IO/itkAnalyzeImageIO.cxx,
>>>>>>>>>> line 1280
>>>>>>>>>> AnalyzeImageIO (0x8169a98): ERROR: Analyze 7.5 File Format
>>>>>>>>>> Only Allows RPI,
>>>>>>>>>> PIR, and RIP Orientation
>>>>>>>>>>
>>>>>>>>>> However when I tried to run it on a real stuff (all my
>>>>>>>>>> images in Analyze75
>>>>>>>>>> format), the same image but
>>>>>>>>>> taken from IJ archive (SquareBinary201.hdr), it crashes.
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Insight-users mailing list
>>>>>>>> Insight-users at itk.org
>>>>>>>> http://www.itk.org/mailman/listinfo/insight-users
>>>>>>>
>>>>>>> --Ga?tan Lehmann
>>>>>>> Biologie du D?veloppement et de la Reproduction
>>>>>>> INRA de Jouy-en-Josas (France)
>>>>>>> tel: +33 1 34 65 29 66 fax: 01 34 65 29 09
>>>>>>> http://voxel.jouy.inra.fr http://www.mandriva.org
>>>>>>> http://www.itk.org http://www.clavier-dvorak.org
>>>>>>>
>>>>>>
>>>>>
>>>>> --Ga?tan Lehmann
>>>>> Biologie du D?veloppement et de la Reproduction
>>>>> INRA de Jouy-en-Josas (France)
>>>>> tel: +33 1 34 65 29 66 fax: 01 34 65 29 09
>>>>> http://voxel.jouy.inra.fr http://www.mandriva.org
>>>>> http://www.itk.org http://www.clavier-dvorak.org
>>>>>
>>>>
>>>> <dm.tar.gz>
>>>
>>> --Ga?tan Lehmann
>>> Biologie du D?veloppement et de la Reproduction
>>> INRA de Jouy-en-Josas (France)
>>> tel: +33 1 34 65 29 66 fax: 01 34 65 29 09
>>> http://voxel.jouy.inra.fr http://www.mandriva.org
>>> http://www.itk.org http://www.clavier-dvorak.org
>>>
>>
>
> --
> Ga?tan Lehmann
> Biologie du D?veloppement et de la Reproduction
> INRA de Jouy-en-Josas (France)
> tel: +33 1 34 65 29 66 fax: 01 34 65 29 09
> http://voxel.jouy.inra.fr http://www.mandriva.org
> http://www.itk.org http://www.clavier-dvorak.org
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: PGP.sig
> Type: application/pgp-signature
> Size: 186 bytes
> Desc: This is a digitally signed message part
> URL:
> <http://www.itk.org/pipermail/insight-users/attachments/20080706/a48f3c8d/attachment-0001.pgp>
>
> ------------------------------
>
> Message: 5
> Date: Sun, 6 Jul 2008 15:17:24 +0200
> From: "Michael Schmidt" <michael at familie-schmidt.com>
> Subject: [Insight-users] LevelSetFunction / CurvesLevelSetFunction and
> minimal curvature
> To: <insight-users at itk.org>
> Message-ID: <8D987C57E9364068A08C0BAE2A59E0FF at thinkpadx61s>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi there,
>
> I think there is a small mistake in the implementation of the
> CurvesLevelSetFunction or the LevelSetFunction respectively, regarding
> computation of minimal curvature. Although I currently don't use this
> feature, I think I might have found a litte mistake in the implementation,
> and want to share it with you so it can be fixed or somebody can correct
> me.
>
> As far as I understand the implementation of ComputeMinimalCurvature, this
> function returns the principal curvature term that has minimal *absolute*
> value.
>
> I don't know, if this function is used for other LevelSet-Filters as well,
> but at least in the context of CurvesLevelSetFunction this doesn't make
> sense in my opinion. In this filter the regularization force is defined on
> the minimal curvature and supposed to "smoothen" small tubelike shapes
> only along their centerline, not it's crossection. Now, given ITK's
> definitions of inside and outside, the principal curvature along the cross
> section of the tube will *always* be positive. Accordingly, negative
> principal curvature can only result from curvature of the centerline and
> should always be used for regularization.
>
> Now, in most cases this might not be a problem, but suppose a small tube
> with a very sharp corner, where the negative curvature on the "inner" side
> of the corner has a higher amount than the curvature of the crosssection.
> Then the regularization force is computed using the curvature of the cross
> section and driving the surface in the wrong direction, resulting possibly
> in a cut in the tube. Especially look at Figure 6 in the work (in the
> version I got at http://certis.enpc.fr/publications/papers/01mia.pdf).
> There the regularization quickly smoothens the sharp corners with negative
> curvature. Has anybody tested the ITK-Filter on similar data? In their
> work the authors only refer to taking "the smaller nonzero eigenvalue",
> which probably can be interpreted in both ways, juding by absolute values
> or not.
>
> Regards, Michael
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://www.itk.org/pipermail/insight-users/attachments/20080706/589b7a9d/attachment.htm>
>
> ------------------------------
>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>
>
> End of Insight-users Digest, Vol 51, Issue 19
> *********************************************
More information about the Insight-users
mailing list