hi everybody, i want to do per pixel image manipulation in gem (running pd.extended 0.39-3). so far i've been trying pix_dump with a lister and then until with packel to access individual rgba values in a loop. after i do the manipulations i accumulate them back into a list using repack and send it to pix_set.
it all works out pretty smooth. only problem is the list that gets sent to pix_set somehow seems to get one float prepended, which effectively shifts all the rgba-values one step and messes up the colors.
any advice/examples on a correct pix_dump / pix_set setup? ...any other solutions?
thx, martin
hi martin, not sure where you want to go with that, but if you want to create visuals stuff, you should dive into glsl programming and do your manipulations in shader language. this is extremely efficient and fast. there are examples by cyrille and the pd montreal community (alexandre etc). there is also a mailing list (glslang@dataflow.ws). for your patch it could be a triggerproblem, but difficult to say without seeing it. marius.
Martin Leopold Grödl wrote:
hi everybody, i want to do per pixel image manipulation in gem (running pd.extended 0.39-3). so far i've been trying pix_dump with a lister and then until with packel to access individual rgba values in a loop. after i do the manipulations i accumulate them back into a list using repack and send it to pix_set.
it all works out pretty smooth. only problem is the list that gets sent to pix_set somehow seems to get one float prepended, which effectively shifts all the rgba-values one step and messes up the colors.
any advice/examples on a correct pix_dump / pix_set setup? ...any other solutions?
thx, martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hi marius & others, thanks for pointing me to glsl, i will have a look!
but for now i think i found what's causing the trouble: actually i want to apply per pixel manips continuously on a stream of pixes. eg. video from pix_film. so i was constantly triggering pix_dump with the gemhead. when triggering pix_dump manually it works fine. (see attached test-patch)
i know it's not very efficient to do it like that in the first place (pix_dump/pix_set), but is there a way to properly "synchronize" it all? i want to have a data flow like this: [gemhead] -> [pix_image] or [pix_film] -> [pix_dump] -> manipulate data -> [pix_set] -> output on screen
---martin.
marius schebella schrieb:
hi martin, not sure where you want to go with that, but if you want to create visuals stuff, you should dive into glsl programming and do your manipulations in shader language. this is extremely efficient and fast. there are examples by cyrille and the pd montreal community (alexandre etc). there is also a mailing list (glslang@dataflow.ws). for your patch it could be a triggerproblem, but difficult to say without seeing it. marius.
Martin Leopold Grödl wrote:
hi everybody, i want to do per pixel image manipulation in gem (running pd.extended 0.39-3). so far i've been trying pix_dump with a lister and then until with packel to access individual rgba values in a loop. after i do the manipulations i accumulate them back into a list using repack and send it to pix_set.
it all works out pretty smooth. only problem is the list that gets sent to pix_set somehow seems to get one float prepended, which effectively shifts all the rgba-values one step and messes up the colors.
any advice/examples on a correct pix_dump / pix_set setup? ...any other solutions?
thx, martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Martin Leopold Grödl wrote:
hi marius & others, thanks for pointing me to glsl, i will have a look!
but for now i think i found what's causing the trouble: actually i want to apply per pixel manips continuously on a stream of pixes. eg. video from pix_film. so i was constantly triggering pix_dump with the gemhead. when triggering pix_dump manually it works fine. (see attached test-patch)
the problem you are experiencing is, that [pix_dump] will output an empty list (aka "bang") the first time it is called (no image yet at its input)
the bang will be distributed down your "processing" chain, and eventually, in [* 0.5] it will be converted into a number "0" which will be the first element in your [repack 100], thus introducing an offset.
the most naive workaround is to filter the bang with a [route bang].
apart from that: why do you manually unwrap the lists? [repack 1] will do just as well. and for scalability, you should dynamically size the [repack 100]
(see attached patch)
i know it's not very efficient to do it like that in the first place
indeed, it is not...:-)
fgmasdrö IOhannes
#N canvas 783 11 739 891 12; #X obj 216 -22 gemhead; #X obj 206 878 square; #X obj 56 309 gemwin; #X msg 43 76 create , 1; #X msg 80 108 destroy; #X msg 89 274 frame $1; #X obj 269 266 pix_dump; #X obj 91 212 loadbang; #X obj 207 805 pix_set 5 5; #X msg 229 771 RGBA; #X obj 229 745 loadbang; #X obj 327 325 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 403 676 repack 100; #X msg 90 190 bang; #X obj 19 155 r gw; #X obj 260 160 pix_alpha; #X msg 314 122 1 1 1; #X obj 271 83 t a b; #X msg 277 121 0; #X msg 130 238 25; #X msg 48 485 0; #X obj 51 563 s gw; #X msg 48 396 bang; #X msg 80 486 1; #X obj 48 463 del 500; #X obj 48 421 t b 1 b; #X obj 207 845 pix_texture; #X obj 403 627 * 0.5; #X floatatom 458 605 5 0 0 0 - - -; #X msg 86 140 reset; #X obj 500 360 pls 8 pix_dump; #X msg 95 529 frame 5; #X msg 95 550 frame 25; #X obj 217 28 pix_image w55.jpg; #X text 240 697 the list seems to be right-shifted by one element?!? ; #X msg 400 171 bang; #X text 197 584 do some manips here. for instance multiply by some value; #X text 378 27 5x5 pixels white square; #X obj 257 212 t b a; #X msg 90 239 1; #X msg 95 508 frame 1; #X obj 406 848 pls 8 pix_set:; #X text 299 718 square should be white. not colored; #X text 305 192 manually triggering pix_dump works fine; #X text 308 213 <- remove trigger to test it; #X text 368 229 (and reload patch!); #X text 498 315 debug output; #X text 497 331 beginning of the dumped list; #X obj 367 319 t a a a; #X obj 367 397 repack 1; #X obj 403 369 length; #X connect 0 0 33 0; #X connect 3 0 2 0; #X connect 4 0 2 0; #X connect 5 0 2 0; #X connect 6 0 8 0; #X connect 6 1 11 0; #X connect 6 1 48 0; #X connect 7 0 39 0; #X connect 8 0 26 0; #X connect 9 0 8 0; #X connect 10 0 9 0; #X connect 12 0 8 1; #X connect 12 0 41 0; #X connect 13 0 39 0; #X connect 14 0 2 0; #X connect 15 0 38 0; #X connect 16 0 15 3; #X connect 17 0 15 0; #X connect 17 1 16 0; #X connect 17 1 18 0; #X connect 18 0 15 1; #X connect 19 0 5 0; #X connect 20 0 21 0; #X connect 22 0 25 0; #X connect 23 0 21 0; #X connect 24 0 20 0; #X connect 25 0 24 0; #X connect 25 1 23 0; #X connect 25 2 40 0; #X connect 26 0 1 0; #X connect 27 0 12 0; #X connect 28 0 27 1; #X connect 29 0 2 0; #X connect 31 0 21 0; #X connect 32 0 21 0; #X connect 33 0 17 0; #X connect 35 0 6 0; #X connect 38 0 6 0; #X connect 38 1 6 0; #X connect 39 0 5 0; #X connect 40 0 21 0; #X connect 48 0 49 0; #X connect 48 1 50 0; #X connect 48 2 30 0; #X connect 49 0 27 0; #X connect 50 0 12 1;
IOhannes, thank you very much, that trick with [repack] fits nicely. ;) still beginning pd, you see... and i'm already starting to love that zexy library ;)
thx again, martin
IOhannes m zmoelnig schrieb:
Martin Leopold Grödl wrote:
hi marius & others, thanks for pointing me to glsl, i will have a look!
but for now i think i found what's causing the trouble: actually i want to apply per pixel manips continuously on a stream of pixes. eg. video from pix_film. so i was constantly triggering pix_dump with the gemhead. when triggering pix_dump manually it works fine. (see attached test-patch)
the problem you are experiencing is, that [pix_dump] will output an empty list (aka "bang") the first time it is called (no image yet at its input)
the bang will be distributed down your "processing" chain, and eventually, in [* 0.5] it will be converted into a number "0" which will be the first element in your [repack 100], thus introducing an offset.
the most naive workaround is to filter the bang with a [route bang].
apart from that: why do you manually unwrap the lists? [repack 1] will do just as well. and for scalability, you should dynamically size the [repack 100]
(see attached patch)
i know it's not very efficient to do it like that in the first place
indeed, it is not...:-)
fgmasdrö IOhannes
-
IOhannes m zmoelnig -
marius schebella -
Martin Leopold Grödl