just a little remark : This is [pix_snap] (and not [pix_snapshot]) to get back pixels buffer from your gfx card to the RAM of your computer ;) ++
Jack Le 28/02/2018 à 09:54, IOhannes m zmölnig a écrit : > 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 > > > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list