Re: [PD] processing images with GEM?

2008-06-04 Thread palmieri, ricardo
matteo: try this: http://hangar.org/wikis/lab/doku.php?id=start:puredata_opencv palmieri 2008/1/21 IOhannes m zmoelnig [EMAIL PROTECTED]: Derek Holzer wrote: Hi IOhannes, IOhannes m zmoelnig wrote: the problem is, that some pix-sources (platform dependent!) supply the images with (0/0)

Re: [PD] processing images with GEM?

2008-01-21 Thread Derek Holzer
See the attached patch, Sara Kolster and I use it in our workshops. Original by Ben Bogart, posted to the list when we had similar questions a few years ago. best, d. matteo sisti sette wrote: I have to perform some very very simple computer-vision tasks (such as motion detection) on image

Re: [PD] processing images with GEM?

2008-01-21 Thread Derek Holzer
Hi Matteo, I don't have a camera to plug in and double check, but I never noticed this inverted problem before. You can always re-invert the numbers if you need to ;-) Anyways, inverted or not, the patch does what it's supposed to, I hope! best, d. matteo sisti sette wrote: Thanks a lot,

Re: [PD] processing images with GEM?

2008-01-21 Thread matteo sisti sette
Thanks a lot, very interesting!! Just a quetion/problem. I'm trying your attached patch, and it works, but the Y position of the cursor seems to be systematically inverted! I mean, if the actual blob (as I can see it in the preview window) is on the top, the circle is drawn on the bottom of the

Re: [PD] processing images with GEM?

2008-01-21 Thread matteo sisti sette
I don't have a camera to plug in and double check, but I never noticed this inverted problem before. You can always re-invert the numbers if you need to ;-) Yes of course it is stright-forward to correct the inversion. But I was wondering if there may be some weird platform-dependence in the

Re: [PD] processing images with GEM?

2008-01-21 Thread IOhannes m zmoelnig
matteo sisti sette wrote: I don't have a camera to plug in and double check, but I never noticed this inverted problem before. You can always re-invert the numbers if you need to ;-) Yes of course it is stright-forward to correct the inversion. But I was wondering if there may be some weird

Re: [PD] processing images with GEM?

2008-01-21 Thread Derek Holzer
Hi IOhannes, IOhannes m zmoelnig wrote: the problem is, that some pix-sources (platform dependent!) supply the images with (0/0) in the upper-left corner, whereas others (0/0) is the lower-left corner (like openGL expects it). Would be good to know which platforms do it right, and which

Re: [PD] processing images with GEM?

2008-01-21 Thread chris clepper
On Jan 21, 2008 9:20 AM, Derek Holzer [EMAIL PROTECTED] wrote: Hi IOhannes, IOhannes m zmoelnig wrote: the problem is, that some pix-sources (platform dependent!) supply the images with (0/0) in the upper-left corner, whereas others (0/0) is the lower-left corner (like openGL expects

Re: [PD] processing images with GEM?

2008-01-21 Thread chris clepper
On Jan 21, 2008 9:07 AM, IOhannes m zmoelnig [EMAIL PROTECTED] wrote: finally, i am wondering how much the penalty would be to manually flip the images when retrieving them (this would involve one additional copy of the entire image, each time it is pulled from the source) - this will just

Re: [PD] processing images with GEM?

2008-01-21 Thread IOhannes m zmoelnig
chris clepper wrote: On Jan 21, 2008 9:07 AM, IOhannes m zmoelnig [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: finally, i am wondering how much the penalty would be to manually flip the images when retrieving them (this would involve one additional copy of the entire

Re: [PD] processing images with GEM?

2008-01-21 Thread IOhannes m zmoelnig
Derek Holzer wrote: Hi IOhannes, IOhannes m zmoelnig wrote: the problem is, that some pix-sources (platform dependent!) supply the images with (0/0) in the upper-left corner, whereas others (0/0) is the lower-left corner (like openGL expects it). Would be good to know which platforms