> Huh, pe seems to rotate Oriented boxes clockwise, instead of ccw. To
> fix it, you have to change the 'initPoly' method in the
> edu.umd.cfar.lamp.viper.geometry.OrientedBox class, on line 198, add a
> negative sign appropriately:
> trans.concatenate(AffineTransform.getRotateInstance(Math.toRadians(-
> data[ROTATION])));
> On Feb 29, 12:12 pm, avastreg <isac.new...@gmail.com> wrote:
> > I have another question..
> > In the framewise evaluation, when we try to compare this target:
> > <data:obox framespan="135:135" height="58"
> > rotation="90" width="86" x="133" y="150"/>
> > with this candidate:
> > <data:obox framespan="135:135" height="23"
> > rotation="90" width="27" x="157" y="123"/>
> > (the candidate is totally included in the target)
> > the counters for the matched/missed calculation are really wrong.
> > Results are:
> > Pixels matched: 0.0 <--- shouldn't be 0
> > Pixels missed: 4988.0 <--- this is the full target area, but it
> > should be that one minus the candidate area
> > Pixels falsely detected: 621.0 <--- must be 0
> > this problem shows up only when the candidate is very close (or
> > included) in the target (or viceversa).
> > it should be a bug somewhere in the computation of the areas...
> > any idea?
> > or any idea where is the piece of code that calculate the obox
> > pixels?
> > Thank you in advance again!
|
