Forums > Jitter

Width and height of rectangular CV.Jit "Blobs"

July 5, 2009 | 6:25 am

Hello,

This is a question for CV.Jitter and Lobject users…

I’ve spent the whole day trying to figure out why this patch doesn’t work. I ignore if this is related to the Max data-flow (bottom-right)or whatever.

What I’m trying to do is calculate the length of 2 sides from all rectangular blobs registered by [cv.jit.blob.bounds]. So far I only get the correct length for height; width tends to become a list of 0′s for some unknown reason.

If someone can help me make this right and explain to me why this happens, it would mean much to me…

Thanks to all for your time and dedication!

– Pasted Max Patch, click to expand. –

July 5, 2009 | 7:45 am

Here you go:

– Pasted Max Patch, click to expand. –

July 5, 2009 | 8:41 am

Thank you very much Zachary!

I appreciate your help (and the cleanliness of the patch) but there’s just one problem:

Through [jit.itter] it will always be displaying the last rectangle from every display refresh; in my particular setting this last blob rectangle is the smallest, and my idea was to get the biggest blob’s width and height (and hopefully all blobs’ dimensions to perform some testing).

Could you please lend me another hand?

Thanks for your time…


July 5, 2009 | 7:34 pm

Hi Radiotonga,

How about this? This should at least get you going, you can see that the 1st blob isn’t always the largest blob (it may start off that way, but it can change).

best,
Zachary

– Pasted Max Patch, click to expand. –

July 5, 2009 | 8:10 pm

That’s just it!

I do realize that the biggest blob isn’t necessarily the first one; now I’ll just try to crack the logic of your patch (e.g. [jit.iter] after [t l l]).

Thanks a lot for your quick and helpful response, I’ve learn a lot from your approach. I don’t want to abuse, but if you have some more spare time I would like to know why my approach didn’t work (did it have anything to do with Max data-flow, for instance?).

Of course if you don’t want to, that’s ok. I’m infinitely grateful as it is.

Have a nice day!


July 5, 2009 | 10:13 pm

I haven’t taken a close look at your original patch, but one problem I see is with the jit.unpack going to a jit.pack. There is an ordering of operations issue. The way you have it hooked up, you’re packing the current plane 3 with the previous plane 0, 1, and 2. But I think you can figure out the rest with some analysis, and research where necessary. Good luck.

best,
Zachary


July 17, 2009 | 1:17 am

radiotonga wrote on Mon, 06 July 2009 05:10

I do realize that the biggest blob isn’t necessarily the first one; now I’ll just try to crack the logic of your patch (e.g. [jit.iter] after [t l l]).

Actually, if you specify @mode 1 to cv.jit.label, the first blob will always be the biggest. (Sadly, this means Zachary went through a lot of trouble when there was a much simpler solution.)

You can use jit.iter with a gate to access individual blobs, or you can also use named matrices, which may be a bit cleaner but might confuse beginners.

– Pasted Max Patch, click to expand. –

July 17, 2009 | 9:45 am

Sh*@#%t. I can’t believe I missed that in the help – know I used it at some point. Well, thanks for the correction Jean Marc.

I still might be missing something though. With @charmode 1 @mode 1, cv.jit.label should order the matrix according to size, right?

So here’s the patch that does it this way, also with my extremely inefficient method alongside it. I’ve noticed the results vary. See the attached image:

-at this momennt, with @mode 1, the 1st cell in the matrix in not the largest blob. It has a width of 171 and height of 116 – that’s an area of 19836.

-my method shows another cell containing the largest blob, with a width of 143 and height of 164 – that’s an area of 23452.

I bet I’m making some stupid mistake with the use of the cv objects here. Any ideas?

best,
Zachary

– Pasted Max Patch, click to expand. –

July 17, 2009 | 10:08 am
Zachary Seldess wrote on Fri, 17 July 2009 18:45

-my method shows another cell containing the largest blob, with a width of 143 and height of 164 – that’s an area of 23452.

I bet I’m making some stupid mistake with the use of the cv objects here. Any ideas?

Two things: first, you calculate the area from the bounding box but cv.jit.label uses the actual area, or mass, or the blob. If you have something like a very thin diagonal line, the bounding box may be huge, but the actual area not so much.

Secondly, if you haven’t updated your externals in a while, there used to be a bug that was fixed a while ago that used to cause some mistaken ordering in mode 1.


Viewing 9 posts - 1 through 9 (of 9 total)