[Insight-developers] Mesh IO : IJ

[Arnaud GELAS]

  Hi Alex,

I have one gerrit account: arnaudgelas

Sure, you can add me as reviewer!

Thanks,
Arnaud

On 09/22/2010 08:46 PM, Alexandre GOUAILLARD wrote:
> 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
>>>>>