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

Arnaud GELAS arnaud_gelas at hms.harvard.edu
Fri Apr 1 09:45:10 EDT 2011


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 <mailto: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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110401/c2f8ba6d/attachment-0001.htm>


More information about the Insight-developers mailing list