Sorry if this repeats - i just got a bounce from Insight Developers, so im trimming the message and resending.... -------------------------------------------------------------- Rupert Brooks [email protected]
On Wed, Jul 25, 2012 at 4:03 PM, Rupert Brooks <[email protected]>wrote: > It could be the Jacobian - the change from having a member jacobian, which > made the transforms non-threadsafe, to an external jacobian that is filled > by the GetJacobianWithRespectToParameters function places the > responsibility for the jacobian allocation /deallocation in the Metric, > where it used to be in the transform. > > Check around line 202 of itkMeanSquaresImageToImageMetric. > > // Jacobian should be evaluated at the unmapped (fixed image) point. > TransformJacobianType jacobian; > transform->ComputeJacobianWithRespectToParameters(fixedImagePoint, > jacobian); > for( unsigned int par = 0; par < this->m_NumberOfParameters; par++ ) > > But this does not use operator=()... So maybe not what you are seeing. > Still looking... > > Rupert > -------------------------------------------------------------- > Rupert Brooks > [email protected] > > > > > On Wed, Jul 25, 2012 at 1:51 PM, Bradley Lowekamp > <[email protected]>wrote: > >> Just to summarize: >> >> Most of the filters are about the same performance, however the otsu >> thresholding is significantly slower. >> >> The registration is about 2x slower the v3.20. >> >> I quickly sampled the process during registration with on my apple and it >> revealed the following interesting bit: >> >> 88.45% itk::ImageToImageMetric<itk::Image<unsigned >> char, 3u>, itk::Image<unsigned char, 3u> >> >::GetValueAndDerivativeThread(unsigned int) const >> 56.62% >> itk::MeanSquaresImageToImageMetric<itk::Image<unsigned char, 3u>, >> itk::Image<unsigned char, 3u> >> >::GetValueAndDerivativeThreadProcessSample(unsigned int, unsigned long, >> itk::Point<double, 3u> const&, double, itk::CovariantVector<double, 3u> >> const&) const >> 25.04% >> vnl_matrix<double>::operator=(vnl_matrix<double> const&) >> 15.69% malloc >> >> So there is a significant amount of time spent creating and destroying >> the matrix. >> >> Most likely this indicates that there is a variable inside the inner loop >> in the registration that is requiring new and delete, we could likely >> regain a significant portion of the performance by moving this allocation >> out side of the loop. >> >> Brad >> >> <snipped> >> >
_______________________________________________ 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://kitware.com/products/protraining.php 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-developers
