-----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@x1,y1 blob2@x2,y2" whereas the new one will output "blob1@x1,y1 blob2@x3,y3 blob3@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