[Insight-developers] modularization and FastMarching filters (on itk:Image and itk::QuadEdgeMesh) ?

[Luis Ibanez]

Well, strictly speaking Level Set classes do not depend
on Fast Marching, and Fast Marching classes do not
depend on the Level Sets.

They are part of two independent ITK class hierarchies.

Their tests, on the other hand,
may have crossed dependencies.

--

The confusion probably arises because in the Examples
we tend to use FastMarching filters to initialize LevelSet
filters.


    Luis


-----------------------------------------------------------------------
On Fri, Apr 1, 2011 at 5:39 PM, Xiaoxiao Liu <xiaoxiao.liu at kitware.com> wrote:
> Hi Jim,
> Hmm, by "If  level sets methods will be initiated from the fast marching
> algorithms, it seems to be reasonable to make ITK-LevelSets depend on
> ITK-FastMarching",
> I meant  LevelSets could depend on FastMarching.
> Sorry if I caused confusion.
>
> On Fri, Apr 1, 2011 at 4:55 PM, Jim Miller <millerjv at ge.com> wrote:
>>
>> Xiaoxiao I think you got that backwards. FastMarching does not depend on
>> LevelSets. But LevelSets "can" depend on FastMarching.
>>
>> On Apr 1, 2011, at 10:55 AM, Xiaoxiao Liu wrote:
>>
>> If  level sets methods will be initiated from the fast marching
>> algorithms, it seems to be reasonable to make ITK-LevelSets depend on
>> ITK-FastMarching.  And all the common headers could  go to ITK-FastMarching.
>> After your refactorization, if you decide not to have the backward
>> compatibility, we could put the v3 version in ITK-Deprecated module.
>> Otherwise it could be a seperate module that will continue to be  available
>> for users.
>>
>> On Fri, Apr 1, 2011 at 9:45 AM, Arnaud GELAS
>> <arnaud_gelas at hms.harvard.edu> wrote:
>>>
>>> Hi Xiaoxiao,
>>> On Mar 31, 2011, at 11:24 PM, Xiaoxiao Liu wrote:
>>>
>>> Hi Arnaud,
>>>   Conceptually, one  "ITK-FastMarching" under the group "Filtering" makes
>>> sense to me.
>>>   Is this module still going to be  depending on ITK-LevelSets (still
>>> requires some common headers) after  moving it out of LevelSets module? Or
>>> it's relatively stand-alone?
>>>
>>> ITK-LevelSets may depend on ITK-FastMarching module (optional
>>> dependency), but the opposite is not true. Let me explain, with the current
>>> framework all level sets needs the fast marching procedure to reinitialize
>>> the level sets.
>>> We propose to break this strong dependency... Fast marching methods would
>>> become one of the potential methods one can use to reinitialize level sets.
>>> There may be common traits with ITK-FastMarching and ITK-Module where all
>>> common types are defined.
>>>
>>>   It also depends on the size of the module to decide whether it should
>>> be further divided by two,  and  whether the Image one and the QuadEdgeMesh
>>> one share a lot of common files.
>>>   If there are not many classes in each category (say less than 20 each),
>>> and they share a lot of common classes, it makes more sense to be in one
>>> unit.
>>>
>>> Base classes are the same and the difference in terms of number of
>>> classes is not that much (1 additional class for QuadEdgeMesh). So one unit
>>> may be better then!
>>>
>>>
>>>   Let me know if I could be more help.
>>>   Thanks.
>>>
>>>
>>> Where could we move the (future) common header levelsets / fastmarching ?
>>> I may also need some guidance in the creation of a new module
>>> ITK-FastMarching, could you guide me on that one?
>>> In the refactorization process, are we supposed to move ITKv3 code in a
>>> special module (or submodule)? What happens in this case?
>>>
>>> (I ask cause it is going to happen pretty soon for us, for some
>>> components).
>>>
>>> We could schedule a skype or tconf to discuss these issues (short one).
>>>
>>> Thanks,
>>> Arnaud
>>>
>>>
>>>
>>>
>>> On Thu, Mar 31, 2011 at 6:10 PM, Arnaud GELAS
>>> <arnaud_gelas at hms.harvard.edu> wrote:
>>>>
>>>> Xiaoxiao, Luis,
>>>>
>>>> We have been working on fast marching filters, and we would like to
>>>> submit gerrit patches for its refactorization.
>>>>
>>>> Currently, fast marching filters are
>>>>
>>>> part of the level sets module
>>>> work only on itk::Image
>>>>
>>>> With our changes, fast marching filters will also work on
>>>> itk::QuadEdgeMesh, while the level sets framework does not (at this stage).
>>>>
>>>> Would it make sense to create a separate module for fast marching
>>>> filters?
>>>>
>>>> Do we need to split fast marching filters into 2 sub-module one for
>>>> itk::Image and one for itk::QuadEdgeMesh, or keep everything together at a
>>>> cost of adding one dependency to itk::QuadEdgeMesh in the case where people
>>>> want to only use it for itk::Image and vice-et-versa ?
>>>>
>>>> Please let us know what would be your recommendations,
>>>>
>>>> Thanks,
>>>> Arnaud
>>>
>>>
>>>
>>> --
>>> ---------------------------------------------
>>> Xiaoxiao Liu, Ph.D.
>>> R & D Engineer
>>> Kitware Inc.
>>> Clifton Park, NY
>>> Phone: (518) 881-4924  or  (518) 371-3971 x124
>>>
>>>
>>
>>
>>
>> --
>> ---------------------------------------------
>> Xiaoxiao Liu, Ph.D.
>> R & D Engineer
>> Kitware Inc.
>> Clifton Park, NY
>> Phone: (518) 881-4924  or  (518) 371-3971 x124
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Kitware offers ITK Training Courses, for more information visit:
>> http://kitware.com/products/protraining.html
>>
>> Please keep messages on-topic and check the ITK FAQ at:
>> http://www.itk.org/Wiki/ITK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.itk.org/mailman/listinfo/insight-developers
>>
>> Jim Miller
>> Senior Scientist
>> GE Research
>> Interventional and Therapy
>> GE imagination at work
>
>
>
> --
> ---------------------------------------------
> Xiaoxiao Liu, Ph.D.
> R & D Engineer
> Kitware Inc.
> Clifton Park, NY
> Phone: (518) 881-4924  or  (518) 371-3971 x124
>
>