[madshi]

Originally Posted by SamuriHL

madVR now actually slightly beats out PDVD for those scenes for me. So, again, well done. That's pretty amazing since you weren't intending to "fix" anything!

Yes. Furthermore: This is just with the standard resamplers. Image quality should further improve when I implement some better quality upsamplers. (Not too soon, though.)

Originally Posted by SamuriHL

I'm using J. River's MC16 these days and when I hit stop MC16 crashes

Oh, this does look like a madVR problem, not an MC problem. Is this 100% reproducible?

Originally Posted by DigitalLF

post processing with FFDSHOW that way couldn't have been good for PQ, right?

I don't know, not sure how you configured ffdshow exactly. And no, I don't want to know...

Originally Posted by 6233638

New major issue: I cannot seem to get 4:2:0 into madVR now. Upsampling is being applied before the video gets into it.

Actually, the only problem is that "Nearest Neighbor" is broken. If you select "Nearest Neighbor", madVR accidently uses "Bilinear". Other than that there's nothing wrong.

Originally Posted by 6233638

Lumagen boxes do. (or at least did, when I was beta-testing the Radiance)

They do color correction in linear light. But they do not *scale* in linear light, AFAIK.

Originally Posted by 6233638

8-bit showed no movement, but 7-bit helped mask the edges a bit.

In that case I'd recommend staying with 8bit.

Originally Posted by Budtz

I had a few bugs disappear since i upgraded to 0.62. They were not in the changelog thou. Am I correct in assuming that not every optimization and bugfix to existing feateres is in the changelog but only actual changes like new feateres and options?

Important bugfixes are listed in the changelog, too. There might be a couple small bugfixes which I don't list in the changelog. Also, some things might be fixed "accidentally". Anyway, if a problem is gone for you, there's really no reason to wonder why...

Originally Posted by Budtz

Also are there any optimizations I can make to the new display properties settings in madvr? I do not know the calibration or bitdepth of my tv thou I have looked throu any documentation I could find.

Just stick to the defaults if you don't know.

Originally Posted by pirlouy

But now, I can clearly say that I'm totally lost with all these options (no problem if it helps others). I'll stay with default settings.

Yes, staying with the default settings is a good idea if you don't understand the new options. Maybe I should introduce an "expert" mode and hide some of these settings there.

Originally Posted by janos666

Why don't you correct the bug on the other side?

Because a day has only 24 hours. And because adding 10bit output is not at the top of my priority list.

Originally Posted by cyberbeing

Properties
primaries/gamut - Since it's very rare for any display without a hardware lut to have a perfect gamut, what should this be set to? To maintain accuracy without a 3dlut should I pick the closest option or 'Something Else'? What does madVR do (not do?) when 'Something Else' is selected? Does this setting do anything when using a 3DLUT?

If you use a 3dlut, the primaries/gamut setting on the "Properties" page has no effect. As I mentioned before, I plan to make gray out this option in the next madVR version, if you activate a 3dlut.

If you do not use a 3dlut, you should set this option to the closest match. The value "Something Else" means that madVR disables gamut correction, if no 3dlut is used.

Originally Posted by cyberbeing

gamma/transfer - I calibrate my gamma to an ambient light scaled REC.709 curve with Argyll CMS, and as I've learned this doesn't match how yCMS or Janos666's MPC-HC-mod calculates it, so I doubt it matched madVR shaders either... To maintain accuracy without a 3dlut should I pick the closest option or 'Something Else'? What does madVR do (not do?) when 'Something Else' is selected? Does this setting do anything when using a 3DLUT?

Same as with "primaries/gamut". Setting this to "Something Else" means that madVR treats your display as having the default Pure power curve of 2.2, though. This has no meaning, though, unless you modify the "Color & Gamma" settings.

Originally Posted by cyberbeing

Calibration & Color & Gamma
Color & Gamma appears to be some sort of Output Gamma setting? So if you are doing gamma correction in a 3dlut with something like grayscale measurements & gamma_curve, or don't want any gamma correction at all, madVR is forcing you to change it? I don't want anything to touch the gamma I may or may not have specified in a 3dlut, so this is a major problem for me.

If you keep all options to the default values madVR will not touch the gamma at all. That's the default behaviour. If you enable yCMS calibration (or use an external 3dlut file), madVR will still not touch the gamma at all, if you keep using the default settings on the "properties" and "color & gamma" pages.

Originally Posted by cyberbeing

Bug: The Color & Gamma section should not be used by default when using a 3dlut. Gamma corrections should be done with the 3dlut (if needed) when one is used. Currently madVR uses shaders on-top for the 3dlut. An 'Native' gamma option is needed to disable madVR's gamma modifications when using a 3dlut.

Let's say you want to use a 2.35 gamma for night time watching and a 2.2 gamma if there's some ambient light. How can you do that? With older madVR versions you had to create and then switch between different 3dlut files for that to work. Now with madVR v0.62 you create only one 3dlut file and you can do gamma adjustments on the fly. And you can do this with the same (or even better) quality than before.

The one standard 3dlut file created by madVR v0.62 defaults to a "Gamma_Curve" of a 2.2 pure power curve, which is also the default setting in the "color & gamma" settings page. If you want to achieve a different gamma curve, you can realize that by changing the "color & gamma" settings. Having the "color & gamma" settings set to the default values means that madVR is not doing any gamma processing at all.

Or in other words: v0.62 uses the 3dlut only to correct display faults. It does not use the 3dlut, anymore, to achieve specific gamma curves / values. So basically the yCMS command "Gamma_Curve" is what you can configure now in the "color & gamut" madVR settings page. This is done via shader math now, though. The purpose of this change is higher usability, because you only need one 3dlut, anymore, and you can switch "Gamma_Curve" on the fly, without delay.

Originally Posted by cyberbeing

Bug: When 'using yCMS' is selected, clicking edit in the yCMS tab doesn't load the template from the Color & Gamma sections. Same issue in both sections with the grayscale edit button.

The real bug is that the yCMS tab is visible sometimes when it should not be. It should only be visible if you've selected the "calibration" tab. The yCMS tab should not be visible in any other case.

Originally Posted by cyberbeing

Related question: Does madVR only accept yCMS settings separated by commas or can spaces be used like a normal yCMS config file?

If you edit it manually, you have to use commas. However, you can copy & paste the full "Gamma_Measurements" and "Grayscale_Measurements" sections from your 3dlut script to the madVR settings gamut/gamma sections and madVR will accept them as they are (with spaces). But for that to work, the "xxx_Measurements" header must be part of the copy & pasted text.

Originally Posted by cyberbeing

Bug: madVR shouldn't be creating 3dluts with Output_Transfer_Function set (currently always set to 1.0 0.0 0.45454545454545454545454545454545 0.0) since you are using yCMS presets. Do you have a reason for doing this? Will madVR misbehave is fed a 3dlut using the yCMS defaults for yRGB (no Output_Transfer_Function specified)?

I wasn't sure which output transfer function yCMS was using for yRGB, so I defined it, just to be safe. Since then yesgrey confirmed that the default yRGB output transfer function matches the one I manually defined. So I can remove that, but it won't make any practical difference.

Originally Posted by cyberbeing

Bug: madVR sets both input and output levels to RGB_Video (16-235) instead of RGB_PC (0-255). This will cause full-range videos to get clipped.

Are you sure? If that's true, I consider it a bug in yCMS. yCMS should not clip BTB/WTW, so it should also not clip full-range videos. That said, full-range videos are extremely rare.

Originally Posted by cyberbeing

Feature Request: Option to have madVR create a 3DLUT with an external yCMS config file and set the lut as the external 3DLUT after creation.

What extra options in the yCMS config file do you need? I think most users won't need this. So those few who do can create the 3dlut manually and use the "use external" option in madVR.

Originally Posted by cyberbeing

Hopefully you add an option to disable all these forced gamma corrections in madVR 0.63.

As explained above, with the default settings there is no forced gamma correction at all.

Originally Posted by cyberbeing

You've made things overly complex for something which should be very simple. I would like to see input settings grouped with their corresponding output settings, with an option to disable all this forced behavior and use defaults with identical behavior (taking yRGB into account) to versions prior to 0.62.

The problem is that there are various situations users can be in:

(1) They might have a meter and want to use yCMS.
(2) They might have a meter and use a different 3dlut creator.
(3) They might have no meter, but have their displays calibrated by an ISF calibrator to e.g. BT.709.
(4) They might have a display which is known to be mostly BT.709 calibrated out of the box.
(5) They might have a display with an unknown calibration.

I need to support all of that. And I want to offer all of these users the option to use both gamut correction (so both DVDs and Blu-Rays are shown with correct colors) and gamma adjustments (to match the ambient light level, or to match movies with a weird encoding).

If I would only have to take care of one of those 5 groups mentioned above, the settings dialog would be easier. But I don't really feel like creating 5 different versions of the settings dialog, either. So I have to find a solution which works for everyone. Of course it's going to be somewhat complicated. So help me optimize it. I'm open for suggestions.

My logic behind all this is that there are some settings which should be setup once and then never touched again ("properties" and "calibration") and there are other settings which users may want to tweak depending on ambient light level or movie ("color & gamma"). I think these settings should be separated into different tabs. Because of that I cannot put "input and output settings" into one tab, as you suggest.