The problem you see has to do with DirectShow using a different set of coordinates for drawing. An AVI clip opened with pix_film that also uses DirectShow should not have this problem. An updated version of GEM that does this can be found at http://gem.iem.at/download/SNAPSHOTS/gem-CVS20060914-w32-i686-bin-doc.zip
pix_draw is not the fastest way to get images drawn. Try pix_texture and the rectangle object. A 640x480 or 1024x768 window is filled with [rectangle 5.33 4]. On 12/8/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
thanks for your help About compositing 3D I can't use pix_snap because my GLoutput is in 1024 768 and I think that the computer will cry to pix_snap and pix_resize continuously About the problem with the pix_mix object at the begining, I put a pix_flip object before the right inlet with a result strange : picture is alternativelly flipped up and down the solution that I found is by the pix_film source object : before, I used a metro to changing number of image (to get the possibility to change the rate) in fact, if I replace this metro by a derivating bang from the gemhead of the pix_film, the path pix_flip>pix_mix is working well You can see the exemple patch next the last problem is that, if I put a rate < 1 (in the |pd lecteur_video_boucle|) the hysteric flip is recoming but it's now very better!!!!
_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
