- This topic has 12 replies, 2 voices, and was last updated 3 years, 7 months ago by
.
-
Posts
-
I’m planning to calibrate my monitor to Rec.709 (by following the steps in the wiki) by creating a 3D LUT. My monitor covers Adobe RGB 99% and I’ve read that for good 3D LUT calibration I should choose the largest available gamut that the monitor supports and not the Rec.709 profile/mode option that the monitor also has.
Is this the correct approach with my monitor, or am I missing something?
Also, does the monitor physically restrict the gamut when using smaller gamut profile/mode then Adobe RGB, or is there some other way it achieves Rec.709?
Native gamut => profile it in detail (XYZLUT profile with huge number of patches)
That profile is input for LUT3D creation. The other input is the colorspace you want to simulate: sRGB, P3-D65, whatever.So profile ONCE, then make as many LUT3D you need just changing the colorspace you want to simulate. That is a good reasonto use native.
Another one is that your Rec709 factory calibrated mode can be not accurate at all… but you can check it (you should have checked it before writing). DisplayCAL > set proper colorimeter correction if you use one > validation/verification tab > simulation profile, choose the one you need, like Rec709 2.2 or 2.4 > Measurement report.LUT3D approach requires that your video software can use such “software” LUT3D, like MadVR or Davinci Resolve. Or an external lutbox where uploading it.
For non color managed video editors like Vegas in Windows (at least some versions ago) this approach is not valid, you need to make your display behave like an ideal display meant to play that content (typical Rec709 g2.4)Native gamut => profile it in detail (XYZLUT profile with huge number of patches)
That profile is input for LUT3D creation. The other input is the colorspace you want to simulate: sRGB, P3-D65, whatever.I’m not quite sure what you mean. There is no native gamut option in the menus, the largest one is Adobe RGB (or P3). So I guess my question is does using A RGB effectively mean that I’m using the monitor’s native gamut?
I have tried to calibrate the monitor using the 709 gamut for this calibrarion workflow, but the actual corerage turnout to be about 97%.
With those weird options looks like one of these extremely low quality Benq SWs…
Anyway, if display has a mode that equal AdobeRGB at 9x% and P3 at 9x% it has a native gamut union of that colorspace boundaries. If display has not an OSD mode that allows you to use use… that’s another fault to blame manufacturer (but it has a native gamut, and its boundaries are limited by backlight type).
For your task choose P3 setting, or try to find custom/user color OSD mode with RGB gains for white point. The reason is to be able to generate LUT3D fro Rec709 g2.2, g2.4 and some P3-D65 for HDR to SDR simulation woth the same ICC profile
For your task choose P3 setting, or try to find custom/user color OSD mode with RGB gains for white point.
Okay, but using a custom color mode on my BenQ (yes, it’s a Benq) still requires me to choose a gamut from their list that consists of A RGB, sRGB, P3 and 709. Using 709 leaves me about 97% coverage, so I should either use A RGB or P3, correct?
Use P3, there is no reason to choose AdobeRGB for video. Loose potentially usable reds to gain cyans and tuquoise not used in video. Loose X, gain 0.
(joke) I have a crystal ball
(formal) ***If*** it is one of those extremely low quality monitors (but expensive) from ***SW line***, use Benq’s PME software to get a CAL1 (or CAL2 or CAL3) equal to Rec709 g2.2 or g2.4 just in case you need you edit or play video content in a non color managed app. Since PME uses WRONG spectral correction fro Xrite colorimeters, white will be off (depending on each colorimeter firmware) but it if “looks” white, may work.
If white is not too off and you get neutral grey after HW cal (which is not guaranteed because of this garbage called PME) you can use PME and another CALx as P3-D65 basis instead of custom OSD mode, then profile it in displaycal and use that XYZLUT detailed profile as source data for making the n LUT3D you need (simulate sRGB, simulate Rec709 g.4, simulate your phone…).
If white was too off of there are unresolved grey neutrality issues when using proper spectral correction in validation (Validate PME results with DisplayCAL), go to custom OSD mode and proceed as usual: fix white with RGB gains, choose a suitable gamma preset if available.. etc, then make ICC profile, then LUT3D from it (keep in mind if you need or you do not need to apply VCGT: usually for full screen madVR you apply it to LUT3D, for desktop mode GUI in Resolve you “usually” want to keep VCGT applies to whole desktop, like in default display ICC profile for your OS, so no not apply to twice)Loose potentially usable reds to gain cyans and tuquoise not used in video.
Not sure what you mean?
I know those images of gamut sizes compared to each others (like this) usually oversimplify things but how do I gain more reds with P3 since sRGB “border” seem to roughly run along the same line with A RGB? Aren’t those extra reds on P3’s side unusable for sRGB to begin with?
That profile is input for LUT3D creation. The other input is the colorspace you want to simulate: sRGB, P3-D65, whatever.
So profile ONCE, then make as many LUT3D you need just changing the colorspace you want to simulate. That is a good reasonto use native.Because of that.
Right now you want Rec709. After a while you may want to simulate how things will look on a non color managed video player on a mobile, or tablet.
Same display prfile, switch colospace to simulate (that mobile device, even synthetic aprox. description), make a new LUT3D, switch current LUT3T in ypur video player with the new one and voilà… you simulate that screen under no color management.That’s why native is recommended, then a LUT3D limiting it to whatever you need. If no native, P3 is more usable (more devices, or even P3 video)
IDNK what did you look at, what that matters is:
for PME
- white OK against actual colorimeter correction (the accurate one, not PME’s choice)
- Neutral grey (a=b=0)
- fairly additive response (PME matrix profile is or is not good description or colorspace volume)
for custom color mode (OSD gains & GPU calibration)
- white OK against actual colorimeter correction
- Neutral grey (a=b=0)
- good match against XYZLUT profile upon profile verification
and the highest contast you can get for each one. 900:1 should be easy for an IPS @ D65 with custom OSD mode, even higher depending on technology (backlight+panel)
No, I mean I calibrated it using displaycal and the 3d lut workflow like i’ve always done, i just used p3 instead of a rgb.
Maybe I will test the palette master element workflow at some point, though i’m not really planning to do any serious grading with my benq anymore. This whole thing was mostly just to satisfy my curioisity.
No, I mean I calibrated it using displaycal and the 3d lut workflow like i’ve always done, i just used p3 instead of a rgb.
In which sense were they worse?
For validating a LUT3D like resolve you use device link in validation (remember the apply or do not apply VGCT explained bfore).
Then check for white, neutral grey (individual & range), gamma and overall color patches dE => that is what to check, not 0.1% coverage gain or lose. It’s all in displaycal report verification in HTML.I didn’t mean to imply that the results were unusable, far from it, average dE was 0.31, maximum 1.53, patch #42. The blues seemed to suffer the most, othe one where it jumped was #24, slighty darker blue. Otherwise the results were fairly identical to the last A RGB attempt from couple of days ago when average was 0.25 but maximum only 0.62, patch #2, black. Nothing out of the ordinary between the two with RGB Grey balance or CCT etc. very similar contrast and black levels.
