jonathan Goodwin

I'm having a problem with this patch in which a live webcam feed from an

Apple i-sight gets keyed in over a pre-edited video loop.

The problem is that when I run the video loop through the chromakey setup it

gets output at the wring res and looks shocking. I'm guessing this may be to

do with the fact the the video is 720x576 PAL res, whilst the webcam is

320x240. How does the chromakey object handle different resolutions? And is

there a way I can scale the webcam feed up to match the res of the video

I've added Gswitches into my patch for diagnostics. If I bypass the

chromakey, the video plays as well as it does in Quicktime player.

I'm having a problem with this patch in which a live webcam feed from an
Apple i-sight gets keyed in over a pre-edited video loop.

The problem is that when I run the video loop through the chromakey setup it
gets output at the wring res and looks shocking. I'm guessing this may be to
do with the fact the the video is 720x576 PAL res, whilst the webcam is
320x240. How does the chromakey object handle different resolutions? And is
there a way I can scale the webcam feed up to match the res of the video
feed?

I've added Gswitches into my patch for diagnostics. If I bypass the
chromakey, the video plays as well as it does in Quicktime player.

chromakey-resolutions

the iSight can do 640 x 480. Might want to bump that up. From there,

one way to match the two sources is to interpolate one of them up or

down before sending to the chromakey, e.g.,

[jit.qt.grab 640 480] --> [jit.matrix foo 720 576]

[jit.qt.movie @adapt 1] --> [jit.matrix foo 640 480]

offhand, i don't know how doing the interpolation in jit.qt.movie

the iSight can do 640 x 480.  Might want to bump that up.  From there,
one way to match the two sources is to interpolate one of them up or
down before sending to the chromakey, e.g.,

offhand, i don't know how doing the interpolation in jit.qt.movie
differs from doing it in a jit.matrix.

--
***
http://danwinckler.com
http://share.dj
http://gunshowimprov.com


oops, i think you need to do @interp 1 in those foo matrices.

My problem seems to be more complex than I originally thought. It seems that

all my res issues seem to stem from the branch of data coming into the

chromakey from the webcam feed. Even though the webcam data and the video

loop are kept entirely separate until the chromakey object, the res of the

webcam feed seems to effect the res of my video loop.

If I change the webcam feed res before it arrives at the chromakey to

anything above 320x240 then the video loop becomes stuttery, missing frames

and the picture can't keep up with the sound. If I leave the webcam feed

as-is (which I don't mind doing in theory), then the video loop displays at

this same low resolution (even though it should be 720x576), but smoothly. I

can't figure this out, it's very frustrating!

My problem seems to be more complex than I originally thought. It seems that
all my res issues seem to stem from the branch of data coming into the
chromakey from the webcam feed. Even though the webcam data and the video
loop are kept entirely separate until the chromakey object, the res of the
webcam feed seems to effect the res of my video loop.

If I change the webcam feed res before it arrives at the chromakey to
anything above 320x240 then the video loop becomes stuttery, missing frames
and the picture can't keep up with the sound. If I leave the webcam feed
as-is (which I don't mind doing in theory), then the video loop displays at
this same low resolution (even though it should be 720x576), but smoothly. I
can't figure this out, it's very frustrating!

- you've limited jit.qt.movie containing your background to 320x240. 

initialize it with the matrix size you want(jit.qt.movie 720 576).

- every jitter object having adapt attribute set to 1(@adapt 1) _adapts_ to 

the properties of the matrix coming in their leftmost inlet. This means that 

if you feed 320x240 matrix into left inlet of chromakey, and 720x576 in 

right inlet, jit.chromakey will adapt to 320x240 one.

One solution to this is to resize that matrix just before it goes to 

you've noticed frame drop when you resize matrix coming to jit.chromakey. on 

of the reasons this is happening is that your matrices are of the type 

float32, which takes 32 bits, instead of 8bits as char type needs, so if we 

skip everything else, amount of data coming into jit.chromakey is 4 times 

One solution to this is to set the matrix type to char just before it goes 

to chromakey(after jit.slide) in your case.

if you do these two solutions, you'll notice that you're using float32 just 

for jit.slide, but the same effect can be achieved with jit.glop or jit.wake 

- maybe jit.chromakey is not needed at all: it seems that you want to 'draw' 

edges of incoming web camera stream, which are white pixels. if you want to 

'compose' something white-with-black-background over something else, you 

could use jit.op @op + instead of jit.chromakey. using this trick, you can 

avoid two solutions offered above by feeding your properly sized background 

movie to left inlet of jit.op, and whatever you want to put over it in the 

right inlet(this way jit.op internally scales right-input matrix to 

- you've limited jit.qt.movie containing your background to 320x240. 
initialize it with the matrix size you want(jit.qt.movie 720 576).

- every jitter object having adapt attribute set to 1(@adapt 1) _adapts_ to 
the properties of the matrix coming in their leftmost inlet. This means that 
if you feed 320x240 matrix into left inlet of chromakey, and 720x576 in 
right inlet, jit.chromakey will adapt to 320x240 one.
One solution to this is to resize that matrix just before it goes to 
chromakey(after jit.slide) in your case.

you've noticed frame drop when you resize matrix coming to jit.chromakey. on 
of the reasons this is happening is that your matrices are of the type 
float32, which takes 32 bits, instead of 8bits as char type needs, so if we 
skip everything else, amount of data coming into jit.chromakey is 4 times 
bigger then necessary.
One solution to this is to set the matrix type to char just before it goes 
to chromakey(after jit.slide) in your case.

if you do these two solutions, you'll notice that you're using float32 just 
for jit.slide, but the same effect can be achieved with jit.glop or jit.wake 
only with less cpu.

- maybe jit.chromakey is not needed at all: it seems that you want to 'draw' 
edges of incoming web camera stream, which are white pixels. if you want to 
'compose' something white-with-black-background over something else, you 
could use jit.op @op + instead of jit.chromakey. using this trick, you can 
avoid two solutions offered above by feeding your properly sized background 
movie to left inlet of jit.op, and whatever you want to put over it in the 
right inlet(this way jit.op internally scales right-input matrix to 
left-input matrix size)

> - maybe jit.chromakey is not needed at all: it seems that you want to 'draw'

> edges of incoming web camera stream, which are white pixels. if you want to

> 'compose' something white-with-black-background over something else, you

> could use jit.op @op + instead of jit.chromakey. using this trick, you can

> avoid two solutions offered above by feeding your properly sized background

> movie to left inlet of jit.op, and whatever you want to put over it in the

> right inlet(this way jit.op internally scales right-input matrix to

Thanks so much, this trick has worked wonders! I always thought there must

be a better way round this than to use chromakey, but I hadn't really got to

grips with understanding jit.op, although it's now becoming increasingly

apparent to me how important this object is!

> One solution to this is to set the matrix type to char just before it goes

> to chromakey(after jit.slide) in your case.

Thanks for solving another newb error too....now my fan isn't going into

overdrive when I try to run my patch on my poor little Mac Mini!

> - maybe jit.chromakey is not needed at all: it seems that you want to 'draw'
> edges of incoming web camera stream, which are white pixels. if you want to
> 'compose' something white-with-black-background over something else, you
> could use jit.op @op + instead of jit.chromakey. using this trick, you can
> avoid two solutions offered above by feeding your properly sized background
> movie to left inlet of jit.op, and whatever you want to put over it in the
> right inlet(this way jit.op internally scales right-input matrix to
> left-input matrix size)

Thanks so much, this trick has worked wonders! I always thought there must
be a better way round this than to use chromakey, but I hadn't really got to
grips with understanding jit.op, although it's now becoming increasingly
apparent to me how important this object is!

> One solution to this is to set the matrix type to char just before it goes
> to chromakey(after jit.slide) in your case.

Thanks for solving another newb error too....now my fan isn't going into
overdrive when I try to run my patch on my poor little Mac Mini!

Chromakey resolutions