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

[Xiaoxiao Liu]

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 <http://www.kitware.com/>.
>>  Clifton Park, NY
>> Phone: (518) 881-4924  or  (518) 371-3971 x124
>>
>>
>>
>>
>
>
> --
> ---------------------------------------------
> *Xiaoxiao Liu*, Ph.D.
> R & D Engineer
> Kitware Inc <http://www.kitware.com/>.
> 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 <http://www.kitware.com/>.
Clifton Park, NY
Phone: (518) 881-4924  or  (518) 371-3971 x124
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110401/5d99ee2d/attachment.htm>