[PD] pix_video alphachannel

[chris clepper]

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 at free.fr <cdriko at 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!!!!
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20061208/1e3aefff/attachment.htm>