[Insight-developers] Mesh IO : IJ

[Alexandre GOUAILLARD]

thanks,

I l look into that next week when out of beijing.

alex.

On Sat, Sep 25, 2010 at 1:29 AM, Arnaud GELAS
<arnaud_gelas at hms.harvard.edu> wrote:
> 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
>
>