[Insight-developers] Mesh IO : IJ

[Alexandre GOUAILLARD]

hi arnaud,

yes, I think we should start a wiki page on that specific problem. The
question touches QE2QE filter (shall we always copy celldata /
pointdata from input to output when present?) and the design of
Decimation filter (shall we template the data modification part with a
function, shall we let the user inherit, ...) and there might be
several answers.

Before we do that, I need your advice: do you think we should hold on
moving the Decimation classes from review then? We know there is a
performance issue we did not address either, and I had written in my
to do list to write a benchmark, and profile this part (most likely a
problem in our implementation of the mutable priority list).

The rest of QE (the structure and the other filters) could move independantly.

please advise.

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