r21
(added mean-shift tracker and supporting event.) committed by sshipman
- added mean-shift tracker and supporting event.
added mean-shift tracker and supporting event.
Feb 15, 2009
issue 3
(Tilted integral image calculation) reported by huangnankun
- see here for the simple test case I wrote
http://pastie.org/389932
I will post the correct way to calculate the tilted II once I port it over
from my java code ( or someone else figures it out )
see here for the simple test case I wrote
http://pastie.org/389932
I will post the correct way to calculate the tilted II once I port it over
from my java code ( or someone else figures it out )
Feb 15, 2009
issue 2
(tilted feature never gets computed) changed by sshipman
- The current development state of deface has been oriented towards performance
improvements. I did actually have the tilted case working at one point, but it has
been neglected while optimization to the non-tilt case were put in. This is not an
excuse, only an explanation.
The actual replacement line should be
var sum:Number = tilted ? ii.getTiltRectSum(operatingRect) :
ii.getRectSum(operatingRect);
You are probably correct that the tilted II calculations are not quite correct. I
was never particularly happy with them. Please post test cases as you come up with them.
I am very open to including your code contributions. Please contact me outside of
the issue system: sshipman@gmail.com
Status: Accepted
Owner: sshipman
The current development state of deface has been oriented towards performance
improvements. I did actually have the tilted case working at one point, but it has
been neglected while optimization to the non-tilt case were put in. This is not an
excuse, only an explanation.
The actual replacement line should be
var sum:Number = tilted ? ii.getTiltRectSum(operatingRect) :
ii.getRectSum(operatingRect);
You are probably correct that the tilted II calculations are not quite correct. I
was never particularly happy with them. Please post test cases as you come up with them.
I am very open to including your code contributions. Please contact me outside of
the issue system: sshipman@gmail.com
Status: Accepted
Owner: sshipman
Feb 15, 2009
issue 2
(tilted feature never gets computed) reported by huangnankun
- What steps will reproduce the problem?
1. Line 75 of HaarRect.as
It seems to me that "tilted" haar features never gets computed in the
current version of deface.
Currently, the code does this:
line 75: var sum:Number = ii.getRectSum(operatingRect);
however, I'd expect it to be
var sum:Number = tilted ? ii.getTiltSumXY(operatingRect) :
ii.getRectSum(operatingRect);
to take into account of the tilting.
Also, I don't think your tilted integral image calculations are quite right
but I will post a seperate issue for it once I write out a few test cases.
I actually have some code which I'd like to contribute to this project
which does results grouping like openCV. If you are open to it, we can get
in touch.
What steps will reproduce the problem?
1. Line 75 of HaarRect.as
It seems to me that "tilted" haar features never gets computed in the
current version of deface.
Currently, the code does this:
line 75: var sum:Number = ii.getRectSum(operatingRect);
however, I'd expect it to be
var sum:Number = tilted ? ii.getTiltSumXY(operatingRect) :
ii.getRectSum(operatingRect);
to take into account of the tilting.
Also, I don't think your tilted integral image calculations are quite right
but I will post a seperate issue for it once I write out a few test cases.
I actually have some code which I'd like to contribute to this project
which does results grouping like openCV. If you are open to it, we can get
in touch.
Feb 12, 2009
issue 1
(application of bwfilter in Integral Image) Status changed by sshipman
- You are absolutely correct on all counts. The line mentioned is in the
updateWithTilt function, but updateWithoutTilt is used more commonly. I've made the
changes in both places. The bw matrix was pulled from the internet without proper
research, and I've updated it to use the more standard one.
Also checked in in this update: change to use getVector instead of getPixels for very
minor efficiency boost. And fixed some xml serialization issues with the Haar
classes to enable a very hacked clone method.
Status: Fixed
You are absolutely correct on all counts. The line mentioned is in the
updateWithTilt function, but updateWithoutTilt is used more commonly. I've made the
changes in both places. The bw matrix was pulled from the internet without proper
research, and I've updated it to use the more standard one.
Also checked in in this update: change to use getVector instead of getPixels for very
minor efficiency boost. And fixed some xml serialization issues with the Haar
classes to enable a very hacked clone method.
Status: Fixed
Feb 12, 2009
r20
(Issue 1:
fixed black and white filter application in integra...) committed by sshipman
- Issue 1 :
fixed black and white filter application in integral image. Use getVector rather than getPixels for
very minor efficiency boost.
Fixed some xml serialization on the Haar classes to enable clone hack.
Issue 1 :
fixed black and white filter application in integral image. Use getVector rather than getPixels for
very minor efficiency boost.
Fixed some xml serialization on the Haar classes to enable clone hack.
Feb 11, 2009
issue 1
(application of bwfilter in Integral Image) reported by huangnankun
- What steps will reproduce the problem?
1. Navigate to line 117 of IntegralImage.as
padded.copyPixels(bd, bd.rect, paddedPoint, null, null, false);
bd.applyFilter(padded, rect,zero, bwfilter);
var ba:ByteArray = padded.getPixels(rect);
By doing this, you are applying the bwfilter to the bitmap "bd" instead of
the bitmap "padded". Subsequently, the pixels from "padded" are used to
compute integral image sums.
This does not seem to be the expected behavior since you want the grey
values after the black-white filter has been applied to be used in the
computation of the integral image.
an easy way to fix it is to replace the 2 lines
padded.copyPixels(bd, bd.rect, paddedPoint, null, null, false);
bd.applyFilter(padded, rect,zero, bwfilter);
with
padded.applyFilter(bd, bd.rect,paddedPoint, bwfilter);
Also, the coefficients used in the bwfilter seems kind of wierd to me. The
coefficients you used are:
.59R, .3G, .11B
Both matlab and java uses
0.2989 * R + 0.5870 * G + 0.1140 * B
as the coefficients for the RGB -> BW conversion.
besides that, great job on this project!
What steps will reproduce the problem?
1. Navigate to line 117 of IntegralImage.as
padded.copyPixels(bd, bd.rect, paddedPoint, null, null, false);
bd.applyFilter(padded, rect,zero, bwfilter);
var ba:ByteArray = padded.getPixels(rect);
By doing this, you are applying the bwfilter to the bitmap "bd" instead of
the bitmap "padded". Subsequently, the pixels from "padded" are used to
compute integral image sums.
This does not seem to be the expected behavior since you want the grey
values after the black-white filter has been applied to be used in the
computation of the integral image.
an easy way to fix it is to replace the 2 lines
padded.copyPixels(bd, bd.rect, paddedPoint, null, null, false);
bd.applyFilter(padded, rect,zero, bwfilter);
with
padded.applyFilter(bd, bd.rect,paddedPoint, bwfilter);
Also, the coefficients used in the bwfilter seems kind of wierd to me. The
coefficients you used are:
.59R, .3G, .11B
Both matlab and java uses
0.2989 * R + 0.5870 * G + 0.1140 * B
as the coefficients for the RGB -> BW conversion.
besides that, great job on this project!
Jan 11, 2009
r19
(efficiency and flash 10 updates) committed by sshipman
- efficiency and flash 10 updates
