[ITK] Redudancy in LevelSetBase hierarchy

David S. Paik (Elucid Bioimaging) david.paik at elucidbio.com
Wed Jun 22 10:57:15 EDT 2016


Dženan,

  Thank you for your response!  Although it really is more the level set segmentation framework for V4 that this applies to.  If either of you can point me to someone who’s done work on that, it’d be appreciated.

Thanks!
David


On Jun 22, 2016, at 3:30 AM, Dženan Zukić <dzenanz at gmail.com<mailto:dzenanz at gmail.com>> wrote:

Hans, I think you were involved with refactoring registration framework for V4. Can you pitch in?

Regards

On Sat, Jun 11, 2016 at 1:24 AM, David S. Paik (Elucid Bioimaging) <david.paik at elucidbio.com<mailto:david.paik at elucidbio.com>> wrote:
I am going through the level set v4 classes in 4.9.1 and I noticed a few things.

In itk::LevelSetBase

-  EvaluateMeanCurvature( const InputType& iP ) is declared pure virtual (.h line 75) but a definition is provided (.hxx line 88).  While syntactically permissible, this seems more likely an oversight rather than an intentional design. (see below)

- Both versions of EvaluateLaplacian are pure virtual even though they could be computed at this point in the hierarchy as the trace of the Hessian matrix.  This is analogous to how EvaluateGradientNorm is calculated even though EvaluateGradient is still pure virtual in this class. (see below)


In itk::DiscreteLevelSetImage

- EvaluateLaplacian (both versions) do their own redundant calculation of second derivatives even though they may have already been calculated in the Hessian matrix.  There’s probably a design tradeoff between redundantly computing the Laplacian (as it is now) vs. Laplacian triggering a full Hessian computation even if the off diagonal elements of the Hessian are not used.  One possibility is to check to see if Hessian has been computed and if so use it but not trigger a full Hessian computation.

- EvaluateMeanCurvature (both versions) override itk::LevelSetBase’s version but they appear to be exactly the same.  The virtual function calls should work from the base class.  Not a bug but this seems to be an unnecessary redundancy.  Am I missing something?


David

_______________________________________________
Community mailing list
Community at itk.org<mailto:Community at itk.org>
http://public.kitware.com/mailman/listinfo/community


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/community/attachments/20160622/35c4b2eb/attachment-0001.html>


More information about the Community mailing list