Okay, I have been fighting with this for about 7-8 hours now, and it just isn't working.

The basic outline of the patch, now with gem objects (and leaving out some details) is:

[gemhead]
v
[pix_video]
v
[pix_movement]
v
[pix_crop] -- the x and y offsets are driven by a subpatch that acts like a nested loop
v
[pix_blob] -- mode 4 = alpha channel

... and the x, y and size outlets are packed into a list and sent out by OSC.

The problem is that pix_blob very frequently outputs nothing. This really shouldn't happen, if all the objects were doing what I think. Explanation --

Suppose in one frame, I crop the image to the top left quadrant and calculate pix_blob just for that quadrant. Then, on the next frame, I crop to the top right quadrant and get pix_blob again. The successive frames may have very different blob coordinates, and I'd expect to get the different sets of coordinates each time. Instead, pix_blob goes silent sometimes.

I thought, maybe it goes quiet because there was no change -- but these are different areas of the image, and the likelihood of having the same centroid in two different slices of the image seems rather low.

Or maybe it's because the frames are so different that pix_blob doesn't know what to do. (I have no way to guess, in the absence of documentation of exactly what pix_blob is doing.)

Sorry to keep posting so much about this, but I really have to get this working, documentation is not answering my questions, and my previous thread (link) has gone dead. I'm starting to get a bit desperate. At this point, I may have no choice but to chuck out the vast majority of the data I was hoping to get from the camera and go for just one, simple, dumb centroid. Rather frustrating.

Thanks in advance -- I will give credit in the concert program to people who can help me get this running.

James

PS You also need a 320x240 black image. saved as "black320x240.png" - I made one with GIMP. Or just delete the pix_composite part.

http://www.pdpatchrepo.info/hurleur/frame-diff-gem.pd

hi james,

sorry for the late reply, i've been really busy with work.

first thing you should give a look at the opencv library for gem. you'll find a nice frame difference object, noise removal and tracking stuff. i guess they are more accurate than native gem objects.

that said, for the slicing part two options are coming to my mind right now and none of them is easy. you could use multiple [pix_crop] chains, but i'm not sure what could happen by making 25 of them. other option is to get a texture out of [pix_video] > [pix_movement] (or something) and send it to multiple [pix_coordinate] objects, in this way you'll be using just one texture but you'll have an hard time figuring out how to extract all the 25 slices.

that's all for now, sorry i can't be more helpful than this.

update: gem handles massive slicing using [pix_crop], see patch attached. please note that if the image size is different from 320 x 240 only a small portion will be visible

http://www.pdpatchrepo.info/hurleur/videoCrop.zip

Ah, right, openCV -- I always forget about that -- I've had epic troubles trying to download from their site (from mainland China).

That's worth a look for a future iteration. For the moment, I'm under enough time pressure that I think I had better just simplify.

Well, actually I'll have one go at the [t a a a a a...] approach. Actually it wasn't clear to me that you could do that. I was worried that one pix_crop operation would alter the image and subsequent [pix_crop]s, even in a different branch, would work on the previously cropped pix. But if that's wrong, then I have no problem moving the blob stuff into a subpatch and copying it.

Thanks!
James

yes, you can place all the code you want in each [slice] abstraction and output whatever you need. like the [pix_mean_color] or the [pix_blob] thing, then you just have to route the results and send them to OSC

btw think about the opencv thing, i understand that having a pd-extended clean patch might be better for your purpose, but in my experience it's a lot more effective to spend some time setting up their library than to freak out by fine tuning gem native motion tracking objects

Sure, it's a good idea to keep opencv in mind. In this case, I was already just inches away from getting the gem approach to work. I have a feeling it would have taken more time to learn a whole new set of objects. But a future version of the project might use opencv.

BTW it's all working quite nicely now. The only hiccup is that the first time I turn on the camera in Linux, I get a whole bunch of

error: GEM: Someone sent a bogus pointer to copy2Image
error: GEM: Someone sent a bogus pointer to copy2ImageStruct
error: GEM: Someone sent a bogus pointer to copy2ImageStruct

But that goes away if I switch the camera off and switch it on again, so I'm not very worried about it. I don't remember seeing it do that in Windows.

Thanks again for all the help! It was a bit frustrating when what I thought would be a 30 minute job turned into 9-10 hours, but it's all working now !! (and in some ways, the data coming out are smoother than I was getting with gridflow).

James