madVR - high quality video renderer (GPU assisted)

[yesgrey]

Originally Posted by Mark_A_W

And yesgrey, someone is going to have to write a dummies guide to yCMS....I'm lost....

You only need to know two commands (the mandatory), and now with madVR's GUI you don't need to know any. How can we make it more simple? Unless you are referring to the more advanced commands...

Originally Posted by cyberlolo

By the way, when trying to use an external 3dlut file, madvr says: "this 3dlut file does not match the input format required by madVR"

This is the file used for generating the 3dlut with yCMS:

# Set input format
Input_Format HD YCbCr 8

madVR v0.62+ only works with 3DLUT files with yRGB input. It looks for the first line in the 3DLUT file to see if it's: Input_Format yRGB RGB_Video 8. If it isn't, it doesn't accept it.

Originally Posted by tschi

in colorHCFR I have XYZ and xyz values, I think XYZ in madVR is xyz in colorHCFR (my red x= 0.653 <-> X=26.219) Am I wrong ?

Yes. You should use XYZ. Alternatively, you could use Yxy (also available in HCFR).

If XYZ in madVR was the same as xyz in HCFR, it would be named xyz.

[pawlol83]

Hello Madshi
Could I ask you to familiarize yourself with a problem regarding the rendering mode madVR. Earlier I wrote about the issue in the thread about MPC-Home Cinema ...
As a reminder,
"Hello, I have a problem with video rendering mode MadVR. Despite the choice of rendering mode, I am still not Able to call its instance. This "error" probably occurred on the version of MPC-Home Cinema 3110 (x86). In another player I have no problem running the video rendering mode MadVR. I tried to restore the default settings by deleting the settings file, deleting the entry from the registry, but it did not give Satisfactory results. Using the built-in codecs solves the problem. If you use the ffdshow filter (set to download) I can not run rendering mode MadVR ....."

Currently madVR (from version 0.62 and later) rendering mode is initialized correctly, but the picture looks like the subtitles are in the middle of the screen. I'm using the latest version MadVR 0.64.

Ffdshow settings, screenshot attached to this post.

Please refer to the problem. Greetings

[madshi]

Originally Posted by leeperry

I guess these options will be remembered?

Nope. When a new video is loaded, default is always auto detection.

Originally Posted by leeperry

I guess my last problem is that I feed PC levels to mVR?! But I'll try some test patterns to ensure that everything's cool

It shouldn't be a catastrophe, but it won't be 100% accurate because both madVR and yCMS think you're delivering video levels. So de-gamma and en-gamma processing will not be 100% correct. Don't know how much of a problem this is, though.

[janos666]

1080i29 worked for me now, I managed to watch a full TV Show episode without loosing the sync (v0.64).
It wasn't always as smooth as it should but it could be any other problem (the TV, the flush and other presentation settings, the material itself, etc)

[leeperry]

Originally Posted by madshi

Nope. When a new video is loaded, default is always auto detection.

auto-detection of the source gamut? how's that? I'd mostly be playing 23.976fps@96Hz and 29.97@89.91Hz. I thought there were no automatic rules for the source gamut (yet)? I'd need the BT.709 decoding matrix at all times, as upscaled SD from ffdshow cannot be automatically detected (yet).

Originally Posted by madshi

It shouldn't be a catastrophe, but it won't be 100% accurate because both madVR and yCMS think you're delivering video levels. So de-gamma and en-gamma processing will not be 100% correct. Don't know how much of a problem this is, though.

OK, that sounds scary....I might have to wait a bit for you to allow PC levels input

FWIW, FRAPS videos are PC levels, and someone else said that he needed PC levels in this very thread.

[madshi]

Originally Posted by leeperry

auto-detection of the source gamut? how's that? I'd mostly be playing 23.976fps@96Hz and 29.97@89.91Hz. I thought there were no automatic rules for the source gamut (yet)?

There is some auto detection, but it's really simple:

If the source width > 1024 or if the source height > 576 then I'm using BT.709 primaries. If the source height is exactly 576 I'm using EBU primaries. Otherwise I'm using SMPTE-C primaries.

[leeperry]

Originally Posted by madshi

There is some auto detection, but it's really simple:

If the source width > 1024 or if the source height > 576 then I'm using BT.709 primaries. If the source height is exactly 576 I'm using EBU primaries. Otherwise I'm using SMPTE-C primaries.

meaning that upscaled SD ends up in HDTV gamut? that can't be good

hopefully at some point you'll be adding:
-user manageable rules, as previously discussed
-allow PC levels input
-compressed LUT support, so it'll load faster and not waste 100MB of space(which does matter when you host it on a ramdisk, and avoids HDD fragmentation)
-detect upscaled SD from ffdshow

but it's all about baby steps, and it's really great to see that mVR is moving towards the right direction

You could also allow the end-user to change the name of the gamuts, so he can call them anything he likes: PAL/EBU or REC.709/sRGB/BT.709/HDTV or SMPTE-C/NTSC, so everyone will be happy in the end

[SamuriHL]

Originally Posted by madshi

madVR v0.65 released

http://madshi.net/madVR.zip

* fixed: decode matrix + source primaries detection only worked once
* fixed: yet another bug in the automatic display changer

I hope that the display mode changer will now finally work. It seems that GPUs require modes to be named 1080i29 instead of 1080i59. I have removed matching support for 1080i59 now. Hopefully that won't break anything.

Ok, probably last version for a couple of days.

You're killing me, man! Thanks.

[Andy o]

Originally Posted by madshi

madVR v0.65 released

http://madshi.net/madVR.zip

* fixed: decode matrix + source primaries detection only worked once
* fixed: yet another bug in the automatic display changer

I hope that the display mode changer will now finally work. It seems that GPUs require modes to be named 1080i29 instead of 1080i59. I have removed matching support for 1080i59 now. Hopefully that won't break anything.

Ok, probably last version for a couple of days.

Working! Thanks.

[tschi]

Originally Posted by yesgrey

If XYZ in madVR was the same as xyz in HCFR, it would be named xyz.

XYZ values seems to not be accepted by madVR GUI but xyz are accepted (with XYZ as prefix) that's why I was a bit confused. I will make other test tomorrow...

[fairchild]

Originally Posted by tschi

XYZ values seems to not be accepted by madVR GUI but xyz are accepted (with XYZ as prefix) that's why I was a bit confused. I will make other test tomorrow...

The new madVR GUI accepts xyY/Yxy and XYZ, at least those are the 2 sets of values that I entered and it automatically converted fine.

[e-t172]

Originally Posted by leeperry

meaning that upscaled SD ends up in HDTV gamut? that can't be good

Why are you feeding upscaled SD to madVR? Why don't you let madVR do the upscaling, which it does very well?

[leeperry]

Originally Posted by e-t172

Why are you feeding upscaled SD to madVR? Why don't you let madVR do the upscaling, which it does very well?

upscaled SD looks a lot nicer through some Avisynth scripts...LSF comes to mind, and LSF looks much better when using SuperSampling..and mVR uses the GPU to resize, so it can do the final downscale part for free.

[pankov]

madshi,
you are always able to amaze me with your work.

I really like the direction that madVR is taking and I hope you'll be able to polish everything soon.
I've ran a few tests on the new version (0.65) and noticed two problems (probably related):
The first one is that when I try to exit exclusive mode for the second time (the first is OK) I get a full black screen while the playback continues in the back and I can close the player with Alt+F4. Here is a log showing the problem
http://www.mediafire.com/?4ezl4eh77zh36qs
The second problem is that sometimes (pretty often - ~1/5 attempts) Zoomplayer hangs on starting a file in fullscreen mode when I use madVR. Other renderers are OK and also when I start the playback in windowed mode and then go to fullscreen everything is OK also. I suspect that there is something wrong with the initialization of the D3D surface but I guess you'll know better if you look at this log
http://www.mediafire.com/?rqraf2ga7m8c0wa

I also have a "calibration" question - is there somewhere a guide/post/FAQ where I can find a simple explanation how to take the needed values from colorHCFR so madVR can build a 3dlut file for me? I've used a i1d2 probe and measured my display. I've also done some basic calibration using the display's settings but I'd like madVR/yCMS to make it even better so I'll be glad if someone is able to help me. Also is it better to use the display's setting to do some basic correction and then let madVR/yCMS improve them or it's recommended to reset all display settings and let madVR/yCMS do all the work?

[Snowknight26]

http://pastebin.com/ZmwEffHi

madVR flips the output both horizontally and vertically. To generate it yourself, have avisynth output an error.

[madshi]

Originally Posted by leeperry

-compressed LUT support, so it'll load faster and not waste 100MB of space(which does matter when you host it on a ramdisk and avoid HDD fragmentation)

FWIW, you can check whether using a 7bit 3dlut results in any visible degradation. If not, you can use 7bit, that will reduce the 3dlut size and loading times by a factor of 8x.

Originally Posted by Snowknight26

madVR flips the output both horizontally and vertically. To generate it yourself, have avisynth output an error.

Yes, I've seen this, too. And I know the solution for that. However, the solution will break compatability with AVI/QuickTime files with uncompressed video in them. So I'll have to find a solution which works for everything. It's on my to do list.

[Mark_A_W]

Originally Posted by yesgrey

You only need to know two commands (the mandatory), and now with madVR's GUI you don't need to know any. How can we make it more simple? Unless you are referring to the more advanced commands...

My confusion comes from the interaction of (as I understand):

1. Gamut - the triangle mapped out by the colour coordinates of the display, versus the desired colour standard. Gamut mapping fixes this, using the 3D lut.

2. Gamma - The beautiful desired gamma curve (say 2.2) versus the complete mess that is my projector, even after an "ISF" style calibration, which is just playing with the fairly crude colour controls on the projector (bias and gain per colour).

3. The PC Gamma control, which works in a different way to the "2.2" description above - it's not a curve, it's a straight line and you tweak it, and up is a lower gamma, and down is higher....and am I supposed to put this back to zero before calibration?



I was lost as to how to combine them all.

So, this is my workflow, as I understand:

1. Set PC gamma back to "flat".

2. Calibrate projector as best as I can with the internal controls, using colorimeter (I use HCFR software as the source and HCFR sensor).

3. The final calibration result is the input to yCMS/madVR. Generated by measuring the primary colours.

4. Input the values into madVR. Make sure the formats match.

5. Set my desired gamma in madVR (if it's not 2.2).

6. Whisky.

yCMS and madVR will then convert the video gamut to the projector gamut - pulling in the colours if they overrun, and remapping as necessary. AND equalise the response (gamma) to match the target.


Is that it?

Thanks

Mark

[fairchild]

Mark_A_W your workflow has gotten me a bit confused.

For your step 3. I've always used the primary gamut values from my calibration once it's all set correctly. Now the measurement is taken using the output of my blu-ray player which is what I use to calibrate my display.

So the primaries values should be those (from the calibrated values which were measured with my meter from my blu-ray player's output), or should I be measuring again and taking down values from MadVR's output from my video card?

[Mark_A_W]

Originally Posted by alph@

leepery,you must be the only which use a crt display

Originally Posted by fairchild

Mark_A_W your workflow has gotten me a bit confused.

For your step 3. I've always used the primary gamut values from my calibration once it's all set correctly. Now the measurement is taken using the output of my blu-ray player which is what I use to calibrate my display.

So the primaries values should be those (from the calibrated values which were measured with my meter from my blu-ray player's output), or should I be measuring again and taking down values from MadVR's output from my video card?

I've edited it, I hope for clarity.

Yes, the final values from the calibration become the inputs to yCMS.

And I would use the PC as a source, as that's what you are watching, but it probably won't matter.

[yesgrey]

Originally Posted by Mark_A_W

So, this is my workflow, as I understand:

1. Set PC gamma back to "flat".

2. Calibrate projector as best as I can with the internal controls, using colorimeter (I use HCFR software as the source and HCFR sensor).

3. The final calibration result is the input to yCMS/madVR. Generated by measuring the primary colours.

4. Input the values into madVR. Make sure the formats match.

5. Set my desired gamma in madVR (if it's not 2.2).

6. Whisky.

Nice guide.
I will only add to 3 the grayscale measurements. Without it, both the gamut correction and your desired gamma will be less accurate.

Another thing is step 2. I'm not sure if it's a good idea to do it or not. If display's internal controls have a very good precision, then it might be good to use them, but in some cases might be preferable to only set the brightness and contrast and let all the rest to yCMS.