[PD] pix_data issue

[Jack]

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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>