[opendtv] Re: Math of oversampling - a simple comparison
- From: Tom Barry <trbarry@xxxxxxxxxxx>
- To: opendtv@xxxxxxxxxxxxx
- Date: Mon, 25 Apr 2005 07:27:00 -0400
Inline ...
Jeroen Stessen wrote:
> Hi,
>
> Tom Barry wrote:
>
>>(...) I have included a link to a captured image from
>>the Pilot of the Medium TV series. The LEFT half of that image
>>was left untouched.
>>But on the RIGHT half of the image I filtered out all frequencies
>>that would correspond to a spatial resolution higher than a 1/4
>>rez of 960x544, using my DctFilter plugin for Avisynth
>>(www.trbarry.com/Readme_DctFilter.txt). That filter does a
>>discrete cosine transform and then (in this case) zeros out all
>>coefficients except for the 4x4 square in the top left of the 8x8
>>matrix. Then an inverse transform back to pixels.
>
>
> You did what ? If I understand it, then you first cut the picture
> in blocks of 8x8 pixels, then you applied a DCT, then you discarded
> 3/4 of the coefficients, and you transformed it back to an 8x8
> block, which by the way could also be represented by a 4x4 block.
>
> But That Is Not The Way to properly down-sample a picture !
>
> You have to down-sample it before you cut it into blocks, with a
> low-pass filter that has more taps than the size of a block.
> Typically a low-pass filter for 2x down-sampling has 10 or more
> taps, so it would look beyond the block edges. Cutting a picture
> into blocks creates higher harmonics from the block edges, which
> can not be just discarded or you would create blocking artefacts.
>
Mostly agreed, I was working with what I had in hand. Though in
practice DctFilter does not seem to do that badly.
But also remember that the intended target would be more MPEG-2/4
compression which is in turn going to cut the data into blocks and
represent it again with cosine basis functions, mostly ignoring
what happens over 8-byte block boundaries. So while you are right
I've still found this compresses well and you won't see those
artifact is that particular sample pic I posted.
>
>>Thus the resulting image could theoretically be encoded at only
>>960x544 without any more loss of detail. Of course in practice
>>that would introduce additional scaling and compression artifacts.
>
>
> Exactly, but those artefacts have already been introduced by you.
> The error is not in the further down-sampling per block, that is
> a completely valid operation after the top DCT coefficients have
> been set to zero. The error has already been introduced when you
> set the DCT coefficients to zero. Now there will be ringing on
> every block edge. I don't think that you would want that...
>
Those artifact would possibly appear if the original really
contained much detail above 960x544. But my example was chosen to
be typical of current HDTV shows, especially telecined. They
mostly do NOT contain that detail, which what I was trying to show
since then they could more effectively be sent at a lower rez.
I've previously posted results doing similar things using more
normal resize methods. The results are usually similar except for
pure (often live) 1080 video material. There is very little real
HD detail in most shows above 1/4 rez.
> If I can find your original picture then I can try to perform my
> scaling operations on it, and I will mail the result to you. OK ?
>
Okay. That would be nice. But it wouldn't need my original
picture. Feel free to use any OTA HDTV show actually as broadcast
(after compression) as an example. I didn't select this one to
look bad. But no fair using material they COULD be broadcasting,
but aren't, since I made this point to Bob about what it might
take to be competitive, not perfect.
There certainly could be much more detail in HDTV. Some of the
early PBS demo loop or the "Rudy Maxa Smart Travels" series for
instance was very nice. But most is very soft these days. And
you can compete with soft by just using dense, a sharper MTF curve
and a lower resolution.
- Tom
> Greetings,
> -- Jeroen
>
> +-------------------------------+------------------------------------------+
> | From: Jeroen H. Stessen | E-mail: Jeroen.Stessen@xxxxxxxxxxx |
> | Building: SFJ-5.22 Eindhoven | Deptmt.: Philips Applied Technologies |
> | Phone: ++31.40.2732739 | Visiting & mail address: Glaslaan 2 |
> | Mobile: ++31.6.44680021 | NL 5616 LW Eindhoven, the Netherlands |
> | Pager: ++31.6.65133818 | Website: http://www.apptech.philips.com/
> |
> +-------------------------------+------------------------------------------+
>
>
>
>
> ----------------------------------------------------------------------
> You can UNSUBSCRIBE from the OpenDTV list in two ways:
>
> - Using the UNSUBSCRIBE command in your user configuration settings at
> FreeLists.org
>
> - By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
> unsubscribe in the subject line.
>
>
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
Other related posts:
