[Insight-developers] Mesh IO : IJ

Tue Sep 21 21:08:10 EDT 2010

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!
>>
>> Also, it looks like you have been having quite a few discussions off
>> the list.
>
> Like this thread :-P?

When this thread was speaking about the code review of identified
Insight journal papers, it was relevant to address only the authors
and the identified experts.

I agree that the current discussion would be beneficial to all. this
e-mail, pruned of the previous review discussion is now copied to the
dev-list.

> I have had discussions in person with few researchers and who asked me
> couple of questions on QuadEdgeMesh filters, and they made their points.
>>

There is nothing wrong about that. I am not saying that discussing
with researchers, or them making a point or not, is a bad thing, it
isn't. You are first authors on some mesh papers, and rightfully
people contact you. Even if you weren't, and if the questions weren't
it s great when people begin to speak between each other of ITK.

<IJ mechanism broken>

I'm saying that the whole mechanism of insight Journal , and
specifically the migration of code from IJ to review and then from
review to itk fully depends on the feedback of the community. If that
feedback is invisible, there is first no improvement of the code, and
then the code stays forever in review or in IJ.

You were not there at those times, but it's been a recurrent
discussion between bill, luis and other for as far as I can remember.
A direct result of that failure to get reviews and feedback from the
community is the size of /Review that account for 30% of the toolkit
today. QuadEdgeMesh account for 20% of that (19% of the code, 22% of
the tests). Well as of today not anymore. Next would be labelmap.

The best way we found to make that better is to rigorously and
systematically tell everybody that make comment on an IJ either on or
off the list, to write a review. The second way is to systematically
answer to general question with a copy to the corresponding list. The
third, is to show example and review IJ articles. The Insight Journal
stats are self-explanaory:
http://www.insight-journal.com/browse/users

< give other people opportunity to work on it >

What I am also saying is that we are all doing that on our spare time.
You point out some problems on QuadEdgeMesh that you might have been
aware of for a certain time, still it is not addressed today. I am
also aware of problems in QuadEdgeMesh that I did not find the time to
address untill this week. Putting the issues on the mailing list will
- give people that might want to work on QE, or anything, an awareness
of what is missing or not working well (give no surprise, get no
surprise)
- give motivated people challenges to undertake
- give the opportunity to people that have suddenly time to spend on
the subject (like luis and myself this week) to grep all the issues
from the mailing list archive.
- give people the opportunity to grab items from the wish/bugs list,
and list it as NAMIC week project.
- give the community time to decide if it is a feature or a bug.

< be sure that things are known and documented >

Now, as you where in touch with the development of QuadEdge for as far
as 2003, even if at that time you preferred not to take part of the
development of the structure, you are aware of the wiki page we have
been using since 2005 to report progress, migration guide, and many
other stuff:
http://www.paraview.org/Wiki/Proposals:New_Mesh_Class

I think the best for the community is for all of us to keep this page
(and the new one for v4) alive, to avoid the "beer truck" effect. What
happen if any of us get hit by a bus? nothing, everything is
documented.

Same for enhancement, if you ideas, share them, for the same reasons.
Your ideas are usually brilliant. For example, (and I don t have the
answer to that question, google doc is not reachable from beijing).
The megason lab had a mesh proposal for v4. Did you make it public to
all v4 PI afterward like CoSMo (multithreading of meshes) and Kitware
(better solvers and arithmetic kernel) did for example?

< 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 think luis is
>> providing a great exampel of how answering on the list to questions
>> that were made off the list is profitable to everyone eventually.
>>
> Yup, hats off to Luis!
>>
>> thanks in advance.
>>
>> alex.
>
> Arnaud
>>
>>
>> On Tue, Sep 21, 2010 at 5:23 AM, Arnaud GELAS
>> <arnaud_gelas at hms.harvard.edu>  wrote:
>>>
>>> Hi all,
>>>
>>> sorry for the delay, I have just got back from Pittsburgh...
>>>
>>> As of now, there is a big problem in QuadEdgeMeshToQuadEdgeMeshFilters
>>> when
>>> dealing with data (apart from the fact that you need to choose from the
>>> beginning the right template for data).
>>>
>>> Let me take a simple example, you take one mesh, you compute the gaussian
>>> curvature, then you decimate.
>>>
>>> What happens to data?
>>> Should they be pruned following the decimation?
>>> Should we apply a particular scheme on data during the decimation?
>>>
>>> Similar problems exist when data are attached to cells and the cell
>>> container is modified.
>>> One possible solution consists in providing one additional helper class
>>> to
>>> process data for each filter...
>>> What do you think about it?
>>>
>>> Another question that I have been recently asked:
>>> "Is it possible to have the gaussian curvature, mean curvature, and
>>> normals
>>> attached to vertices for a given mesh?"
>>> I have no simple solution for that one.
>>> What do you think about it?
>>>
>>> Arnaud
>>>
>>> ps: I start updating the wiki
>>>