[PD] pix_data issue

[IOhannes m zmölnig]

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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180228/27f4956d/attachment.sig>