madVR - high quality video renderer (GPU assisted)

[Matching_Mole]

That's weird. I know my filter is supposed to have bugs, but not this kind of bug. In theory it should always stay very close to the original frame timestamps; it cannot "deviate" from them. That may be caused by the heavy buffering the filter does though (which causes the playback to freeze briefly when you seek so it can buffer frames).



Because I wrote this code 2 years ago and didn't finish it; in fact, I wouldn't even have released it if nevcairel hadn't brought up the subject of IVTC. So it's only a proof of concept and it's supposed to be full of bugs. The filter is designed to be better than everything else (there would not be much point otherwise), but I expected it to be too "annoying" for real, day to day viewing.

The reason why it's not integrated into ffdshow is that there's no maintainer for it. I don't have time to maintain it myself now, as I have other projects which take priority. I may be able to get back into it some day, but that won't be before at least several months. I'm hoping someone implements a real, well-maintained filter inspired from my work so it can be made into something "releasable".

I must admit, I'm really surprised to see that you're using this code without experiencing severe problems.

In order to avoid off topic discussion here, I think you should create a separate topic because your filter is great but as you said it still in development. For example, I found that it works greatly on NTSC DVD but not on telecined H264 blu-ray.

Currently I think that your IVTC filter is great and far better for live situation than Avisynth filters. I can understand that its development is not your priority but at least the Doom9 community can help you to know what are exactly the situation of your filter and what amount of work is needed. A dedicated topic will be the better place to share this kind of information.

[wayland]

is biWidth: 2048 the resolution madvr is scaling to? if so why isnt it scaling to the native resolution of my monitor (2560) if i press cntr+j the target rectangle says its 2560 with the high depending on the aspect ratio of the movie

[madshi]

A test pattern for measuring the primaries would not need any correction. Ideally the primaries would be measured using pure RGB images, and not the ones from YCbCr test patterns converted to RGB, like the ones we find on Blu-ray or DVDs, because the latter, when converted to RGB, might not result in exact RGB values.
Ok, makes sense. I'll put RGB test patterns on my to do list for a (far away) future version. Let's talk about that later...

I will soon be outputting RGB32 to madVR(that's mandatory when using ddcc for gamut mapping), will that be as bad as it sounds? I currently use LSF in SuperSampling mode so it goes like: major uspcale(Spline for luma/Bicubic 0.0 for chroma) > Avisynth scripts(using ColorMatrix for upscaled SD to map the 601 coeffs to 709) > YV12 to madVR > downscale using the GPU(LSF looks jaggy in 1:1, so it's better to use SuperSampling). So I guess all that resizing and 8bit processing more or less kills the whole point of outputting YV12 to mVR in the first place? And going RGB32 will allow me to ditch ColorMatrix and output proper 601 RGB for upscaled SD...that cannot hurt.

I remember you saying that RGB32 didn't remain untouched in mVR, so I guess I'll still benefit a bit from whatever it is that mVR does better than the other VR's :p
leeperry, just remember when designing your scripts that the current version of madVR requires TV levels (16-235/16-240) as input for both Y'CbCr and RGB.
In other words, don't use SmoothL to expand levels from TV to PC with madVR 0.62+, until madshi adds support for 0-255 input.
only when using the LUT's from what I understood?!

I do feed 0-255, whatever as YV12..or as RGB32 tomorrow when I'll be testing the new CUDA version of ddcc() (https://forum.doom9.org/showpost.php?p=1508124&postcount=675) . I've disabled all gamut/gamma tweaks and the TV>PC conversion in mVR.

I don't have crushed blacks or burned whites, but OK I'll run some test patterns. It doesn't seem to mess w/ the BTB/WTW as far as I can tell :confused:
@leeperry

That is strange. HR RGBHQ vs 0.65 RGBHQ are identical (dithering aside). 0.49 YV12 vs 0.62 YV12 vs 0.65 YV12 are identical (dithering aside). 0.62/0.65 RGBHQ vs 0.62/0.65 YV12 has a large difference.

Did the shaders in 0.49 also assume 16-235 input? leeperry, when you wake up, can you do another test in 0.49 with the following "HD - PC.3dlut" and output set to PC levels in madVR to see if that changes things?
Input_Format HD YCbCr 8
Input_Range 0 255
Output_Format HD RGB_PC 16

madshi, could you take another go at explaining how 0-255 input is handled in madVR compared to 16-235 input? From leeperry's results, it does appear 0-255 RGB is handled correctly, but 0-255 YV12 isn't? How is it working with 0-255 RGB, if you aren't supporting it? Does this mean 16-235 RGB is left untouched, even when set to output 0-255?
Hmmmm... Let's see. madVR does not ever cut BTB/WTW, so if you feed madVR with PC levels and switch madVR to PC levels output, then TV levels would pass through undamaged, as long as madVR doesn't need to do any processing which would be sensitive to the source levels. Let's say you tell madVR to apply gamma or gamut processing. In that case it does matter whether you feed madVR with video or PC levels, because if you feed madVR with PC levels and madVR thinks it's TV levels, then the gamma/gamut processing (and also 3dlut processing) will be inaccurate. If madVR doesn't have to do any of these processing steps, feeding madVR PC levels does not harm, I guess, for now at least.

I do plan to add proper support for PC input levels soon.

It works fine. MadVR 6.5 will pause when I press Win+L, but after I login to Windows and continue to play, it become seriously dropping. This phenomenon also can be found in earlier version, not only 6.5.
I can't reproduce this problem here. Can you try to use an NVidia/ATI tweaker to force your GPU clocks to a fixed value? Maybe that will take care of the problem?

Still not sure why ffdshow outputs 1024x420 nor why MadVR chooes to connect to it when other options are closer to the the actual media.
madVR does not choose the connection. ffdshow asks madVR "would this media type be ok with you?" and madVR can either say "yes" or "no". madVR is ok with many different media types, so it's ffdshow's responsibility to connect first with the best matching media type.

I'm also confused why MadVR shows the movie resolution as 704, 480 yet the PIN info says 1024x480.
Don't worry about the 1024, it's just that some decoders work better when transporting a 2^x width. Transporting pixels with a 704 width can make trouble. So the transport from ffdshow to madVR is done with the next higher 2^x width. The image isn't scaled, though. The 1024 - 740 superfluous pixels are simply unused filler pixels. VMR and EVR work the same way.

For the frame rate problem, i assume that ffdshow creates a 25fps media type at the beginning, and offers that to madVR, but afterwards ffdshow probably updates the media types to 29.97 because it figured out the real frame rate, but then its too late for madVR.
That's a good guess, quite possible/probable.

So I suspect it's madVR saying "hey I've got a 16:9 screen to render to could you supply me such a feed"
No. The decoder that feeds madVR with data is the one who has the active role in communication. madVR mostly just says "yes" or "no". There are a couple of exceptions to this, but let's not make it too complicated here.

Thanks for explaining, now i understand. Afaik all movies are shot at 24 frames per second, that's why i'm speeding up 23.976 movies to 24 with ReClock. I know that 1080p23 works as expected and probably i have to use it from now on.
I'm not sure what people prefer. Maybe using 1080p24 for 1080p23 content would be better than 1080p59? I'll ask the madVR users in the next "feedback" post. See post below...

Ok, I try to explain it in more detail: My LCD TV supports for example 1080i50, 1080i60(and 59), 720p50, 720p60 (but no 24Hz modes).
But in ATI's CCC I must set 1080i@25Hz to select 1080i50, 1080i@30Hz for real 60Hz interlaced etc.
So do I have to write 1080i50 or 1080i25 in the display changer line?

My projector supports all usual modes, 1080p23.976, 1080p24, all progressive and interlaced modes up to 1080i/p@60, but here the modes are clearly named: 1080p@24 or 1080p@50. So I guess for the projector I have to specify for example: 1080p23.976?
Tell madVR the numbers that Windows uses. So for your LCD TV use "1080i25, 1080i30, 720p50, 720p60" and for your projector use "1080p23, 1080p24, 1080p50, 1080p59, 1080p60". madVR will then automatically pick the best matching mode for either display from these lists.

Is it feasible to implement advanced image scaling techniques from super-resolution frameworks (like this one (http://www.cs.huji.ac.il/~raananf/projects/lss_upscale/index.html)) on madVR as real-time resize filters?
To be honest, I don't like this specific algorithm very much. E.g. look at the unnatural looking artifacts in this image:

http://www.cs.huji.ac.il/~raananf/projects/lss_upscale/sup_images/images/koala/our.png

I think madshi said (way before) that he is willing to add advance algorithm. It's just that someone has to give him the code i.e. he do not want to write the implementation himself.
I don't need someone else to do the coding. But my math is not good enough to create a working solution from just a science paper with a few math formulas and images in it. I need some kind of demo code, doesn't matter which code language (MathLab, C++, Delphi, Java, whatever). Furthermore, the algorithm needs to produce good results and be fast enough for real time usage.

I may be seeing something not related to madvr because switching to VMR9 or EVR still results in the same problem.
In that case it's not a madVR related problem.

What are the relative merits / drawbacks of Exclusive Mode VS Full Screen Windowed Mode in madVR?
merits: better performance, no tearing
drawbacks: lack of media player GUI support

When I have an MPC-HC window open when I sent the computer to hibernation after restarting MPC takes up a full core. The whole system gets very slow and unresponsive until I close MPC. This only happens when I use Mad-VR as renderer.
I'm not using hibernation here, don't even know if my PC can do it (afraid to try). Can you provide a madVR log? Please try to keep is small. Meaning: Start video playback, let it play just 5 seconds. Then hibernate. Then wakeup. Wait maybe 20 seconds. Kill MPC-HC. Zip and upload the log. Thanks.

I have a little problem with madVR (LACUVID / ffdshow). In H.264 (and I think also in MPEG-2) streams the primaries/transferfunction and colormatrix can be set. Unfortunately this information is ignored. My DSLR (EOS 550d / Rebel X2i) for example uses bt709 primaries, bt709 transfer function and bt601 matrix, no matter if recording in SD or HD. So any auto-guessing by resolution is wrong.
Isn´t it possible that ffdshow/LAVCUVID passes this data to madVR if available and only if not available auto-guessing is used?
I'm aware of this problem and I will fix it soon, one way or another.

Then I displayed the screenshot on my projector, CCC set to RGB 4:4:4 -> some parts are green some parts gray. Moving the picture some pixels to the right or to the left, the gray parts don't move, it seems to be as if they stay at their original location, so now are others parts in gray. (I hope one can understand what I mean).
I'd guess it's a projector issue, but I'm not sure. Could also be a GPU problem.

There is a problem with exclusive fullscreen mode and Zoom feature in Zoom Player. When I try to zoom picture (Num+/Num-) in exclusive fullscreen mode ZP crashes with error in madVR.ax
Problem signature:
Problem Event Name: APPCRASH
Application Name: zplayer.exe
Application Version: 8.0.0.0
Application Timestamp: 2a425e19
Fault Module Name: madVR.ax
Fault Module Version: 0.65.0.0
Fault Module Timestamp: 4dee9614
Exception Code: c0000005
Exception Offset: 00005dfb
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1049
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
If I use zoom feature in windowed fullscreen mode then madVR fails to enter exclusive mode with scaled picture. Is it a known bug/limitation of madVR or ZP?
I'm not sure. Have you asked Blight about it? If he says it's my problem then I'll look into it. Since this problem doesn't seem to occur with other media players, though, it might be a ZoomPlayer issue? Not sure...

madshi, how about special filter for FOTR green tint?
Hmmmm... I was planning to add color controls sooner or later. But I'm not sure what kind of controls would be needed exactly for FOTR. But also see the feedback post below where I'll ask a related question...

Mine is the other way around. Looks OK in Windowed Mode, Switches to Exclusive seems OK then it seems to present the Video Frames in the wrong order (and droped frames goes nuts). It may seem to settle down then off it would go again. Neither a pause/play or a seek will fix it. Only a STOP/Play. It is defiantly related to the refresh rate change that has just happened and I did not ever see this with the ATI card, so it is a combo of madVR, Refreshrate change, nvidia / LAV CUVID.
Weird. Are you using any of the tweaks in the "exclusive mode settings" tab (like e.g. "run presentation in a separate thread")?

I get a few "exclusive mode failed" msg with madVR in MC16. Once it occurs the only fix is to close and restart MC16. Any ideas of what causes this and how to avoid it?
No idea. Anybody else having similar issues?

It was a recorded TV show, which has since been deleted (I use my PC as my DVR). However, it is a weekly show, so I'll keep an eye on future episodes to see if results are the same.

EDIT: The same episode is being rerun this weekend. I'll record it again and get a sample from one of the more obvious trouble spots (there was one particular scene change where other decoders would consistently drop/repeat a frame).
That'd be nice. Difficult to handle samples are always very useful. Thx.

Would it be possible to add additional matrices? Currently only BT.601 and BT.709 is supported. Please add the other matrices supported by H.264 too:
GBR:
R = Cr
G = Y
B = Cb

United States Federal Communications Commission Title 47 Code of Federal Regulations (2003) 73.682 (a) (20):
Kr = 0.3
Kb = 0.11

SMPTE240M:
Kr = 0.212
Kb = 0.087

YCgCo:
Cb -= 128
Cr -= 128
R = Y - Cb + Cr
G = Y + Cb
B = Y - Cb - Cr
For YCgCo see also: http://de.wikipedia.org/wiki/YCgCo-Farbmodell (no english version)
Maybe it could be possible to select the matrices you want to have in the Ctrl+Alt+Shift+M list in a settings dialog.
I will add support for this in a future version. I plan to automatically read out the matrix from the video bitstream, so you don't have to manually switch. Of course this will work only if the bitstream actually contains this information.

It has a TN panel which (according to some reviews) accepts 8 bit color depth but can only display 6 bit. It uses dithering to get back to a (emulated) 8 bit output. Should I set it to 6 bit or 8 bit in madVR?
Can't say that from here. Try the "colors.ytp" test pattern (see madTestPatternSource folder). With this test pattern you should see no horizontal, vertical or diagonal movement in the picture at all. If you do, your dithering strength is too low. In that case switch from 8bit to 7bit (or even 6bit). If you don't see any movement with dithering set to 8bit then probably using 8bit is just fine. Don't use 7bit/6bit unless you have to.

I have downloaded (and installed) a ICC profile which some other user has created (I don't have a meter to calibrate myself). As far as I understand all that, this ICC profile makes a best possible match to the sRGB color space. How should I configure madVR in the "calibration" and "color & gamma" pages based on that?
I'd suggest to ask about this in the yCMS thread. I think there was another user asking a similar question there recently, too.

is biWidth: 2048 the resolution madvr is scaling to? if so why isnt it scaling to the native resolution of my monitor (2560) if i press cntr+j the target rectangle says its 2560 with the high depending on the aspect ratio of the movie
This is just the transport format. The movie is not scaled to 2048. Those 2048 - 1920 = 128 pixels are just empty filler pixels to bring the transport width to a 2^x number. Don't worry about it.

[madshi]

Request for Feedback:

(1) When playing back a 1080p23 movie, which mode of the following two is preferable? 1080p24 or 1080p59?

(2) I'd like to implement a brightness control. I've looked up how to do that, but it seems there are different algorithms out there. E.g. there's one brightness algorithm which simply moves the histogramm to the left/right. A different brightness algorithm leaves the left side of the histogramm untouched, but stretches the right side of the histogramm to the left/right. Which way do you think is better?

(3) I'd like to implement a contrast control. I've seen two different algorithms here, too: One multiplies only the luma channel with a factor, but not the chroma channels. The other algorithm multiples the luma *and* chroma channels with the same factor. Which is the right way to do it?

(4) I'd like to implement some kind of color control. This could be used as a "poor man's calibration". Or it could be used to fix bad color gradings of some movies. Any suggestions on specific algorithms for this?

[leeperry]

Hmmmm... Let's see. madVR does not ever cut BTB/WTW, so if you feed madVR with PC levels and switch madVR to PC levels output, then TV levels would pass through undamaged, as long as madVR doesn't need to do any processing which would be sensitive to the source levels. Let's say you tell madVR to apply gamma or gamut processing. In that case it does matter whether you feed madVR with video or PC levels, because if you feed madVR with PC levels and madVR thinks it's TV levels, then the gamma/gamut processing (and also 3dlut processing) will be inaccurate. If madVR doesn't have to do any of these processing steps, feeding madVR PC levels does not harm, I guess, for now at least.
0-255 RGB32 from Avisynth(using REC.709 coeffs w/o TV>PC conversion): http://thumbnails51.imagebam.com/13814/0c0fc1138132086.jpg (http://www.imagebam.com/image/0c0fc1138132086)

0-255 RGB32HQ from ffdshow(using REC.709 coeffs w/o TV>PC conversion): http://thumbnails35.imagebam.com/13814/ed6f68138132581.jpg (http://www.imagebam.com/image/ed6f68138132581)

0-255 YV12 w/o TV>PC conversion in mVR: http://thumbnails41.imagebam.com/13814/21403d138132093.jpg (http://www.imagebam.com/image/21403d138132093)

and now 0-255 YV12 w/ TV>PC conversion in mVR: http://thumbnails21.imagebam.com/13814/e62e1c138132089.jpg (http://www.imagebam.com/image/e62e1c138132089)

Feeding YV12 or RGB32 gives different colors. Only RGB32 gives the same ones as HR. It's possible that I goofed up in my ffdshow settings, but I don't think that's the case :o

[madshi]

@leeperry, please check with Ctrl+Shift+Alt+M/P whether madVR uses the correct matrix and source primaries. Also make sure you set your display to BT.709 in the madVR calibration tab (= default setting). And make sure you have gamma processing disabled (= default setting). Do you still get different results with YV12 and RGB32? What is HR? Do you mean Haali Renderer? I thought the Haali Renderer is known to have incorrect colors?

P.S: You're feeding madVR with *PC levels* YV12? I think the BT.709 decoding matrix will output wrong results if it's fed with PC levels, while it expects to be fed with video levels? Not sure, would have to check the math. Have a bit of headaches atm, so I'll leave that up to someone else.

P.P.S: madVR has *always* expected video levels input. PC levels input was never properly supported (yet).

[cremor]

Can't say that from here. Try the "colors.ytp" test pattern (see madTestPatternSource folder). With this test pattern you should see no horizontal, vertical or diagonal movement in the picture at all. If you do, your dithering strength is too low. In that case switch from 8bit to 7bit (or even 6bit). If you don't see any movement with dithering set to 8bit then probably using 8bit is just fine. Don't use 7bit/6bit unless you have to.
I can see some slight diagonal movement with 8 bit. If I switch to 7 bit, the movement is gone but the picture is quite unstable. Hard to describe, but I think this must be coming from the dithering madVR is applying then? Whatever it is, it's more noticeable (and distracting) than whatever the display is doing to achieve its emulated 8 bit output.

I'd suggest to ask about this in the yCMS thread. I think there was another user asking a similar question there recently, too.
Ok thanks, will do/search for that.

(1) When playing back a 1080p23 movie, which mode of the following two is preferable? 1080p24 or 1080p59?
I prefer 1080p24. Like already said, the movie was shot in 24p originally so speeding it back up to 24p with Reclock should be the best possible option.

About your other feedback questions: No idea what you are talking about ;)

[leeperry]

@leeperry, please check with Ctrl+Shift+Alt+M/P whether madVR uses the correct matrix and source primaries. Also make sure you set your display to BT.709 in the madVR calibration tab (= default setting). And make sure you have gamma processing disabled (= default setting). Do you still get different results with YV12 and RGB32? What is HR? Do you mean Haali Renderer? I thought the Haali Renderer is known to have incorrect colors?

P.S: You're feeding madVR with *PC levels* YV12? I think the BT.709 decoding matrix will output wrong results if it's fed with PC levels, while it expects to be fed with video levels? Not sure, would have to check the math. Have a bit of headaches atm, so I'll leave that up to someone else.

P.P.S: madVR has *always* expected video levels input. PC levels input was never properly supported (yet).

I've chosen "don't calibrate this display" in mVR, gamma correction is also disabled. I've just double-checked and it's indeed using the 709 decoding matrix coeffs and it's set on REC-709 primaries(which shouldn't matter, as I've disabled all color calibration in mVR)...and I still get a darker picture as if the gamma was tempered w/.

The YCbCr>RGB32 decoding matrix coeffs and gamut mapping don't change depending on the levels you feed AFAIK.

[madshi]

I've chosen "don't calibrate this display" in mVR, gamma correction is also disabled. I've just double-checked and it's indeed using the 709 decoding matrix coeffs and it's set on REC-709 primaries(which shouldn't matter, as I've disabled all color calibration in mVR)...
Even if you say "don't calibrate this display" you still have to choose how your display is calibrated. Have you set that to BT.709? I mean the combobox with the title "The display itself is calibrated to the following primaries/gamut". If you set that to BT.601 then madVR will convert a BT.709 source to BT.601, even if you set "don't calibrate this display". The switch "don't calibrate this display" does not mean that madVR doesn't do any processing. It just means that you don't want to use a 3dlut to improve the calibration of your display. madVR still wants to know how your display is calibrated, so that it can convert the source's primaries, if necessary.

I still get a darker picture as if the gamma was tempered w/.

The YCbCr>RGB32 decoding matrix coeffs and gamut mapping don't change depending on the levels you feed AFAIK.
Not sure about that. I'm not fit to think about math at the moment.

[leeperry]

Even if you say "don't calibrate this display" you still have to choose how your display is calibrated.
I've set it like this: http://thumbnails43.imagebam.com/13816/8ee455138157012.jpg (http://www.imagebam.com/image/8ee455138157012) http://thumbnails57.imagebam.com/13816/7076f0138157014.jpg (http://www.imagebam.com/image/7076f0138157014)

Well, I'm forced to feed RGB32 if I wanna use ddcc() CUDA anyway, so that's no biggy. But supporting PC input via YV12 could come in handy to other users(eg. FRAPS videos for instance).

[pankov]

Request for Feedback:

(1) 1080p24
(2), (3) and (4) Sorry, but I lack the knowledge to recommend any algorithm. I hope other users will be able to help you select the best possibility.

[cyberbeing]

Request for Feedback:

(1) 1080p24 (On NVIDIA, a 24hz custom setting has a valid range of 23.000Hz to 25.000Hz. In most cases a 1920x1080@24hz setting is either 23.976Hz or 24.000Hz which is better than 59.94Hz for film content. Only exact multiple refresh rates like 48Hz, 72Hz, 96Hz, 120Hz should be preferred over 24hz for 1080p24 content IMHO.)

(2) Implement it similar to Photoshop's non-legacy brightness method. (http://img714.imageshack.us/img714/2531/psbrightness.png)

(3) Implement it similar to Photoshop's non-legacy contrast method. (http://img814.imageshack.us/img814/7389/pscontrast.png)

(4) Were you thinking along the lines of a white balance slider (color temperature), saturation sliders (gamut), photo filters (colored filters used for grading), or something more advanced like Color Balance in Photoshop/GIMP?

[Mark_A_W]

1.) 1080p24. With Reclock the subtle difference between 24.0000 and 23.976976976 becomes moot anyway - you can choose to run your monitor at either and only leeperry can pick the difference ;)

[madshi]

@Everyone: Ok, feedback question (1) was clearly answered, thanks.

(2) Implement it similar to Photoshop's non-legacy brightness method. (http://img714.imageshack.us/img714/2531/psbrightness.png)

(3) Implement it similar to Photoshop's non-legacy contrast method. (http://img814.imageshack.us/img814/7389/pscontrast.png)
Hmmmm... I'm not sure I can interpret those histogram pictures correctly. Do you happen to know which algorithm Photoshop is using?

(4) Were you thinking along the lines of a white balance slider (color temperature), saturation sliders (gamut), photo filters (colored filters used for grading), or something more advanced like Color Balance in Photoshop/GIMP?
I'm not really an expert on this. What controls would you find useful? I'll need a detailed algorithm description to implement whatever algorithm you suggest.

[TheElix]

Request for Feedback:

(1) When playing back a 1080p23 movie, which mode of the following two is preferable? 1080p24 or 1080p59?Pretty strange question for me. For a 1080p23 movie a 1080p23 mode is preferable, because my display is capable of 1080p23 (23,976) and 1080p24 (24,000) both.

[Andy o]

How about doing "brightness" as most displays do it, but label it correctly ("black level")? Which would mean move the left side of the histogram. I think "contrast" in most displays actually means "brightness" which moves the whole histogram. This in photoshop I think is called "exposure" (at least for RAW files).

[madshi]

@TheElix, the question was not whether to use 1080p23 or 1080p24. The question was whether to use 1080p24 or 1080p59 (in case 1080p23 is not available).

[madshi]

How about doing "brightness" as most displays do it, but label it correctly ("black level")? Which would mean move the left side of the histogram. I think "contrast" in most displays actually means "brightness" which moves the whole histogram. This in photoshop I think is called "exposure" (at least for RAW files).
Hmmmm... So "brightness" would only change the black level, but not the white level? Meaning if you decrease brightness a lot, whites are still just as white? I would find that weird, to be honest. I could expect that decreasing "brightness" should make whites less bright.

One thing to think about is this: Do we want to use brightness/contrast controls as a means to define which RGB level is used for "white" and which is used for "black"? If so, it might make more sense to add specific controls to define the exact white and black level. If we do that, is there even a need, anymore, to have brightness and contrast controls?

[Andy o]

I think most displays (and the AMD and possibly Nvidia drivers too) usually mislabel "brightness" and "contrast". With brightness, they mean black level, so when you move the slider, indeed the whitest whites don't move. When you move the "contrast" slider, it actually moves the whole proper brightness, which doesn't really affect proper contrast.

[Mark_A_W]

I think most displays (and the AMD and possibly Nvidia drivers too) usually mislabel "brightness" and "contrast". With brightness, they mean black level, so when you move the slider, indeed the whitest whites don't move. When you move the "contrast" slider, it actually moves the whole proper brightness, which doesn't really affect proper contrast.

All devices call black level "brightness". It's an historical error.

[pankov]

madshi,
I kind of agree with Andy O and Mark_A_W. Here are the definitions from the famous
GREYSCALE & COLOUR CALIBRATION FOR DUMMIES (http://www.curtpalme.com/forum/viewtopic.php?t=10457)
Brightness: The control used to adjust black level. Setting brightness too low will cause darker details to be lost into black (called 'black crush'). Setting brightness too high will cause the black to appear grey. Brightness affects all colours at the same time.
Contrast: The control used to adjust white level or peak light output. Setting contrast too low will result in a dim picture. Contrast set too high can cause lighter details to be lost into white (called 'white clipping') or blooming/smearing. Contrast affects all colours at the same time. Some manufacturers call it 'Picture'.

here is one more article that states the same
http://www.poynton.com/notes/brightness_and_contrast/

I remember I've seen somewhere a nice explanation of these two but I can't seem to find it now. It was explaining how some TVs had brightness and contrast affecting each other (increasing the contrast increased the white level but also moved down the black level) and this made the calibration very difficult and how it's better to have them independent - brightness changing the black level and contrast not expanding the whole picture but only changing the white - "expanding only from one side".

I apologize for using such simple words but I hope you'll be able to understand what I mean.

P.S.
I'll try to find this article ... or was it a video (don't remember right now) ... and post back

[jmone]

@TheElix, the question was not whether to use 1080p23 or 1080p24. The question was whether to use 1080p24 or 1080p59 (in case 1080p23 is not available).

+1 to use either 23 or 24hz as a default for either 23.976 or 24fps material (obviously combined with audio resampling by MC's VideoClock or Reclock etc). That said NTSC users already have a tollerance for 2:3 pulldown so they may be fine with 59hz for 23.976 material over dropped frames if they don't use resampling.

[madshi]

Ok, that Poynton article tells me what I needed to know about brightness/contrast, thanks.

So the only remaining question is that about color/hue/whatever controls.

[jmone]

Re: Exclusive Mode Failed:
There are a few reporting this issues over at the MC forum - http://yabb.jriver.com/interact/index.php?topic=64733.0
Also there may be an issue with the refresh rate changes throwing stuff off - http://yabb.jriver.com/interact/index.php?topic=64904.0

It may also be complicated by the use of MC's Video Clock code....

[cyberbeing]

The Brightness/Contrast adjustment lets you make simple adjustments to the tonal range of an image. Moving the brightness slider to the right increases tonal values and expands image highlights, to the left decreases values and expands shadows. The contrast slider expands or shrinks the overall range of tonal values in the image.

In normal mode, Brightness/Contrast applies proportionate (nonlinear) adjustments to image layer, as with Levels and Curves adjustments. When Use Legacy is selected, Brightness/Contrast simply shifts all pixel values higher or lower when adjusting brightness. Since this can cause clipping or loss of image detail in highlight or shadow areas, using Brightness/Contrast in Legacy mode is not recommended for photographic images (but can be useful for editing masks or scientific imagery).
Brightness algorithm leaves the left side of the histogram untouched, but stretches the right side of the histogram to the left/right. = Photoshop Normal Method (useful)

Brightness algorithm which simply moves the histogram to the left/right = Photoshop Legacy Method (useless)

Contrast/Brightness +0 (http://img231.imageshack.us/img231/838/noadj.png)

Brightness +50 (http://img694.imageshack.us/img694/7958/bplus50.png)
Legacy Brightness +50 (http://img191.imageshack.us/img191/9873/legacybplus50.png)
Brightness -50 (http://img8.imageshack.us/img8/3756/bminus50.png)
Legacy Brightness -50 (http://img88.imageshack.us/img88/5665/legacybminus50.png)

Contrast +50 (http://img268.imageshack.us/img268/305/cplus50.png)
Legacy Contrast +50 (http://img94.imageshack.us/img94/5541/legacycplus50.png)
Contrast -50 (http://img35.imageshack.us/img35/6654/cminus50.png)
Legacy Contrast -50 (http://img163.imageshack.us/img163/2691/legacycminus50.png)

Hopefully these linear gradient images make things more clear. I would highly recommend that you DO NOT implement Brightness/Contrast similar to Photoshop's legacy method which only shifts the histogram and introduces clipping. The legacy method is the traditional way to adjust brightness/contrast (as seen in the Poynton link) but it's extremely destructive to image quality. It was a godsend when Photoshop finally introduced the new method and made Brightness/Contrast safe to use on photographic content.

[xvidivx]

I can't reproduce this problem here. Can you try to use an NVidia/ATI tweaker to force your GPU clocks to a fixed value? Maybe that will take care of the problem?


Even if I force GPU clocks ,The values still increase after Win+L, but EVR-CP doesn't has this problem.


--
ATI 4670 / CCC 11.6
MPC 1.5.2.3255
madVR with restore default settings.bat

[HTPC-User]

Hello!

Request for Feedback:
(4) I'd like to implement some kind of color control. This could be used as a "poor man's calibration". Or it could be used to fix bad color gradings of some movies. Any suggestions on specific algorithms for this?

Perhaps it would be userfriendly to offer the typical functions of a modern TV set, for example tint etc. (I don't know the maths behind the scenes if you wanted to know that.)

And perhaps it would be useful to integrate also CMS controls in a (far, far away) next version: for example separate sliders for each primary and secondary color in combination with your idea of test patterns so the calibration could be in some way more interactive, i.e. calculating the correction for the primaries and secondaries in real time, so pushing the sliders influences directly the output of the test patterns. Given that one uses a second computer with a calibration software in continous measuring mode the calibration act would be quite interactive.
(The complete table could be calculated afterwards.)

If my feedback is crap, don't bother. :)


Hi!

Ok, now I did some tests to locate the problem, why some parts of madVR's OSD are grey and the other parts are green.

Hopefully someone can give me a clue if the problem are the ATI drivers or the projector.

At first I made a screenshot of madVR being in windowed mode. Then I examined the screenshot on my computer CRT display: everything is fine, the OSD is completly green.

Then I displayed the screenshot on my projector, CCC set to RGB 4:4:4 -> some parts are green some parts gray. Moving the picture some pixels to the right or to the left, the gray parts don't move, it seems to be as if they stay at their original location, so now are others parts in gray. (I hope one can understand what I mean).

For the next test I set CCC to YCbCr 4:4:4 -> The same behavior as before, no difference.

At last I tried YCbCr 4:2:2 -> Now the OSD seems to be almost complete in green, but the picture quality decreases as the text seems to be somehow unsharp, not so clear and rich as before.
I think this is the result of a conversion between RGB 4:4:4 (madVR output) and YCbCr 4:2:2 done by the ATI driver/hardware?

Obviously my suspicion is right, it is not a madVR related problem, the problem is caused by the ATI CCC or the projector.

So can anyone definitely and for 100% sure confirm that the ATI Catalyst Center 11.1 (which I use) is capable of outputting RGB 4:4:4 without glitches and bugs?

Due to a lack of proper equipment, i.e. more displays, I can't do more comparative tests by myself.

:thanks:

I can't believe that no one here uses full RGB 4:4:4 on a ATI card with a full HD display or LCD projector who can confirm wether madVR's OSD is completely green or not?? :eek:


I'd guess it's a projector issue, but I'm not sure. Could also be a GPU problem.


In the case it is really not possible to display 4:4:4 with my equipment, are there any special recommendations how to get the best possible picture quality? For example better use YCbCr 4:2:2 in CCC instead of RGB 4:4:4, which seems to be a logical consequence? Any other tips?

:thanks:

[madshi]

Brightness algorithm leaves the left side of the histogram untouched, but stretches the right side of the histogram to the left/right. = Photoshop Normal Method (useful)

Brightness algorithm which simply moves the histogram to the left/right = Photoshop Legacy Method (useless)

Hopefully these linear gradient images make things more clear. I would highly recommend that you DO NOT implement Brightness/Contrast similar to Photoshop's legacy method which only shifts the histogram and introduces clipping. The legacy method is the traditional way to adjust brightness/contrast (as seen in the Poynton link) but it's extremely destructive to image quality. It was a godsend when Photoshop finally introduced the new method and made Brightness/Contrast safe to use on photographic content.
Well, that's why I asked for the main purpose of the brightness/contrast controls. There are 2 ways to use these controls:

(1) You can use them with the purpose to calibrate your display. Every calibration guide tells you to use the brightness & contrast controls first to setup black and white levels properly. For this kind of needs the legacy Photoshop method is exactly what is needed and the new method wouldn't work at all, because the new method doesn't change black and white levels at all.

(2) Provided the display is already properly calibrated and black & white levels properly setup, the new Photoshop method would allow you to tweak the look of the image.

Two *very* different purposes. So again: What are users looking for when using a brightness & contrast control? Do they want to use it for (1) or (2)?

BTW, Photoshop's new method seems to be some kind of gamma tweaking. So if you enable gamma processing in madVR, you can probably achieve somewhat similar results to the Photoshop contrast tweak, I guess...

Even if I force GPU clocks ,The values still increase after Win+L, but EVR-CP doesn't has this problem.
That's too bad. Unfortunately I can't reproduce the problem here. Video playback works just fine here after Win+L. Without being able to reproduce it, there's not much I can do. Well, you could try to create a log (as short as possible, please!). Maybe that would help, but I'm not sure. A problem like this will probably be hard to find.

I can't believe that no one here uses full RGB 4:4:4 on a ATI card with a full HD display or LCD projector who can confirm wether madVR's OSD is completely green or not?? :eek:
Many of us do. Nobody has seen the problem you've reported.

In the case it is really not possible to display 4:4:4 with my equipment, are there any special recommendations how to get the best possible picture quality? For example better use YCbCr 4:2:2 in CCC instead of RGB 4:4:4, which seems to be a logical consequence? Any other tips?
The only tip from my side: Fix your hardware! If it's not possible, replace it.

[Skwelcha]

hmm i use ati 4:4:4 RGB with a Full HD LCD, can't remember seeing grey parts in the OSD, but I will check that again when i'm home today. But i use CCC 11.6, don't know if that makes a difference

[madshi]

madVR v0.66 released

http://madshi.net/madVR.zip

* rewritten large parts of the OSD logic
* added APIs for media player devs to draw their OSDs/GUIs in exclusive mode
* added API for media player devs to disable the madVR seekbar
* fixed: OSD is now above subtitles instead of under
* OSD + seekbar are now drawn to full window size, not to video rect, anymore
* madVR debug OSD is now white with a dark background
* using higher internal precision for internal calculations now
* fixed a couple of bugs in gamma / gamut / 3dlut processing
* instead of yRGB, madVR/yCMS are now using the measured display primaries
* improved compatability with uncompressed video files
* fixed: avisynth -> ffdshow -> RGB -> madVR produced upside down image
* fixed: seekbar showed up when playback monitor was positioned "under" primary
* simplified calibration settings a bit more
madVR benchmark:

http://madshi.net/madVR [benchmark].zip

[edison]

gts 450 275.33, qx6700 @ 2.93ghz , 1080p59.94 h.264 mkv, lav cuvid decoder, potplayer, madvr benchmark :
mode 1: 83.xx fps.
mode 2: 85.xx fps.
mode 3: 86.xx fps
mode 4: 123.xx fps
mode 5: 198.xx fps

[NoirNL]

GTX580 Driver: 275.33
i5-760 @ 3.8ghz
1080p24 mkv in mpc-hc using lav cuvid decoder

Mode 1: ~ 110 fps
Mode 2: ~ 117 fps
Mode 3: ~ 124 fps
Mode 4: ~ 242 fps
Mode 5: ~ 332 fps

[TheElix]

Thanks a lot, madshi, for a new version. Currently I'm testing your 0.65 vs. 0.66 to see how changes that you've made affected CMS. I'm comparing the results measued with i1 Display 2 colorimeter on my display. These set of numbers were taken with 100% Color Small in ColorHCFR APL test pattern. I'm measuring Red, Green, Blue primaries first without CMS, then with CMS in 0.65 version and lastly with CMS in 0.66 version. Here're my results as I measure them:

EVR CP (no CMS):
Red: x=0.638453, y=0.332729, Y=23.401230
Green: x=0.301765, y=0.601575, Y=70.685165
Blue: x=0.145604, y=0.067744, Y=8.468634
White: x=0.313689, y=0.328451, Y=96.700

So, this data represents how my current display is calibrated.

Let me write here target numbers by a standard HDTV - REC 709 (D65 white point):
Red: x=0.640, y=0.330, Y=20.307 (21% of 100% white Y value)
Green: x=0.300, y=0.600, Y=68.657 (71% of white Y value)
Blue: x=0.150, y=0.060, Y=7.736 (8% of white Y value)
White: x=0.31272661468101209, y=0.32902313032606195, Y=96.700

Now let's see the values measured with MadVR 0.65 (yCMS activated):
Red: x=0.614878, y=0.320393, Y=21.763636
Green: x=0.309221, y=0.594263, Y=68.825661
Blue: x=0.145777, y=0.068266, Y=7.559962

As we can see luminance (Y) was made closer to reference howerer color values (esp. Red) are way off, worse than without CMS.

Finally let's test MadVR 0.66 (yCMS activated):
Red: x=0.636788, y=0.330190, Y=22.304373 (21.96%)
Green: x=0.299994, y=0.596300, Y=69.570641 (68.48%)
Blue: x=0.145917, y=0.069311, Y=8.435363 (8.3%)
White: x=0.312921, y=0.329656, Y=101.590332

Yay! Reds are definitely improved! Luminance is OK (except maybe for green). Green could use some improvement? Irrelevant? Blues are somewhat the same, maybe limitations of my display.
Well, here's the data! The results aren't perfect but is it possible to achieve perfect by using CMS? I don't know.

Oh, yes. Some visual comparison: http://screenshotcomparison.com/comparison/62427

[leeperry]

:thanks: for the new version!

96SP 8800GS/XPSP3: 275.33
Q9450@3.5Ghz
1080p24 h264 untouched m2ts in PotPlayer using CoreAVC CUDA + 1360x_ downscale in ffdshow > Avisynth scripts > 0-255 RGB32

Mode 1: 25 fps
Mode 2: 25 fps
Mode 3: 26 fps
Mode 4: 112 fps (no more audio)
Mode 5: 187 fps (no more audio)

[xv]

What input/output format for 3dlut does madVR require now? Can someone give an example file?instead of yRGB, madVR/yCMS are now using the measured display primariesThat´s my output format for 3dlut, what´s the use of 3dlut if input/output is identical?

[fastplayer]

madVR consumes CPU cycles when video is paused (checked with Process Explorer). That didn't happen before with 0.65. It's not a whole lot, just less than 10% on a 2.4GHz K8 but still "weird". :)

Here's my setup:
MPC-HC rev3267, latest Haali Media Splitter, Radeon HD4670, CAT11.6 on Win7 (32-bit)

[yesgrey]

Well, here's the data! The results aren't perfect but is it possible to achieve perfect by using CMS? I don't know.
Are you using Grayscale_Measurements command? Without it is not likely for you to have perfect results...

Note: Please let's keep yCMS related discussions on yCMS thread. There are a lot of people that don't use yCMS, so let's keep this thread mainly for other madVR features.

[Andy o]

Well, that's why I asked for the main purpose of the brightness/contrast controls. There are 2 ways to use these controls:

(1) You can use them with the purpose to calibrate your display. Every calibration guide tells you to use the brightness & contrast controls first to setup black and white levels properly. For this kind of needs the legacy Photoshop method is exactly what is needed and the new method wouldn't work at all, because the new method doesn't change black and white levels at all.

(2) Provided the display is already properly calibrated and black & white levels properly setup, the new Photoshop method would allow you to tweak the look of the image.


The problem with (1) is that every calibration pattern/tool I've seen tells you to use brightness to calibrate black level. This "legacy" method of Photoshop which moves the rightmost part of the histogram is the opposite of everything anybody has ever done when calibrating their displays!

I think (not 100% sure) that (2) is what the "contrast" slider does in displays, or at least the ATI/AMD driver here.

I guess my point is that unless I've misunderstood you, I think you can have both (1) and (2). For (1) you could name it "black level" instead of "brightness" (and this will change overall contrast), and for (2) you can name it "picture level" or something like that, instead of "contrast", and that will move everything to compensate for relative brightness, but would not affect contrast ratio.

[madshi]

What input/output format for 3dlut does madVR require now? Can someone give an example file?That´s my output format for 3dlut, what´s the use of 3dlut if input/output is identical?
See yCMS thread.

What input/output format for 3dlut does madVR require now? Can someone give an example file?That´s my output format for 3dlut, what´s the use of 3dlut if input/output is identical?
Let's discuss that in the yCMS thread, please. Thx.

madVR consumes CPU cycles when video is paused (checked with Process Explorer). That didn't happen before with 0.65.
Will check that.

[fastplayer]

Will check that.
Thanks, madshi!
If you turn on OSD, you can see that the number of delayed frames is continuously rising even though playback is paused.

[TheElix]

Personally I like CMSed picture better. Unfortunately, periodically (approx. in 1 second periods) I get frames like this (even when I scroll with a framestep): http://rghost.ru/12613821/image.png

[madshi]

That is weird, TheElix. Does that only occur with yCMS activated? Have you tried different decoders?

[Plutotype]

madVR consumes CPU cycles when video is paused (checked with Process Explorer). That didn't happen before with 0.65. It's not a whole lot, just less than 10% on a 2.4GHz K8 but still "weird". :)

Here's my setup:
MPC-HC rev3267, latest Haali Media Splitter, Radeon HD4670, CAT11.6 on Win7 (32-bit)

On i7 980x, when 0.66 video is paused, I get 1-2% utilisation. However with 0.65 it is 0%. So confirmed here.

[noee]

Bench, fwiw:

Athlon II 620 @ 2.3Ghz, HD2600XT (stock), 23.976Hz
Video: 1080p23 @ 19.6 Mbps (BD), FFDshow Decoder

Mode 1: 27fps
Mode 2: 27fps
Mode 3: 27fps
Mode 4: 28fps
Mode 5: 48fps

[Xaurus]

madshi,

I couldn't find a guide for how to use the benchmark.

Does one exist, for us not-so-elite people? :)

[TheElix]

That is weird, TheElix. Does that only occur with yCMS activated? Have you tried different decoders?I'm sorry, it seems it was LAV splitter's fault.
Another problem which made me drop 0.65 and still exists in 0.66 is the freezing of a video in exclusive D3D mode. Switching to windowed mode unfreezes it but it's annoying.

[alph@]

madshi,

I couldn't find a guide for how to use the benchmark.

Does one exist, for us not-so-elite people? :)

yes, it is the demand that I wanted to

[madshi]

I couldn't find a guide for how to use the benchmark.

Does one exist, for us not-so-elite people? :)
It's pretty simple: You rename "madVR.ax" to something else, and then you download "madVR [benchmark].ax" and rename it to "madVR.ax". After that just play a video and benchmarking will start.

FWIW, I'm not really interested in benchmarking results at this point in time. I just made the benchmark available because it was requested.

Another problem which made me drop 0.65 and still exists in 0.66 is the freezing of a video in exclusive D3D mode. Switching to windowed mode unfreezes it but it's annoying.
I can't reproduce it here. Can I get a log? As small as possible, please.

[Xaurus]

Thanks madshi, simple enough! :thanks:

[TheElix]

I can't reproduce it here. Can I get a log? As small as possible, please.Gladly, but I don't know how to write a log with madVR.