- This topic has 39 replies, 3 voices, and was last updated 6 years, 10 months ago by
.
-
Posts
-
I noticed some artifacts in saturated color areas of video when using madVR with 3D LUT, created by DisplayCAL.
Here is an example of video and the 3dlut file:
https://www.mediafire.com/folder/lnusmyaz3dlv6/madVR
These arttiacts look like oversaturated areas and it could possibly be to handling of WtW values. Example:
The author of madVR recommended to address these issues here: “A 3dlut is calculated offline, so it has the chance to calculate everything is perfect accuracy. Because of that, when using a 3dlut, madVR leaves *everything* in the hands of the 3dlut, which includes handling of WTW and BTB. It’s the job of the 3dlut to handle WTW and BTB correctly.”
I used madVR preset when creating the 3dlut file. Also, I tried different settings for 3dlut file output, but that had no visible effect on the problem.
What could be the problem here and how to fix it?
The issues you are seeing has nothing to do with WtW. Your video chain or player is setup incorrectly or faulty. The 3D LUT doesn’t cause these artifacts, see attached screenshot.
Strange, I wasn’t the only one who saw this problem with 3dlut:
http://forum.doom9.org/showpost.php?p=1807613&postcount=43822
Actually, the screenshot you provided shouldn’t contain many problematic pixels, it’s better to see a little later, with curve moved. I see only some red saturated pixels on top of the color wheel here. But they still seem to be there.
Look at your screenshot. If your video chain was setup correctly, that screenshot should look exactly like mine – it doesn’t, in fact not even close, so something’s wrong on your end (and the other guys from the thread you linked as well).
Screenshot of the same frame (about 00:13) looks indeed very close.
Mine was from around 00:27 or so – at that time the effect is very pronounced.
What are the reasons for that? It could be not from WtW handling, but it’s certainly visible in saturated areas.
Is the LUT file correct? The same file when played without 3D LUT doesn’t exhibit this behavior (the image is just more saturated as a whole, but no banding/ringing or how to call this?)
Is the LUT file correct? The same file when played without 3D LUT doesn’t exhibit this behavior (the image is just more saturated as a whole, but no banding/ringing or how to call this?)
I don’t have this effect with my own 3D LUTs. Attach the profile from which the 3D LUT was created please (in DisplayCAL, “Create compressed archive” next to settings, with the profile selected).
I have recreated 3dlut recently to make sure that it wasn’t an error (I didn’t like the result, maybe due to colorimeter – but the effect in madVR is the same).
Uploaded it to the directory from the first message, name of the file is “madVR 2017-05-24 0.3127x 0.329y S XYZLUT.7z”.
Any news on this 3D LUT problem?
By the way, I have the same artifacts when I create 3dlut file for madVR from the official ICC profile for my monitor.
I have the same problem as “igvk2 with a Widegamut very similar to igvk’s CS240 GB-LED. It has been there for years and nobody seems to fix it whoever the culprit is. AFAIK it cannot be a DisplayCAL issue, I’ll explain it latter.
Regarding the “wigdemut artifacts”:
At 0:10, 0:25, 0:30 or 0:35 video goes “widegamut” at 7-8 hour direction (green) and at 6 hour ( cyan). It also goes widegamut at 12 hours (red) at 0:40 for example.
At 0:12 video goes sRGB/rec709 again so Florian’s screenshot is not valid. Please Florian, if you do not mind and you have a widegamut monitor calibrated to its native gamut (I think you have), please post a screenshot at 0:10, 0:25, 0:30, 0:35. Choose the one you like most.These issues are seen in some videos like the example from igvk, but others like sample mp4 files with Rec709 full RGBCMY saturation calibration patches are ok.
Although I know it is the wrong way to solve it, “igvk” you should try to get a LUT3D without Florian’s GUI. Use console and collink.exe and compute full range input-output LUT3D for madVR. Yes, I know madVR expects limited range, but give this a try with your CS240. Results will be “visually similar” to a correct one (I mean sRGB/Rec709-like, without those artifacts) and if you validate such LUT3D with madVR + HCFR you should only see minor oversaturation <2dE in RGB primaries. If those “out of gamut artifacts” bother you, give it a try.
I’ve tested pixelshader shown in doom9’s thread, it solves the problem to this video and a few more with those issues on my computer
sampler s0 : register(s0); float4 main(float2 tex : TEXCOORD0) : COLOR { return clamp(tex2D(s0, tex), 0.0, 1.0); }So… if these piece of code solves the issues and “visually” seems to do not corrupt or alter videos without those issues, then… who is the culprit of those artifacts?
-collink computing the LUT3D wrong while in 16-235 range? You WON’T see these issues unless you have a widegamut monitor to test.
“igvk” try to contact ArgyllCMS programmer in its maillist. You may get better answers there but IDNK if Mr. Hill has a wideganut monitor to check our problem.-video decoder which does not clip some values? Since Florian is using MPC-BE and it’s very likely that he uses embebed LAV codec, Florian, do you mind to post a screenshot of your MPC’s shader configuration and LAV configuration? Do you use some trick like that pixel shader code?
-madVR, unable to deal with those values?
Ok, perhaps I should have really posted to ArgyllCMS list. But I used DisplayCAL, and not actually sure of all the components needed to clearly describe the problem.
According to DisplayCAL log, when I used DisplayCAL-3DLUT-maker to create 3dlut for madVR from icm file of my monitor, the command line of collink was:
collink.exe
-v
-qh
-G
-iaw
-r65
-n
-3m
-et
-Et
-b
-IB:0.0:2.4
-a
“PA302W.cal”
Rec709.icm
“PA302W.icm”
BT.709.icmICM file can be downloaded from NEC site: http://www.necdisplay.com/documents/Drivers/pa302w.zip
With the result 3dlut file, the artifacts are visible, and I’m sure should be visible on any monitor – they will only be unsaturated on sRGB one.
I’ve already mentioned this a few times I think over at AVSforum, but maybe a little more in-depth explanation is in order:
- Correctly encoded video content should only encode legal video levels, meaning code values in the range 16..235. Anything else is not correctly encoded, and is probably a sign of bugs in the encoder or encoding software used, or user (creator) error on the encoding side, with the exception of test patterns (see below).
- There’s the concept of “BtB” (blacker than black, range 1..15) and “WtW” (whiter-than-white, range 236..254), but this only applies to test patterns used to setup a TV’s black and white level correctly. Actual content must not encode these values, because a correctly setup TV would clip them anyway. It is certainly an error if video content encodes actual color (chromatic) values past 235 (it’s called WtW for a reason, whiteness implies achromaticity).
- Levels 0 and 255 are reserved for timing information according to the current video standard and must not be encoded by video content. For this reason, Argyll-generated video level 3D LUTs take care that levels 0 and 255 are passed through unchanged. As the 3D LUTs that Argyll generates are limited to a resolution of 65^3, this means level 251 (which is cLUT grid point 64) and up will be a linear interpolation towards the 255 endpoint (cLUT grid point 65).
- The aforementioned means that if a video levels 3D LUT corrects the whitepoint (i.e. the display is not calibrated or adjusted to the target whitepoint already), that values above 235 encoded in video content (which, as already mentioned, would likely be an error on the encoding side) will gradually but still somewhat abruptly cross over to the native display response between levels 251 and 254.
- The only way to really fix this is to correctly re-encode the faulty video content according to the video standards currently in use, i.e. so that it uses legal video levels 16..235. A workaround is to calibrate or adjust the display to hit the target whitepoint exactly.
Florian,
Is the video from the first post really encoded incorrectly? Meaning it’s full-range (but interpreted as limited).
As far as I understand, due to limited resolution of 65^3, there is no way for Argyll to correctly map values 236-254. But isn’t 3D LUT for madVR of higher resolution?
And, the whitepoint of the display profile that I referenced should coincide exactly with the one of sRGB, as far as I understand. Is it only whitepoint problem and not wide gamut?
Interesting:
The only way to really fix this is to correctly re-encode the faulty video content according to the video standards currently in use, i.e. so that it uses legal video levels 16..235. A workaround is to calibrate or adjust the display to hit the target whitepoint exactly.
I’m interested in a “how to” guide to generate a LUT3D “legal levels” from a widegamut monitor which has hardware calibration or RGB gain levelsin OSD, capable of bring monitor’s white point close to (<3dE) but not equal to D65 with it’s own hardware, whithout modifiying white point with the LUT3D and thus avoiding the cause you point to be the responsible these issues.
Maybe to generate a synthetic profile like Rec709 but with monitor’s whitepoint?Is this covered in 3.3 changelog without workarounds?
Calibration whitepoint targets other than “As measured” will now also be used as 3D LUT whitepoint target, allowing the use of the visual whitepoint editor to set a custom whitepoint target for 3D LUTs.
Thanks in advance
