[Insight-users] DeformableModelSimplexMesh

[alex. gouaillard]

Lots of e-mails during the night.
I'll try to address the main issues.

On Thu, 2006-08-24 at 20:44, Luis Ibanez wrote:
> Hi Alex,
> 

Hi luis and all,

we have been sticking to itk policy and did everything by the book. That
includes commenting the code, writing functional test suite, compiling
using Cmake, auto generation of the docs, separation of base classes,
filters, and vtk or fltk dependent filters/demo. Matthieu (thanks to
him) is double checking everything nowadays.

> mesh classes
there are actually two seperated things here.
1. The mesh structure (itkQEMesh) along with the euler operator coded as
functors
2. the filters

itkQEMesh is 100% backward compatible. It means all API are the same as
those of itkMesh. We have included in our testsuite the modified
itkMesh1|2|3 examples with exactly the same code but itkQEMesh instead
of itkMesh to guaranty that. Interesting enough, existing code can
directly use itkQEMesh and beneficiate from speed improvement
(buildlinks is not needded anymore, and is overloaded by an empty
method. Cheers!). We provide the code we used to test and quantify the
speed improvement in the /Example part of the code.

2. the filters
a/ We are implementing filters that are in vtk and not in itk. In that
case, we do it directly above itkQEMesh.
b/ We are thinking of implementing quite a few Active shape algorithms.
itk already has a couple of those, but the specifics of itkQEMesh would
make the coding much easier/elegant and should improve a lot the
performance. 
c/ We will most surely (work already started) add two "toolkits" to itk:
a geometry processing toolkit ( subdivision framework, parametrisation,
....) and a topology toolkit ( cut graph, homology and homotopy bases,
fundamental domains, ... ricci flows ...).
There is a lot of interest around the geometry toolkit (think flatening
of the brain, conformal or spherical parametrisation , ...) but without
a structure like itkQEMesh, coding it is possible but akward ... I saw
such toolkits proposed to IJ, I would have to take a look see if it's
worth recoding, but it seems it will.
There is a lot of things to be done using topology, but once again,
without orientation and 2-manifoldness, few you could do with itkMesh
(or vtkMesh for what it matters). Ask sylvain Jaume, he'll surely
confirm ;-)

> Do you have a design for these classes ?
> 
> We will be very interested in looking at the hierarchy
> that you are planning to implement.
> 

This work has not been started and I wanted to gather your thoughts
before that. Thanks for all the feedback. I will come up with a draft of
the design within 2 weeks, and once we all agree, do the work.

> 
> One resource that you could use is to add a page in the ITK
> Wiki (anybody has write access to it) describing the details
> of your design and implementation.  We do this for any major
> modification to the toolkit.
> 
> The page were you can add this proposal is:
> 
>   http://www.itk.org/Wiki/ITK_Oversight_Committee#Proposals
> 
> 

I'll do that.

> Also, since you are planning to contribute code to the
> toolkit, we should probably move this discussion to the
> developers list. You can subscribe to the list at the
> following link:
> 
> http://www.itk.org/mailman/listinfo/insight-developers
> 

Thanks. I'll do that too.

> 
> You are also welcome to joing the weekly phone conferences
> that are held on Fridays at 1:00pm EST. You will find
> information about this at:
> 
> http://www.itk.org/Wiki/Telephone_Conference_Agendas_and_Minutes
> 
> 

chinese timeline and USA EST are not very friendly :-D But I'll see what
I can do.

thanks again,

alex, for the itkQE team.