- This topic has 88 replies, 13 voices, and was last updated 3 months, 2 weeks ago by
.
-
Posts
-
Thanks for posting the plots. I planned to plot their CS-1000’s and my i1Pro2’s curves on the same chart for two reasons:
- to see how the two instruments compare around the peaks (or in general)
- to check if they used native gamut
Even though the recommended ColourSpace WOLED Rec709 calibration workflow is generally a single profiling step (measure the display in native gamut [native primary saturations but pre-adjusted WP, to be precise], create a 3DLUT, upload it, verify the result), so basically all the important measurements take place in native gamut (only the verification happens in Rec709 emulation mode), I see some sense in putting Rec709 emulation mode measurements into the CSV file because one can argue that the single most important thing is the final accuracy of the Rec709 emulation mode (regardless of whatever the hell might happen in-between).
But I personally prefer to profile the colorimeter using native primaries myself, so I guess I will stick to my i1Pro2’s readings from now on. The difference is not that big anyways (I mean the x,y outputs of my i1d3 between the two CCSS files).
Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.@Janos, thanks for the excel file, very helpful
looks like they ignored Florian’s warning and took measurements in gamut clamped mode on the LG CX
Just to be clear: even if I want to profile my display in precalibrated rec709 mode, I need to measure the correction file in native gamut?
@mark-walter please refer to this post by Graeme on how to use oled.cmf
https://www.freelists.org/post/argyllcms/Observer-optimized-for-measuring-OLEDs,1
in Displaycal menu, choose Options > Advanced > Set additional commandline arguments
I just tried it (see picture attached) but I get
Diagnostic: Failed to read custom observer CMF from -Q file 'oled.cmf'make sure you are using full file path with -Q flag
colorimeter corrections should always be created in native gamut mode. There is a warning about this when you open the create corrections window.
make sure you are using full file path with -Q flag
OK, thank you.
colorimeter corrections should always be created in native gamut mode. There is a warning about this when you open the create corrections window.
But should I stick to native gamut mode for characterization as well, or can I switch to Rec709 for calibration afterwards?
You definitely don’t want to switch to Rec709 for profiling at any case. But it’s up to you if you wish to pre-calibrate the WP (preferably in the EZ-ADJUST menu or very carefully in the normal menu – never going above 192 in the SM and only decreasing 1 or 2 values in the normal menu from 0). Also, if you reset the 1DLUT (and thus do the profiling with the SM values effectively being ignored, as if those are set to all 192/192/192) you probably want to pre-calibrate Brightness and Contrast in SDR mode (not necessary in HDR mode because only SDR mode has a black-crush once you reset the 1DLUT). I personally prefer to reset the 1DLUT to save time, make the whole process less complicated and to be free to change the target white-point at any time (to try various suggested alternative white-points).
Creating the CCSS in native gamut is generally a good advice. But as I already wrote above… it’s not insane to do it in Rec709 calibrated state either if your utmost priority is to improve the accuracy of the final validation of a Rec709 calibration (but I think it’s more important to get that calibration right than to get the validation right).
@Janos regarding some of your issues with LG HDR, are you using the ‘standard way’ – 1dlut + matrix. The format is a plain text file with .matrix extension with the icc colorant tag XYZ values.
Like so:
hdr_cinema_3x3.matrix
0.518173217773 0.241088867188 -0.001113891602 0.310180664062 0.705825805664 0.061874389648 0.135848999023 0.053085327148 0.764129638672
then we upload using bscpylgtv:
bscpylgtvcommand 192.168.1.18 set_3by3_gamut_data_from_file "bt2020" "hdr_cinema_3x3.matrix"i’m not familiar with any other way to do it ‘correctly’
one key point I forgot to add, the TV can accept negative values for the upload but the image wont look correct so we have to push red negative Z value to zero. thats all, and the image will look correct.
I posted too early. im still in the process of figuring out how matrix is handled by the tv, the image will not look correct with the above method.
I looked into the matrix method and the correct way to calculate the conversion matrix is using something like LutCalc(pictured) or colorscience matrix transform. im not sure if collink offers a way to generate a simple conversion matrix using rec2020 ref and the measured icc. I tested and didnt find any matrix in the devlink icc.
This is an interesting thread. I have a colormunki display and a monitor with a quantum dot filter. I’ve been using novideo_srgb to calibrate to srgb, using displaycal with the calibration settings all set to “As measured” and CIE1931 2 degrees as the observer.
I’ve always found white looks like it might have a bit of a green tint. It doesn’t bother me, but I thought that might just be how the white point looks. Now I’m wondering if this is the observer problem described here, and wondering how I’d go about correcting it.
I checked the ccss file I downloaded, which is a spectral correction with reference(Colormunki), display(matching mine), type(spectral) and observer(not applicable). Does that mean I should be able to use the CIE 2012 2 degree observer to generate my icm? Would that even make a difference if I have the whitepoint “as measured”? I think I might be able to set the whitepoint to specific target and use it for calibration in novideo_srgb. The only note I see about generating the icm is “Only the VCGT (if present), TRC and PCS matrix parts of an ICC profile are used. If present, the A2B1 data is used to calculate (hopefully) higher quality TRC and PCS matrix values.” I’m not sure what setting a target whitepoint would do.
This tool allows you to set separate SDR and HDR 3DLUTs for all your desktops. If you select “absolute with wp scaling” during the .cube file generation (DisplayCAL 3DLUT tab, you can go crazy and do 65^3) then the white point will try to match your taget (without clipping).
https://github.com/lauralex/dwm_lut
I would personally advise you either not to calibrate at all (even set your display’s OSD settings back to “neutral” [save for the SDR backlight intensity] but do take a few thousand measurements, like 18 multipoint and 52 per channel and 52 neutral, not just “auto” – this will take several hours though…) or calibrate to your actual targets instead of “as measured” (save for the luminance targets) when it comes to the WP (D65) and gamma (2.2 rel 100% for SDR, PQ for HDR).
