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
    max v2;

    • 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
      --
      ***
      http://danwinckler.com
      http://share.dj
    • May 06 2006 | 4:52 pm
      oops, i think you need to do @interp 1 in those foo matrices.
      --
      ***
      http://danwinckler.com
      http://share.dj
    • 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