[opendtv] Re: Math of oversampling - a simple comparison

Jeroen Stessen wrote:
 > I think you forgot to include the last link:
 >
 >>               http://www.trbarry.com/Leno_1080_480_1080p.jpg

Sorry, that was indeed the correct last link, and sort of 
necessary for this discussion.

 > I find it interesting to note that with otherwise identical AA
 > filters, there is a significant difference in sharpness between
 > the 544p and 480p intermediate steps. Due to the transposed
 > sample-rate converter design, the anti-aliasing filter scales
 > automatically with the output sample-rate (544p versus 480p).
 > So my filter has always 8 taps in the output space, this is
 > equivalent to 16 or 18.13 taps respectively in the input space.
 > The difference in bandwidth is only 480/544 = 88%, I had not
 > expected it to be so visible ! Anyone care to explain this ?
 > (Wasn't the original question about down-sampling to 480p ?)

Your filter really is quite impressive.  But I tend to visualize 
the sudden loss of detail just by visualizing a possible MTF 
curve.  If there was only mild detail in the original above 544 
then filtering that amount would not be noticeable.  But possibly 
when you filter at 480 then the cut off point starts climbing the 
steeper shoulder of the MTF curve, suppressing frequencies that 
really exist in the image to some degree.  And the actual 
perceived sharpness is the square of this ratio, so it is more 
like (480/544)^2 = .778.

If this is so then you probably wouldn't notice the effect much on 
my first image from Medium.

Also if true then my scary prediction would be that if you started 
with a very sharp detailed 1080p image (sharp, properly down 
sampled from 4k) then we would not at all get away with even 544p 
when compared side by side close on a big display.

Few, if any, commercial HDTV shows seem to be in that category 
though hopefully some HD DVD's will be.

- Tom


> Hello, 
> 
> Tom Barry wrote: 
> 
>>(...) 
>>this brings the total collection to 5 images, listed below in 
>>chronological order:
>>(...) 
>>4)  Jeroen's Leno image creating by scaling to 544p and then back 
>>up to 1088p. Possibly softer but with fewer artifacts.
>>               http://www.trbarry.com/Leno_1080_544_1080p.jpg
>>
>>5)  Jeroen's Leno image creating by scaling all the way down to 
>>480p and then back up to 1088p. Definitely softer but again with 
>>fewer artifacts.
> 
> 
> I think you forgot to include the last link: 
> 
>>               http://www.trbarry.com/Leno_1080_480_1080p.jpg
> 
> 
> My images are necessarily a bit softer than yours, because: 
> - I used realistic filters, you used a DCT truncation that is 
>   equivalent to a brick-wall filter (with severe ringing), 
> - I actually performed the down-sampling and up-sampling, so 
>   I had to worry about anti-aliasing. You did only a low-pass 
>   filter (within each 8x8 block), and you assume that this is 
>   good enough for down-sampling. It's not a bad assumption, 
>   but you do show bad blocking artefacts. 
> - I tend to choose soft filters because I like to balance 
>   between sharpness, aliasing and ringing artefacts. We have 
>   to worry about moving pictures too, and motion tends to 
>   reveal more of the aliasing artefacts. 
> 
> I find it interesting to note that with otherwise identical AA 
> filters, there is a significant difference in sharpness between 
> the 544p and 480p intermediate steps. Due to the transposed 
> sample-rate converter design, the anti-aliasing filter scales 
> automatically with the output sample-rate (544p versus 480p). 
> So my filter has always 8 taps in the output space, this is 
> equivalent to 16 or 18.13 taps respectively in the input space. 
> The difference in bandwidth is only 480/544 = 88%, I had not 
> expected it to be so visible ! Anyone care to explain this ? 
> (Wasn't the original question about down-sampling to 480p ?) 
> 
> I believe that I have designed my polyphase filters carefully 
> to have approximately equal bandwidth over all phases, for 
> sofar as this is mathematically possible. 
> (The half-pixel delay filter has a zero at 1/2*fS, it always 
> has less bandwidth than the zero-pixel delay filter. I designed 
> for a -3 dB point at 3/8*fS, which is not too high, I know.) 
> 
> Tom: 
> 
>>BTW, I was thinking again about the discussion of artifacts being 
>>caused at the edges of the 8x8 blocks.  Of course I believe they 
>>will be created by MPEGx compression anyway. 
> 
> 
> Well... there is a difference between blind truncation of 
> higher DCT coefficients and adaptive quantisation of them. 
> Quantisation leaves at least something to soften the block 
> edges, but your choice for truncation of 48 out of 64 coefs 
> will always cause bad blocking. This is unnecessary if you 
> just down-sample the entire image before MPEG encoding. 
> 
> 
>>But it on the way home today it occurred to me that for the 
>>cost of a few hundred vectorized multiplies and additions per 
>>pixel it would probably be possible to treat the entire image 
>>as one big block and avoid this problem anyway.
> 
> 
> Come on, re-sampling is not that expensive ! For the down-
> sampling, for each of the H and V directions I paid 7 
> multiplies and 7 additions per input pixel (times 2 Mpixels 
> times 3 colors). Add to this the cost for converting to the 
> linear-light domain and back, but this is optional. (It does 
> improve the brightness of details.) For the up-sampling, for 
> each of the H and V directions I paid 5 multiplies and 5 
> additions per output pixel (times 2 Mpixels times 3 colors). 
> So in total it cost (7+5)*2M*3 = 72 Meg multiplies + 72 Meg 
> additions for the entire frame, down and back up. Decent 
> hardware these days can literally do it in 1/60th second. 
> 
> 
>>I need a faster computer.
> 
> 
> I bet my computer is much slower than yours, but this was 
> only a few seconds work. I also had to convert jpeg to bmp 
> and back, because my simple scaler eats only bmp files. 
> And no, it is not open source code and I can not distribute it. 
> But I can give you all an impression of the 16-taps and 6-taps 
> filter coefficients that I have used in the process, so that 
> you may analyse the two filters for bandwidth. 
> 
> Best regards, 
> -- 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: