madVR - high quality video renderer (GPU assisted) [Archive] - Page 14

ericgur

28th April 2009, 16:29

I have read somewhere that the best way to do resizing is to resize in RGB colorspace (and maybe in "linear light").
And MadVR resizes in YCbCr colorspace if I get your algorithm correctly.
Performance is the problem? What do you think about that?
Thanks!

If the video was 4:4:4 format (Y Cb & Cr are of equal dimensions) than using the currently implemented algorithms you'd get the same or very similar results. Since 99.999% of the video is 4:2:0, the resolution of the chroma (Cb & Cr) is half of that of luma (Y) in both directions. RGB only exists in 4:4:4 format so upscaling should be done in YCbCr color space. Scaling in linear light should be avoided. Here's a simple example:
You have 2 samples/pixels with values [0, 100] and you want to find the samples between them. The result should be a linear gradiant. In linear light the sample will be (assuming Gamma of 2 for simplicity):
[0, 100^2] == [0, 10000]
Let's resample the value exactly between 0 and 100 or 0 and 10000.
In gamma corrected space the value will be 50 and in linear space it will be 5000 which is ~71 in gamma corrected space.
The result will not appear linear at all.

madshi

28th April 2009, 16:59

I wonder to know if use 41 for less h/w usage, that, can it be smoothly like 40?
From your screenshots I can't see which one is 41 and which is 40. But the one with the lower average GPU rendering times should produce the smoothest result with the "final" madVR version (but not necessarily with the current madVR version).

Can't step the video and get snapshots...
Both problems are already known.

I thought that a chroma resampling algorithm would always resample in Y direction first, to give 4:2:2 and to X direction after that, to give 4:4:4.
It doesn't matter in which direction you scale first. The end result is the same.

Surprised the "macrovision failed" error still occurs in the latest version. :( this stopped me using haali for playing back all of my ripped DVD's also... did you get a chance to look into this error madshi?
I did look into it and made the one (demo) DVD I have work for me. But it seems that it still doesn't fix the issue for most other DVDs. I'll need to find a real movie DVD. You know, I don't have any DVDs, anymore. Only watching HD content these days...

I have read somewhere that the best way to do resizing is to resize in RGB colorspace (and maybe in "linear light").
And MadVR resizes in YCbCr colorspace if I get your algorithm correctly.
Performance is the problem? What do you think about that?
Performance is the problem with what? With the current algorithm? It doesn't matter much in which colorspace I scale, the scaling performance is the same. However, converting between different colorspaces costs performance.

madshi

28th April 2009, 17:03

Scaling in linear light should be avoided. Here's a simple example:
You have 2 samples/pixels with values [0, 100] and you want to find the samples between them. The result should be a linear gradiant. In linear light the sample will be (assuming Gamma of 2 for simplicity):
[0, 100^2] == [0, 10000]
Let's resample the value exactly between 0 and 100 or 0 and 10000.
In gamma corrected space the value will be 50 and in linear space it will be 5000 which is ~71 in gamma corrected space.
The result will not appear linear at all.
Don Munsil and Stacey Spears (the guys who gave the CUE - chroma upsampling error - its name) disagree with you. They actually have a patent on linear light scaling, which is now owned by Microsoft. See here for a post by Don Munsil where he explains why ~71 is actually the value we should get in his opinion:

http://www.avsforum.com/avs-vb/showthread.php?p=16313488#post16313488

Here's an extract:

the concept of "perceptual linearity" isn't applicable here, because when we scale an image we are effectively modeling what happens when we take bunch of photons in one set of buckets (pixels) and redistribute them into different buckets. Scaling an image by 50% in both dimensions should produce similar results to taking a picture of the same scene with a digital camera with 50% fewer pixels in both dimensions. It's pretty obvious that this is a physical process, not a perceptual one.
Maybe you could post on AVSForum and discuss with Don? Would love to read the both of you discussing this... :)

pirlouy

28th April 2009, 17:25

About subtitles, you said you would work on it at some point. But are you interested in jfs (http://forum.doom9.org/showthread.php?p=1278788#post1278788) stuff ? Or do you prefer to implement it your way ?

I know subtitles support is not a priority for you, but for those simple users as me, it's the only thing which prevents your rendered from being used as the default one and then, to help reporting bugs.

Anyhow, your motivation and your work (no problem since v0.1) are really appreciated. Thank you for that.

nlnl

28th April 2009, 19:43

madshi
Originally Posted by nlnl View Post
I have read somewhere that the best way to do resizing is to resize in RGB colorspace (and maybe in "linear light").
And MadVR resizes in YCbCr colorspace if I get your algorithm correctly.

Performance is the problem? What do you think about that?
Performance is the problem with what? With the current algorithm? It doesn't matter much in which colorspace I scale, the scaling performance is the same. However, converting between different colorspaces costs performance.
ericgur
If the video was 4:4:4 format (Y Cb & Cr are of equal dimensions) than using the currently implemented algorithms you'd get the same or very similar results. Since 99.999% of the video is 4:2:0, the resolution of the chroma (Cb & Cr) is half of that of luma (Y) in both directions. RGB only exists in 4:4:4 format so upscaling should be done in YCbCr color space. Scaling in linear light should be avoided.

I have found where I read about it.
I am not a video expert. So I just quote recognized authority :) Don Munsil.

dmunsil
http://archive2.avsforum.com/avs-vb/showthread.php?t=460922&page=3&pp=30 #88 (very interesting thread by the way)
For best results, scaling should in fact be done with linear-light values, not gamma-corrected values. And of course it should be done in RGB, not Y'CbCr, since Y'CbCr values aren't even gamma-corrected values, they're a linear combination of gamma-corrected values. Mathematically, processing in Y'CbCr is a complete abomination. Practically, it works sorta OK and requires a lot less CPU, so people go ahead and do it.

The best pipeline for scaling images in a Y'CbCr space is:

Y'CbCr->R'G'B'->RGB->[scale]->RGB->R'G'B'->Y'CbCr

Obviously the downsampling and upsampling of the chroma channel for 4:2:0 or 4:2:2 has an effect on the final image, but it can't be helped (other than by not using 4:2:0 or 4:4:4). There's no way to linearize Y', Cb, or Cr.

Don

nijiko

29th April 2009, 01:18

>>madshi

Just the picture's name is the version of madVR.

ericgur

29th April 2009, 06:40

I have found where I read about it.
I am not a video expert. So I just quote recognized authority :) Don Munsil.

What Munsil said is mathematically correct and IF you wanted to do the "correct" thing for zooming - zoom like an optical lense (e.g. projector/camera lense) than you should do it in linear light RGB.
My background is from professional video post processing. In this field correctness is not important as other features like sharpness, noise level, detail and implementation cost versus achieved quality. The latter is a key factor in algorithm selection. Conversion to linear RGB back and forth is not expensive in HW but performing Lanczos4 on RGB is very expensive than performing Lancso4 on Y and bi-cibuc/Lanczos2 on YU. Madshi uses a softer kernel on UV with good results - this isn't possible in RGB. Many video processing algorithms work better or are much easier to implement in YUV than RGB. Post scaling algorithms like sharpness is a good example. Sharpness filters are not "correct" but they look nice. We want to enhance the video beyond its original digital quality (the output of the decoder).

nlnl

29th April 2009, 07:11

What Munsil said is mathematically correct and IF you wanted to do the "correct" thing for zooming - zoom like an optical lense (e.g. projector/camera lense) than you should do it in linear light RGB.
My background is from professional video post processing. In this field correctness is not important as other features like sharpness, noise level, detail and implementation cost versus achieved quality. The latter is a key factor in algorithm selection. Conversion to linear RGB back and forth is not expensive in HW but performing Lanczos4 on RGB is very expensive than performing Lancso4 on Y and bi-cibuc/Lanczos2 on YU. Madshi uses a softer kernel on UV with good results - this isn't possible in RGB. Many video processing algorithms work better or are much easier to implement in YUV than RGB. Post scaling algorithms like sharpness is a good example. Sharpness filters are not "correct" but they look nice. We want to enhance the video beyond its original digital quality (the output of the decoder).

Thank you very much for very informative reply!
Sorry, I do not have my own opinion, but have a look at the posts #90 Mr.D, # 102 dmunsil in these thread:
http://archive2.avsforum.com/avs-vb/showthread.php?t=460922&page=4&pp=30

madshi

29th April 2009, 07:18

Just the picture's name is the version of madVR.
41 seems to be *much* better on your hardware. Maybe it's less smooth for you with the current madVR build, but with a future madVR build it will be much better than 40.

However, your average GPU rendering times are generally too high! You won't be able to get really perfectly smooth playback with these rendering times, regardless which shader compiler version you're using. You will have to either disable some quality options or use different resampling filters, or upgrade your hardware. E.g. the Radeon 4770 was released yesterday and looks great to me. 50W under full load with performance almost identical to the 4850. Can't get much better than that for HTPCs, I think...

What Munsil said is mathematically correct and IF you wanted to do the "correct" thing for zooming - zoom like an optical lense (e.g. projector/camera lense) than you should do it in linear light RGB.
My background is from professional video post processing. In this field correctness is not important as other features like sharpness, noise level, detail and implementation cost versus achieved quality. The latter is a key factor in algorithm selection. Conversion to linear RGB back and forth is not expensive in HW but performing Lanczos4 on RGB is very expensive than performing Lancso4 on Y and bi-cibuc/Lanczos2 on YU. Madshi uses a softer kernel on UV with good results - this isn't possible in RGB. Many video processing algorithms work better or are much easier to implement in YUV than RGB. Post scaling algorithms like sharpness is a good example. Sharpness filters are not "correct" but they look nice.
Thanks, that makes sense. Don Munsil also stated that he asked Gennum and HQV etc to implement linear light scaling and they replied to him that the hardware cost is too high to justify the theoretical improvement in image quality - at least at this point in time.

My plan is to (at least optionally) offer this processing chain:

(1) Upsample chroma to 4:4:4 by using a soft kernel.
(2) Convert Y'CbCr -> R'G'B' -> RGB -> YCbCr by using shader math (floating point with 32bit per channel), without clipping in between, so the conversion should be nearly lossless. The resulting linear light YCbCr data will be stored in 16bit integer.
(3) Eventually adjust brightness, contrast and saturation (in linear light).
(4) Scale to the final output resolution (in YCbCr linear light).
(5) Eventually do some further post processing (in YCbCr linear light).
(6) Convert linear light YCbCr back to 16bit R'G'B' by using a precalculated 3dlut, which will also do gamut & gamma correction.
(7) Dither down to 8bit R'G'B'.

I think a graphics card like the Radeon 4770 should be able to do all this with ease, at least with 24p content (60p content might be too much of a burden).

Does that sound to you like the optimal way to go for image quality? Or do you have a suggestion on how to make things even better? E.g. I'm not sure on whether I should scale on linear light RGB or linear light YCbCr? Probably it doesn't matter much, I'd guess? I'd prefer to scale linear light YCbCr because I have some scaling algorithm tweaks in mind which might show less artifacts when doing scaling in linear light YCbCr. Also I'm wondering if 16bit integer is enough for linear light YCbCr? Or should I better use 32bit floating point buffers for linear light YCbCr instead?

I don't care right now how much burden it is on the hardware, because graphics cards are getting faster at an almost ridiculous pace. So what may be too much burden today might be easily doable in a year or two. So I want to implement the best quality that is possible, even if it overloads current budget hardware. (But of course there will be options to trade quality for performance...)

FoLLgoTT

29th April 2009, 07:44

@madshi
I love your no-compromise-thinking! I think it is the right way. :)

(6) Convert linear light YCbCr back to 16bit R'G'B' by using a precalculated 3dlut, which will also do gamut & gamma correction.

I don't understand why you gamma correct at this point and not in the hardware LUT of the graphics card. It usually works with 10bits which is enough to avoid banding. Is there a special reason? Or is it impossible to do gamma correction after gamut correction?

Also I'm wondering if 16bit integer is enough for linear light YCbCr?

Maybe I missed the point, but 255 ^ 2.2 is much bigger than 65535.

nlnl

29th April 2009, 07:51

madshi
Please have a look at the ATI Avivo Display Engine architecture:
http://ati.amd.com/technology/Avivo/pdf/Avivo_Whitepaper.pdf.
May be that will help you to develop the best processing chain.

By the way they claim using spatial and
temporal 10bit -> 8,6bit dithering and 10x6 taps scaling filters.

FoLLgoTT

29th April 2009, 08:28

By the way they claim using spatial and
temporal 10bit -> 8,6bit dithering.

This is very interesting! I always wondered why there is no banding when using gamma correction on a Radeon using DVI output.

tetsuo55

29th April 2009, 09:11

That's still sad compared to HQV http://www.hqv.com/technology/index1/1024tap_scaling.cfm?CFID=19763703&CFTOKEN=18870619

1024 tap :eek:

madshi

29th April 2009, 09:56

I don't understand why you gamma correct at this point and not in the hardware LUT of the graphics card. It usually works with 10bits which is enough to avoid banding. Is there a special reason? Or is it impossible to do gamma correction after gamut correction?
There are a number of reasons:

(1) We want to do gamut & gamma correction, not only gamma correction. For doing gamut correction we're using a very big 3dlut. Now if we already use a 3dlut for gamut correction, gamma correction can be done through the very same 3dlut "for free". So why should madVR limit itself to 10bit ATI gamma correction, if it can do 16bit gamma correction on its own without any additional performance cost?

(2) I don't trust the graphics cards manufacturers to get things right. If you look at the chroma upsampling screenshots, you'll see what terrible quality my ATI card gives me. Now there are reports that some users are getting much better chroma upsampling quality from their ATI cards, but only with specific renderers and specific video formats. Anyway, it's a mess. Also I can't get VMR9 or EVR to output video levels without getting BTB and WTW clipped. Or I'm having trouble getting VMR9 to provide PC levels. You see, getting the standard renderers to do what we want is extremely hard. And the fault lies with ATI. Don't know about NVidia. But why the heck should we rely on graphics manufacturers to get things right, if they've proven again and again that they don't know what the heck they are doing in the HTPC area?

(3) The purpose of madVR is to provide best possible quality. On any graphics card. With any source. Without worrying about having to tweak decoder and renderer settings all the time. And this is only possible if I avoid any and all video related processing offered by the graphics card manufacturers. Because they simple are not reliable. Sometimes they work, sometimes not. It can change with driver revisions. It can change with the OS, with the graphics card model, with the video format etc etc. madVR doesn't have any of these problems right now, so why should I even consider going back to depend on graphics card manufacturers getting things right? IMO that would be major step back.

By the way they claim using spatial and
temporal 10bit -> 8,6bit dithering and 10x6 taps scaling filters.
Great. If only they would get the basics right. Like chroma upsampling. Or color conversion without clipping BTB and WTW. Etc...

BTW, if I'd use their taps calculation, madVR's Lanczos8 scaling filter uses 16x16 taps instead of 10x6. And madVR uses 16bit -> 8bit dithering instead of 10bit -> 8bit. So in both cases madVR "wins". The problem is that the number of taps alone is not the decisive factor for image quality...

That's still sad compared to HQV http://www.hqv.com/technology/index1/1024tap_scaling.cfm?CFID=19763703&CFTOKEN=18870619

1024 tap :eek:
HQV marketing is drinking the cool aid. They are counting the number of pixels that go into their scaling filter. If I do the same calculations, Lanczos8 comes out with 16x16 = 256 taps. Ok, so HQV is using Lanczos16 instead of Lanczos8. Or something like that. I could easily add a Lanczos16 resampling filter to madVR, too. The problem is that IMHO actually Lanczos4 looks better than Lanczos8 and much better than Lanczos16 because Lanzos4 is 99% as sharp and aliasing free as Lanczos16 while having *much* less ringing artifacts.

Ok, I don't know which exact resampling filter HQV is using. Maybe it's not Lanczos, maybe they are using something else which has less ringing at higher taps. But still, I don't really see much benefit from using more than 8x8 = 64 taps. The increase in sharpness in minimal, the increase in ringing is big.

BTW, Don Munsil and Stacey Spears prefer using Catmull-Rom scaling over Lanczos scaling because of the Lanczos ringing artifacts. Now Catmull-Rom uses only 2 taps (or 4x4 = 16 taps according to HQV math). Go figure... I don't really agree with their choice of Catmull-Rom, though.

IMHO the number of scaling taps is somewhat similar to the megapixel race with digicams. J6p likes big numbers. Marketing likes big numbers. But the reality is different. Best image quality does not always come with the highest number. Sometimes a higher number can even be bad.

FoLLgoTT

29th April 2009, 10:38

@madshi
OK, I got your points and I agree with you.

So why should madVR limit itself to 10bit ATI gamma correction, if it can do 16bit gamma correction on its own without any additional performance cost?

I just thought about CRT projector users who are using analog output. In this case there is no dithering in AVIVO's pipeline when using ATI's gamma correction, because the DAC itself works with 10bit. So If my projector had a perfect BT.709 gamut and I only wanted to correct gamma, I get dithering with madVR which is limited to 8bit output. With ATI's gamma I don't have this dithering.
Anyway, this special case is no problem at all. I can still use VideEqualizer "behind" madVR and deactivate 3D LUT processing and dithering. :)

tetsuo55

29th April 2009, 10:48

Ok, I don't know which exact resampling filter HQV is using.

They claim to be using a modified version of teranex scaler, which according to them is a military grade scaler.

Teranex scaler seem to used to upscale movies filmed with pre-HD cameras to HD for release on bluray.
The technology has even won an emmy.

The demo's on their site look very impressive, but that's the marketing guys talking ofcourse, reviews on the net seem positive though

It doesn't matter though because its closed source and very expensive.

madshi

29th April 2009, 11:07

They claim to be using a modified version of teranex scaler, which according to them is a military grade scaler.
That's all nothing but marketing talk.

Teranex scaler seem to used to upscale movies filmed with pre-HD cameras to HD for release on bluray.
So what? That does not say anything. If you look at how bad some Blu-Rays look which were "upconverted" from older masters, I'd say it's not even a good idea to market your product with such a reference.

It doesn't matter though because its closed source and very expensive.
And according to my information not as good as Lumagen's scaling, which uses less taps than HQV's scaling, AFAIK.

I'm not saying that HQV quality is bad, not at all. But just because their marketing department goes fancy you shouldn't believe that it isn't possible for us to compete with them quality wise...

yesgrey

29th April 2009, 11:08

Does that sound to you like the optimal way to go for image quality? Or do you have a suggestion on how to make things even better? E.g. I'm not sure on whether I should scale on linear light RGB or linear light YCbCr? Probably it doesn't matter much, I'd guess? I'd prefer to scale linear light YCbCr because I have some scaling algorithm tweaks in mind which might show less artifacts when doing scaling in linear light YCbCr. Also I'm wondering if 16bit integer is enough for linear light YCbCr? Or should I better use 32bit floating point buffers for linear light YCbCr instead?

Remember that YCbCr needs more 1 bit than RGB to contain the same number of colors (to be lossless it would need more 2 bits), so, the only reason I see to perform all the processing in RGB is to gain that extra bit(s).
IMHO 16bit integer is not enough for linear processing. 32bit FP should be the bare minimum. I have tryed running cr3dlut only in 32bit FP and it was not lossless. When I say lossless, I mean simply removing the gamma and reapplying it would yield different results. Not much, only by 1 in some of the components, but there was a difference. Only with 64bit FP I achieved completelly lossless degamma/engamma.
Also, if you're looking for the ultimate solution, the final step should also be performed using shader math, because the 3dlut only can have 8bit per component at the input side, and if you have 32bit FP you will loose some precision when you interpolate linearly for the 3dlut indexing.

tetsuo55

29th April 2009, 11:17

That's all nothing but marketing talk.

Yes i agree.
The end result should be compared right?

Do you think madvr will eventually rival/beat the image quality of those 5000$ players?(assuming DVI/HDMI, videocard's often cannot be the high quality dac's on those standalone players for analogue signals)

I think you are going in the right direction with the "scientific facts only please, no snakeoil" approach.

madshi

29th April 2009, 11:45

IMHO 16bit integer is not enough for linear processing. 32bit FP should be the bare minimum. I have tryed running cr3dlut only in 32bit FP and it was not lossless. When I say lossless, I mean simply removing the gamma and reapplying it would yield different results. Not much, only by 1 in some of the components, but there was a difference. Only with 64bit FP I achieved completelly lossless degamma/engamma.
Ok, that's fair. So I'd have to use 32bit floating point buffers when doing linear light scaling. I'm beginning to see why it costs more performance than scaling in gamma corrected light... :p

Also, if you're looking for the ultimate solution, the final step should also be performed using shader math, because the 3dlut only can have 8bit per component at the input side, and if you have 32bit FP you will loose some precision when you interpolate linearly for the 3dlut indexing.
How about returning to gamma corrected light by using shader math and then feeding the resulting R'G'B' data into the 3dlut? Obviously I *have* to use the 3dlut somewhere if we want to do gamut & gamma correction!

The end result should be compared right?
That would be ideal, but it will be difficult to get clean screenshots from HQV processing! So comparisons might have to be done in real time playback and that means it might be somewhat subjective...

Do you think madvr will eventually rival/beat the image quality of those 5000$ players?
I have no idea, but I sure hope so. Actually I expect to beat them in some ways (e.g. doing linear light scaling etc). HTPCs might lose in deinterlacing quality, though.

yesgrey

29th April 2009, 12:19

How about returning to gamma corrected light by using shader math and then feeding the resulting R'G'B' data into the 3dlut? Obviously I *have* to use the 3dlut somewhere if we want to do gamut & gamma correction!
I think that if you go for the linear processing route you should perform all processing inside madVR using the shaders.
You don't need to use the 3dlut for the gamut and gamma correction. The gama correction is easy, is just using a custom gamma function when converting from RGB->R'G'B'. The gamut correction is also easy to perform; if you use the linearized bradford transform is just a simple matrix multiplication, and the error by using the linearized vs the full bradford transform is not significative, at the maximum is a +/-1 difference in some component values... and since it affects the blue most, it would not be very easy to see the differences. You can always add using the full bradford transform as an option for more powerfull GPUs, of course.
The 3DLUT is a very good solution, but it's limited by it's size. We could never use more than 8 or 9 bit at the input size, and when you consider so important to create a processing chain with a full 16bit depth precision, having one component limiting it to 8 or 9 bit does not seems very logical...
I will run some tests to see how much time the current code I have needs for processing a few pixels. This could give you a raw idea of how it should perform if ported to the GPU...

leeperry

29th April 2009, 13:03

oh yes, 64FP HSLS gamut conversion w/ the existing PS script would be great! no loading time, perfect colors!

just two text files SD.txt/HD.txt that you can switch w/ a batch file depending on the gamut/display

w/ automatic 601/709 decoding depending on the resolution, and we'd be good to go

yesgrey

29th April 2009, 14:14

Here are some benchmarking results using cr3dlut code:

Time for processing 2 107 392 pixels using an Intel E2160@2700MHz (2 cores)
(1920x1080 = 2 073 600 pixels)

YCbCr->RGB 64bit FP: < 1ms

YCbCr->RGB, gamut & gamma correction, CA 1, 32bit FP, 1 thread: 813ms
YCbCr->RGB, gamut & gamma correction, CA 1, 32bit FP, 2 thread: 421ms

YCbCr->RGB, gamut & gamma correction, CA 1, 64bit FP, 1 thread: 688ms
YCbCr->RGB, gamut & gamma correction, CA 1, 64bit FP, 2 thread: 359ms

YCbCr->RGB, gamut & gamma correction, CA 2, 64bit FP, 1 thread: 1656ms
YCbCr->RGB, gamut & gamma correction, CA 2, 64bit FP, 2 thread: 968ms

Now the question is: How can we translate these cpu processing times into gpu processing times?
I've measured the YCbCr->RGB conversion to serve as a reference, because it's already implemented by madshi.
This code is parallel by nature, so with more processing units the processing time should decrease proportionally. Considering the GPUs have lots of processing units, maybe cr3dlut can be fully ported to shader code and used in realtime with no significant penalty...

madshi

29th April 2009, 14:23

You don't need to use the 3dlut for the gamut and gamma correction. The gama correction is easy, is just using a custom gamma function when converting from RGB->R'G'B'. The gamut correction is also easy to perform; if you use the linearized bradford transform is just a simple matrix multiplication
What about your Akima splines? What about doing independent gamut corrections at multiple stimulus levels? What about 10-point (or more) gamma correction? Are you saying that all of that can be achieved with a few simple math instructions? I don't think that's true...

We could never use more than 8 or 9 bit at the input size, and when you consider so important to create a processing chain with a full 16bit depth precision, having one component limiting it to 8 or 9 bit does not seems very logical...
I think you are underestimating the effectivity of trilinear interpolation. Yes, the 3dlut itself may be limited to 8 or 9 bit. But thanks to trilinear interpolation we should have support for virtually any bitdepth we want. Ok, interpolation is not perfect, but I think it's the best we can do.

oh yes, 64FP HSLS gamut conversion w/ the existing PS script would be great!
No, it would not. A really good CMS needs different corrections for different stimulus levels. And that is not possible with a simple PS script.

nijiko

29th April 2009, 14:43

41 seems to be *much* better on your hardware. Maybe it's less smooth for you with the current madVR build, but with a future madVR build it will be much better than 40.

However, your average GPU rendering times are generally too high! You won't be able to get really perfectly smooth playback with these rendering times, regardless which shader compiler version you're using. You will have to either disable some quality options or use different resampling filters, or upgrade your hardware. E.g. the Radeon 4770 was released yesterday and looks great to me. 50W under full load with performance almost identical to the 4850. Can't get much better than that for HTPCs, I think...

Yes, I know. This videoclip is encoded in highly usage of h/w.
So I use it for testing.
In these moments, sadly, I have no plan to buy new h/w...

rack04

29th April 2009, 14:53

I don't want to call this a bug but I do want to see if others are experiencing the same thing.

MPC-HC Build 1.2.1079.0
madVR v0.8
ffdshow tryouts, svn 2918
Windows XP SP3
NVIDIA Quadro NVS 135M

http://i11.photobucket.com/albums/a199/rack04/ffdshowoutput.jpg

http://i11.photobucket.com/albums/a199/rack04/ffdshowrgb.jpg

http://i11.photobucket.com/albums/a199/rack04/madvr.jpg

When playing a 1280x720 video on my 1280x1024 LCD monitor I noticed a delay when switching the video to full screen. When the video switches to full screen the video is stretched for approximately 5 seconds and then adjusted to the correct AR. I don't experience this with VMR or EVR CP. I'm assuming this is due to the video card but I just wanted to bring it up. Thanks.

noee

29th April 2009, 15:10

If you're output is YV12 in FFDShow (which is must be for madVR), then the RGB conversion settings are meaningless.

Second, seems like somebody reported that when using FFdshow, unchecking the "Allow output format changes...." solved some AR issues....Just a guess based on a faded memory.

leeperry

29th April 2009, 15:24

No, it would not. A really good CMS needs different corrections for different stimulus levels. And that is not possible with a simple PS script.
honestly, the PS script does the job! it gives identical results to ddcc. if you can somehow improve its accuracy the better, but it "works". colors look fantastic w/ it in MPC.

maybe in some extreme test patterns, some much more GPU intensive algorithms would show improvements, but IRL it prolly won't....but I'm beating a dead horse here as you're only focused on quality, kudos for that http://forum-images.hardware.fr/images/perso/mzarella.gif

now I'll shut it and let you talk between grown-ups :p

madshi

29th April 2009, 15:36

When playing a 1280x720 video on my 1280x1024 LCD monitor I noticed a delay when switching the video to full screen. When the video switches to full screen the video is stretched for approximately 5 seconds and then adjusted to the correct AR. I don't experience this with VMR or EVR CP.
I'm aware that madVR is slower in switching between full screen and windowed mode compared to some other renderers, but 5 seconds is much more than I'm seeing here. Not sure why it's *that* slow for you...

honestly, the PS script does the job! it gives identical results to ddcc. if you can somehow improve its accuracy the better, but it "works"
It seems to me that you didn't at all understand what I wrote. Do you know what "independent correction at different stimulus levels" means? You may want to read the AVSForum "Lumagen Radiance" thread. Look for posts by Tom Huffman.

yesgrey

29th April 2009, 15:46

What about your Akima splines? What about doing independent gamut corrections at multiple stimulus levels? What about 10-point (or more) gamma correction? Are you saying that all of that can be achieved with a few simple math instructions?
The Akima splines is for calculating the custom gamma curve, so it only needs to be run at the beggining. The gamma correction could be done using 1D LUTs, which are not size limited. We can use 3 1D LUT, of 32MB size each, with 24bit input/16bit output, for example.
I have not yet started the multiple stimulus gamut correction, but I think it would not be very cpu intensive.

I think you are underestimating the effectivity of trilinear interpolation. Yes, the 3dlut itself may be limited to 8 or 9 bit. But thanks to trilinear interpolation we should have support for virtually any bitdepth we want. Ok, interpolation is not perfect, but I think it's the best we can do.
No, I'm not. I only think that the trilinear interpolation works good if the linear aproximation is good. In the case you are considering, converting YCbCr->R'G'B' it would not be so good, because you will convert from a linear quantity at the input, to a non-linear quantity at the output, so using trilinear at bothe sides it's not so good as if both sides had a linear relationship.
Probably it would be better doing something like:
1) madVR processing in YCbCr 32bitFP
2)YCbCr->RGB using 3DLUT (8bit in 16bit out) using trilinear only at the input to get RGB 16bit at the output.
3)RGB->R'G'B' using 3x1DLUT (16bit in 16bit out)

or with a little more precision:
2)YCbCr->RGB using 3DLUT (8bit in 16bit out) using trilinear at the input and output to get RGB 24bit at the output.
3)RGB->R'G'B' using 3x1DLUT (24bit in 16bit out)

Of course this last would be a little overkill, with 1 3dlut of 96MB and 3 1dlut of 32MB each...:D

honai

29th April 2009, 15:47

However, your average GPU rendering times are generally too high! You won't be able to get really perfectly smooth playback with these rendering times, regardless which shader compiler version you're using. You will have to either disable some quality options or use different resampling filters, or upgrade your hardware. E.g. the Radeon 4770 was released yesterday and looks great to me. 50W under full load with performance almost identical to the 4850. Can't get much better than that for HTPCs, I think...

Not to nitpick here, but the claim about the 4770 is not entirely correct. Typical max. power draw of the RV740 GPU is rather at 80W, not 50W. At 90W you'd already get an nVidia 9600GT, but that one has a 256bit data bus compared to the 128bit bus of the 4770. I think for what we're looking here a wider data bus is much more important than a negligible power consumption advantage. ;)

yesgrey

29th April 2009, 15:52

At 90W you'd already get an nVidia 9600GT, but that one has a 256bit data bus compared to the 128bit bus of the 4770.
Yes, but the 4770 uses GDDR5, which has double the transfer rate than the GDDR3 used in the 9600GT.;) and you also need shader power, and for the same shader power of the 4770 you should look into GF9800 or GF250...

madshi

29th April 2009, 16:04

I have not yet started the multiple stimulus gamut correction, but I think it would not be very cpu intensive.
Well, if we want smooth curves between the multiple stimulus points, there needs to be some kind of real time smoothing filter between the multiple correction points, maybe even another Akima spline, or am I wrong?

No, I'm not. I only think that the trilinear interpolation works good if the linear aproximation is good. In the case you are considering, converting YCbCr->R'G'B' it would not be so good, because you will convert from a linear quantity at the input, to a non-linear quantity at the output, so using trilinear at bothe sides it's not so good as if both sides had a linear relationship.
No problem. I don't have to do YCbCr->R'G'B'.

Probably it would be better doing something like:
1) madVR processing in YCbCr 32bitFP
2)YCbCr->RGB using 3DLUT (8bit in 16bit out) using trilinear only at the input to get RGB 16bit at the output.
Would YCbCr->RGB be better than R'G'B'->R'G'B' or Y'CbCr->R'G'B'? I thought using linear light input would not be as good because the range is much higher compared to R'G'B' (you said, we need 32bit float, while for R'G'B' even 10bit integer is usually considered good enough)? No problem for me either way. I can use whatever input/output formats the 3dlut works best with...

3)RGB->R'G'B' using 3x1DLUT (16bit in 16bit out)
Why would we want to use separate 1DLUTs if we already use a big 3DLUT? Doesn't it make more sense to have it all combined in the 3DLUT?

or with a little more precision:
2)YCbCr->RGB using 3DLUT (8bit in 16bit out) using trilinear at the input and output to get RGB 24bit at the output.
I'm letting the graphics card do all the dirty work here. I feed it floating point data and I receive floating point data. Trilinear interpolation is done by the GPU, almost "for free". So output is not limited to 16bit integer. I do get 32bit floating point from the 3dlut processing, anyway. That was already the case with madVR 0.1.

madshi

29th April 2009, 16:17

Not to nitpick here, but the claim about the 4770 is not entirely correct. Typical max. power draw of the RV740 GPU is rather at 80W, not 50W. At 90W you'd already get an nVidia 9600GT, but that one has a 256bit data bus compared to the 128bit bus of the 4770. I think for what we're looking here a wider data bus is much more important than a negligible power consumption advantage. ;)
The 9600GT consumes >20% more power. I don't consider that negligible. For fanless setup every Watt counts. Also you seem to have missed the fact that the 4770 uses GDDR5 memory which has double the bandwidth compared to GDDR3 (which the 9600GT uses).

Here are the true numbers (power consumption measurements done by Xbitlabs):

9600GT:
power consumption: 60.8 W
memory bandwidth: 57.6 GB/s
shader power: 312 GFLOPs
HDMI audio: limited to AC3 & DTS bitstream

4770:
power consumption: 49.5 W
memory bandwidth: 51.2 GB/s
shader power: 960 GFLOPs
HDMI audio: multichannel PCM transport supported

Add to that that the 4770 is seriously underclocked by ATI. E.g. the memory chips used by the 4770 are rated for 64 GB/s.

yesgrey

29th April 2009, 16:22

Well, if we want smooth curves between the multiple stimulus points, there needs to be some kind of real time smoothing filter between the multiple correction points, maybe even another Akima spline...
Yes, probably, but until I start working on it I don't know how it would end up...

Would YCbCr->RGB be better than R'G'B'->R'G'B' or Y'CbCr->R'G'B'?
I don't know. In YCbCr->RGB the trilinear interpolation is a natural choice, because both sides are linear, in the other conversions don't. OTOH, with linear the bit depth used should be higher... I think we should decide which one to use when you start working on it; then we could perform some tests to see what would give the best results...

Why would we want to use separate 1DLUTs if we already use a big 3DLUT? Doesn't it make more sense to have it all combined in the 3DLUT?
No, because the 3DLUT indexing is limited to 8/9 bit and for higher bit depths we have to use trilinear interpolation, which is not so good with non-linear quantities. With 1D LUTs, we can use 24bit indexing, and have full precision for the conversion between linear and non-linear, and leave the trilinear interpolation only for the linear quantities.

Remember I am only answering your question about any suggestions to improve the accuracy. I'm not saying that the possible accuracy improvement by all this would be noticeable...;)

nlnl

29th April 2009, 16:24

The 9600GT consumes >20% more power. I don't consider that negligible. For fanless setup every Watt counts.
Are they going to produce fanless (with passive cooler) 4770 cards?

yesgrey

29th April 2009, 16:24

shader power: 960 GLOPs

Wouldn't it be GFLOPs?

honai

29th April 2009, 16:37

The 9600GT consumes >20% more power. I don't consider that negligible. For fanless setup every Watt counts. Also you seem to have missed the fact that the 4770 uses GDDR5 memory which has double the bandwidth compared to GDDR3 (which the 9600GT uses).

Here are the true numbers (power consumption measurements done by Xbitlabs):

9600GT:
power consumption: 60.8 W
memory bandwidth: 57.6 GB/s
shader power: 312 GLOPs
HDMI audio: limited to AC3 & DTS bitstream

4770:
power consumption: 49.5 W
memory bandwidth: 51.2 GB/s
shader power: 960 GLOPs
HDMI audio: multichannel PCM transport supported

Add to that that the 4770 is seriously underclocked by ATI. E.g. the memory chips used by the 4770 are rated for 64 GB/s.

What was the load (game? video decoding?) to produce that power consumption?

In any case a 10% advantage in memory performance is always significant because that might be just those last 10% that decide between stutter-free and stuttering playback. ;) On the other hand, 10W less power draw is insignificant in light of the fact that a typical northbridge consumes in excess of 40W, a soundcard in excess of 20W, a gigabit NIC in excess of 10W, etc. Also, I think we can agree that the target market for the 4770 is desktop or mATX HTPC machines, i.e. the power supply will always draw in excess of 120W.

So effectively for HTPC usage we should aim for memory bandwidth first, and only then we can start counting W beans. ;)

tetsuo55

29th April 2009, 16:37

The 4770 looks seriously awesome

It has UVD 2.2, i wonder of that means it supports higher than L4.1 h264 video like nvidia does?
Probably not...

I also could not find any application that uses its mpeg1 and divx assisted decoding

If these specs where real facts madVR would not even be needed:

• ATI Avivo™ HD Video and Display Platform
o 2nd generation Unified Video Decoder (UVD 2)
o Enabling hardware decode acceleration of H.264, VC-1 and MPEG-2
o Dual stream playback (or Picture-in-picture)
o Hardware MPEG-1, and DivX video decode acceleration
- Motion compensation and IDCT
o ATI Avivo Video Post Processor
- New enhanced DVD upconversion to HD new!
- New automatic and dynamic contrast adjustment new!
- Color space conversion
- Chroma subsampling format conversion
- Horizontal and vertical scaling
- Gamma correction
- Advanced vector adaptive per-pixel de-interlacing
- De-blocking and noise reduction filtering
- Detail enhancement
- Inverse telecine (2:2 and 3:2 pull-down correction)
- Bad edit correction
- Full score in HQV (SD) and HQV (HD) video quality benchmarks
o Two independent display controllers
- Drive two displays simultaneously with independent resolutions, refresh rates, color controls and video overlays for each display
- Full 30-bit display processing
- Programmable piecewise linear gamma correction, color correction, and color space conversion
- Spatial/temporal dithering provides 30-bit color quality on 24-bit and 18-bit displays
- High quality pre- and post-scaling engines, with underscan support for all display outputs
- Content-adaptive de-flicker filtering for interlaced displays
- Fast, glitch-free mode switching
- Hardware cursor
o Two integrated DVI display outputs
- Primary supports 18-, 24-, and 30-bit digital displays at all resolutions up to 1920x1200 (single-link DVI) or 2560x1600 (dual-link DVI)3
- Secondary supports 18-, 24-, and 30-bit digital displays at all resolutions up to 1920x1200 (single-link DVI only)3
- Each includes a dual-link HDCP encoder with on-chip key storage for high resolution playback of protected content4
o Two integrated 400MHz 30-bit RAMDACs
- Each supports analog displays connected by VGA at all resolutions up to 2048x15363
o DisplayPort™ output support
- Supports 24- and 30-bit displays at all resolutions up to 2560x1600
o HDMI output support
- Supports all display resolutions up to 1920x10803
- Integrated HD audio controller with up to 2 channel 48 kHz stereo or multi-channel (7.1) AC3 enabling a plug-and-play cable-less audio solution
o Integrated AMD Xilleon™ HDTV encoder
- Provides high quality analog TV output (component/S-video/composite)
- Supports SDTV and HDTV resolutions
- Underscan and overscan compensation
o MPEG-2, MPEG-4, DivX, WMV9, VC-1, and H.264/AVC encoding and transcoding
o Seamless integration of pixel shaders with video in real time
o VGA mode support on all display outputs

Too bad it doesnt have hdmi1.3c with hd audio streaming.
And the lack of ati-stream applications is not helping either

Nvidia is flooding the market with open and closed source applications using CUDA and VDPAU

EDIT:

I forgot to mention that its very overclockable, asus has announced a model that will overclock to 1 ghz

madshi

29th April 2009, 16:58

No, because the 3DLUT indexing is limited to 8/9 bit and for higher bit depths we have to use trilinear interpolation, which is not so good with non-linear quantities. With 1D LUTs, we can use 24bit indexing, and have full precision for the conversion between linear and non-linear, and leave the trilinear interpolation only for the linear quantities.
I think I should probably do the "linear <-> gamma corrected" conversion via shader math. So we don't need those 1DLUTs for that purpose.

What was the load (game? video decoding?) to produce that power consumption?
As you can read on Xbitlabs: "the 3D load was created by the first SM3.0/HDR test from 3DMark06 running in a loop at 1600x1200 with forced 4x FSAA and 16x AF".

In any case a 10% advantage in memory performance is always significant because that might be just those last 10% that decide between stutter-free and stuttering playback. ;)
(1) I think the chance is *much* higher that those 300% faster shaders will make more of a difference for smooth playback compared to those 10% more memory bandwidth, even if the 9600GT was really 10% faster in memory access.

(2) Remember that those memory bandwidth numbers are purely theoretical. The effective real life memory bandwidth depends a lot on how effective the graphics card is. FWIW, the 9600GT is speced with 10.4 GPixels/s and 20.8 GTexels/s. The 4770 claims to do 12 GPixels/s and 24 GTexels/s. If those numbers are true, the 4770 seems to be actually faster in memory access than the 9600GT.

On the other hand, 10W less power draw is insignificant in light of the fact that a typical northbridge consumes in excess of 40W, a soundcard in excess of 20W, a gigabit NIC in excess of 10W, etc.
It might be insignificant for you. It is quite significant for me because I want to go fanless and there 49.5W vs. 60.8W makes a noticeable difference.

yesgrey

29th April 2009, 16:59

So effectively for HTPC usage we should aim for memory bandwidth first, and only then we can start counting W beans. ;)
You seem to forget that madVR is based in shader code... the 4770 has 3x the shader power of the 9600GT.;)

If these specs where real facts madVR would not even be needed
Yes it will. Those specs bring nothing new. The 30 bit they talk to are for the three components. madVR processing is 16bit per component, or 48bit for the three components. And there is also all other stuff that is/would be possible using the 3dluts.

leeperry

29th April 2009, 16:59

It seems to me that you didn't at all understand what I wrote. Do you know what "independent correction at different stimulus levels" means? You may want to read the AVSForum "Lumagen Radiance" thread. Look for posts by Tom Huffman.
OK, so the CMS needs to take in account that 25,50,75 and 100 IRE need different coeffs?

but even Tom Hoffman says that it's overkill...if I got it right ?!

http://www.avsforum.com/avs-vb/showpost.php?p=15078121&postcount=3118

http://www.avsforum.com/avs-vb/showpost.php?p=15035842&postcount=3103

The improvement, though measurable, would be very small, relevant to only absolute purists

I'm sure you can nitpick until the end of days about colorimetry, but what is required is fully achieved by ddcc/the PS script IMVHO....not until we get 10bit displays at least.

but indeed almost 5 ΔE on the red at 100 IRE is a hell lot :eek:

http://www.avsforum.com/avs-vb/showpost.php?p=15126353&postcount=3130

but OTOH, you need a freshly recalibrated spectrophotometer, a pitch black room w/ black painted walls and some obsessive–compulsive disorder about colorimetry to make it even matter I think...it won't matter as much for an HTPC enthusiast w/ a 8bit display and a $200 colorimeter :o

but sorry to interrupt, I'll come back when you'll polish the smooth side of mVR :thanks: