Re: [PD] pix_invert for livevideo?
thank you - both worked great! the extended help patch for pix_multiblob was great, without that i would have never figured out how it actually works. pix_invert works after pix_rgba, i use pix_grey afterwards. thank you again, emanuel On 25 Sep 2007, at 15:12, -- wrote: hi, I quickly integrated [mtx] object in the help patch to have separates values for each blob ... if it can help works on linux Pd-extended rc5 pix_invert works fine for me : maybe [pix_rgba] after your [pix_video] ? a++ benjamin IOhannes m zmoelnig a écrit : |||__||| wrote: also i'm not really sure about the way the list works that pix multiblob outputs: am i right assuming that i have to add + 10 for every additional blob in order to get their values? so $6 is minX for the first blob, $16 minXfor the second blob... ? for now, the [pix_multiblob] outputs a matrix (as used by the iemmatrix objects). the format is matrix rows columns el_1_1 el_1_2 ... el_1_columns el_2_1 ... ... el_rows_columns so if you [list split] the meta information matrix rows columns then your assumption is somewhat correct: the #columns is 8(!) mfga.sdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list #N canvas 509 42 863 826 10; #X obj 9 265 cnv 15 430 145 empty empty empty 20 12 0 14 -233017 -66577 0; #X text 40 267 Inlets:; #X text 39 352 Outlets:; #X obj 9 227 cnv 15 430 30 empty empty empty 20 12 0 14 -195568 -66577 0; #X text 18 226 Arguments:; #X obj 8 56 cnv 15 430 165 empty empty empty 20 12 0 14 -233017 -66577 0; #X obj 449 37 cnv 15 200 380 empty empty empty 20 12 0 14 -228992 -66577 0; #X obj 451 684 cnv 15 100 60 empty empty empty 20 12 0 14 -195568 -66577 0; #N canvas 0 0 450 300 gemwin 0; #X obj 132 136 gemwin; #X obj 64 202 outlet; #X obj 67 10 inlet; #X msg 64 183 set destroy; #X msg 132 112 create \, 1; #X msg 216 117 destroy; #X msg 190 58 set create; #X obj 67 41 route create; #X obj 219 6 inlet; #X connect 2 0 7 0; #X connect 3 0 1 0; #X connect 4 0 0 0; #X connect 5 0 0 0; #X connect 6 0 1 0; #X connect 7 0 3 0; #X connect 7 0 4 0; #X connect 7 1 6 0; #X connect 7 1 5 0; #X connect 8 0 0 0; #X restore 456 723 pd gemwin; #X msg 456 704 destroy; #X text 452 683 Create window:; #X obj 451 133 cnv 15 185 120 empty empty empty 20 12 0 14 -24198 -66577 0; #X obj 451 43 gemhead; #X text 17 366 Outlet 1: gemlist; #X text 24 281 Inlet 1: gemlist; #X obj 453 605 pix_texture; #X floatatom 491 235 3 0 100 2 threshold - -; #X obj 491 252 / 100; #X text 71 31 Class: pix object (analysis); #X msg 491 273 treshold \$1; #X floatatom 581 235 3 0 100 2 blobsize - -; #X obj 581 252 / 100; #X msg 581 273 blobSize \$1; #X text 24 296 Inlet 1: treshold float: minimum luminance of a pixel to be considered part of a blob. (default=0.04); #X text 24 325 Inlet 1: blobSize float: minimum relative size of a blob. (default=0.1); #X text 50 12 Synopsis: [pix_multiblob]; #X text 29 57 Description: blob detector (for multiple blobs); #X text 17 73 [pix_multiblob] is able to detect multiple blobs within an image.; #X text 17 103 a blob is a number of adjacent(!) pixels with a luminance that is bigger than the value defined by treshold. you can set the minimum size of a blob that is needed to be detected.; #X text 17 156 the output is a matrix following the conventions of the mtx-objects from zexy/iemmatrix. each row describes one detected blob as follows: centerX(weighted) \, centerY(weighted) \, size (weighted) \, minX \, minY \, maxX \, maxY \, size; #X text 64 237 int: max number N of blobs to detect; #X text 17 381 Outlet 2: (k \, 8) matrix: describing k detected blobs (with 0=kN); #X obj 604 114 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 453 325 pix_multiblob 6; #X obj 451 111 pix_video; #X msg 683 93 driver 0; #X obj 453 660 rectangle 5.33 4; #X msg 683 69 device 1; #X obj 451 146 pix_rgba; #X floatatom 580 465 5 0 0 1 x - -; #X floatatom 581 481 5 0 0 1 y - -; #X floatatom 581 497 5 0 0 1 size - -; #X floatatom 582 513 5 0 0 1 minX - -; #X floatatom 582 529 5 0 0 1 minY - -; #X floatatom 583 545 5 0 0 1 maxX - -; #X floatatom 583 561 5 0 0 1 maxY - -; #X floatatom 584 577 5 0 0 1 area - -; #N canvas 183 567 687 354 showblob 0; #X obj 67 86 inlet blobinformation; #X obj 67 138 unpack 0 0 0 0 0 0 0 0; #X obj 67 167 outlet weightedX; #X obj 88 187 outlet weightedY; #X obj 109 207 outlet weightedSize; #X obj 156 236 outlet minX; #X obj 177 256 outlet minY; #X obj 243 236 outlet maxX; #X obj 260 256 outlet maxY; #X obj 348 238 outlet size; #X text 60 45 this extracts information of the 1st detected blob; #N canvas 517 405 450 300 rectangle 0; #X obj 68 75 inlet; #X obj 215 -1 inlet; #X obj 68 269 rectangle; #X obj 68 234
Re: [PD] pix_invert for livevideo?
|||__||| wrote: thank you - both worked great! the extended help patch for pix_multiblob was great, without that i would have never figured out how it actually works. pix_invert works after pix_rgba, i use pix_grey afterwards. so the problem only occurs when [pix_invert]ing a greyscale image? ma.-sdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_invert for livevideo?
|||__||| wrote: but it only processes the upper half image, the lower half stays normal is there a solution or another way to invert a live video signal in gem? which os?which Gem version? does it go away if you put a [pix_buf] before the [pix_invert] ? mfga-sdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_invert for livevideo?
IOhannes m zmoelnig wrote: |||__||| wrote: but it only processes the upper half image, the lower half stays normal is there a solution or another way to invert a live video signal in gem? which os?which Gem version? does it go away if you put a [pix_buf] before the [pix_invert] ? and do you think it is related to http://sf.net/tracker/index.php?func=detailaid=1609198group_id=64325atid=507079 mfg.asdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_invert for livevideo?
On 25 Sep 2007, at 08:38, IOhannes m zmoelnig wrote: but it only processes the upper half image, the lower half stays normal is there a solution or another way to invert a live video signal in gem? which os?which Gem version? does it go away if you put a [pix_buf] before the [pix_invert] ? and do you think it is related to http://sf.net/tracker/index.php? func=detailaid=1609198group_id=64325atid=507079 ah - misunderstanding: i'm not trying to flip the image, i want to turn white pixels black and black pixels white. using pix_buf didn't work. i use pd 039.3-extended-rc5 with gem 0.91-cvs on OSX 10.4.10, now on a 1.83ghz intel mini mac. best, emanuel ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_invert for livevideo?
alright - so this looks like a bug with no way around it? my problem is, that i want to use pix_multiblob to track 3 black stones on a white table, but pix_multiblob recognizes blobs only it they are brighter than their ambiance. is there anyone who has ideas how to work around this problem? also i'm not really sure about the way the list works that pix multiblob outputs: am i right assuming that i have to add + 10 for every additional blob in order to get their values? so $6 is minX for the first blob, $16 minXfor the second blob... ? thank you for your help! emanuel On 25 Sep 2007, at 11:28, IOhannes m zmoelnig wrote: |||__||| wrote: ah - misunderstanding: i'm not trying to flip the image, i want to turn white pixels black and black pixels white. no misunderstanding. but the problem might appear not only with [pix_invert] but also with other pix-objects... mfga.dr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_invert for livevideo?
|||__||| wrote: also i'm not really sure about the way the list works that pix multiblob outputs: am i right assuming that i have to add + 10 for every additional blob in order to get their values? so $6 is minX for the first blob, $16 minXfor the second blob... ? for now, the [pix_multiblob] outputs a matrix (as used by the iemmatrix objects). the format is matrix rows columns el_1_1 el_1_2 ... el_1_columns el_2_1 ... ... el_rows_columns so if you [list split] the meta information matrix rows columns then your assumption is somewhat correct: the #columns is 8(!) mfga.sdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_invert for livevideo?
IOhannes m zmoelnig wrote: |||__||| wrote: also i'm not really sure about the way the list works that pix multiblob outputs: am i right assuming that i have to add + 10 for every additional blob in order to get their values? so $6 is minX for the first blob, $16 minXfor the second blob... ? for now, the [pix_multiblob] outputs a matrix (as used by the iemmatrix objects). this means that it is probably the best idea to use the iemmatrix library to extract the data from the list. it also means that in future version there will probably be an alternative output format (in order to not depend on iemmatrix) (this will be optional to not break older patches) fma.sdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_invert for livevideo?
hi, I quickly integrated [mtx] object in the help patch to have separates values for each blob ... if it can help works on linux Pd-extended rc5 pix_invert works fine for me : maybe [pix_rgba] after your [pix_video] ? a++ benjamin IOhannes m zmoelnig a écrit : |||__||| wrote: also i'm not really sure about the way the list works that pix multiblob outputs: am i right assuming that i have to add + 10 for every additional blob in order to get their values? so $6 is minX for the first blob, $16 minXfor the second blob... ? for now, the [pix_multiblob] outputs a matrix (as used by the iemmatrix objects). the format is matrix rows columns el_1_1 el_1_2 ... el_1_columns el_2_1 ... ... el_rows_columns so if you [list split] the meta information matrix rows columns then your assumption is somewhat correct: the #columns is 8(!) mfga.sdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list #N canvas 509 42 863 826 10; #X obj 9 265 cnv 15 430 145 empty empty empty 20 12 0 14 -233017 -66577 0; #X text 40 267 Inlets:; #X text 39 352 Outlets:; #X obj 9 227 cnv 15 430 30 empty empty empty 20 12 0 14 -195568 -66577 0; #X text 18 226 Arguments:; #X obj 8 56 cnv 15 430 165 empty empty empty 20 12 0 14 -233017 -66577 0; #X obj 449 37 cnv 15 200 380 empty empty empty 20 12 0 14 -228992 -66577 0; #X obj 451 684 cnv 15 100 60 empty empty empty 20 12 0 14 -195568 -66577 0; #N canvas 0 0 450 300 gemwin 0; #X obj 132 136 gemwin; #X obj 64 202 outlet; #X obj 67 10 inlet; #X msg 64 183 set destroy; #X msg 132 112 create \, 1; #X msg 216 117 destroy; #X msg 190 58 set create; #X obj 67 41 route create; #X obj 219 6 inlet; #X connect 2 0 7 0; #X connect 3 0 1 0; #X connect 4 0 0 0; #X connect 5 0 0 0; #X connect 6 0 1 0; #X connect 7 0 3 0; #X connect 7 0 4 0; #X connect 7 1 6 0; #X connect 7 1 5 0; #X connect 8 0 0 0; #X restore 456 723 pd gemwin; #X msg 456 704 destroy; #X text 452 683 Create window:; #X obj 451 133 cnv 15 185 120 empty empty empty 20 12 0 14 -24198 -66577 0; #X obj 451 43 gemhead; #X text 17 366 Outlet 1: gemlist; #X text 24 281 Inlet 1: gemlist; #X obj 453 605 pix_texture; #X floatatom 491 235 3 0 100 2 threshold - -; #X obj 491 252 / 100; #X text 71 31 Class: pix object (analysis); #X msg 491 273 treshold \$1; #X floatatom 581 235 3 0 100 2 blobsize - -; #X obj 581 252 / 100; #X msg 581 273 blobSize \$1; #X text 24 296 Inlet 1: treshold float: minimum luminance of a pixel to be considered part of a blob. (default=0.04); #X text 24 325 Inlet 1: blobSize float: minimum relative size of a blob. (default=0.1); #X text 50 12 Synopsis: [pix_multiblob]; #X text 29 57 Description: blob detector (for multiple blobs); #X text 17 73 [pix_multiblob] is able to detect multiple blobs within an image.; #X text 17 103 a blob is a number of adjacent(!) pixels with a luminance that is bigger than the value defined by treshold. you can set the minimum size of a blob that is needed to be detected.; #X text 17 156 the output is a matrix following the conventions of the mtx-objects from zexy/iemmatrix. each row describes one detected blob as follows: centerX(weighted) \, centerY(weighted) \, size(weighted) \, minX \, minY \, maxX \, maxY \, size; #X text 64 237 int: max number N of blobs to detect; #X text 17 381 Outlet 2: (k \, 8) matrix: describing k detected blobs (with 0=kN); #X obj 604 114 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 453 325 pix_multiblob 6; #X obj 451 111 pix_video; #X msg 683 93 driver 0; #X obj 453 660 rectangle 5.33 4; #X msg 683 69 device 1; #X obj 451 146 pix_rgba; #X floatatom 580 465 5 0 0 1 x - -; #X floatatom 581 481 5 0 0 1 y - -; #X floatatom 581 497 5 0 0 1 size - -; #X floatatom 582 513 5 0 0 1 minX - -; #X floatatom 582 529 5 0 0 1 minY - -; #X floatatom 583 545 5 0 0 1 maxX - -; #X floatatom 583 561 5 0 0 1 maxY - -; #X floatatom 584 577 5 0 0 1 area - -; #N canvas 183 567 687 354 showblob 0; #X obj 67 86 inlet blobinformation; #X obj 67 138 unpack 0 0 0 0 0 0 0 0; #X obj 67 167 outlet weightedX; #X obj 88 187 outlet weightedY; #X obj 109 207 outlet weightedSize; #X obj 156 236 outlet minX; #X obj 177 256 outlet minY; #X obj 243 236 outlet maxX; #X obj 260 256 outlet maxY; #X obj 348 238 outlet size; #X text 60 45 this extracts information of the 1st detected blob; #N canvas 517 405 450 300 rectangle 0; #X obj 68 75 inlet; #X obj 215 -1 inlet; #X obj 68 269 rectangle; #X obj 68 234 translateXYZ; #X obj 215 69 unpack 0 0 0 0; #X obj 215 94 +; #X obj 254 95 +; #X text 248 125 0..2; #X text 250 145 -1..+1; #X obj 340 148 -; #X obj 377 149 -; #X obj 193 124 - 1; #X obj 222 123 - 1; #X obj 222 146 * 4; #X obj 377 180 * -4; #X obj 155 151 * 5.334; #X obj 320 179 * -5.334; #X msg 184 263 draw line; #X obj 245 246 loadbang; #X connect 0 0 3 0; #X connect 1 0 4 0; #X connect 3 0 2 0; #X connect 4 0 5 0; #X connect 4 0 9 0; #X connect 4 1
[PD] pix_invert for livevideo?
hi, i'm trying to invert a live video signal on OSX 10.4.10, G4 1.67 like this: gemhead | pix_video | pix_invert | pix_texture | rectangle 4 3 but it only processes the upper half image, the lower half stays normal is there a solution or another way to invert a live video signal in gem? thank you, emanuel p.s.: i only found this unanswered mail from 2003 in the archives: [PD] Gem - pix_invert - only bottom 1/3 of image gets processed! robcanning rscanning at eircom.net Fri Nov 28 18:55:39 CET 2003 Hello, while i am at it - bombarding the list with my problems - here is another one! sorry:-) in XP with the latest stable PD and Gem if i use: pix_video_ds pix_invert pix_texture2 square 4 for example, only the bottom third of the my webcam feed gets processed by pix_invert in the gem window. I don't have this problem in OSX with the same patch (but using pix_video instead of pix_video_ds) Anybody got and ideas why this is happening? Thanks, Rob ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
