Re: SVP's downscaling algorithm?

Mystery
Rendering 1080p image on 768p display is a waste of CPU resources

Let's say "rendering 4k on 480p display"  big_smile

27 (edited by dlr5668 23-07-2015 06:59:31)

Re: SVP's downscaling algorithm?

Mystery
Rendering 1080p image on 768p display is a waste of CPU resources and forces you to render with lower settings.

not a waste. any cheap 4+ cores cpu (I have fx 6300 6 cores @ 4.6 Ghz, 85$ only + 20$ cooler) can handle it. Down-scaling after svp rendering should bring higher quality.

wish I had spare money for 2 GPUs and madvr doubling

28 (edited by Nintendo Maniac 64 23-07-2015 07:13:40)

Re: SVP's downscaling algorithm?

dlr5668 wrote:

not a waste. any cheap 4+ cores cpu (I have fx 6300 6 cores @ 4.6 Ghz, 85$ only + 20$ cooler) can handle it. Down-scaling after svp rendering should bring higher quality.

That's because SVP is a program that can actually use extra cores quite effectively, but not everyone can build a PC purely for multi-threaded tasks - a good amount of software is still largely dependent on single-threaded performance.

Also consider that you would have quite a large amount of heat output with that CPU and that overclock - not exactly optimal for HTPC situations.  For such TDP-limited use-cases, you'd be stuck with either a quad core A10 with poor single-thread performance, a dual-core Intel with poor multi-thread performance, or a quad core Intel with poor bang-per-buck.

Re: SVP's downscaling algorithm?

Nintendo Maniac 64
It is a mistake in the script generate.js: hmm

sorry
roll

    //downsize
    if(    mediaInfo.main.reswidth>mediaInfo.main.cbhwidth ||
        mediaInfo.main.resheight>mediaInfo.main.cbhheight)
        resizeString="BicubicResize("+mediaInfo.main.reswidth+", "+mediaInfo.main.resheight+", b=0, c=0.75)";
    else //upsize
        resizeString="LanczosResize("+mediaInfo.main.reswidth+","+mediaInfo.main.resheight+")";

I mean downsize and upsize algorythms are confused.
In the past for upsize used Lanczos and for downsize - Bicubic(0,0.75). It can be reviewed and changed.
These algos was selected as optimal (speed/quality) for CPU's in 2010 year.

See picture in Russian. smile
http://www.svp-team.com/forum/misc.php?item=3606

Your suggestions?

Post's attachments

Resize_speed.png, 32.6 kb, 351 x 593
Resize_speed.png 32.6 kb, 419 downloads since 2015-07-23 

Re: SVP's downscaling algorithm?

Nintendo Maniac 64
Or you can just use a big water pump and 3x480 radiators that you mount outside of your media room to get the best quality and no noise. smile
Doesn't really solve the bang per buck issue though...

I also wanted to ask you about your monitor description of a few posts back:
Are you using a CRT because of its superior motion resolution at high frame rates?
I too am very sensitive to the motion abnormalities of 'modern' displays, unfortunately I also have a stupidly high flicker fusion threshold (CRTs' flicker, even at 120Hz, becomes completely unbearable after 30 minutes or so. Also, I simply cannot resolve even a still picture at 60Hz on account of the stobing, something that my friends had a lot of fun with while CRTs were still commonplace...) so strobing really does nothing to solve the problem for me either.

Unfortunately, it seems that all of the OLED panel manufacturers will only be implementing 'Active Matrix' panels due to their lower power consumption and slim profiles, quality be damned.
Is there some specific reason why you believe that AM-OLED displays (not just the Samsung specific AMOLED, lol) will do anyting to change the quality of motion resolution on modern displays?

31 (edited by Nintendo Maniac 64 23-07-2015 21:32:17)

Re: SVP's downscaling algorithm?

MAG79, I'm not really interested in using something higher quality than Bicubic for downsizing since performance is key for me - the main thing was that I was trying to actually use Bicubic rather than Lanczos but have not (yet) succeeded in doing do.



Xenonite, yes I'm a CRT user, but I do not have issues with flicker at 90hz and up on my monitor.  One must also consider how quickly the phosphors decay - that will make a difference in the intensity of the flicker (quick decay = worse flicker).

Regarding OLED, I do not understand what active-matrix has to do with anything...we already know that OLED can support strobbing as seen with the Oculus Rift DK2 - that combined with OLEDs ridiculously quick pixel response times (sub .1ms) was actually deemed a requirement for people to not want to throw up when using said headset.

You also don't seem to be aware that LG is currently selling OLED HDTVs.  Even though LG's implementation lacks strobbing, it has been recently discussed on AVSforum in response to the recent "2015 Value Electronics Flat-Panel Shootout" that the human eye seems to actually be more sensitive to blur and ghosting due to poor pixel response time than to sample-and-hold when it comes to actual content; in other words, sample-and-hold + fast pixel response looks better for actual content than strobbing + poor pixel response, and the faster the framerate the greater the difference should be.

Re: SVP's downscaling algorithm?

Nintendo Maniac 64
Thank you for your detailed answer.
Yes I know about the OLED TVs being sold, but they have poorer pixel response times than even my 144Hz TN-TFT LCD, due to the AM addressing scheme. I do not want to derail this thread any further, but I feel I owe you at least a basic answer. Basically, what happens is that they are addressing each pixel line-by-line, the same way you would a normal TFT LCD.

Since each pixel can only be controlled for a small fraction of the frametime (t= (column_drivers) / (fps * display_width * display_height * num_subpixels)), where column_drivers refers to the number of column driver outputs that can be active at the same time, fps is the refresh rate and the display height and width refer to the numbers of pixels the display has.
This limited time that each pixel can be actively powered would therefore result in an unacceptably dim screen (consumers flock to extremely bright displays, since they look more vibrant under the extreme showroom lights). Thus, a capacitor is included with each pixel to store enough charge to allow the pixel to continue emitting light long after the addressing pulse has moved on.

To also ensure that the display is thin, light and does not have a lot of power, the driving electronics get limited to a small amount of maximum current (since conductive losses and heat production scale quadratically with the amount of applied current).

The pixel response time then gets fixed by the amount of charge that has to be moved either to or from the capacitor, divided by the maximum current that the column driver can output. In almost all cases of modern displays, this limited output current, combined with the limited active pixel addressing time, prohibits most of the pixels from attaining their desired brightness in a single frame time.

Overdrive techniques try to compensate by 'overdriving' the pixel on the first frame and then gradually settling down to the final value, however the effectiveness of pixel overdrive techniques are limited by the tolerances involved in manufacturing the energy storing capacitors (which affects the pixel's time constant) as well as the voltage limits of the capacitors, transistors and the pixels themselves (a full range, i.e. a black to white transition can usually not be overdriven, since the final, settled voltage is already required to be at the maximum possible voltage).

I hope my explanation is sufficient to understand what I meant about Active Matrix OLED displays not really improving motion resolution as pf yet.
Of cource, in the future, someone could construct a commercial AM OLED display with sub 1ms reaponse times, but that would require thick, 'ugly?' heatsinks, high framerates and a much lower maximum luminance. Unfortunately, there does not seem to be any indication that there will ever be sufficient consumer intrest for those trade-offs to make economic sense. sad

33 (edited by Nintendo Maniac 64 31-07-2015 00:47:50)

Re: SVP's downscaling algorithm?

Wait, you sound like you're mixing up pixels response time and display lag (not input lag).  An OLED pixel should be able to switch from white to black or black to white in less than .1ms, but it'll still take at least 16.666...ms for the display itself to respond to the video signal that is being sent to it.

If you take a photo without flash at a fast shutter speed of an OLED display showing various blurbusters tests, none of the photos should have any motion blur even though your eyes see there being motion blur.

Re: SVP's downscaling algorithm?

Nintendo Maniac 64
Unfortunately, no.
I do not know how much circuit theory you know, but what I tried to explain was that ALL current commercial OLED panels use an addressing technique which causes the pixels to respond sluggishly.

Ok, let me explain it like this: you know how a CRT TV has a scanning electron beam that lights up the display pixel-by-pixel, one row at a time? Even though it would be possible (in theory) to update the pixels on a "flatscreen" display (LCD or OLED are similar in this regard) all at once, this is never done in practice.
All displays still use the same scheme of refreshing the pixels one line at a time. And while you are correct in the sense that this scanning behaviour CAN be independent of the usual 16.67ms frame period, they VERY RARELY are, because they want the pixels to be on for as long as possible to put out the most light (and to reduce the column and row drivers' operating frequencies).

What this means in practice is that all the pixels on screen need to be refreshed by at least the end of the 16.67ms frame window. The way this is done is one row of pixels (called a scanline) at a time, so that each row has only frametime/number_of_rows ( = 0.01543ms = 15.43 MICROseconds for a 1080P/60Hz display) of time to change their state.

In the BEST CASE, the display update an entire row of pixels all at once, but this is very expensive and thus also very rare.
The usual practice is for each column driver IC to update a single pixel, one at a time, until it has updated all the pixel lines attached to it. Since there are between 2-8 of these chips in an average display (1-2 for an expensive, thinner model), only those many pixels get updated at the same time (reducing the actual per-pixel addressing time by a factor of between 10-100).

For the sake of a best case argument, lets say each pixel gets a full 15.43us of addressable time.
Up to this point, I have not even considered the actual pixels' RESPONSE times (display lag is another thing entirely and has to do with frame bufferring and digital electronics; analog processing only adds a variable 0-16.67ms of lag to it because the lowest rows of pixels get refreshed much later than the uppermost ones).
This way of addressing didn't have that big of an impact with the slow nature of LCD pixel response times, but it has a HUGE impact when the actual pixel CAN transition as quick as OLED is able to.
THIS IS THE IMPORTANT PART:
Since each pixel is only connected to an electric supply for 15.43us of each frame (best case with a 1080p display, although many OLED displays are 4k), the display driver deposits a huge pulse of electricity to the pixel's storage capacitor during that time. The capacitor then slowly discharges through the pixel, keeping it at roughly the correct value until the next frame refresh comes along. It is this sluggish capacitor response that limits the pixel's response time. Even though the OLED pixel on its own CAN switch in under 0.01ms like you said, it takes much longer for the capacitor to stabalise to the correct value.

Response time compensation techniques try to enhance pixel response by charging the capacitor with a higher voltage than is required for the current transition, which causes a faster transition (since capacitive charging rate is eaqual to the capacitance value multiplied by the time derivative of the voltage over it) but also results in RTC overshoot artifacts.

Hopefully someone will make a OLED panel that works like the old plasma display panels used to (no charging capacitor = almost instant pixel responses), but until that time, I suppose we are stuck with what we have...

Hopefully I have better explained how it all fits together this time around, but please do let me know if you have any other questions / see any errors.

35 (edited by Nintendo Maniac 64 31-07-2015 19:30:03)

Re: SVP's downscaling algorithm?

...yeah, to me it still sounds like we're not talking about the same thing.

At least to me, what you described sounds like not the pixel response time but rather the panel refresh time (not an actual term AFAIK) - that being the amount of time for all pixels to change from one state to another.

What I was speaking of is the amount of time it takes for a single OLED pixel to transition from one state to another thereby not including the "waiting time" of waiting for any pixels located before said pixels to be updated.  AFAIK, this is typically what is referred to when speaking of to "pixel response time" (note that there is no standard definition for it).


Now yes, you would indeed still need a high refresh rate in order to not have a slow refresh time, but that wasn't my point.  I mean, even current OLED TVs can do 240hz and the like - they just can't accept an input video signal above something like 75hz.


DERP!  Double post...oh well. >_>


xenonite wrote:

Since each pixel is only connected to an electric supply for 15.43us of each frame (best case with a 1080p display, although many OLED displays are 4k), the display driver deposits a huge pulse of electricity to the pixel's storage capacitor during that time. The capacitor then slowly discharges through the pixel, keeping it at roughly the correct value until the next frame refresh comes along. It is this sluggish capacitor response that limits the pixel's response time. Even though the OLED pixel on its own CAN switch in under 0.01ms like you said, it takes much longer for the capacitor to stabilise to the correct value.

I would like to mention that I did not actually say 0.01ms but rather sub 0.1ms - that could even be 0.09ms.

But nevertheless, isn't that like saying CRTs cannot do high refresh rates because some low-end CRT monitor couldn't run above 75hz at an adequate resolution?  There's always going to be cheaper units with worse components - I mean, laptops with 15" 1366x768 LCD displays are still a thing!  My aunt had a Toshiba laptop with 1280x800 in 2004.

xenonite wrote:

Response time compensation techniques try to enhance pixel response by charging the capacitor with a higher voltage than is required for the current transition, which causes a faster transition (since capacitive charging rate is eaqual to the capacitance value multiplied by the time derivative of the voltage over it) but also results in RTC overshoot artifacts.

Is this not what "overdriving" is on LCD monitors?  AFAIK, there is no need to do such a thing on OLED displays...

36 (edited by Nintendo Maniac 64 31-07-2015 19:31:00)

Re: SVP's downscaling algorithm?

Derp, double-post. >_>


Maybe we should take this discussion to somewhere like AVSForum instead...?  I mean we're clearly way off-topic now.  This would be the appropriate forum section FYI:
http://www.avsforum.com/forum/40-flat-p … echnology/

Re: SVP's downscaling algorithm?

No, I was trying to explain the difference between the two, but I was talking about the single pixel's response time being artificially made 100-1000x slower than the sub 0.01ms that a single non-AM OLED pixel would be capable of, completely independant of the panel's refresh rate.

But yes, I am waaay off topic here; will look into that site you mentioned, thanx.

Re: SVP's downscaling algorithm?

So, more on-topic, it would seem that using SVP 4.0.0.21 doesn't make any difference regarding this.