Video pixel shader pack [Archive] - Page 4

JanWillem32

21st December 2010, 12:39

For both, I'd have to edit the lines and compile.
I'm not so worried about compiling with lines 1661 to 1666 of DX9RenderingEngine.cpp disabled/removed. The DirectX reference documentation is quite clear on inheriting the default rendering and sampler states, if it's not overridden by other code.
For the other item I had to search a bit, because I'm mostly working with DirectX10 and 11. The DirectX 9 rules are a bit different, and I don't remember everything from when I was educated on this subject. A basic search confirmed what I already thought:
http://www.robertwrose.com/2005_05_01_robertwrose_archive.html
"Currently only floating point textures are supported by today's vertex shader hardware, so the data needs to be stored in one of these formats:

D3DFMT_R32F: 32-bit float format using 32 bits for the red channel.
D3DFMT_A32B32G32R32F: 128-bit float format using 32 bits for the each channel (alpha, blue, green, red)."

That is quite logical: look inside some pixel shaders, the main function and return type are "float4". That means that any texture that goes trough the shader pipeline will have to be converted to fp32. I do know that there's a trick with using partial precision mode, but that only works on the calculation format, not the texture in process.
With DirectX 8 and older hardware, the surface formats were locked to the display format, so A8B8G8R8 was the largest processing format available if 32-bit color was the display format. There was no support for floating point surfaces.

I would have to test if setting D3DFMT_A32B32G32R32F as surface format improves performance because of not having to convert between fp16 and fp32 textures. It could also very well be that with some types of older hardware texture swapping occurs, and memory speed becomes an issue. I don't think that's likely, by the way. (Even the cheapest GPUs have huge amounts of L2/L3-like cache to store big chunks of textures and vertices in.)
http://developer.amd.com/media/gpu_assets/R2VB_programming.pdf
That document indicates that the D3DFMT_A32B32G32R32F format has been used as default since the earliest DirectX 9 hardware, the Radeon 9500. (Too bad I couldn't find anything from nVidia, they usually have good documentation of the hard- and software capabilities, too.)

bobdynlan

21st December 2010, 12:47

That was funny, MPC-HC it's not such a big mess, your comments are scaring people away :devil: "texture" keyword should have nailed it down.
While I'm at it anyway, why is "full floating point processing" specified as fp16 RGBA? In my book, a full floating point is fp32, a half is fp16 and a double is fp64.Marketing...
True, it's not the best choise, it should be fp24, as that's the highest precision you can get that works on all dx9+ gpus. It's only alpha that's missing, the color bits are all there. My 9800pro was fp24. nvidia did support fp32 at that time, I guess it will make a better platform for this kind of work. I remember reading not so long ago about ati "optimizing" fp16 by halving the bits, and that may be a reason for the mixed results people are getting now.
Anyway, this feature is more of a overkill until higher bit panels become mainstream.
[EDIT]
If you’re using wide data types the bandwidth required for this could become a bottleneck. Also keep in mind that wide data types not only require extra bandwidth, but also need additional cycles when you sample them in the pixel shader, even if all data is in the cache. An RGBA32F texture requires 4 cycles per sample, whereas RGBA16F only requires 2 cycles. With the
Radeon X1900 and Radeon X1600 providing a 3:1 ALU:TEX ratio in pixel shaders it becomes increasingly more important to keep the amount of cycles spent on texture sampling down.
From that doc. Keep in mind that it's refering to X1xxx hardware.

tetsuo55

21st December 2010, 12:56

Interesting stuff!

Quality should come first, and performance second. (although its always a good idea to support a mode with lower quality and higher performance)

@bob > higher bit panels = more than 10bit?

bobdynlan

21st December 2010, 13:14

Higher than 6 :) Most people have shitty TNs.

It compiles fine without those presets and it works as usual at runtime with all the Presentation options and shaders enabled.
[EDIT]
Magnification shader seems different with the new build... for the naked eye. Maybe it's placebo...
Down-scaling does not create white borders on my system on both builds, instead repeats the last pixel until it reaches the screen border. Hmm, I don't have a proper sample to observe the filtering, but it seems it's not enough to fix the issue (again, naked eye).
[EDIT2]
Comparation: Left is the new build
http://img156.imageshack.us/img156/5203/38703114.png:cool:

JanWillem32

21st December 2010, 14:25

Well, I'm probably a scary programmer..:p (I know I should spend more time on creating regular shaders. At the moment I'm only testing a new sharpening method/filter.)

The fp24 calculation format exists, but it doesn't have a equivalent surface format.
Currently D3DFMT_A16B16G16R16F surfaces are used in MPC-HC when "full floating point processing" is enabled. The standard fp16 only holds 10 integer bits, so it's already not much to go with if you want to use dithering for the A2B10G10R10 display format. Two whole bits of overhead over the X8B8G8R8 format should be fine when dithering for just 8-bit output.
When I saw the format section in the source code, I was wondering why D3DFMT_A16B16G16R16F was used exclusively. When working with heavy HDR rendering, floating point surfaces are required for the lighting effects. For real-time rendering, it's usually a mixture of fp32 for critical or heavily shaded surfaces, and fp16 or less for "background".
When sampling a texture, it does quite matter if alpha blending, mipmap generation, anti-aliasing and anisotropic filtering is disabled. That's all quite normal to disable if you're working in 2D only. The sampling of textures only requires one unfiltered input pixel per sampled pixel in that case.
Sampling textures becomes harder in 3D games due to the usual filtering that requires multi-sampling to render a single pixel (from a few layers of alpha-blended textures). That's why the documentation warns to not sample too many points for each shader. It eats up a lot of memory resources to supply a single shader unit with many pixels at once.

It's good to know that the sampler states can probably be reverted to the defaults.
Can you also take a look at lines 120 and 121 that force "clamp"? I don't now if the entire block of sampler states should be removed or "D3DSAMP_ADDRESSU, filter" and "D3DSAMP_ADDRESSU, filter" should be inserted.

bobdynlan

21st December 2010, 15:11

Maybe D3DTADDRESS_BORDER is what you need? My experience in this field is next to none...

While you are at it, maybe you can take a look at the issue with 10bit output mentioned by Mercury_22. First not-working rev 1826. Back then mpc-hc had another layout, I guess DX9AllocatorPresenter.* was all-in-one, now DX9RenderingEngine.* is branched from that?!
http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/trunk/src/apps/mplayerc/?pathrev=1825

JanWillem32

21st December 2010, 15:51

DX9RenderingEngine.cpp, lines 191 to 196 allow detection for 10-bit support. The problem with 10-bit is that it requires exclusive mode with this kind of implementation. See also: http://msdn.microsoft.com/en-us/library/bb172558%28v=VS.85%29.aspx

The older source code didn't include detection. If it was enabled (forced) back then, it either worked or blanked the screen. Right now, I'm guessing the detection is done outside of the exclusive mode, so it always returns negative. A good first step would be to test if 10-bit output can be forced again, to see if it still works. I don't know the exact syntax to force "succes" out of lines 191 to 196, however.
Enabling 10-bit again would be very nice indeed. In the past I've successfully used it with MPC-HC, and I still use it with Photoshop.

tetsuo55

21st December 2010, 15:57

Awesome work so far guys!

From what you guys have been posting here it looks you are going to fix up to 10 bugs with regards to performance and image quality for "scaled" video!
:thanks:

JanWillem32

21st December 2010, 16:20

...:D Well, right now I haven't actually produced anything but a few half-baked pixel shaders. But with some luck, and a lot of help from some skilled people, we might just produce something useful.

As for lines 120 and 121:
hr = pD3DDev->SetSamplerState(i, D3DSAMP_ADDRESSU, filter);
hr = pD3DDev->SetSamplerState(i, D3DSAMP_ADDRESSV, filter);
It could also very well be that the entire block 115 to 122 is useless.
All entry's of "D3DSAMP_MIPFILTER" can be set to "none" if the work is done on pure 2D space, by the way. That might improve performance when a shader doesn't exclude mipmap fitering in the sampler state. -Correction, for DirectX 9, the default value is already D3DTEXF_NONE.

bobdynlan

22nd December 2010, 17:50

You can't just comment the whole block, because there are some other stuff involved. For example the OSD needs linear filtering or else it looks bad. So it needs to be patched case by case.
I do remember image looked sharper some time ago. These pictures prove that an extra filtering step it's being applied. First two compare the nearest neighbour, last two bicubic -1, 16x(double window + test resize shader).
http://img149.imageshack.us/img149/3118/defaultnearest.th.png (http://img149.imageshack.us/i/defaultnearest.png/)http://img232.imageshack.us/img232/7791/patchednearest.th.png (http://img232.imageshack.us/i/patchednearest.png/)
http://img836.imageshack.us/img836/6718/defaultbicubic1.th.png (http://img836.imageshack.us/i/defaultbicubic1.png/)http://img69.imageshack.us/img69/8595/patchedbicubic1.th.png (http://img69.imageshack.us/i/patchedbicubic1.png/)

JanWillem32

22nd December 2010, 19:26

If the OSD is handled by a pixel shader, it can specify linear interpolation for up- and downsizing by the sampler in the shader code:
sampler2D s0 = sampler_state{MagFilter = Linear; MinFilter = Linear;};
(Or whatever sampler addressing instead of s0 is used in that case.)

This webpage points out the default sampler states:
http://msdn.microsoft.com/en-us/library/bb172602%28v=vs.85%29.aspx
Unless some fancy type of effect filtering has to be forced for all shaders, I don't think any of the defaults should be overridden in the main code.

It's good to see that the test shader is working as it should. Next time, do avoid the "double window" setting, it's not that pretty to see two filtering methods combined.

JanWillem32

24th December 2010, 14:09

To do:
-Try to compile a program with a GUI for the first time...
-Try to do the same with MPC-HC, for testing purposes.
-Test to see if the most recent shader compiler can be included. (The current version is 9.29.952.3111, http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=3021d52b-514e-41d3-ad02-438a3ba730ba&pf=true indicates that the most recent version is 9.29.1962.)
-Test to see if there's any quality degradation with the default scalers, if the shader sampler states are reverted to the DirectX 9 defaults. (That's unlikely, as the code of the default scalers isn't bad at all.)
-Test to see if any other shader components require updating (e.g. the current dithering and color correction shader).
-Test the difference in performance with standard fp16 and fp32 surface formats.
-Force the code to allow 10-bit RGB output to the display.
-Make proper detection code for the 10-bit RGB output mode.
-Submit a support ticket concerning the exact lines of code that have to be altered to make shaders work properly, including sufficient explanation.
-Submit a support ticket concerning the HLSL shader compiler.
-Submit a support ticket concerning code updates to make the 10-bit RGB output mode work again.
-Submit a support ticket to ask which shaders are interesting enough to include in the source.
-Have a merry Christmas and a happy new year.

For the people that I've scared with my techno-babble the past few days:
My normal shaders are quite easy to use once you know how to copy-paste them to the compiler screen.
I always include a few lines of comments for when to use a specific shader and what it generally does, without the techno-babble. If any of the comments need an improvement, please let me know.

I did a lot of work on the shaders this time. The shaders are now ready to work with the default sampler states. Once the sampler states are reverted to default in the program, the biggest improvement will be with the performance of all shaders. For "projector film shaking" and "wave" there will also be proper rendering of the black borders.

CiNcH

24th December 2010, 14:59

It seems you removed your first chroma upsamplers? Quality was quite good at a low GPU usage.

Will the Catmull chroma upsamplers make a big difference quality-wise? How about GPU usage? Seems chroma has to be upsampled in two steps?

JanWillem32

24th December 2010, 16:00

"4÷2÷0 chroma blur for SD&HD video input on old and slow PS 2.0 hardware" is still included, it has everything the old version had, except for the sharpening kernel (that had a "bleeding" problem).
There is a one-step shader called "~4÷2÷0 Catmull-Rom spline5 chroma up-sampling for SD&HD video input", but it has a compiling problem with compiling for PS 3.0 in MPC-HC at the moment. The external shader compiler does take it, and MPC-HC does compile it with PS 2.0a. The problem can probably be solved by upgrading the internal HLSL shader compiler to the newest version.
The quality that the spline chroma up-samplers deliver is subjective, but I like the well-defined chroma borders, even with small details of intense colors. For what I've seen, the ringing artifacts are rare. Also, the color of both surfaces and borders with high chroma differences seemed better balanced, compared to what my first shader produced.
The GPU usage isn't too much with the spline4-type, but the spline5-type does sample 25 pixels and performs 15 spline fittings to produce 1 pixel. I don't know how much much improvement in performance the change in sampler states will give. I will have to test it once I find out how to work with the MSVC2010 compiler.

DottorLeo

24th December 2010, 17:25

Hi JanWillem32! I would try to use your shaders to improve my dvd and mkv (SD) experience but i'm quite new to this. How should the shader filter chain be created?

My final target would be:
1) Upscale the source to 720/1080
2) Denoise slightly (and take care of mosquito noise if it's possible)
3) Sharpen

My GPU is an ATI 5770. Thanks!

JanWillem32

24th December 2010, 18:05

Cater it to taste, but the settings I use currently are:
-If the chroma isn't up-sampled (like with my HD4890 with its current settings), the first step is "4÷2÷0 to 4÷2÷2 intermediate Catmull-Rom spline5 chroma up-sampling for SD&HD video input", the second is "4÷2÷2 Catmull-Rom spline5 chroma up-sampling for SD&HD video input".
-"gamma conversion of HD&SD video RGB to linear RGB"

In screenspace: (in this thread I already described how to disable the internal scalers completely)
-"Catmull-Rom spline5 height doubler" (my display resolution has more than twice the width and height of all SD material, a combination of spline5 and spline6 is roughly equivalent to spline10)
-"Catmull-Rom spline5 width doubler"
-"Catmull-Rom spline6 height resizer" (with the correct magnification factor for my display resolution)
-"Catmull-Rom spline6 width resizer"
-"sharpen complex v3 + deband + minimal denoise"
-"gamma conversion of linear RGB to HD&SD video RGB" +color profile enabled (you might want to use one of the two other gamma conversion types if you don't have a color profile installed)

I set all of them to compile for PS 3.0. I do have to increase the 2D load GPU clock to 675 MHz. That's still well below the 3D clocks, and it doesn't need a higher voltage than the idle setting. It does heat up my former high-end GPU a lot (the fan is loud).
For HD I can't use the "Catmull-Rom spline5 ? doubler"-type shaders, because of the higher resolutions. On top of that, I will use different denoise presets, depending on the amount of noise present in a video. I adapt the standard "mosquito denoise" and the regular "denoise" in the Catalyst Control Center, as well. My advice is not to overdo on the three of them, they can all blur a lot in their own way.

DottorLeo

24th December 2010, 23:01

JanWillem32

25th December 2010, 20:35

MPC-HC sets 6 environment data registers for both video input and screenspace shaders.
c0.x: horizontal texture/screen resolution (integer)
c0.y: vertical texture/screen resolution (integer)
c0.z: amount of frames processed since starting the render (integer)
c0.w: amount of seconds passed since starting the render (floating-point)
c1.x: the pixel width relative to the texture sampling range <0,1> (floating-point)
c1.y: the pixel height relative to the texture sampling range <0,1> (floating-point)

The default scaling shaders also receive data of how much each should position and resize the picture. (The color correction and dithering shader uses some extra registers as well.)
I tried to access those registers, but I think those registers are excluded from the normal shader environment. Without those registers, I can only write shaders that automatically scale down to a certain resolution.
I personally use .REG file profiles to switch scaling and noise filtering settings. It's currently a lot easier to switch by writing a shader list preset to the registry, compared to manually switching. I might help the project a bit, so that shader lists can be loaded from presets inside the program, and without having to start playing a video first. (I've never done any GUI design before, so that will be more of a long-term plan.)

tetsuo55

25th December 2010, 20:44

You could join us on IRC, some dev's idle there and can help you create the changes.

server freenode, channel mpc-hc

TheElix

4th January 2011, 18:16

Hi! I've just begun to try out your new batch of shaders and I think I've found a bug:
error X3000: syntax error: unexpected token ';'
In sharpen complex v3 + deband + minimal denoise.txt

Maybe you can help me in this issue. I have this particular BD for testing LCD TVs. On my LCD monitor I have too bright blacks. Let me say that I have set full dynamic range (0-255) in the player MPC-HC, in the video driver, in the decoder - everywhere. And still I get "gray" blacks on some sources.
I tried to fix this with your 16-235 to 0-256 for SD&HD video input shader, however it diminished detail greatly: http://screenshotcomparison.com/comparison/17151
Do you have any advice?

Oh, and concerning your hybrid shader. This time I tested deband and... is this it? Well, I see the difference. Maybe it's the best you can do with a shader. But the difference is not as dramatic as with madVR. http://screenshotcomparison.com/comparison/17153

Here's the video I tested deband with. http://narod.ru/disk/2732005001/Banding_720p.rec709.mkv.html

bobdynlan

4th January 2011, 21:46

Testing banding (as in colour banding) with only gray gradients it's not the best choice, you should try out some anime (cartoons) or some movie with sky, oceanic views.

Please check this thread for some test samples regarding levels: http://www.avsforum.com/avs-vb/showthread.php?t=948496 Try the mp4 samples. Everything is based upon http://w6rz.net/ test patterns.

I guess your issue is with gamma. So you should try a gamma conversion shader, with some custom parameter. It does not work out of the box, you must test different values yourself.

These type of shaders were not made very user-friendly unfortunately. JanWillem32, take a look at this one that I've translated some long time ago from virtualdub's vdshader - Apply gamma correction://ps_2_0 LINEAR GAMMA
/* translated from virtualdub's vdshader:Apply gamma correction */
sampler s0 : register(s0);
#define adjust_gamma 1.5

float3 LinearToGamma(float3 c) {
return c <= 0.0031308 ? 12.92*c : (1+0.055)*pow(c, 1.0/adjust_gamma) - 0.055;
}

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float4 c0 = tex2D(s0, tex);
float3 c1 = LinearToGamma(c0.rgb);
return float4(c1.r,c1.g,c1.b,c0.a);
} Is it not more familiar to adjust a gamma value like 1.5 than 563/256.0? :cool: I suspect you've used the same "magic constants" to come up with your integers, not?

TheElix, some value less than 1.0 (like 0.8) will work for you with the above shader. Or you could use some of JanWillem32's gamma conversion shaders like the wide gamut RGB to linear RGB and mess with the 563/256. parameter.

JanWillem32

4th January 2011, 23:47

@TheElix I corrected the typo in "sharpen complex v3 + deband + minimal denoise". It's becoming a bit hard to test all shaders, at the moment I've made 93 (revisions not included). Thank you for noticing.
I had exactly the same problem when calibrating my parent's LCD TV. I couldn't get decent black without the "dynamic" (ugly torch) mode. I fixed it by disabling all color controls in the hidden factory setup menu. It now needs a color profile to display properly, but at least I can use the complete dynamic range of the display. I know, that type of setup isn't the most consumer-friendly. Another thing that worked okay for me was lowering the total brightness, while raising the whitepoint settings and contrast. It's a bit different with every device. I just wish every device had a RGB 1:1 mapping-to-panel mode. "16-235 to 0-256 for SD&HD video input" causes clipping in your case, it's best not to use it.
The debanding shader works okay. It's not very fair however to compare it to the dithering engine of MadVR, as it doesn't dither on its own. What you're seeing is simply banding by 8-bit limitations.

@bobdynlan "brightness, contrast and gamma control" is the regular gamma control shader, it's not the hardest one to configure.
"gamma conversion of HD&SD video RGB to linear RGB" is the normal shader to remove gamma from a SD or HD video. It's useful because with linear RGB you can use exact multiplications of color values, while keeping the same contrast impact when working on lighter gray compared to darker gray. That's why I mark some shaders with: "This shader benefits from converting to linear RGB, instead of using sRGB or HD&SD video gamma input directly."
"gamma conversion of linear RGB to ?"-type shaders are for converting the linear gamma to the display gamma format.
The shader you pasted is only valid for sRGB conditions, it's not for HD and SD video.
Nice test patterns, by the way. It's a good for testing constant gamma on output.

TheElix

5th January 2011, 00:00

Thanks, bobdynlan! I've tried this shader and the results lead me off the track, as always. Is this the video I really want to apply any changes to? Take a look...
The End screen. It should be black, right? http://img29.imageshack.us/img29/3831/blacktc.png Well, it isn't. That's why I thought the black levels should be tweaked.
And then here's another black screen that comes after: http://img41.imageshack.us/img41/8952/blackip.png. And it's... blacker than the previous one. It doesn't seem completely black, but if I open this picture in Photoshop I can even spot 0,0,0 dots there. Along with 1,0,4; 5,1,2 etc. And it doesn't look perfect black, it doesn't bland with the black stripes on top & on bottom. I'm not knowledgable in these things. But I'm no dumb either to assume that this isn't about TV or PC levels. That color noise might come from somewhere else. And it's not something you can do about with gamma conversion shaders, right?
It's nasty, btw. It darkens the dark parts but it also brightens the bright parts. At 1.45 it gives me perfect black screen (the last one), but it also over-brights some frames.
The temporary solution I found (if I want to see perfect-black THE END screens, lol) is to decrease brightness. I did it in my graphics card drivers. Brightness set at -2: http://img29.imageshack.us/img29/5163/blackbrightness2.png

JanWillem32
It's not very fair however to compare it to the dithering engine of MadVR, as it doesn't dither on its own. What you're seeing is simply banding by 8-bit limitations.
You're absolutely right. Sorry I even mentioned it.

bobdynlan

5th January 2011, 04:44

JanWillem32, I take no credit as I've only linked the patterns.
I was just pointing out the need for a user-friendly parameter, but now there is no point after seeing your "brightness, contrast and gamma control shader".
It looks very clean and works well, :thanks:
Was easy to miss as your layout is not very well organized. What do you think about this one:http://www.mediafire.com/?bda6xd63czecdvb?

TheElix, you should definitely use that one. But even if it does feel more comfortable adjusting things in mpc-hc alone, on-the-fly, without messing with the by-now-get-used-to desktop settings, color profiles and so on, in the end you need a proper calibration.

For the brightness, contrast and gamma control shader, start by adjusting gray gamma, i.e. same value for RedG, GreenG and BlueG. To make the numbers more meaningful (display settings or calibration software), replace default 1s with 2.2/x.xx where x.xx is the new gamma. Higher than 2.2 will increase midtones, less will decrease them. I guess you need to increase them for detail (ex: 2.2/2.4). Then decrease brightness in .01 steps (ex -0.01) and increase/decrease contrast. Be careful with the contrast, as that can break your previous result quite dramatically, that's why it is better to set it last or not use it. Those patterns will be useful for brightness and contrast, I don't know some available source for gamma. I've re-uploaded one file I've found here (http://www.filefactory.com/file/b4fd52e/n/GAMMA_TEST_CLIP_HD.mp4). You will find yourself adjusting many times for different sources until you settle for just a few presets. Or maybe you're lucky and you only have issues with that particular media. Btw, screenshots are not so useful as those do not reflect postprocessing. The best way to capture it is with a physical camera pointed at the screen.

Looks like panels these days are the same as light - not linear by design :cool: So most of us we have to live with less accuracy for deeper blacks without detail crush. Happy Backlit Bleeding, everyone :devil:

janos666

7th January 2011, 19:36

DirectX 10 and 11 can use the output from the processing format without changing it. The video card then uses the color LUT to convert the colors of the output frame and (preferably) input that at the highest acceptable bit depth format for the digital connection, or pass it trough a DAC to output analog signals. Such processing chains are completely normal for full-screen DirectX games with HDR

It sounds very interesting but I can't believe it. :p

I use my display with DisplayPort connection, so the output after the VGA LUT is always 10 bit/color RGB.

Do you say that I have real 10-bit display mode when I run any DX10/11 games with HDR rendering?
Can I really enjoy a real high dynamic range? Isn't it truncated/rounded or dithered back to 8-bit, and always 8-bit, every time in the current game engines?
(Did I miss the big marketing BS about the new features or did they forgot to diffuse BS around it?)

I didn't really played too much since I have this display and very few games use DX10+ (which I care about).

///Sidenote:
According to the HDMI-EDID info, it can receive 12 bit/color (not a surprise since the DeepColor standard requires at least 12 bit/color -> works in the practice or not is another question... ; There is no further information if it works with any resolutions or some resolutions which are smaller than the native resolutios.) But there is no any indicator which tells me the actual output bit depth when I use a HDMI connection. So, I am not sure if it's dithered 8-bit (ATI cards like to dither the output with single-link DVI connection too), real 10-bit, or what... That's why I kept the DP connection where I can see the indicator that it's real 10-bit. (Confirmed 10-bit <-vs-> "up-to-12bit but actually unknown")
What do you think about it?

And sorry for the offtopic talks, but: What do you think about the possibility to inject a small code into any DX engines which uses a 3DLUT for color correction (mostly for WCG displays)?
Would it be even possible? (I could see that a lot of thing can be done with a simple DLL injection.)

Last OFFtopic thing:
Aren't you interested in a small C++ practicing? :)
Here is this CMS engine: lcms2 (http://www.littlecms.com/). It's already used by MPC-HC to construct the "small" 3DLUT for color correction. (Another thing: Don't you want to increase the size of it? Like 256x256x256, for testing purposes...)
I think it would be very easy to write a small command line software which creates a madVR compatible 3DLUT (http://heanet.dl.sourceforge.net/project/thr3dlut/doc/specification.txt) with the necessary corrections between a reference (for example, a matrix+gamma type Rec709 virtual) and a device (display XYZ cLUT type) profiles.
But I have zero real life programming skills. (I gave it up after a short time during the basics of the object oriented programming and I kept learning civil engineering :p).

JanWillem32

8th January 2011, 06:02

Okay, a basic lesson in DirectX work then:
HDR allows the usage of complex shaders by allowing floating-point formats. I will keep the implication for the vertex math aside for now. In the past you had to be careful not to overstep 0% or 100% brightness for each of the 4 ARGB components, as integer formats such as A8R8G8B8 will always clamp the range to 0% or 100% for each step. Floating point surfaces have a sign bit that allow values below 0% and a number of exponent bits to allow values beyond 100%.
It's normal in games to have all kinds of layers of rendering by textures and shaders that set up a pixel before it's sent to the backbuffer. All those layers can overshoot the normal range, especially the lighting effects. Constantly clamping the range hurts the quality of black and white values. Additionally, HDR rendering often adjusts the dynamics of the contrast, brightness and gamma to human perception characteristics. Think about bloom effects, automatic adjustments to night vision, blinding effects by intense lights. The two floating-point color formats use 10 or 23 integer bits minimum in the normal range, for A16B16G16R16F or A32B32G32R32F formats respectably. That also helps to maintain more quality throughout the processing chain.
HDR techniques were introduced after the introduction of DirectX 9. DirectX 10 and 11 further refined them. Not all rendering engines use HDR techniques.

A real 10-bit display mode requires a complete display chain that maintains the quality throughout the chain. Currently, it's not possible to get better than 8-bit output to the video card without the fullscreen exclusive mode. The windows desktop locks the display mode to desktop format, that's a maximum of 8-bit with the current display drivers. The rendering engine of the program has to set the display mode to 10-bit or more, as well. DirectX 10 and 11 allow the complete rendered surface to be used as the display surface, even if it's in A32B32G32R32F. DirectX 9 is limited to these formats: http://msdn.microsoft.com/en-us/library/bb172558%28v=VS.85%29.aspx .

It's reported that 10- and 12-bit modes do work with both ATi and nVidia graphics cards. For digital signals, the receiver needs to set the capability of accepting the 10- and 12-bit modes. Single-link DVI doesn't have a lot of bandwidth, so that might be an obstacle, too.

The 3DLUT can be handled in the screenspace processing chain, just like the regular brightness and contrast settings. To make it work properly, it has to be compiled into the main engine.

I'm already developing a bit, and indeed I've taken a look at the CMS engine. It's one of the last items that's completely stuck to one format (A16B16G16R16F on the renderer side). I'd love to improve it, once I learn how it's operated.

@bobdynlan I do have to sort them a bit. I'm currently trying to get the shaders integrated into the main code, but it will need a bit of work to get there. I made too many shaders to handle in the current menu and the Y'CbCr-type shaders have to do RGB conversions because they are inserted in the wrong place in the processing chain.

janos666

8th January 2011, 14:15

You wrote a lot of things which I already knew or I don't feel important to answer my question. I hoped a simple Yes or No. :)

Currently, it's not possible to get better than 8-bit output to the video card without the fullscreen exclusive mode.

Is there a difference between the usual D3D Full Sreen Exclusive mode and how the usual D3D games work in Full Screen mode? (Do the games basically work in D3D Full Sreen Exclusive mode? Is there "Non-Exclusive D3D Full Screen" mode? Do games use that?)

The rendering engine of the program has to set the display mode to 10-bit or more, as well.

This is what never happens right now with any games, I think.

It's reported that 10- and 12-bit modes do work with both ATi and nVidia graphics cards.

MPC-HC uses it already, doesn't it?

DirectX 10 and 11 allow the complete rendered surface to be used as the display surface

I already quoted the period from your earlier post which puzzled me, but I think this period clarified it. It's allowed but that doesn't mean it's used.
You earlier post suggested (for me) that the final display output is automatically set to the highest available format with DX10+ engines. That's why I thought it means my current DX10+ games use 10 or even 12-bit output already.
But none of the current games (any DX or OpenGL game engines) work with more than 8 bit/color display output. Is this right?

That GUI looks nice. I hate the right-click menu.

JanWillem32

8th January 2011, 16:06

Is there a difference between the usual D3D Full Screen Exclusive mode and how the usual D3D games work in Full Screen mode? (Do the games basically work in D3D Full Screen Exclusive mode? Is there "Non-Exclusive D3D Full Screen" mode? Do games use that?)
There is a full screen "windowless" mode. It's like MPC-HC when you enable the "Full Screen" option in the right click menu. The exclusive mode performs a lot better. That's because there's no rendering or interference of the Windows desktop environment in the exclusive mode. A lot of games don't use exclusive mode, probably because it requires programmers with some DirectX or OpenGL skill.

This is what never happens right now with any games, I think.
It's indeed true that many games just do 8-bit output, often even with a complete 8-bit processing chain. That's because older video cards can't do anything else, IGP's lack capabilities, memory speed and processing power, and designing processing chains for low-end to high-end PCs is often too bothersome for programmers. At least MPC-HC allows switching the rendering modes.

MPC-HC uses it already, doesn't it?
8-bit regular or 10-bit in exclusive mode. DirectX 9 doesn't allow more than that. Video card drivers often constantly send signals to the display with the highest available color bit depth, to avoid losses when using the color LUT. That's even when the input format is of a lower bit depth.

I already quoted the period from your earlier post which puzzled me, but I think this period clarified it. It's allowed but that doesn't mean it's used.
You earlier post suggested (for me) that the final display output is automatically set to the highest available format with DX10+ engines. That's why I thought it means my current DX10+ games use 10 or even 12-bit output already.
But none of the current games (any DX or OpenGL game engines) work with more than 8 bit/color display output. Is this right?
I know a few developer demos that transfer between entire frontbuffers to be used as a backbuffer in DirectX 10/11. The surfaces, backbuffer and display format can be up to A32B32G32R32F. Such a mode allows the video card to execute dithering or rounding to the transferred format for DP/HDMI/DVI/analog. For games, well, see my other two comments.

That GUI looks nice. I hate the right-click menu.
Same for me, too. I'd love to have the option to set presets quickly in a menu, though.

JanWillem32

18th January 2011, 11:00

cca

19th January 2011, 13:31

I've made some corrections to the "0-256 to 16-235 for SD&HD video output" and "16-235 to 0-256 for SD&HD video input" shaders.
There's also a new "unsharp luma mask for SD&HD video" for specific sharpening on luma.

http://www.mediafire.com/?n3skdfx0thvps53

Tried to download, instead mediafire gives "Error downloading file. Retrying..." and fails.

EDIT: the re-upload works, thank you.

JanWillem32

24th January 2011, 22:29

For this batch, I've cleaned up the gamma conversion shaders. I turns out that the video gamma transfer formula is simply never used. The usual gamma for consumer video mastering is 2.4. There are exceptions when 2.35 is used, and I've been told that some just transfer the Digital Cinema gamma of 2.6 (quite wrong for the current consumer devices).
I also added "semi-random colored surface noise" and "contour color".

mr.duck

5th February 2011, 04:45

I'm just using one of the shaders to adjust the saturation down a bit.

Most useful, thanks. Wish I found it sooner.

:thanks:

DottorLeo

6th February 2011, 03:02

JanWillem32 i'm experimenting your shader with MPC-HC, they works correctly, compile and stacks fine but there is a problem: the output video is all cutted around, all zoomed in as this picture (from Harry Potter and The Chamber of Secret DVD) instead of showing the entire upscaled picture:

http://img9.imageshack.us/img9/6632/cutji.th.png (http://img9.imageshack.us/i/cutji.png/)

I've disabled the internal scaler as you suggested some post before ("Scaling shaders require the "View", "Video Frame", "Normal Size" setting. This disables resolution scaling by the renderer, the picture is then centered on the screen with either black borders or parts of the frame cut off. ").

My monitor is a 16:10 LG that support up to 1080p resolution (Lg flatron e2250v). I have to specify the resolution manually in your shader somewhere?

Also i suggest you to copy your instruction from post #42 (http://forum.doom9.org/showpost.php?p=1457640&postcount=42) to the first one for better visibility.

ikarad

6th February 2011, 18:56

Where can I download mpc with these new shader because on xvidvideo.ru there aren't these shaders?

DottorLeo

6th February 2011, 21:05

Where can I download mpc with these new shader because on xvidvideo.ru there aren't these shaders?

You have to build them manually. Follow the #42 link on my last post. It's quite easy.

JanWillem32

6th February 2011, 23:10

The scaling shaders should be placed in the "Combine Screen Space Shaders..." window when up-scaling. I'm investigating why that item is currently grayed out for VMR-9. It's one of the last things we have to solve before starting to integrate some shaders.

JanWillem32

15th February 2011, 04:54

I added the "Pixel Shader Scripts, test 20.7z" file in my development folder, see my signature for the download. I'll try to edit the OP to something better, soon.
This is mostly cleanup and style formatting of the code. I did edit two shaders.
"contour color expose banding"
This shader is useful to visually expose even the slightest banding, but also encoded blocking and ringing artifacts. You can use this for example to test debanding and denoising filters.
"hue, saturation, luma gamma and chroma gamma control for SD&HD video input"
This shader is a nice update, it's now a lot more useful to influence over-saturated video trough chroma gamma control. I believe this function is rather unique. I've never seen it on any other software or hardware.
I came up with this idea after mr.duck's comment.

toniash

15th February 2011, 09:25

I added the "Pixel Shader Scripts, test 20.7z" file in my development folder, see my signature for the download. "hue, saturation, luma gamma and chroma gamma control for SD&HD video input"
This shader is a nice update, it's now a lot more useful to influence over-saturated video trough chroma gamma control. I believe this function is rather unique. I've never seen it on any other software or hardware.
I came up with this idea after mr.duck's comment.
Thanks for your good work!
It's possible to implement some visual controls so we can change the values and see the effect in realtime?

JanWillem32

15th February 2011, 16:50

Sure, but it will take some time, as that would require making a new items in the "options" screen. It's not possible to merge these with the "Color controls for VMR-9 (windowed)".

mr.duck

18th February 2011, 21:25

"hue, saturation, luma gamma and chroma gamma control for SD&HD video input"
This shader is a nice update, it's now a lot more useful to influence over-saturated video trough chroma gamma control. I believe this function is rather unique. I've never seen it on any other software or hardware.
I came up with this idea after mr.duck's comment.

I basically contributed nothing but some how feel like I helped :D

I'm using it now. It looks nice. I'm not sure on all the technical details I just tweaked chroma gamma till it looked good. Around 1.08 for me after 3 mins tweaking. Colors look natural. Flesh tones are the give-away.

I have a TN monitor. I set it to sRGB mode and can only adjust brightness and contrast. That's why this shader is so useful otherwise the video looks a bit garish. Would you say that adjusting chroma gamma is the best way of fixing it? Also why do some shaders such as the standard 16-235 -> 0-255 have [SD] and another for [SD][HD]? Does it really make any difference?

JanWillem32

19th February 2011, 00:03

I mostly updated that shader because even on my calibrated CRT some sources can be really over-saturated. Because the normal "saturation" setting damages the dynamic range, I thought it might be a nice update to implement the same gamma controls for luma and chroma as with the RGB controls. The chroma gamma setting preserves minimum and maximum saturation nicely, but can bend the s-shaped curves in the range <-.5,.5>, to get a lower or higher average saturation.

A TN monitor can be calibrated, I've done that with a dozen or so monitors and TV's. I own a X-Rite i1Display 2 to do calibration, but it did cost me € 183.
TN monitors have a difficult s-shaped RGB luminance versus voltage curve like all LCD screens, so those always need extensive editing to the analog voltage settings in the panel driver. It's too bad that many screens don't even nearly match any proper calibation at all (even the expensive ones). I've even seen the "dynamic" (torch) mode enabled by default.
I wonder if sRGB mode is a good choice in your case. I've never heard about a TN monitor that can display the full range of the sRGB spectrum anyway. A picture of the sRGB range and links to other ranges is available at http://en.wikipedia.org/wiki/SRGB .
On my monitor sRGB settings never worked well at all. After unlocking the "factory preset" menu and messing with all the settings, I've made a good calibration with the "6500K" setting. It could very well be that your monitor's sRGB setting isn't very accurate either. Apart from technical limitations, many screens (even cheap ones) can be calibrated a bit after unlocking service menus. There a quite a few guides on how to open it. Many service manuals for display devices can be found by a basic search. The service manual I use was hosted on quite a few websites. Maybe you can try that, too.

The 16-235 -> 0-255 SD shader was to fix an ATi driver problem in 2007 with SD sources. It was mentioned in the first few pages of this thread, along with some other things I wanted to point out. That shader is useless now, so that's why I didn't include it in my shader pack.

mr.duck

19th February 2011, 01:31

The default modes for the monitor was really horrendously bad. I don't know how much % of the sRGB spectrum the sRGB mode covers, but I guess it's the best the monitor is capable of. To me, it looks not just acceptable but pretty decent (for a TN anyway).

Sometimes I have seen some one else calibrate their monitor and post the result online for others with the same monitor to use. That would be good enough for me but I doubt anyone has bothered for this monitor. It's a BenQ G2420HDBL.

JanWillem32

19th February 2011, 02:19

The software part calibration (.ICC/.ICM file) only works with one hardware setting, and should be replaced monthly, due to aging components. (Quite a job if you do calibrations on a projector.) Just a warning not to use a downloaded one.
Your monitor is featured in quite an extensive thread on: http://forums.overclockers.co.uk/showthread.php?t=18089775&page=23 . Some people posted settings that seem to work for them. I haven't found a guide to enter factory/service mode. It's usually a menu that pops up with holding a button or two, while switching on with the "hard" on/off switch. I used to have a complete service manual, but this site shows how it's done for my monitor and it works on a lot of other monitors, as well: http://www.network54.com/Forum/87612/thread/1126720987/last-1126733323/HELP+Desperately+seeking+access+to+service+menu+Compaq+P1220+%28Mitsubishi+2060u%29 . Don't forget to note down settings, so you can always reset it. I've never seen a reset function in the service menus.

toniash

24th February 2011, 18:00

Sure, but it will take some time, as that would require making a new items in the "options" screen. It's not possible to merge these with the "Color controls for VMR-9 (windowed)".
I thought about some more generic with a standarized comment in front of the #define for each control from where to extract the min, max and default value and also a description and build a GUI with this values.

bobdynlan

25th February 2011, 01:23

I thought about some more generic with a standarized comment in front of the #define for each control from where to extract the min, max and default value and also a description and build a GUI with this values. Exactly what I'm working on - a limited meta parser, used in a "Live Shaders" gui bar, for easy adjusting of parameters with sliders. Will post a demo when I finish it.

toniash

25th February 2011, 11:11

Exactly what I'm working on - a limited meta parser, used in a "Live Shaders" gui bar, for easy adjusting of parameters with sliders. Will post a demo when I finish it.

PERFECT! thanks

JanWillem32

3rd March 2011, 07:20

A minor update to "semi-random colored surface noise" and some typo corrections were needed, so I've released the "Pixel Shader Scripts, test 21" package in my folder. No new functions were added this time.

toniash

10th March 2011, 15:49

@JanWillem32

in "unsharp luma mask for SD&HD video"
// minimum limit to sharpen, 0 means disabled, low = 8/16384., medium = 12/16384., high = 16/16384.
#define Threshold 12/4096.
What is wrong, the comment or the define?
Thanks

JanWillem32

10th March 2011, 16:11

I resolved major errors in "Catmull-Rom spline6 height resizer", "Catmull-Rom spline6 width resizer", "sharpen complex v2 + deband + denoise" and "sharpen complex v3 + deband + denoise".
I edited the comment in "unsharp luma mask for SD&HD video". Thank you toniash. The precursor to this shader was very sensitive to its input, the comment was a left-over.
Only the "blur" shaders are new.
Blur uses the same sampling area as "sharpen complex v3 + deband + denoise". In other words, it has the same debanding capacity.
Blur minor uses the same sampling area as "sharpen complex v2 + deband + denoise".
For "!readme - how to properly chain shaders" I added an optimization trick, mostly for screenspace shaders.