Closed kreupeldier closed 11 years ago
Here's an example where it does work, even though it looks like it shouldn't:
When looking at the raw (unrotated) data, you can see that one paw really doesn't touch the edge of the plate.
Even with padding, there is at least one pixel of space. What seems to happen is that when I calculate the bounding box, based on the contours, I round off the floating point positions (which technically make no sense in a discrete grid like this) and voila. Suddenly the 1.47 gets rounded off as 1, which is the actual edge, in a padded measurement.
It seems there was a rounding error when converting from floats to ints, causing the 1.47 instead of 1.5 and then causing that to be cast to 1 instead of 2.
As for the measurement in your example:
That one definitely touches the edges of the plate, but I fear my rounding has caused them to be a bit too conservative.
One problem is that I'm displaying an interpolated signal, so it might be that due to the cubic smoothing, the bounding box and the paw no longer perfectly align. But judging from the looks of it, it seems to be underestimating the paw on all sides.
Displaying the data without interpolation seems to confirm that the bounding box isn't perfect.
Rolling back the rounding does not seem to fix the problem with the poorly fitting bounding boxes. However, increasing their size with 1 pixel in all directions would be dangerous, since it would create a lot more false positives with this naive boundary checking method.
As a first check to see if its a display issue or something with the creation of bounding boxes. Check whether convert_contour_to_slice isn't missing any pixels on the side
It seems that with the current bounding box shapes, we're underestimating the size
Current
Padding 2 pixels in all directions
Guess I'll have to jump it and figure out which of the steps is causing this problem
I changed calculate_bounding_box from using minAreaRect to boundingRect. However, that still underestimates it.
Lets see how it does for a single frame
Ok, part of the confusion seems to be caused by the way I display 2D data. It draws 2D data by taking a row and column and then going 0.5 +/- to either side of the row and column and fills it. Which means that if you want to draw a line AROUND that color, you need to add a little 0.5 sensor offset.
However, if you want to slice the data, the 0.5 makes no sense as there's no index that corresponds to 0.5 step sizes
If you slice out the data exactly according to the values of their bounding boxes:
It seems to be exactly right, because everything around it is zeros. I also checked it, whether its correct if you try to calculate the bounding box for the entire paw and that one seems to match too. So I guess I need to update a couple of things and then test to see how this affects touches_edges
Both examples I've looked at earlier seem to be fixed now.
So unless someone finds another counter example, I'm going to leave things as they are right now. Reopen if there's a new case
I have a measurement where the test that checks for contact at the edge of the plate seems to fail. Please add some test cases to check if this is working.