Home › Forums › General Discussion › novideo_srgb: GPU-side LUT-Matrix-LUT calibration
- This topic has 137 replies, 22 voices, and was last updated 4 weeks ago by Omelette.
-
AuthorPosts
-
2023-12-06 at 11:32 #139972
No if “madVR xxxxxxxx” or “AW xxxxxx” were made at native gamut.
2023-12-06 at 11:41 #139973No if “madVR xxxxxxxx” or “AW xxxxxx” were made at native gamut.
They were made at native gamut dci-p3.
2023-12-06 at 11:48 #139974Then 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.
2023-12-06 at 13:59 #139975Then 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.
- This reply was modified 9 months, 1 week ago by S Simeonov.
2023-12-06 at 14:12 #139977Then 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.
2023-12-06 at 14:44 #139978I’ve tried that too, same result. “simulated colorspace by novideo_sRGB” is srgb.
- This reply was modified 9 months, 1 week ago by S Simeonov.
- This reply was modified 9 months, 1 week ago by S Simeonov.
2023-12-07 at 13:54 #139983Then 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.
2023-12-07 at 14:09 #139984The 3dlut is in the correct slot.
2023-12-07 at 14:48 #139985Then it cannot desaturate and the claims are false.
2023-12-07 at 15:01 #139986For the 3dlut in madvr to work, it needs the windows calibration disabled.
2024-01-01 at 21:49 #140246novideo_srgb added support for “L* EOTF”. What is this?
2024-01-02 at 12:47 #140251A 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.
2024-01-03 at 22:17 #140266Just 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.
2024-01-04 at 16:13 #140270This 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.
2024-01-04 at 23:14 #140276Shouldn’t you profile the display and use that?
-
AuthorPosts