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, cdriko@free.fr cdriko@free.fr 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!!!!