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

[Xiaoxiao Liu]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110401/2b2ad445/attachment.htm>