[Insight-users] Still bug in Mesh Filters ?

Mon Mar 22 04:02:41 EDT 2010

Dear Luis

I'm sorry, the name of the class is not itkSimplexMesh3DFilter but itkDeformableSimplexMesh3Dfilter

I will create a new bug entry, but I'm not sure the behavior we saw is really a bug. 
We use a modified version of the InsightApplication program DeformableModelSimplexMesh. We have modified the DeformMesh method of the DeformableModelApplication class, using the base SimplexMeshAdapTopologyFilter we added a mesh refinement. This gives the following modified implementation of the for loop in the mentioned DeformMesh method

  for( unsigned int i=0; i<numberOfIterationsToGo; i++ )
    {
	std::cout << " >> Iteration   " << i << std::endl;
	m_SimplexMesh->DisconnectPipeline();
	m_DeformFilter->SetInput(m_SimplexMesh );
	m_DeformFilter->Update();
	simplexMesh2 = m_DeformFilter->GetOutput();

	m_RefineMesh->SetInput( simplexMesh2);
	m_RefineMesh->Update();
	m_SimplexMesh = m_RefineMesh->GetOutput();

}

This code crashes in the 3rd iteration (i=2, at m_DeformFilter->Update). Inspecting m_SimplexMesh and SimplexMesh shows that the data of m_GeometryData gets lost in the previous statement m_DeformFiter->SetInput (an internal reference count of becomes 1, so the pointer is deleted)
I think this is because the pointer of GeometryData is copied and not the contents

Is this a right conclusion ? Should the actual data of m_Geometry copied instead of the pointer in itkSimplexMeshAdaptTopologyFilter and also other mesh filters

Kind regards - Jan

Jan Menssen
Clinical Physics Lab
Radboud University Nijmegen Medical Centre
Nijmegen - The Netherlands

-----Original Message-----
From: Luis Ibanez [mailto:luis.ibanez at kitware.com] 
Sent: maandag 15 maart 2010 20:38
To: Menssen, Jan
Cc: insight-users at itk.org; Insight Developers
Subject: Re: [Insight-users] Still bug in Mesh Filters ?

Hi Jan,

I couldn't find a class named:

                         itkSimplexMesh3DFilter

so, let me follow up on your comments on the:

                itkSimplexMeshAdaptTopologyFilter

1) The methods "CopyInputMeshToOutputMesh***" are
     provided in the base class

                        itkMeshToMeshFilter

     as service methods.

     Whether some or all of them should be called, is
     something that only the developer of a particular
     filter can determine.

2)  You are correct on expecting that some filters
     should call:

             CopyInputMeshtoOutpoutMeshCellLinks()

      although others may not need to make this call.

3) In the particular case of the

             itkSimplexMeshAdaptTopologyFilter

    There is a larger structural problem:

             This filter takes the liberty of modifying its own
              input. Which is a violation of the acceptable
              behavior of filters in a data-pipeline.

     The filter rebuilds the cell links in the input image
     directly.

4)  The decision about copying pointers versus copying
      the actual data (deep copy) on some of the inputs
      of the mesh filters is something we went back and
      forth during the early days of the toolkit.

      The main deciding factor was whether we will be
      managing very large meshes or not. (and therefore,
      whether we could avoid some memory allocations
      by sharing data between the input and output of a
      filter, when such data was not modified by the filter.

      You have just found one spot in which the developer
      considered that sharing the data between input and
      output was a good idea.

     Note that in practice, we tend to deal with meshes
     that are not so large, and therefore the memory
     duplication has been less of a concern.

5)  Although both of your points are quite valid and
     important, it looks like they are not really related
     to the bug:
     http://public.kitware.com/Bug/view.php?id=9554

     Can you please create a new bug entry for the
     specific issue of copying Cell Links, and another
     one for the specific issue of the lack of deep
     copy in the Geometry Data  ?

   Thanks

         Luis

--------------------------------------------------------------------------
On Mon, Mar 8, 2010 at 10:35 AM,  <J.Menssen at cukz.umcn.nl> wrote:
> Hello
>
> I'm working on a ITK project using the ITKSimplexMesh3DFilter and
>
> itkSimplexMeshAdaptTopologyFilter.
>
> I'm using the latest versions of itk (v1.26 and 1.19, cvs archive) because I
> read in the ITK bug-tracker database there were bugs in these filters (bug
> 0009554)
>
> Maybe there are still bugs in these filters
>
> Inspecting the code (itkSimplexMesh3DFilter::ComputeOutput), I read the
> following
>
> ::ComputeOutput()
>
> {
>
>   OutputMeshType * output = this->GetOutput();
>
>   this->CopyInputMeshToOutputMeshPoints();
>
>   this->CopyInputMeshToOutputMeshPointData();
>
>   this->CopyInputMeshToOutputMeshCells();
>
>   this->CopyInputMeshToOutputMeshCellData();
>
>   output->SetGeometryData(this->m_Data);
>
>   output->SetLastCellId( this->GetInput(0)->GetLastCellId() );
>
> }
>
> My Questions about these are
>
> 1)      Why are the Cell links not copied, there is a routine
>
> CopyInputMeshtoOutpoutMeshCellLinks
>
> 2)      The pointer to the GeometryData is copied, not the content. Why not
> the content, now
>
> it's possible to delete the original data (when reference count of the input
> data becomes 0, it's impossible to access these data in a next stage of a
> program
>
> Kind regards
>
> Jan Menssen
>
> Clinical Physics Lab, Dept. Pediatrics
>
> Radboud University Nijmegen
>
> j.menssen AT cukz.umcn.nl
>
> Jan Menssen
> Klinisch Fysisch Medewerker
>
> Universitair Medisch Centrum St Radboud
> Klinisch Fysisch Lab - Kindergeneeskunde
> Huispost 833, route 833
> Postbus 9101
> 6500 HB Nijmegen
> Telefoon: (024) 36 19063
> E-mail J.Menssen at cukz.umcn.nl
>
> http://www.umcn.nl
>
> Het UMC St Radboud staat geregistreerd bij de Kamer van Koophandel in het
> handelsregister onder nummer 41055629.
> The Radboud University Nijmegen Medical Centre is listed in the Commercial
> Register of the Chamber of Commerce under file number 41055629.
>
> _____________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://www.kitware.com/products/protraining.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-users
>
>

Het UMC St Radboud staat geregistreerd bij de Kamer van Koophandel in het handelsregister onder nummer 41055629.
The Radboud University Nijmegen Medical Centre is listed in the Commercial Register of the Chamber of Commerce under file number 41055629.