On 02/27/2018 11:50 PM, Derek Holzer wrote:
I can disconnect the Gemlist from the second inlet, so that it is only getting the metro bangs at the first inlet and the X and Y coordinates to analyze at the third and fourth inlet, and still it gives data output.
I know that it is still getting the changing video signal and not just reading the last frame that came in the Gemlist, because I use the analysis data to reconstruct the image with audio signals on an external analog vector monitor, and I see that image changing and moving even if the [pix_data] receives no Gemlist.
what you are seeing is an artifact of the implementation. pixel data is handed between objects by means of a pointer into memory (which is one of the things stored in the ominous "GemList")
[pix_data] remembers that pointer so it can access the data whenever you "bang" it. if you disconnect the 2nd inlet of a [pix_data] object, it will still remember the last image you sent it - and you can still access it.
now the reason why the data is changing, is because Gem does most of it's stuff in-place, that is: it doesn't copy each of your 4k video frames for every object it goes through. instead all the objects *share* the pixel data (which is the reason why you can see "spill over" of pix-fx from one branch of your graph to another). in your case this means, that the memory where [pix_data] is reading from is the same as the memory where [pix_video] is writing to. thus [pix_data] sees updated pixels.
it is somewhat similar to arrays, where a [tabread] sees updated data even if you disconnect the "set" message. (but probably much less safe - you *might* trigger memory corruption by disconnecting [pix_data] and then somehow invalidating the memory it reads from - which could be as simple as changing the reslution of [pix_video])
Also, no scaling transformations I do to the output of [pix_video] or [pix_film] (for example by texturing it on a rectangle with a [scale] object in front of it) have any effect on what is seen by [pix_data].
hopefully. the pix_* space and the openGL space are two entirely different things. pixel data resides in the main memory of your computer. [pix_data] gives you access to this main memory. [pix_texture] copies the data to your gfx card. [scale] and [rotate] and practically all Gem objects (not prefixed with pix_) operate directly on te gfx card. whatever is done to the image data on the gfx card, has no effect on the contents in main memory.
Does [pix_data] read the pixel values from some other place than the Gemlist? A buffer of some kind? How can I apply any transformations to what it "sees"?
the naive way to do that would be using [pix_snapshot] which is the inverse of [pix_texture] (it copies image data from the gfx card to the main memory). (i call it "naive" as it is an execution path not optimized by modern gfx cards, so it might be slower than expected.) the non-naive solution would be to not require the a transfer from gfx-card to main memory and do everything on the gfx card (see also: shaders). depending on the task you want to solve, this might be feasible or not (in which case go back to [pix_snapshot])
gfmdasr IOhannes