{ "blyg": "0.4", "id": "2va72wbgs5e6nw8mp2zdf5xxxj", "kind": "thread", "origin": "https://notionparallax.co.uk/", "page": "https://notionparallax.co.uk/2008/the-experiment-continues", "author": { "name": "Ben Doherty", "url": "https://notionparallax.co.uk/" }, "created": "2008-03-31T02:55:41Z", "updated": "2008-03-31T02:55:41Z", "version": 1, "content_md": "# the experiment continues\n\n\n

upon getting stuck into any seemingly simple problem, more complicated things always seem to arise.

\n

I think I'll get something at least a little bit useful out of this soon though.

\n

lots of tests and diagrams after this

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
This is the stock code for finding blobs, but with an extra line that marks the centres of the boxes
They make a bit more sense with just the edges turned on.
\nUltimately the display of all this data will be switched off to maximise running speed.
The centre markers can be tagged...
..with a number to identify them.
\nThis highlights a problem that I had anticipated. The numbering (array index) of the blobs is dynamically assigned. They are detected on a frame by frame basis, and therefore the numbering is not consistent across frames. This means that the paths can't just be drawn, but I'll need to do some sort of proximity search to find the nearest one to the previous one, and just hope that the movement isn't sufficiently large to upset the progression.
First attempts at tracking points are proving tricky, even without any sort of continuity tracking.
If the vertices with 0,0 coords are removed, it just spatters points.
\nThis also highlights the vast quantity of data that I am gathering here.
\nThere will probably need to be some sort of data reduction at the end, as at 10 fps, with 5 blobs, that produces 100 values a second, so even recording for a minute will make a huge dataset.
\n

The mapping of a point from frame to frame is going to prove to be the most complicated part of this operation
\nThe possible options for frame to frame changes in path coordinate arrays. I'm going to have a go at implementing a solution that tests to see if there is a centroid in the previous frame within 10ish pixels of the current one, then if there is, starts measuring it's path and adds the list of coords to a list.
\nIt'll take a bit of fiddling to find out how to work with lists in processing, but it should work.I should probably also implement a filter that only bothers dealing with blobs if they are over a certain number of pixels in area, as suggested here.There are all kinds of issues that will probably pop up. I find this sort of data management/array stuff quite hard to get my head around. I wonder why?

\n", "content_html": "

the experiment continues

\n

upon getting stuck into any seemingly simple problem, more complicated things always seem to arise.

\n

I think I’ll get something at least a little bit useful out of this soon though.

\n

lots of tests and diagrams after this

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
This is the stock code for finding blobs, but with an extra line that marks the centres of the boxes
They make a bit more sense with just the edges turned on.
\nUltimately the display of all this data will be switched off to maximise running speed.
The centre markers can be tagged...
..with a number to identify them.
\nThis highlights a problem that I had anticipated. The numbering (array index) of the blobs is dynamically assigned. They are detected on a frame by frame basis, and therefore the numbering is not consistent across frames. This means that the paths can't just be drawn, but I'll need to do some sort of proximity search to find the nearest one to the previous one, and just hope that the movement isn't sufficiently large to upset the progression.
First attempts at tracking points are proving tricky, even without any sort of continuity tracking.
If the vertices with 0,0 coords are removed, it just spatters points.
\nThis also highlights the vast quantity of data that I am gathering here.
\nThere will probably need to be some sort of data reduction at the end, as at 10 fps, with 5 blobs, that produces 100 values a second, so even recording for a minute will make a huge dataset.
\n

The mapping of a point from frame to frame is going to prove to be the most complicated part of this operation
\n</embed>The possible options for frame to frame changes in path coordinate arrays. </embed>I’m going to have a go at implementing a solution that tests to see if there is a centroid in the previous frame within 10ish pixels of the current one, then if there is, starts measuring it’s path and adds the list of coords to a list.
\nIt’ll take a bit of fiddling to find out how to work with lists in processing, but it should work.I should probably also implement a filter that only bothers dealing with blobs if they are over a certain number of pixels in area, as suggested here.There are all kinds of issues that will probably pop up. I find this sort of data management/array stuff quite hard to get my head around. I wonder why?

\n", "content_hash": "sha256:da6d7174fc65482990fb7c0b8504e700e417258500cad094be6362e9cf53059e", "media": [], "changelog": [ { "version": 1, "at": "2008-03-31T02:55:41Z", "note": null } ], "transclusions": [] }