Hi Alexandre,
We need to build a list of the classes directly useful for the user in
your contribution, and for all those classes, a consistent set of
instantiations to wrap. Some classes may be used only internally in some
other classes and won't have to be wrapped.
Can you provide the list of classes to be used by the final user, and with
all those classes, a single example of template parameters ?
With that list, I will build the WrapITK config files needed to wrap those
classes. It may highlight some bugs, and will make your work immediately
available for python, java and tcl users.
Thanks,
Gaetan
On Wed, 20 Dec 2006 23:28:10 +0100, Luis Ibanez <luis.ibanez at kitware.com>
wrote:
> Hi Gaetan,
>
> That sounds like a good idea.
>
> Wrapping (due to its explicit instantiation) catches many
> problems with templated classes.
>
> We just need to work with the authors of the classes to
> figure out what template parameters make sense for the
> instantiation.
>
>
>
> Luis
>
>
> -----------------------
> Gaetan Lehmann wrote:
>> Hi Luis,
>> I would like to make all the new classes directly useful for the user
>> available in WrapITK before the release.
>> I see several reasons to do that:
>> (a) be sure that the API is usable with the wrappers
>> (b) increase the code coverage of WrapITK
>> (c) be sure that everything builds with various template parameters
>> Of course, I would be pleased to work on that.
>> Please let me know what you think about that, and how we can proceed
>> if you agree with that.
>> Thanks,
>> Gaetan
>> On Wed, 20 Dec 2006 14:50:41 +0100, Luis Ibanez
>> <luis.ibanez at kitware.com> wrote:
>>
>>>
>>>
>>> Hi Alex, Thomas, Leila,
>>>
>>>
>>> Sylvain Jaume will be in charge of moving the
>>> itkQuadEdgeMesh and associated classes into ITK.
>>>
>>> He will be reviewing the coding style and the
>>> class hierarchy when he returns from vacations
>>> (in January).
>>>
>>> Presumably we will do this progressively. As you
>>> know, it takes several days to get a single class
>>> to compile correctly in all platforms. So, what
>>> may be a matter of hours when working in a single
>>> platform (Let's say only Linux or only Windows)
>>> becomes a couple of days when we have to clear up
>>> the code for all the compilers that we are supporting
>>> {ICC, Gcc, VS, Borland} and different OS {MacOS, IRIX,
>>> Solaris, Linux, Windows, Cygwin, MinGw}.
>>>
>>> With the highly templated structure of the Mesh classes,
>>> this task is not trivial.
>>>
>>>
>>> I would suggest that we focus first in getting the
>>> data structures right, and then we move into adding
>>> Mesh filters to the toolkit.
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>> Luis
>>>
>>>
>>>
>>> -----------------------------
>>> Alexandre Gouaillard wrote:
>>>
>>>> hi thomas.
>>>>
>>>>> What is the decision for including the meshes into
>>>>> ITK3.2 and if it is positive in what form will it be included?
>>>>> Extended or as is?
>>>>
>>>> extended.
>>>>
>>>>> The classlist gives me more than 60
>>>>> types, so what do you think about introducing groups, something like
>>>>> SurfaceMeshDataStructures, SurfaceMeshAlgorithms,
>>>>> SurfaceMeshOperators, Iterators...? Its just an idea.
>>>>
>>>> Good idea. How could we do that? Is this just a naming convention
>>>> you are thinking about (like creating a namespace) or creating an
>>>> abstract layer ala vtkPolyDataAlgorithms
>>>> Note that abstract layers exist already most classes inherits from
>>>> those two:
>>>> itk::MeshToMeshFilter ==> itkQE::MeshCopy (should be renamed)
>>>> itkQEMeshFunctionBase ==> all operators including eulers (design
>>>> need to be explained more in detail).
>>>>
>>>>> I did not try to implement something, but will start
>>>>> in January. So I might have loads of other questions soon.
>>>>
>>>> You're more than welcome.
>>>>
>>>>> Specific questions:
>>>>>
>>>>> Q1: Could I just define itk::RegularSphereMeshSource with <itkQEMesh>
>>>>> and would this give me a QEMesh as output or do I need to write a new
>>>>> one similar to the CylinderMeshSource? Or could I create the old
>>>>> ITKMesh input it into some filter and simply output the QEMesh?
>>>>>
>>>> Q1.1 could I definie MySurfaceFilter<itkQEMesh>?
>>>> yes, and it should be faster. Q1.2 What would be the output type,
>>>> itkMesh or itkQEMesh?
>>>> Output would be as defined within the implementation (sometimes
>>>> itkMesh is hardcoded, sometimes output type in same as template
>>>> parameter).
>>>> Q1.2 Do I need to write my own filter?
>>>> you do NOT need to if it deals with SURFACES, but filter taking into
>>>> account QEmesh features would be easier to code, implementation
>>>> should be smaller, code should be faster. specific local iterators
>>>> and euler operators simplify greatly the design, even if you can
>>>> write everything following the old itkMesh style. if you want your
>>>> filter to be n-dimensional, no itkQE.
>>>>
>>>>> Q2: Was the reimplementation of the cross product necessary? And why
>>>>> doess it hide in a file named itkQEMeshParamMatrixCoefficients.h?
>>>>>
>>>> Q2 Was he reimplementation necessary?
>>>> there was reason for that (which I don t remember in detail but i
>>>> could dig them in team reports). Anyway, the parameterization classe
>>>> are not mature enough and should be removed from the tarball to be
>>>> integrated in ITK 3.2.
>>>>
>>>>> Q3: Don't you think Doxygen should explain the meaning of
>>>>> "Geometrical
>>>>> Iterator"?
>>>>>
>>>> Yes, will do.
>>>>
>>>>> Q4: Regarding QEPoint: What is the meaning of the return value of
>>>>> 'IsInternal()' in QEPoint? And what exactly does the method GetEdge()
>>>>> return? Could you please change the spelling of 'Initialise()' to
>>>>> Initialize().
>>>>>
>>>> Q4.1 Meaning of internal ?
>>>> Point which is not on a border = point whose edges in the Oring are
>>>> not border edges.
>>>> Q4.2 What exactly the method GetEdge() returns?
>>>> a QEPrimal which is the type of a primal edge as compared to the
>>>> type of a dual edge.
>>>> Q4.3 Initialize() spelling typo?
>>>> will do.
>>>>
>>>>> Q5:Could you please improve documentation for itkQE::MeshWithDual?
>>>>>
>>>> Hum, not for the time being. iT will be removed from the tarball as
>>>> long as the discussion on the design of the containers of the dual
>>>> geometry is not over. This class implements a brute force approach,.
>>>> It is a good feasbility prototype, but a bad design. It will be
>>>> address this wednesday.
>>>>
>>>>> Q6: Could you create a 'How to create a Mesh'- or a 'IO' section
>>>>> and
>>>>> link it on the main page (similar to the 'Global traversing...'). I
>>>>
>>>> Yes. It exists in the documentation you have under the "related
>>>> pages" and "navigating back and forth ..." link. We will improve the
>>>> documentation to send the reader to the
>>>> "QEMeshToVTKUnstructuredGrid", "vtkToItkQEImport",
>>>> "vtkUGToItkQEImport" examples and related tests.
>>>> I am back to france for a few weeks, and thus we resume the usual
>>>> QEbab dinner and coding parties on wednesday nights. I'll get back
>>>> to you with an updated version on wednesday, possibly with a new
>>>> tarball for the insight journal.
>>>> cheers,
>>>> alex.
>>>>
>>> _______________________________________________
>>> Insight-developers mailing list
>>> Insight-developers at itk.org
>>> http://www.itk.org/mailman/listinfo/insight-developers
>>
--
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66 fax: 01 34 65 29 09
http://voxel.jouy.inra.fr