Chromakey resolutions


    May 06 2006 | 4:17 pm
    Hi all,
    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.
    Thanks, Jonathan

    • May 06 2006 | 4:50 pm
      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]
      or
      [jit.qt.movie @adapt 1] --> [jit.matrix foo 640 480]
      or just
      [jit.qt.movie 640 480]
      offhand, i don't know how doing the interpolation in jit.qt.movie differs from doing it in a jit.matrix.
      best, dan
    • May 06 2006 | 4:52 pm
      oops, i think you need to do @interp 1 in those foo matrices.
    • May 06 2006 | 10:01 pm
      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!
      Any ideas? My patch is below.
    • May 07 2006 | 10:03 am
      hello,
      few things:
      - 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)
      - delete all pwindows:)
      hope this helps, nesa
    • May 07 2006 | 10:56 am
      Hi Nesa
      > - 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!
      Thanks again, Jonathan