[ITK] Redudancy in LevelSetBase hierarchy

[Dženan Zukić]

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> 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
> http://public.kitware.com/mailman/listinfo/community
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/community/attachments/20160622/a914d049/attachment.html>