[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