[ITK] Redudancy in LevelSetBase hierarchy

Johnson, Hans J hans-johnson at uiowa.edu
Wed Jun 29 17:24:32 EDT 2016


I did not work on level sets.

Sent from my iPhone

> On Jun 29, 2016, at 11:35 AM, Matt McCormick <matt.mccormick at kitware.com> wrote:
> 
> Hi David,
> 
> Arnaud and Kishore are LevelSetsv4 experts, although they may or may
> not have time to work on the code further.  If patches are submitted
> to Gerrit for review, please add them as reviewers so they have an
> opportunity to review the changes.
> 
> Thanks,
> Matt
> 
> On Wed, Jun 22, 2016 at 10:57 AM, David S. Paik (Elucid Bioimaging)
> <david.paik at elucidbio.com> wrote:
>> 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> 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> 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
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Community mailing list
>> Community at itk.org
>> http://public.kitware.com/mailman/listinfo/community
>> 


More information about the Community mailing list