Hi Matt, As a side note, there is a migration guide for updating the Statistics framework here [1], and there is no mention of this change of behavior there that I can see.
Using 'git blame', it appears that this bug was introduced when migrating the statistics refactoring to default in this commit[2]. I created an issue to track this bug [3]. If you are interested in submitting a patch, instructions can be found here [4]. Thanks, Matt [1]http://www.itk.org/Wiki/Proposals:Refactoring_Statistics_Framework_2007_Migration_Users_Guide [2] http://itk.org/gitweb?p=ITK.git;a=commit;h=c6d83112 [3] https://issues.itk.org/jira/browse/ITK-3206 [4] http://insightsoftwareconsortium.github.io/ITKBarCamp-doc/CommunitySoftwareProcess/SubmitAPatchToGerrit/index.html On Thu, Aug 29, 2013 at 12:13 PM, Clarkson, Matt <[email protected]> wrote: > Hi there, > > I am upgrading from ITK 3.20 to 4.3.2 and noticed that in 4.3.2 a histogram > with 64 bins (0-63), spanned by the image values 0-255 mapped the value 255 > to bin 64, which was subsequently missed. This worked in 3.20, resolving to > bin 63. > > Comparing the code of itkHistogram.txx in 3.20, I see in method: > ::GetIndex(const MeasurementVectorType & measurement,IndexType & index ) > const > > code that does: > > if (tempMeasurement >= m_Max[dim][end]) > { > // one of measurement is below the minimum > // its ok if we extend the bins to infinity.. not ok if we don't > //Need to include the last endpoint in the last bin. > if(!m_ClipBinsAtEnds || tempMeasurement == m_Max[dim][end]) > { > index[dim] = (long) m_Size[dim]-1; > continue; > } > > whereas in version 4.3.2 I see: > > > if ( tempMeasurement >= m_Max[dim][end] ) > > { > > // one of measurement is above the maximum > > // its ok if we extend the bins to infinity.. not ok if we don't > > if ( !m_ClipBinsAtEnds ) > > { > > index[dim] = (IndexValueType)m_Size[dim] - 1; > > continue; > > > > So, it looks to me like version 4.3.2 is missing the condition where if a > value is exactly equal to the upper bound then it is included. Then I went > to JIRA and found: > https://issues.itk.org/jira/browse/ITK-2266 > > which suggests that this was a bug at one point, but was fixed in 3.20. > > So, did I miss a link somewhere? Can someone advise me please? > Has the spec changed such that the upper bound is no longer meant to be > inclusive in version 4+? > > Thanks > > Matt > > ------------------------------------------------------ > Matt Clarkson Ph.D. > CMIC Software Manager > Senior Research Associate > [email protected] > Skype: drmattclarkson > > Centre For Medical Image Computing > http://cmic.cs.ucl.ac.uk/staff/matt_clarkson/ > Tel: 020 7679 0257 > Fax: 020 7679 0255 > Room: 2.21 Malet Place Engineering Building > > Dementia Research Centre > http://dementia.ion.ucl.ac.uk/ > Fax: 020 7676 2066 > ------------------------------------------------------ > > > > > > > > > > _______________________________________________ > 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 > _______________________________________________ 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
