Gideon Kiers

I just spent some time comparing the quality of the various jitter 

output modes when using a 25 fps 768x576 DV-PAL Quicktime in 

The direct to window option provides a clearly visible quality boost, 

compared to the uyvy videoplane example (which looks best compared to 

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 ?

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 ?

directtowindow-vs-jitter

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 

> 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 

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.

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

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 

http://www.telcosystems.net/capture_uyvy.mov.zip

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

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

PNGs : http://www.telcosystems.net/screenshots_1024x768.zip
patches : http://www.telcosystems.net/patches.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..

> 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

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

On Aug 31, 2006, at 8:08 AM, Gideon Kiers wrote:

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 

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 

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

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 

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


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 

I've put up two footage clips and screenshots online, maybe you could 

http://www.telcosystems.net/720x576.mov.zip

http://www.telcosystems.net/768x576.mov.zip

the screenshots of fullscreen UYVY renders - 

Using a slightly modified version of the uyvy-2dv-vidplane patch (one 

qt.movie in 720 576, the other in 768 576).

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

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 

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 

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 

Thanks for your follow up with media files to help us better assess 

this situation. We *really* appreciate this type of thoroughness.

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

Ok, Photo JPEG it is then, thank you for checking it out. I'll go and 

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 

Ok, Photo JPEG it is then, thank you for checking it out. I'll go and  
fire up the converter engines ;)

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


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 

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

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.

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.

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

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.

directtowindow vs. jitter