- This topic has 134 replies, 21 voices, and was last updated 1 week, 5 days ago by
.
-
Posts
-
No if “madVR xxxxxxxx” or “AW xxxxxx” were made at native gamut.
They were made at native gamut dci-p3.
Then those setting are wrong. I’m not a native english speaker, but “from Rec709 to “simulated colorspace by novideo_sRGB”” does not seem so difficult to understand.
Then those setting are wrong. I’m not a native english speaker, but “from Rec709 to “simulated colorspace by novideo_sRGB”” does not seem so difficult to understand.
There is no way to keep novideo_srgb turned on, and watching a movie in madvr with 3dlut made specifically for madvr, it becomes a dark and desaturated mess. The correct way would be, for novideo_srgb to turn off automatically when madvr is detected, just how diplaycal profile loader works.
Then those setting are wrong. I’m not a native english speaker, but “from Rec709 to “simulated colorspace by novideo_sRGB”” does not seem so difficult to understand.
There is no way to keep novideo_srgb turned on, and watching a movie in madvr with 3dlut made specifically for madvr, it becomes a dark and desaturated mess.
Because you are doing it wrong, you are chaining 2 color transforms that asume (each one) taht display behavior has native , and that is true only for one of them.
It’s 100% user’s fault.
The correct way would be, for novideo_srgb to turn off automatically when madvr is detected, just how diplaycal profile loader works.
The correct way would be using a LUT3D on madVR that reencodes “from Rec709 to “simulated colorspace by novideo_sRGB””, and that’s what you are not doing.
Then you apply an AMD driver, novideo sRGB or DWMLUT it is applied globally. Like if uyou had HW calibration capabilities on your display, hence all apps using that group [swoftware simulation + display] must acknowledge current status of that group.
Then such LUT3D won’t desaturate… it can’t (rec709 -> sRGB), unless you had not assigned it to Rec709 slot in madvr lut3d config and that is user’s fault.
novideo_srgb added support for “L* EOTF”. What is this?
A gamma value that results in something like visually equal distances between a grey and another. It has a gamma that starts low, 1.x and then rises to 2.x. It’s like sRGB TRC but more extreme.
Just to make sure, I have novideo_srgb going still.
For my generic icc profile in windows, should I be using a generic synthetic gamma 2.2 profile generated by displaycal, or the stock srgb one?
I just wanted to verify, since I’m calibrated for gamma 2.2 offset 50%, and I’m not sure if setting it to srgb or gamma2.2 is more correct when selecting a synthetic profile.
This is the old disccussion about if sRGB content is meant to be displayed on g2.2 or if you must honor color management definitions : display behavior = display profile. I like the second one.
