[Insight-developers] Mesh IO : IJ

Arnaud GELAS arnaud_gelas at hms.harvard.edu
Fri Sep 24 13:29:42 EDT 2010


  Hi Alex

On 09/21/2010 09:08 PM, Alexandre GOUAILLARD wrote:
> hi arnaud.
>
> On Wed, Sep 22, 2010 at 3:21 AM, Arnaud GELAS
> <arnaud_gelas at hms.harvard.edu>  wrote:
>>   On 09/20/2010 11:58 PM, Alexandre GOUAILLARD wrote:
>>> btw,
>>>
>>> the latest patch to itkMesh remove data (when present) when a point is
>>> removed.
>>> see: SHA:       a17d47b98a6f4a0aeef624b3195e214640306a5a
>>>
>>> I suppose there is more work to de regarding cells.
>>>
>>> Arnaud, you seem to have identified problems, can you contribute small
>>> code to illustrate the problems you've already identified. Even
>>> better, write the corresponding tests?
>> Sure, I will try my best to write couple of tests this week!
>
[...]
> <  if there is bug, there should be a test failing>
>
> QuadEdge Mesh, when looking at the dashboard, is one of the most
> tested part of itk, with a coverage at almost 100%. Still, there are a
> lot of bugs. We are not doing or job correctly. Everytime we find or
> get to know about a bug, we should write the corresponding test right
> away. Write the test first. Even if we're not going to be the ones to
> fix it, we should help reproduce it.
>
> In your e-mails, you od not suggest any solution to the problem you
> are pointing, which is fine. However, you should at least provide the
> minimum test to reproduce the bug or the behavior that you have
> identified as a bug (there is still always the discussion wether it is
> a feature or a bug).

I have just published one test here
http://github.com/arnaudgelas/ITK/tree/QEMeshTest

here is the commit:
http://github.com/arnaudgelas/ITK/commit/9d166fb5a3671e4703c6191c14869ea7547b6765

In this simple example, I add (arbitrary) cell data to a given mesh 
(note that it would have make more sense to use the cell area for 
illustration purpose), and decimate the resulting mesh.
As of now, original data are still in the CellDataContainer, i.e. the 
CellDataContainer is much larger than what is supposed to be.
One first solution is to simply prune the original container, or 
depending on the data (for example the cell area) to compute at each 
iteration the change in the data.
This was another example to illustrate data processing during 
QuadEdgeMeshToQuadEdgeMeshFilters.

To summarize, I think that data processing in filters are

    * filters dependent
    * data dependent (type, and application dependent)

[...]
>>> One possible solution consists in providing one additional helper class
>>> to
>>> process data for each filter...
>>> What do you think about it?
For example, one helper class could copy the (Cell/Point) DataContainers 
from the input to the output (for example for smoothing filters), or 
could apply the smoothing operator on the DataContainer.
Another one in the case of the decimation could prune the DataContainer, 
or apply operations on DataContainer depending on the kind of data.

I can start writing a wiki page on that problem, if needed.

Thanks,
Arnaud

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


More information about the Insight-developers mailing list