- This topic has 39 replies, 3 voices, and was last updated 6 years, 10 months ago by
.
-
Posts
-
Is the video from the first post really encoded incorrectly? Meaning it’s full-range (but interpreted as limited).
I have not analyzed the video. It seems to have chromatic values above 235 though, which is not according to video standards.
As far as I understand, due to limited resolution of 65^3, there is no way for Argyll to correctly map values 236-254.
Values 236..251 will be correct (251 is cLUT grid point 64).
But isn’t 3D LUT for madVR of higher resolution?
Yes, but it’s up-interpolated from 65^3.
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?
On a wide-gamut display, the issue will be exacerbated if the video encodes chromatic values above level 251.
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?It’s as easy as setting rendering intent to relative colorimetric and regenerating the 3D LUT, but see above for wide gamut and chromatic values above 251.
So, the values 236-251 should be correctly mapped, the problem is only with values 252-254? (Are they considered WtW, by the way?)
If I take a frame from this video (interpreted as full range), save it to file and check for values with R/G/B > 251 – will it be a correct test for these poorly encoded values?
I also think that it makes no sense to interpolate values between 251 and 255. They will be wrong in general! Why not extrapolate values past 251 (except for 255)? This could be a better approximation.
So, the values 236-251 should be correctly mapped, the problem is only with values 252-254?
Yes.
(Are they considered WtW, by the way?)
They are part of the WtW range, but as said, WtW should only be used by test patterns.
If I take a frame from this video (interpreted as full range), save it to file and check for values with R/G/B > 251 – will it be a correct test for these poorly encoded values?
You’d need to analyze the raw video stream, otherwise you won’t know if it’s a possible decoding issue.
I also think that it makes no sense to interpolate values between 251 and 255. They will be wrong in general! Why not extrapolate values past 251 (except for 255)? This could be a better approximation.
All the values past 235 are extrapolated.
At first I understood that all the values are interpolated between existing points, with values above 251 interpolated as if there was point mapping 255->255. And by extrapolation I meant following the same function used for mapping values less than 251.
Now I don’t get why you say that values past 235 are extrapolated. I thought that 251 was still used as correctly mapped point.
Now I don’t get why you say that values past 235 are extrapolated. I thought that 251 was still used as correctly mapped point.
The distinction is that everything past 235 is not based on actual measurements (extrapolation).
Does it mean then that the values above 231 to 252 are extrapolated by Argyll? And where is this linear interpolation towards the 255 endpoint implemented and how? Why not implement it as extrapolation following the same curve as values before 252 and not linearly going to 255?
What tool can be used to analyze raw frame data? ffmpeg with saving frames to png? Or will it still be inaccurate?
Why not implement it as extrapolation following the same curve as values before 252 and not linearly going to 255?
How exactly are you going to implement interpolation between two cLUT grid points in the cLUT itself? It’s not possible! The interpolation in consuming software is usually (tri)linear or tetrahedral (which is also a form of linear interpolation).
What tool can be used to analyze raw frame data? ffmpeg with saving frames to png? Or will it still be inaccurate?
I’m not a video specialist, so I can’t tell what would be the best approach to analyze raw video data.
Probably, more information is needed on how “level 251 (which is cLUT grid point 64) and up will be a linear interpolation towards the 255 endpoint (cLUT grid point 65).”
Now I understand there is some problem in extrapolating result values for 252-254, but not what this problem is. Sorry that I didn’t quite get what was impossible to interpolate in cLUT.
Also, version that video encoding is wrong needs to be verified (and whether it’s values 252 and higher giving these artifacts).
For this video, I made the following test: in the video player that was using madVR, switched to interpreting video as full range (via madVR shortcut) and made a screenshot in PNG. Then opened it in Photoshop and analyzed the values in the areas of these artifacts.
Red areas were indeed oversaturated in R channel (highest R was 255), but G and B were less than 252 (and even less that 235 in green area), although R values were 0 (or close to zero) there. So, most of the visible problems are in areas with R not in range 16-235 (or even 1-254).
Not sure whether it’s the problem with the video or madVR. Should these values even go to 3DLUT?
Red areas were indeed oversaturated in R channel (highest R was 255)
255 is reserved and must not appear in video content.
Not sure whether it’s the problem with the video
Going by your analysis, definitely the video.
Is it correct to have 255 in 3D LUT output if it’s reserved?
Shouldn’t values 0 and 255 even not be input to 3D LUT mapping at all in the case they are used for some control information?And the video doesn’t look like it’s full range – the white background is not higher than 235 in any channel. It looks like some color space conversion artifact, though I may be wrong.
Some additional thoughts on this:
madVR can use the full range of values in 3D LUT, and there are no special values that it should use.
Why not have at least an option to not map 0 to 0 and 255 to 255, but instead use the calibrated and interpolated values?Is it correct to have 255 in 3D LUT output if it’s reserved?
Those values are passed unchanged through the 3D LUT.
Shouldn’t values 0 and 255 even not be input to 3D LUT mapping at all in the case they are used for some control information?
That’s not something that the 3D LUT has any control over.
It looks like some color space conversion artifact, though I may be wrong.
I’m pretty sure it’s an encoding error. It would be interesting to know what software was used to encode the original video.
Why not have at least an option to not map 0 to 0 and 255 to 255, but instead use the calibrated and interpolated values?
That’s what it is currently doing.
Is it correct to have 255 in 3D LUT output if it’s reserved?
Those values are passed unchanged through the 3D LUT.
Shouldn’t values 0 and 255 even not be input to 3D LUT mapping at all in the case they are used for some control information?
That’s not something that the 3D LUT has any control over.
Why not have at least an option to not map 0 to 0 and 255 to 255, but instead use the calibrated and interpolated values?
That’s what it is currently doing.
These sentences look contradictory to me.
As far as I understood, because “video level 3D LUTs take care that levels 0 and 255 are passed through unchanged”, values 0 and 255 are not mapped to calibrated colors or colors from ICM profile, but are always mapped to 0 and 255.
Why not map them to values from monitor profile instead? That is, when generating 3D LUT for madVR? This way, there won’t be such artifacts for these kinds of video. I will try to find out where this particular one comes from, but there are other examples, and they go unnoticed simply because they are being watched on non-wide-gamut displays.
