Reducing jitter in marker reading.
Jeffery
The problem I'm having seems to be related to a small amount of jitter
on the marker, which is amplified a great deal when I have long planes
extending from the marker.
I've been working on methods of smoothing this in the following ways:
- Tweening the transform matrix result from the previous transform
matrix result. This works somewhat, but reduces reaction time with the
marker.
- Increasing the amount of time that the marker detection is occurring
by using a timer instead of an enterframe handler. This reduces
jitter, but also reduces movement update.
- Increasing the camera resolution. More pixels should = more better,
yeah? I'm still seeing jitter, but the loops required to go through
the raster image during detection are retarding the experience.
eric socolofsky
i've always ended up easing values to smooth things out. the "best"
way really depends on your application.
another possibility is to threshold changes in the transformation
matrix every frame -- if changes are < threshold value, don't update
that value.
curious, how are you tweening the matrix results, are you just
individually tweening each value in the matrix?
Jeffery
resultIndex = index1 + (index2 - index1) * .5;
Jeffery
We found a solution that is working for us. We tween from one
transform to the next, and in doing so, we round to limit the floating
point. This makes things a little less fluid, but the jitter goes
away.
Also, the farther out something sticks from the pivot point, the
greater it amplifies the jitter. So, if you can limit the length of
extension from the center, the jittering will be much less apparent.
makc
On 9 апр, 05:24, Jeffery <meandmybads...@gmail.com> wrote:
> We found a solution that is working for us. We tween from one
> transform to the next, and in doing so, we round to limit the floating
> point. This makes things a little less fluid, but the jitter goes
> away.
gordee
guys?
Blair MacIntyre
problem has a clear cause and can be fixed.
Doing all these interpolations and so are are just one form of filter
or another; they don't fix the problem, the just trade it off for
other problems (latency, sloshiness, most likely).
Here's what's going on (this is based on having fixed this in the
past, for non-Flash versions of ARToolkit and ARToolkitPlus).
The pose (position + orientation) of the marker, relative to the
camera, is computed based on the pixel coordinates of the 4 corners.
Those corners are determined from the thresholded image. The first
step in ARToolkit processing is to threshold the image and search for
blobs; then, 4 sided blobs are found; then, the pattern inside is
compared to known patterns (aside: the confidence value you get back,
that's been discussed before, is it's measure of how close it matches
the pattern -- if you accept low confidences, you will "detect" more
things that aren't markers).
Once the system has decided it's found a marker, if uses the pixel
locations of the four corners to determine the pose.
The problem, then, is that the corners are not determined very
accurately. If the threshold is not VERY close to correct, the
corners can be off by a few (or MORE!) pixels, since the blob will
bloom out or shrink in depending on how far off the threshold is.
If the corners are off by even 1 pixel, the orientation of the marker
will be wrong (draw some pictures to convince yourself of this,
especially if you move some in toward the center and some out from the
center; the resulting projections are very different).
The solution we used is to take the 2d pixel corners provided by the
ARToolkit, and feed them into a sub-pixel corner finder that operates
on the original color or greyscale image. We used openCV to do it
(cvFindCornerSubPix). I know that some folks have converted some of
OpenCV into AS3, so perhaps someone would be interested in trying it.
I'll be spending some time (finally!) with FLAR this summer, so
perhaps we'll port this in. But I wouldn't hold my breath waiting for
me! :)
Alejandro González
Blair MacIntyre
Sent from my iPhone
type="cite">We found a solution that is working for us. We tween from one
makc
On Apr 9, 5:34 pm, Blair MacIntyre <blair.macint...@gmail.com> wrote:
> The solution we used is to take the 2d pixel corners provided by the
> ARToolkit, and feed them into a sub-pixel corner finder that operates
> on the original color or greyscale image. We used openCV to do it
> (cvFindCornerSubPix). I know that some folks have converted some of
> OpenCV into AS3, so perhaps someone would be interested in trying it.
codes could be merged to achieve better performance?
Blair MacIntyre
way:
- the corner finder is fast, it looks for a gradient corner in the
region around the point you give it.
- you only do it for the things the system has actually decided are
markers
Doing the marker finding on the greyscale image (to avoid the
innaccuracy introduced by threaholding) would be really expensive.
Sent from my iPhone
Jeffery
more accurate readings. Contact me directly if you're interested.
On Apr 10, 10:25 am, Blair MacIntyre <blair.macint...@gmail.com>
wrote:
> way:
> - the corner finder is fast, it looks for a gradient corner in the
> region around the point you give it.
> - you only do it for the things the system has actually decided are
> markers
>
> Doing the marker finding on the greyscale image (to avoid the
> innaccuracy introduced by threaholding) would be really expensive.
>
> Sent from my iPhone
>