[Insight-developers] Mesh IO : IJ

[Alexandre GOUAILLARD]

hi arnaud,

thanks for the comments on the wiki.

I integrated your comments (execpt for curvature tensor). Do you have
an account in gerrit so I can put you as a reviewer?

thanks again.

alex.


On Wed, Sep 22, 2010 at 9:08 AM, Alexandre GOUAILLARD
<agouaillard at gmail.com> 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!
>>>
>>> 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
>>>>
>