directtowindow vs. jitter


    Aug 31 2006 | 12:53 am
    hello there,
    I just spent some time comparing the quality of the various jitter
    output modes when using a 25 fps 768x576 DV-PAL Quicktime in
    fullscreen display mode.
    The direct to window option provides a clearly visible quality boost,
    compared to the uyvy videoplane example (which looks best compared to
    the rest of the jitter options).
    It is for instance also clearly visible when you open the clip in
    quicktime player and put it in fullscreen mode, and then switch to
    the same clip playing through the uyvy videoplane example patch. I
    need jitter operations so I'll have to use uyvy anyhow, but am
    wondering why there is such a difference ?
    thank you,
    Gideon

    • Aug 31 2006 | 2:05 am
      On Aug 30, 2006, at 5:53 PM, Gideon Kiers wrote:
      > I just spent some time comparing the quality of the various jitter
      > output modes when using a 25 fps 768x576 DV-PAL Quicktime in
      > fullscreen display mode.
      > The direct to window option provides a clearly visible quality
      > boost, compared to the uyvy videoplane example (which looks best
      > compared to the rest of the jitter options).
      > It is for instance also clearly visible when you open the clip in
      > quicktime player and put it in fullscreen mode, and then switch to
      > the same clip playing through the uyvy videoplane example patch. I
      > need jitter operations so I'll have to use uyvy anyhow, but am
      > wondering why there is such a difference ?
      Can you post two screen shots with a description about the quality
      difference you are referring to, together with the simple max patch
      used with jit.gl.videoplane.
      Is it possible you are referring to the lack of display gamma
      correction which is always the case with Jitter UYVY (colors look
      less vibrant and contrasted)? You can accommodate for this with
      jit.scalebias or some of the other slab math operators.
      -Joshua
    • Aug 31 2006 | 3:08 pm
      Hi Joshua,
      I've put a few examples online.
      PNGs : http://www.telcosystems.net/screenshots_1024x768.zip
      And a screengrab in Animation codec from the UYVY output. The moving
      images show more clearly the vague distortion that seems to be mapped
      ontop of the video.
      I'm not referring to the lack of gamma no, i'm talking about the
      differences in 'pixelperfect' quality when being mapped to fullscreen
      on a 1024x768 output..
      thank you,
      On 31-aug-2006, at 4:05, Joshua Kit Clayton wrote:
      > Can you post two screen shots with a description about the quality
      > difference you are referring to, together with the simple max patch
      > used with jit.gl.videoplane.
      >
      > Is it possible you are referring to the lack of display gamma
      > correction which is always the case with Jitter UYVY (colors look
      > less vibrant and contrasted)? You can accommodate for this with
      > jit.scalebias or some of the other slab math operators.
      >
      > -Joshua
      ---------------------------
      Gideon G. Kiers MA/IMM
      mobile.: +31 6 16614770
      studio.: +31 10 4143745
      fax....: +31 84 7559757
      home...: +31 10 4112603
      iceland: +354 6626132
      dlf@telcosystems.net
      www.telcosystems.net
      Stadhoudersweg 49B
      3038 EE Rotterdam
      the Netherlands
      ---------------------------
    • Aug 31 2006 | 5:34 pm
      On Aug 31, 2006, at 8:08 AM, Gideon Kiers wrote:
      > I've put a few examples online.
      Thanks for the clear examples.
      The first artifacts are simply linear interpolation artifacts. It
      looks like QT Player is using Higher Order interpolation such as that
      provided by the lanczos-sinc scaling image unit (we we currently
      don't support in jit.gl.imageunit because of it's use of
      NSAffineTransorm). We hope to provide a jitter shader which
      demonstrates higher order interpoloation/scaling soon.
      The second potential issue is the way that he chroma samples are
      decompressed by QT. PAL DV is 4:2:0 and QT does not smooth these
      values for you. The uyvy2argb shader I posted for PC users, can also
      be useful on PC for some chroma smoothing (linear interpolation,
      nothing higher order), but it only handles the X axis. It could be
      modified to perform better chroma smoothing to handle 4:2:0 or 4:1:1
      issues and the lack of smoothness exposed by simply using a UYVY
      texture. I'll try to draw up a chroma smoothing filter for better
      results to demonstrate. (We can also add gamma correction in this
      shader as well).
      The final issue is that there's not necessarily 1 to 1 screen
      mapping. You should be able to get better results using
      @transform_reset 2 @nudge 0 @dim 2 2 attributes for
      jit.gl.videoplane, but there still might be some artifacts from the
      linear interpolation of texture coordinates and quantization error.
      These attributes will exactly match the geometry to the window, and
      not have additional geometry that may expose some quantization error
      w/r/t texture mapping.
      Try the recommended steps for the jit.gl.videoplane attributes for
      now (let us know i they improve things for you or not), and I'll try
      to provide some higher quality UYVY -> RGBA and upsampling shaders in
      the near future.
      -Joshua
    • Aug 31 2006 | 6:15 pm
      Excellent, i'll give it a try. Thanks !
      On 31-aug-2006, at 19:34, Joshua Kit Clayton wrote:
      > Try the recommended steps for the jit.gl.videoplane attributes for
      > now (let us know i they improve things for you or not), and I'll
      > try to provide some higher quality UYVY -> RGBA and upsampling
      > shaders in the near future.
    • Aug 31 2006 | 9:14 pm
      Just a thought, could the fact that the files i'm using for the test
      are in [601/DV-PAL square pixel 4:3 768x576] format instead of the
      regular [601/DV-PAL nonsquare 4:3 720x576 PAL (1,07)] format cause
      the distortion i'm seeing ?
      I've put up two footage clips and screenshots online, maybe you could
      have another look.
      the 720x576 DV test file - http://www.telcosystems.net/720x576.mov.zip
      the 768x576 DV test file - http://www.telcosystems.net/768x576.mov.zip
      the screenshots of fullscreen UYVY renders - http://
      www.telcosystems.net/shots.zip
      Using a slightly modified version of the uyvy-2dv-vidplane patch (one
      qt.movie in 720 576, the other in 768 576).
      thanks,
      Gideon
      On 31-aug-2006, at 19:34, Joshua Kit Clayton wrote:
      > Try the recommended steps for the jit.gl.videoplane attributes for
      > now (let us know i they improve things for you or not), and I'll
      > try to provide some higher quality UYVY -> RGBA and upsampling
      > shaders in the near future.
    • Aug 31 2006 | 10:00 pm
      On Aug 31, 2006, at 2:14 PM, Gideon Kiers wrote:
      > Just a thought, could the fact that the files i'm using for the
      > test are in [601/DV-PAL square pixel 4:3 768x576] format instead of
      > the regular [601/DV-PAL nonsquare 4:3 720x576 PAL (1,07)] format
      > cause the distortion i'm seeing ?
      It is a bit surprising, but this in fact appears to be the issue.
      With your test files I was able to reproduce the horrible artifacts.
      I exported your 768x576 file to photo JPEG at 768x576 (which plays
      back faster than the DV codec, fwiw), and with the naked eye it looks
      to me like it does in QT player (aside from any gamma issues). So it
      would appear that there's something strange with the DV codec
      rendering to non-native dimensions as used within jit.qt.movie. We
      can investigate what we need to do to improve this scenario, but it
      may require us revising some of the internal architecture to require
      QT 7 (which will have to wait until Jitter 2.0).
      So my previous assumptions as to the source of the problem was pretty
      much bogus. And perhaps even QT player is just using linear
      interpolation. However, all my previous recommendations for optimal
      quality still hold and we'll still try to put together chroma
      smoothing, gamma correcting, and higher order interpolation filters
      for scaling together as jit.gl.slab examples.
      The short answer for today is not to use the DV codec in non-native
      resolutions(720x480 NTSC, 720x576PAL) with Jitter, or else you might
      get undesirable artifacts.
      FWIW, in the absence of requiring alpha channel, I consistently get
      the best results with Photo JPEG as a codec, and would like to re-
      iterate my repeated suggestion to encode your movie files in this
      codec for use within Jitter.
      Thanks for your follow up with media files to help us better assess
      this situation. We *really* appreciate this type of thoroughness.
      -Joshua
    • Aug 31 2006 | 11:05 pm
      Ok, Photo JPEG it is then, thank you for checking it out. I'll go and
      fire up the converter engines ;)
      All the best,
      Gideon
      On 1-sep-2006, at 0:00, Joshua Kit Clayton wrote:
      > The short answer for today is not to use the DV codec in non-native
      > resolutions(720x480 NTSC, 720x576PAL) with Jitter, or else you
      > might get undesirable artifacts.
    • Sep 01 2006 | 10:08 am
      Quote: jkc wrote on Thu, 31 August 2006 16:00
      ----------------------------------------------------
      >
      > On Aug 31, 2006, at 2:14 PM, Gideon Kiers wrote:
      >
      > > Just a thought, could the fact that the files i'm using for the
      > > test are in [601/DV-PAL square pixel 4:3 768x576] format instead of
      > > the regular [601/DV-PAL nonsquare 4:3 720x576 PAL (1,07)] format
      > > cause the distortion i'm seeing ?
      >
      > It is a bit surprising, but this in fact appears to be the issue.
      > With your test files I was able to reproduce the horrible artifacts.
      > I exported your 768x576 file to photo JPEG at 768x576 (which plays
      > back faster than the DV codec, fwiw), and with the naked eye it looks
      > to me like it does in QT player (aside from any gamma issues). So it
      > would appear that there's something strange with the DV codec
      > rendering to non-native dimensions as used within jit.qt.movie. We
      > can investigate what we need to do to improve this scenario, but it
      > may require us revising some of the internal architecture to require
      > QT 7 (which will have to wait until Jitter 2.0).
      >
      ....
      Hi Gideon,
      I also fighted with quality issues on PAL DV.
      Just out of curiosity, what Quicktime version did you use when encoding the videos to dv? My observation was that it is also related to the QT version I used.
      I also downloaded your examples.
      After switching on the "high quality" flag in the 720x576 movie and resizing it(in QT Player Pro v7.0.4) to 1024x820 I could hardly see a difference compared to the 1024x768 picture in terms of pixel accuracy. When playing back there was of course more "jitter" visible on the character T at the beginning of the word.
      Bernd