[Insight-users] bug in DeformableModelSimplexMesh ?

Tue Jul 27 08:47:30 EDT 2010

Sorry to hear that, but as I said I no longer use that filter. I was
recently investigating filter reuse (only natural with such a cumbersome
declaration), when I came across this message:
http://www.itk.org/pipermail/insight-users/2003-December/005972.html. It may
not be directly connected with the problem you are having, but  it does not
hurt to know.

Regards,
Dženan

On Tue, Jul 27, 2010 at 14:37, <J.Menssen at cukz.umcn.nl> wrote:

>  Dear Dzenan
>
>
>
> As you proposed in your mail, we created an unnamed block and created a new
> deform filter from scratch
>
> We instantiate the filter and set all parameters
>
>
>
> However, this modification results in the same error message as described
> below
>
> So our problem is not yet solved
>
>
>
> Thank you for your time, kind regards
>
>
>
> Jan Menssen
>
>
>
> *From:* Dženan Zukić [mailto:dzenanz at gmail.com]
> *Sent:* donderdag 22 juli 2010 14:56
> *To:* Menssen, Jan
> *Cc:* insight-users at itk.org; Nillesen, Maartje
> *Subject:* Re: [Insight-users] bug in DeformableModelSimplexMesh ?
>
>
>
> I discovered few weeks back, that you cannot just change input mesh for
> deform filter, that is
>
> *m_DeformFilter->SetInput(m_SimplexMesh);*
>
> this line is a problem. The workaround I used was to create unnamed block
> and create a new deform filter from scratch (instantiate filter and set a
> bunch of parameters) instead of just setting setting input mesh and calling
> update.
>
>
>
> Regards,
>
> Dženan
>
>
>
> On Wed, Jul 21, 2010 at 11:37, <J.Menssen at cukz.umcn.nl> wrote:
>
> Dear All
>
> We are working on a segmentation algorithm using deformable models with a
> refine mesh. The deformation and refinement is done  in a for loop. Our
> application is based on the DeformableModel application as given in the
> InsightApplications example DeformableModelSimplexMesh.
>
> We modified the for loop in de DeformMesh method
> (DeformableModelApplication.cxx) with a refinement of the mesh, but this
> crashes. Below a part of (pseudo) code is given..
>
> *     for i=1:i<nr_iterations;i++*
>
> *   {*
>
> *      m_simplexMesh->DisconnectPipeline()*
>
> *      m_deformFilter-SetInput(m_simplexMesh);*
>
> *      m_deformFilter->Update(0;*
>
> *      simplexMesh2 = m_deformFilter->GetOutput();*
>
> *      *
>
> *      m_refineMesh->SetInput(simplexMesh2);*
>
> *      m_refineMesh->Update();*
>
> *      m_simplexMesh=m_refineMesh->GetOutput();*
>
> *  }*
>
> m_deformFilter is a DeformableSimplexMesh3DGradientConstraintForceFilter,
>
> m_RefineMesh is a  itkSimplexMeshAdaptTopologyFilter
>
>        * *
>
> To isolate the bug, we started with a little modification of the DeformMesh
> method in DeformableModelApplication.cxx. The modifications are given below
> (line 522 in original file, InsightApplciations 3.16). Running this code
> results also in a crash
>
>
> *----------------------------------------------------------------------------------------------------------------------------------------
>
> *SimplexMeshType::Pointer simplexMesh2 = m_SimplexMesh;*
>
> *const **unsigned **int** numberOfIterationsToGo =
> atoi(m_IterationsValueInput->value()); *
>
> *for**( **unsigned **int** i=0; i<numberOfIterationsToGo; i++ )*
>
> *{*
>
> *      std::cout << **" Iteration   "** << i << std::endl;*
>
> *    *
>
> *//* -------------- start modified code
> -------------------------------------------*
>
> *        **// THIS IS MODIFIED CODE THAT (WE THINK) DOESN'T VIOLATE THE
> ITK RULES BUT THIS*
>
> * **// CODE CRASHES*
>
> *                        **m_SimplexMesh->DisconnectPipeline();*
>
> *                        **m_DeformFilter->SetInput(m_SimplexMesh);*
>
> *                        **m_DeformFilter->SetIterations(1);*
>
> *                        **m_DeformFilter->Update();*
>
> *                        **simplexMesh2 = m_DeformFilter->GetOutput();*
>
> *                        **SimplexMesh2->DisconnectPipeline(0*
>
> *m_DeformFilter->SetInput(simplexMesh2);*
>
> *                        **m_DeformFilter->SetIterations(1);*
>
> *                        **m_DeformFilter->Update();*
>
> *                        **m_SimplexMesh = m_DeformFilter->GetOutput();*
>
> *// --------------------- end modified code
> -------------------------------------- */*
>
> *      m_SimplexMeshToShow  = m_SimplexMesh;*
>
> *      **this**->RefreshMeshVisualization();*
>
> *     *
>
> *      **// force a redraw*
>
> *      axialView->redraw();*
>
> *      coronalView->redraw();*
>
> *      sagittalView->redraw();*
>
> *      surfaceView->redraw();*
>
> *      Fl::check(); *
>
> * }*
>
>
> *-------------------------------------------------------------------------------------------------------------------------------------------
>
> Error message (using Visual Studio 2005 and/or 2008) of the crash
>
> Debug Assertion Failed !
>
>         Expression map/set iterator not dereferencable
>
> Do we something wrong?  Using a for loop in a pipeline is dangerous but in
> bug 0001080, we read it’s possible to use a for loop. Also at the Old Nabble
> forum  I read a message that is must be possible to use a for loop. (
> http://old.nabble.com/Using-image-iterators-combined-with-filters-in-a-loop-td28684443.html
> )
>
> Even if we changed the code in the original example
> DeformableModelApplication according to the above  referenced Old Nabble
> article the application crashes (see below)
>
>
>
> *m_DeformFilter->SetInput( m_SimplexMesh );*
>
> *      **m_DeformFilter->SetIterations(1); *
>
> *      m_DeformFilter->Update();*
>
> *      **m_SimplexMesh =  m_DeformFilter->GetOutput(); *
>
> *        **m_SimplexMesh->DisconnectPipeline();*
>
> So is there a bug in the original ITK sources? As far as we now, ITK
> doesn’t allow to change the input of a filter and we think this is what
> happened in the original DeformableSimplexMesh application.
>
> Can someone help us with our problem ?
>
> We tested with ITK 2.8, ITK 3.16 and 3.18 and all crashes
>
> * **Jan Menssen
> **Research assistant*
>
> *Radboud University Nijmegen Medical Centre*
> *Clinical Physics Lab -* Peadiatrics
> Huispost 833, route 833
> P.O  box  9101
> 6500 HB Nijmegen
> Telefoon: +31 24 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20100727/97926a16/attachment.htm>