[GEM-dev] [PD] multiblob tracking in Gem while objects keep their IDs

[IOhannes m zmoelnig]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(moving the post to gem-dev)

On 2013-06-16 19:58, Max wrote:
> 
> Now that it's clarified that this is a bug, not a feature. It 
> should be evaluated why it behaves differently and if it is worth 
> it to keep the changes or we can go back to the original.

yes.

i haven#t fully reviewed the new algorithm, but the main motivation
(for me to include it) was that it supports a dynamic number of blobs
(rather than a fixed maximum number). i think that *this* behaviour is
desirable and i don't really see how it would break compatibility.
(and if it does break compatibility, i think that it can easily be
fixed: e.g. by explicitely specifying a maximum-number-of-blobs (using
the argument) it will become static/fixed, and if you don't specify no
number it is dynamic).

the other thing is how blobs are detected. here there might be some
incompatibility, which ought to be investigated and fixed.

> What can i do, to help fixing it? I didn't quite understand what 
> you
meant at the IRC.

isolating the problem to a static patch ("static" in the sense that it
doesn't require any moving images), so we can do: "if i feed imageA
into the object, the old version will output "blob1 at x1,y1 blob2 at x2,y2"
whereas the new one will output "blob1 at x1,y1 blob2 at x3,y3 blob3 at x4,y4"

finally, we have to make sure that the problem is not simply related
to a "wrong" output order. e.g. do the downstream algorithms (in
Bewegungsmelder) assume that the (upstream) blob-labels are ordered
from top-left to bottom-right?

> Maybe ricoardo can tell us more about the changes? If the changes 
> are worth to keep but can't be compatible to the original i see
> two options: 1. make ricardos version pix_multiblob2

anything but this name!
personally i do have the bad habit of using version numbers in object
names ([pix_texture2], [pix_movement2]) but i always regretted it
(even though [pix_texture2] is somehow related to (non) power-of-two
textures (hence the '2'), and [pix_movement2] is something like a "2nd
order" [pix_movement]).

> 2. send a message (and second argument) to pix_multiblob to set it 
> to the alternative (ricardos) mode.

hmm.. i always wanted to add a 2nd argument / mode-message to change
the output format from the current "iemmatrix" mode to a more pd-ish
format (a number of lists).
i'm a bit afraid of having too many options for anybody to be able to
handle.

but yes, basically these are the two ways how to proceed if the two
algorithms cannot be made compatible. (and i only wrote down my
concerns so we can circumvent them)



fgmasdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlG+u5IACgkQkX2Xpv6ydvTJVQCgvEsu+n5z/RJ67lMgMWlK2ykB
ZiIAn37sRWYAIBbRo5g8nvxrcFqyyVWn
=Sy5e
-----END PGP SIGNATURE-----