Hi,
Have been working with the ofxFiducialFinder a bit lately, and just found a bug in the libfidtrack and i wonder if any of you who’ve used the lib have seen/solved it.
Example:
One of the markers (id 6) is tracked well, except from when the angle is between 260 and 280 degrees (i wont try expressing this in radians). It happens 100% so there is probably nothing wrong with the camera image or image processing.
Another marker (id 9) has the same problem, only the critical angle is between 83 and 97 degrees. In general most markers seem to glitch when angles are close to straight.
Before i go deep in the libfidtrack code i thought i’d ask if anyone seen this problem? Could this be due to how the fiducials are classified? I asumed they where recognized through vectors from the center to the feature points and hence rotation independant, but maybe not.
btw. There was a couple of bugs in the other ofxFiducialFinder code. The marker and (specially) the finger tracking are now more stable. Will upload once i get this angle thing right…
[quote author=“cj”]Hi,
Have been working with the ofxFiducialFinder a bit lately, and just found a bug in the libfidtrack and i wonder if any of you who’ve used the lib have seen/solved it.
/cj[/quote]
Hello CJ,
this is a known segmenter bug from an older version, which is already fixed in the libfidtrack included with latest reacTIVision version. So you should be able to update it easily from there. In general it would be easier though to use a TUIO client within OF in order to stay up to date.
(it was great hanging out in yamaguchi and hope you had / are having a nice vacation…)
I agree with your point about the TUIO (and that way, they’ll stay more up to date, etc), and I’m not sure about CJ, but I think the issue is that in some instances we’ve seen, people need to access the camera data as well as process it through reativision. Is there another approach to allow you to do that?
I would say there are a few arguments to be able to see code
You have control over video input, image preprocessing, warping and so on
Of the ones ive tried, most tools didn’t to track fingers and markers well at the same time. Being able to see the chain of processing and set values hardcore helped a lot to get it right.
Upgrading the libfidtrack didn’t help any, i guess the bug is somewhere else. So, i agree, using an existing software is probably best. Just have to buy me a progressive scan camera, or can reacTIVision do deinterlacing?
Hello CJ, thanks for sending me the video for debugging and for pointing out the apparent bug. I just arrived in Linz now, and will have a look at it tomorrow.
reacTIVision does not do any deinterlacing, in fact interlaced images are really pretty unusable for reacTIVision, since the fiducial structure is destroyed when moving.
The Quicktime camera code on the mac does some deintelacing though.
Hey Zach, yes finally I found my way to the forum since this thread came up …
I had a great time in Yamaguchi and Tokyo, I wish I could go there again soon.
At the moment I will stay in Linz for a while though …
In general I would recommend to use the reacTIVision / TUIO combination, since it allows you to stay up to date and even allows to switch easily to other TUIO sources when the become available.
On the other hand if you need the camera image for some other tasks, then the integration of libfidtrack is probably the better option of course, especially if you can share even some image processing tasks such as thresholding.
So both is fine, depending what you need …
Libfidtrack is taking care of the threshold, segmentation and fiducial search.
With the latest version of reacTIVision I modified the library a bit to take advantage of the existing segmentation data in order track white blobs in addition to the fiducial symbols. I am using this data in reacTIVision to correct eventually lost symbols and for finger tracking. And I also added an error correction for unknown fiducial IDs, that’s probably why I didn’t notice that bug yet.
[quote author=“cj”]Hi,
I’ve been using the deinterlacing zach mentioned (http://forum.openframeworks.cc/t/deinterlace—opencv/443/0) with the ofxFiducialFinder and it works pretty well actually with a interalced cam. for testing at least.
/cj[/quote]
Hello CJ,
yes, this deinterlacing method should work fine, since it is only using the information of a single half-frame. But of course you only have half the resolution then so if you want to build a bigger table using rather small fiducials you are better off with a full frame progressive camera.
best,
Martin.K
Hello CJ,
well, I now just tried your image sequence, and feeding it into reacTIVision it works perfectly finding the fiducial in any frame. Have you been able to reproduce your bug with the sequence you sent?
Maybe you also could send me an individual frame with an angle that failed for you.
Hello again,
looking at your example I now have been able to reproduce the bug, using the small mixed tree file you included in your package. Since your example only includes a very small tree and the actual tree you are searching for, in that case the resulting maximum adjacencies count is lower than the usual result of the full tree file. This again is not the problem itself, since these are the maximum adjacencies of that symbol, but it brought an unsolved problem in the segmenter to the surface again, where symbols are discarded in some cases when the region adjacencies are saturated during the segmentation.
To keep the long story short, there was already a workaround - but not a solution - to that problem in the code. I adapted this workaround, so it also fixes your problem. BTW this now also fixes the problem Karsten had, when he was creating very large fiducials using his fid.gen.
You will find the updated version in the reacTIVision CVS. I also cleaned up the way the rotation angle is calculated, so this finally matches the correct orientation of the symbol (this angle was inverted and shifted by PI/2). So be aware of that.
Hi Martin,
You’re right, the problem did not appear when i use the original all.trees, and your new libfidtrack code solves the problem. Thanks a lot!
Just to understand the tracking algorithm better; is the tracker now slower than before? Why did you want to compare adjacencies in the first place, and block some?
