Re: [PD] pix_video alphachannel
hello I've seen your message on the pd list about alpha mix of live input I'had got the same problem as you with the pix_mix box (vertical flip) It seems that gem prefers working in 3D than with pix_ objects ... so I've made this box to mix two sources (the mix is in 3D however, it's not recordable with pix_record, but it's viewable) --- #N canvas 122 21 618 206 12; #N canvas 73 182 1032 463 melangeur_3D 0; #X obj 88 346 rectangle 5 4; #X obj 78 -9 inlet; #X msg 323 71 quality \$1; #X obj 323 52 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 1 1 ; #X obj 90 229 pix_texture; #X obj 90 251 alpha; #X obj 179 158 pix_coloralpha; #X obj 78 187 pix_takealpha; #X obj 180 134 pix_levels; #X msg 197 99 \$1 1 1 0; #X floatatom 193 30 5 0 0 0 - - -; #X floatatom 193 76 5 0 0 0 - - -; #X obj 192 53 / 100; #X obj 244 -12 loadbang; #X msg 324 31 1; #X obj 470 343 rectangle 5 4; #X obj 472 -10 inlet; #X obj 472 226 pix_texture; #X obj 477 250 alpha; #X obj 571 168 pix_coloralpha; #X obj 472 196 pix_takealpha; #X obj 572 144 pix_levels; #X floatatom 575 27 5 0 0 0 - - -; #X floatatom 575 73 5 0 0 0 - - -; #X obj 574 50 / 100; #X msg 527 28 69; #X msg 145 31 80; #X obj 640 -58 inlet; #X obj 827 104 pack f f f f; #X floatatom 778 25 5 0 0 0 - - -; #X floatatom 778 64 5 0 0 0 - - -; #X obj 778 43 / 100; #X floatatom 827 24 5 0 0 0 - - -; #X floatatom 825 65 5 0 0 0 - - -; #X obj 824 42 / 100; #X floatatom 875 22 5 0 0 0 - - -; #X floatatom 873 63 5 0 0 0 - - -; #X obj 872 40 / 100; #X floatatom 921 22 5 0 0 0 - - -; #X floatatom 919 63 5 0 0 0 - - -; #X obj 918 40 / 100; #X obj 826 83 t b f; #X obj 873 85 t b f; #X obj 924 86 t b f; #X msg 579 96 0.7 1 \$1 0; #X connect 1 0 8 0; #X connect 1 0 7 0; #X connect 2 0 4 0; #X connect 2 0 17 0; #X connect 3 0 2 0; #X connect 4 0 5 0; #X connect 5 0 0 0; #X connect 6 0 7 1; #X connect 7 0 4 0; #X connect 8 0 6 0; #X connect 9 0 8 1; #X connect 10 0 12 0; #X connect 11 0 9 0; #X connect 12 0 11 0; #X connect 13 0 26 0; #X connect 13 0 14 0; #X connect 13 0 25 0; #X connect 14 0 3 0; #X connect 16 0 21 0; #X connect 16 0 20 0; #X connect 17 0 18 0; #X connect 18 0 15 0; #X connect 19 0 20 1; #X connect 20 0 17 0; #X connect 21 0 19 0; #X connect 22 0 24 0; #X connect 23 0 44 0; #X connect 24 0 23 0; #X connect 25 0 22 0; #X connect 26 0 10 0; #X connect 27 0 22 0; #X connect 28 0 21 1; #X connect 29 0 31 0; #X connect 30 0 28 0; #X connect 31 0 30 0; #X connect 32 0 34 0; #X connect 33 0 41 0; #X connect 34 0 33 0; #X connect 35 0 37 0; #X connect 36 0 42 0; #X connect 37 0 36 0; #X connect 38 0 40 0; #X connect 39 0 43 0; #X connect 40 0 39 0; #X connect 41 0 28 0; #X connect 41 1 28 1; #X connect 42 0 28 0; #X connect 42 1 28 2; #X connect 43 0 28 0; #X connect 43 1 28 3; #X connect 44 0 21 1; #X restore 204 88 pd melangeur_3D; #X text 330 59 mix amount (0-100); #X text 244 60 source 2; #X text 150 61 source 1; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_video alphachannel
[EMAIL PROTECTED] wrote: hello I've seen your message on the pd list about alpha mix of live input I'had got the same problem as you with the pix_mix box (vertical flip) well, this is basically a problem of how the images are presented to Gem by whichever source. some systems prefer to anchor an image at the upper-right corner, others (like openGL) prefer to assume that (0/0) is in the lower-right corner. this makes images from one system appear upside down in the other. luckily, Gem automatically takes care of this when it comes to texturing (so you normally shouldn't notice). however, when you want to combine 2 such sources, Gem uses the raw data (for performance reasons), and ignores if one of the 2 images is flipped upside down. thats why you get weird effects in such cases. how to cope with this: 1) don't use pix_objects for doing things you can do without (e.g. mixing) 2) recode the combining pix_objects to obey the upside down flags 3) flip on of the images via the [pix_flip] object It seems that gem prefers working in 3D than with pix_ objects ... obivously, since this is what Gem is made for. you can get a lot of performance from this. so I've made this box to mix two sources (the mix is in 3D however, it's not recordable with pix_record, but it's viewable) it _is_ recordable via [pix_record]; use [pix_snap]. mfg.asdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
