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.
      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