args.EventData.Present allways TRUE?

Nov 15, 2008 at 6:12 PM
Edited Nov 15, 2008 at 6:16 PM
Using the UpdateMarker Event i tried to check against that variable. It never turned false. I exspected it to go to false when i move the marker out of the screen or in any other case where Marker is not tracked. Maybe i dont understand the application right. Can someone explain?

Nov 15, 2008 at 10:27 PM
Thanks for pointing this out, Balex.
Indeed, you'll only be sent UpdateMarker events when the marker is found.
An eariler iteration of the project would post these events every frame.
I suppose MarkerEventData doesn't benefit from this member anymore; I'll remove it soon.
- Mike
Dec 8, 2008 at 12:25 PM

if you need a version that supports Present==false and calculates the AvgColor whenever the marker is visible, see my patch provided under source code - patches.
This version will raise the marker event one last time when the marker becomes invisible.

I have a version applying against rev. 26756, just contact me if you need it.
(or should I upload the patch again, Mike?)

Dec 12, 2008 at 6:39 AM
Efloh, I'm really glad you uploaded those patches, I can always use a helping hand.

Your patch appears to be based off of the 1.0 source code, which has been updated significantly in the source repository.
I've fixed the representative color (again, haha) with change #26832, and I had previously removed the MarkerEventData.ColorAvg.
I don't think it's useful to provide an average color from the marker at each frame. (Marker.RepresentativeColor should be sufficient)
If anyone disagrees and would like a per-marker per-frame average color, please vote or make your case in this thread.

As for MarkerEventData.Present, I'm not sure what users of Touchless want/expect.
In the latest source, I've removed the property, and only send events when the marker is present.
Users that poll data can check the Marker's area to determine if it's present, (0Area == !Present).
However, I do see how your idea of sending a single event when the marker is lost could be helpful.
If anyone would like this change incorporated, please vote or make your case in this thread.

If you would like increased saturation on the highlight color, that's easy enough to do client side.
But if anyone would like this change incorporated into Touchless itself, please vote or make your case in this thread.

(As for the other changes regarding false positives from the highlight color, that's no longer an issue in the latest source)
Thanks for making a contribution to the Touchless community! You rock!

- Mike
Dec 12, 2008 at 1:24 PM

Hello Mike,

I watched your progress happily, I think it could be useful to have a per-frame AvgColor for example when you "paint" using a marker. The brush color would adapt more precise to the "visible" color using the per-frame value, but of course, the RepresentativeColor is fine also... Maybe one could use bool CalcuateAvgColor { get; set; } to choose if the AvgColor should be calculated per frame (or even to recalculate the RepresentativeColor per-frame; thats what I used the AvgColor indeed).

The polling of a marker is fine but, as you nevertheless have to calculate the marker presence, I is much more resource-saving when you get "went-out-of-sight" events. Maybe a better alternative to the Present property would be to add two an event PresenceChanged (using the sematics from my patch: fire once the marker changes its present value). Using this alternative, one can register for the extra events when interested. I already changed by patch to use bool Present { get { return Area > 0; }} to match the new code for more clean client code. We could reuse this.

The saturation change came just from my very own testing for my feedback. How could one add this in client code? I don't see a simple way as it can be done in the scanner loop. But I think this is really not an necessary feature for the lib.

The false positives only come from the highlighting and are gone in the new release, as far as I could observe, good work!

Another point is that I observed that the cam loop is lots slower when at least one marker was not present in the last frame as it has to do a complete scan for the whole picture instead of just the expected "motion" area. For some applications, it would be fine to "preset" if the marker is relevant/has to be searched for. For this purpose, I propose a new property bool Active {get; set; } to disable a marker temporarily without having to delete it.

If you would like, I can add these proposals to the latest release, as states above, half is already done when I updated my checkout of the lib to the new version. I simply would post a new patch containing

  • Property bool CalculateAvgColor {get; set; }
    Determines if the average color of the recognized marker pixels should be calculated in each camera frame
  • Property Color AvgColor { get; }
    Returns the average color of the recognized marker pixels from the current frame. Returns the RepresentativeColor when CalculateAvgColor is set to false.
  • Property bool Present { get; }
    Returns if the marker is currently recognized. Returns true if the Area property is > 0, else false.
  • Property bool Active { get; set; }
    Determines if the marker should be checked for presencein each camera frame and if events should be raised for this marker. When set to false, the system behaves as if the marker was not defined and completely ignores this marker.
  • Event OnPresenceChanged(object sender, MarkerEventArgs e)
    Raised when the Present property of a marker changes. e.Present will return the new state of the marker.

Of course, I am open to other proposals...

BTW: in your pre/post build events, you should add quotation marks around the copy parameters (copy "fromfile" "tofile") because when the paths contain spaces, the commands will fail else.

- Florian

Dec 13, 2008 at 4:23 PM

Hi again,

just had some time, see the patches section for a patch matching my above description... (touchless_present_avgcolor_svn26832)

  • [BUG] Demo Application did not check if a marker is selected at all when clicking the remove button.
  • [FEATURE] Marker.ToString() now contains info if the marker is visible and active.
    Adapted Demo Application to only show the Marker Name in the Marker ComboBox.
  • [FEATURE] added HSV.ToString() for debug purposes.
  • [FEATURE] added property Marker.CalculateAvgColor to enable AvgColor calculation in each cam image scanning loop.
  • [FEATURE] added property Marker.Active to be able to "ignore" markers in the cam image scanner loop (and marker events)
  • [FEATURE] added event Marker.OnPresenceChanged that is fired whenever the marker becomes detected or becomes invisble.
    Adapted comments for event Marker.OnChange and Marker.OnPresenceChanged.
  • [FIX] Renamed Marker.FireMarkerEventData() to Marker.FireMarkerChangedEvent to better match the name of the fired event.
  • [FEATURE] Added MarkerEventData.Present for cleaner code. Returns true iif MarkerEventData.Area > 0.
  • [FEATURE] Added MarkerEventData.ColorAvg. Returns the average color of the recognized pixels when Marker.CalculateAvgColor is set to true, else returns
    the Marker.RepresentativeColor.
  • [INFO] Added TODO about thread safety in TouchlessMgr.UpdateMarkers
  • [FIX] Adapted TouchlessMgr.UpdateMarkers to obey the Marker.Active property and only calulate the MarkerEventData.AvgColor when Marker.CalulateAvgColor
    is set to true.
  • [FIX] Adapted TouchlessMgr.postProcessMarker to use the Present property and determine which events (OnChange, OnPresenceChanged) to fire.