directtowindow vs. jitter

Aug 31, 2006 at 12:53am

directtowindow vs. jitter

hello there,

I just spent some time comparing the quality of the various jitter
output modes when using a 25 fps 768×576 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

#27399
Aug 31, 2006 at 2:05am

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 768×576 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

#82859
Aug 31, 2006 at 3:08pm

Hi Joshua,

I’ve put a few examples online.

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.

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 a 1024×768 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
http://www.telcosystems.net

Stadhoudersweg 49B
3038 EE Rotterdam
the Netherlands

—————————

#82860
Aug 31, 2006 at 5:34pm

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

#82861
Aug 31, 2006 at 6:15pm

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.

#82862
Aug 31, 2006 at 9:14pm

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 720×576 DV test file – http://www.telcosystems.net/720×576.mov.zip
the 768×576 DV test file – http://www.telcosystems.net/768×576.mov.zip
the screenshots of fullscreen UYVY renders – http://
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.

#82863
Aug 31, 2006 at 10:00pm

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 768×576 file to photo JPEG at 768×576 (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(720×480 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

#82864
Aug 31, 2006 at 11:05pm

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(720×480 NTSC, 720x576PAL) with Jitter, or else you
> might get undesirable artifacts.

#82865
Sep 1, 2006 at 10:08am

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 768×576 file to photo JPEG at 768×576 (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 720×576 movie and resizing it(in QT Player Pro v7.0.4) to 1024×820 I could hardly see a difference compared to the 1024×768 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

#82866

You must be logged in to reply to this topic.