Feature miscalculations (since BMC version)

[GoogleCodeExporter]

in statistics/FeatureStatustucs.cpp/EulerNumber(), the code to set the pixel 
value when inverting the image to find the holes is:
cp->pixel(x,y,z).intensity=1;
This does not set the pixel value to anything, so the image is not inverted to 
find the holes.
Its too bad that the pixel() return type is a valid lvalue, and that the 
compiler didn't warn that the statement has no effect (or maybe it did but 
there were too many other warnings that were being ignored).
The code should be:
cp->set(x,y,z,1);
This should be changed in C-chrm trunk and pychrm trunk.
This affects the test results, which requires updating all .sig and .fit test 
files.

Original issue reported on code.google.com by i...@nih.gov on 15 Dec 2012 at 3:22

[GoogleCodeExporter]

That should be cp->SetInt(x,y,z,1);

Original comment by i...@nih.gov on 15 Dec 2012 at 3:39

[GoogleCodeExporter]

This affects gabor features as well.
A grep search through the C codebase reveals there are no other constructions 
like this.
grep -rP '\)\.intensity\s?=[^=]' *

Original comment by i...@nih.gov on 15 Dec 2012 at 7:03

[GoogleCodeExporter]

Chebyshev-Fourier Coefficients for images larger than 300x300 pixels rely on 
ImageMatrix->Downsample().  This method is not implemented correctly in that 
the memory for the data is not reallocated, and the original width/height are 
not kept track of - only the new smaller width and height are kept track of.  
When an offset into the original memory is calculated from x,y coordinates 
using the new width/height, a skew results because the new image is no longer 
contiguous in x,y, due to the extra pixels at the end of every row.

Issue renamed to more general "feature miscalculations" to reflect the 
different nature of the bugs involved as well as the different features being 
affected.

Original comment by i...@nih.gov on 24 Dec 2012 at 2:27

• Changed title: Feature miscalculations (since BMC version)