- This topic has 325 replies, 56 voices, and was last updated 1 month, 3 weeks ago by
.
-
Posts
-
Then aim for equivalent colorspace with transformed white as source profile for making the LUT3D.
yes, I set target white point on calibration tub, and used relative intent, but not works well.
No, I mean to aim to a different colorspace with the same whitepoint as your display
comfirmed the exported LUT on lightspace, black side seemes strange on eotf and white balance.
modify the TRC you aim for: abs, relative, black outoput offset and specific HDR settings when trying to “fake” a TRC beyond display capabilities.
Plot a QLED, like bundled Samsung TV, or some widegamut PG models from Asus. There are not sharp figures in a QLED spectral power distribution.
The sharp ones are in WLED PFS/KFS, or a laser proyector… or some older CCFL.Indeed, the spectrum of Quantom Dot is certainly sharp, but it is certainly different from the angle that looks like a edge line, such as KSF.
This may be preferable for users using the Q-dot type.The Synthetic Editor I found, it could help make my workflow easier in creating correction LUTs for HDR mode. Thank you for your suggestion.
I’ll try over the weekend and report back if I have good results.
*Currently, unless HCFR is used for white balance and EOTF correction, sufficient calibration cannot be obtained as previously attached.The newest version of DWM_LUT works excellent on the latest version of Windows 11.
What does the spectral graph look like for those?
How big of a difference are you seeing?
Also, how come they are both so much less than rec709?
I’d probably use the one that has the higher gamut coverage for the reference. Unless one looks more “white” to you, then go with that one.
2 different humans don’t necessarily even see the color the exact same, so there is no 100% true reference anyways.
It’s a pretty noticeable difference. I no longer have the CCFL anymore so I can’t take anymore measurments of it and show spectral graph. It stopped working so I trashed it
But it was a really old 2007 display.
The WLED is from a tablet computer. So that’s why both their gamuts wasn’t particularly good.
But I mostly use a QD-LCD. So full coverage of P3.
Just to confirm: you are using 2 monitors at the same time and you want them to be tuned in harmony?
I think a monitor should be calibrated for proper display characteristics only for viewing.
Moreover, if it is not calibrated enough, it cannot be used for grading.
Also, in my environment, there are three monitors side by side.
I feel a sense of incongruity when these monitors with greatly different displays are lined up.As for the calibration workflow, thanks to Vincent’s advice.
I got whitepoint corrected 3D LUT from madVR 3D LUT calibrate with relative intent.
I succeeded to create a 3D LUT directly in DispCal without taking a 1D Primary first.Unfortunately, I think 1D correction (including tone mapping) is not enough with DispCal alone.
Created with HCFR and a my excel file for design a 1D LUT is better and easy for me.And Merge these 1D and 3D on DaVinci, I got best result.
Some user complained about “colorimetric intent” (which is one way to get relative whitepoint = no changed white, the other is perceptual) and although i do not remember the detailt he got what he aimed for by using an equivalent Rec 709 colorspace with a whitepoint numerically matched to the “visual white” he wanted.
That’ll be me
For SDR this is what I did to get everything including grayscale correct with DWM_LUT
I have pictures of all the settings I had to do to get everything correct.
On the calibration tab it was important for me to set tone curve and calibration speed. Setting it to as measured is what kept giving me inaccurate grayscale. Usually 3D LUT presets sets it to as measured. So do not set it to as measured.
The 3D LUT tab you can ignore since later I’ll create a 3D LUT.
When profiling is done and it asks to install profile I ignore. Do not install it. Instead have windows default sRGB IEC61966-2.1 loaded into display cal profile loader.
With synthetic profile creator I clicked on Rec.709 preset and manually entered my alternate white point coordinates. And saved it.
In 3DLUT Maker I loaded the profile I created with the alternate white point into the source profile. Clicked Current profile to load my recently created measurements into destination profile. Gamma 2.4. Check Apply calibration (VCGT). And for rendering intent I used absolute colorimetric with white point scaling.
It’ll generate a 3D LUT with my newly create WP targets from source profile. Loaded it into DWM_LUT. And when I verified in DisplayCal and also HCFR everything was spot on accurate. I have pictured the settings in DisplayCal I used for verification.
I made a tutorial video based on the workflow I proposed the other day.
My suggestion is to use 3D LUT application with DWM_LUT instead of dependent ICC display profile,
For SDR display, it should correctly calibrated to sRGB only, fixed at sRGB.
In other words, I does not take into consideration the use of ICC to display AdobeRGB or sRGB, or to reproduce the display of some kind of monitor, on general PC operation.
For HDR, it should be calibrated as accurately as possible to ST2084/rec.2020, and mapping as your necessary.The Relative colorimetry which Vincent taught me matched my requirements is good, it corrects the white point, keeps the chromaticity as standard as possible, and basically saturates the color outside the gamut.
Really thanks to tell it.However, it seems not enough on cccuracy, necessary to design a 1D LUT using HCFR and perform additional corrections in order to achieve the target tone map flexible design and more accurate white point matching.
(I used black output offset at 100%, set target peakluminance correct, choosen relative colorimetry)In addition, the monitor display will be out of alignment every time, but I think that the RGB balance will be lost more often than the saturation map will be greatly out of order again.
This process can correct the RGB balance quickly, not takes 3 hours.
Just by correcting the 1D LUT each time, so I expect that it will be possible to maintain the calibrated state with a simple operation.
(DisplayCal and madTPG 4400point measure takes 3 or 4 hour, it is too long.)If you want to try this process, download the necessary files from my Mega.
Measurement patch for DisplayCal and madTPG
https://mega.nz/file/uiR2lR5a#L6ub_98m3T7lSXwKVYXr_onXRiNy1y8WwtfzXRdoizg
1D LUT creator (xlxs format)
https://mega.nz/file/Wz5W1R4R#lkAPQjz6J_KyWMYYc9r9H7fBGs28mC_C5hnGalFRbIE
black fix lut (.cube)
https://mega.nz/file/CvxmjSYD#DEKW3A7SjS4D0DOLblzyJBXX0Q9uSlnTnydW3_B0dRoMy suggestion is to use 3D LUT application with DWM_LUT instead of dependent ICC display profile,
For SDR display, it should correctly calibrated to sRGB only, fixed at sRGB.
In other words, I does not take into consideration the use of ICC to display AdobeRGB or sRGB, or to reproduce the display of some kind of monitor, on general PC operation.I’m afraid that you did not get how this stuff works.
ICC and LUT3D approach are equivalent. Identical.
Whatever you do with your luts can be done with ICC profiles. Your LUT3D is created from profiles even if calibration app’s vendor does not mention its use (a profile is just the description of the behavior of some device).
Your complains about 1D VCGT are not related to ICC profiles system but to default “target/aiming” of resulting TRC in some apps (or maybe user misconfiguration). You can get your cooked VCGT 1DLUT computed form a 3rd party and inject it in a display ICC profile with whatever fake or real TRC you want.You use a LUT3D (=a “cristalized” transformation between two colorspaces defined each one by a profile) when :
-application showing your desired content is not able to perform such transforms (=> HW calibration or LUTbox is needed)
(or)
-application performance constraints (speed or 3x TRC behavior in some color managed apps)
and
-the content colorspace is limited to very few colorspaces.A field monitor will need 1st requirement, no computer (hence no way to deal with ICC colorspace transformations), plug in whatever device that sends data in a fixed & known colorspace (3rd requirement). A portable instant printer may meet this 1st one + content in SD or mobile phone in sRGB JPG/TIFF (3rd one) as long as you work with the limited range of vendor paper products (otherwise precooked colorspaces won’t match new paper behavior).
Typical video editing workflow matches the 2nd and 3rd, and may need 1st if application is no color managed or software LUT3D support.
Other tasks do not meet 3rd requierement (photo) hence you cannot use LUT3D alone, but may gain points with 2nd (3xTRC with non dithering software).Using a system wide LUT3D (like with DMWLUT) truly makes sense for some purposes as stated before, but still need ICC support if you want to use color managed apps like most browsers and image editors = OS default display profile must be set to the colorspace LUT3D is simulating.
An example of this is “linearization” of bad behaved displays for photo editing. Let’s say that you have a widegamut monitor, with enough contrast & color uniformity to be used in this filed… but its HW calibration is not behaving as it should (Asus, Dell, Benq a*b* grey range) or has not HW calibration and gpu luts are not well behaved (nvidia, intel).
What you do ***for this particular case*** is to simulate an idealized native gamut of display (NOT sRGB, NOT AdobeRGB… it will be pointless & stupid):
-Make a super accurate ICC profile with truye behavior of display
-Make a syth profile of idealized (“in gamut”) native gamut (how display shoudl behave if it was working properly)
-Make LUT3D from thses two profiles (source: idealized, destination : accurate) and load it in LUT3D
-OS must be configured to use as default display profile the idealized version of that display.Here you do not simulate sRGB or AdobeRGB. Why? Because this task do not meet 3rd requirement , while video (and even gaming) with its limited set of content colorspaces meet.
Vincent, thanks for your reply and suggest.
I think you recommend to define the ideal monitor’s native characteristics with ICC, and the complete saturation map is also calibrated in some way, so that any color space can be supported on it, surely, this is one ideal form.
It does not need Windows HDR mode (ST2084/REC.2020) if this works perfectly, probably Mac OS CMS may similar to it.
For example (although I don’t know any ICC that supports such behavior), It may be possible to support HDR (ST2084/REC.2020) with a different method, such as scRGB/linear functions as they are, and mapping according to the monitor’s original luminance upper and lower limits and Primary is acquired from ICC at the time of output.However, I am a video technology specialist who mainly works on HDR grading such as UHD BD.
If you are interested, please watch my work, Robot Carnival UHD BD.
I was in charge of HDR grading.
From the point of view of specializing in video technology, I place importance to provide calibrated output for each monitor on Windows in HDR mode (ST2084/REC.2020).I am aware that ICC functions in the color management of apps under the OS, but as I may mentioned, I think that everything handled as SDR should be output as sRGB.
In other words, all monitors should be set to sRGB as ICC, monitors should be sRGB, SDR should be sRGB for computers, and REC.709 (including BT.1886 with different gamma values) for video.
Whether or not Photoshop outputs AdobeRGB cannot be the subject of this effort, and in addition, I think that AdobeRGB is no longer important for still images.
From my actually dealt with HDR (ST2084/REC.2020), I think ICC, which does not define the display color space itself and depends on the production monitor, has been a source of confusion for a long time.
I believe that it is preferable to use HDR (ST2084/REC.2020), which defines the huge color space impossible to display, as a standard.I think MS seems in a stray state on Windows colour management in HDR mode (ST2084/REC.2020).
However, basically it is assumed that the output destination for HDR completely satisfies ST2084/REC.2020 (in other words, how it is displayed depends entirely on the monitor), and the SDR delivered as sRGB (80cd/m2) in the HDR(2084/2020) container.
This management is very appropriate and correct when viewed as a CMS.
(I know it frustrates people who are used to unmanaged, strange and gaudy SDR output.)
In the future, I think the app should support HDR (ST2084/REC.2020) and handle areas outside of sRGB.I don’t think the currently available ICCs are capable of fully managed saturation maps and excellent 1D corrections like a 65-point 3D LUT.
As I mentioned earlier, I don’t know of any ICC that can do that.As you may be aware, in the display of HDR (ST2084/REC.2020), out-of-gamut and over-luminance are mapped on the monitor side, so it is impossible to calibrate simply by setting a simple vertex or 1D LUT, and without strict remapping by 3D LUT, the saturation correction and EOTF optimization in HDR shown here would not be possible.
My flow uses a 3D LUT for a certain system (sRGB/HDR (st2084/2020)) that the output device assumes.), it is a simulation of responding hardware calibration, like a Lightillusion suggestion
In other words, the DWM LUT is used as an external LUT BOX or as a simulation of LUT calibration function of professional monitors that support hardware calibration on HDR.In the example shown here, Windows assumes that the monitor supports HDR (st2084/rec.2020) and outputs the video signal, and the monitor reproduces it as a light as much as possible.
In this reproduction, the current situation is that mapping including inappropriate ones is applied for each monitor, and as a result, appropriate display cannot be obtained on many monitors and televisions.
To compensate for this problem, I need to disable monitor mapping (which of course, saturates outside the performance cap) and then do proper mapping as needed.
This requires DWM LUT, 3D LUT calibration with an external LUT BOX or monitor’s 3D LUT, but as I mentioned earlier, I do not know any ICC system that supports such 3D LUT correction.When using DispCal, it was impossible to handle HDR (ST2084) in a system that relied on ICC.
Surely, this is not the case with the latest other systems. (sorry for the repetition) but unfortunately i don’t know that.
I have posted all the steps and required files.
If you say that ICC can do same or better, please show me the detailed method and the result of HDR calibration on WIndows HDR mode, I want to try it.The important point is that as a result of measuring HDR (ST2084/REC.2020) using madTPG and DispCal from the settings for madVR, sufficient accuracy was not obtained with DisplayCal alone (4400 points were measured), especially the monitor response in the low luminance range was very unnatural.
This was a fatal problem in this effort.In this example, I need an additional 1D correction to fix this problem.
As shown at the end of the above tutorial video, the result was a very favorable calibration, and in my current environment, the INNOCN M2V and M2U, which are only consumer devices, display the same display as the ProArt PA32UCX that performed hardware calibration for HDR by ASUS ProArt Callibration software.My suggestion is to use 3D LUT application with DWM_LUT instead of dependent ICC display profile,
The way DWM_LUT works is that it needs 1D LUT in order to get grayscale accurate. So that means do not set Tone Curve to as measured under the Calibration tab. So set tone curve and calibration speed to get measurements for 1D LUT creation.
And when you generate a 3D LUT LUT set apply (VCGT) to use the 1D LUT measurements.
Also since you are using an alternate WP do not use the default source colorspace profiles that has D65 coordinates.
Instead generate a new source colorspace profile with your alternate WP using synthetic profile creator and use that instead to generate 3D LUTs. And then after it doesn’t matter if you use relative or absolute colorimetric. You will get more accurate grayscale & colors doing it this way, but I usually use absolute because it usually gives me lower overall DE.
Using the default D65 source colorpaces will always result in high DE for grayscale & color even if you use relative colorimetric.
In my above post I uploaded pictures for exactly what I did to get everything correct. Just apply that to HDR LUT creation instead.
Hi EP98, many thanks for your help, your post was very helpful.
No tone curve is set in the calibration tab.
I used “AS Measured”.As for the changes in WP, I feel like it’s improved by using Relative, but it is not perfect yet.
However, I think that it is not a fatal problem, additional correction improves eotf difference in low luminance and whitepoint.BTW, I finally figured out how to use synthetic ICC profiles.
It was trial and error because it was not reflected on DisplayCal,
but I was able to select it in 3D LUT Creator, I will try it tomorrow.madTPG and DispCal from the settings for madVR, sufficient accuracy was not obtained with DisplayCal alone (4400 points were measured), especially the monitor response in the low luminance range was very unnatural.
This was a fatal problem in this effort.Just to make clear the tone curve under the calibration tab and tone curve under 3D LUT tab are two different things.
You are generating 3D LUT’s without any 1D LUT measurments.
So make sure under calibration tab set speed to whatever you want. This will take extra measurement time but you’ll get 1D LUT measurements. So that the gamma setting under the 3D LUT tab has something to work with to incorporate a 1D LUT when you enable apply vcgt.
Just follow instructions above what I did. I haven’t tested with HDR because I don’t have a good HDR display that can be accurately calibrated but try it to see how it goes. Don’t forget to generate a new source colorspace with your new alternate White Point for lut creation.
However, I am a video technology specialist who mainly works on HDR grading such as UHD BD.
If you are interested, please watch my work, Robot Carnival UHD BD.
I was in charge of HDR grading.
From the point of view of specializing in video technology, I place importance to provide calibrated output for each monitor on Windows in HDR mode (ST2084/REC.2020).Which matches requierent number 1 or 2 and 3… it seems a work were a LUT3D will be useful.
I am aware that ICC functions in the color management of apps under the OS, but as I may mentioned, I think that everything handled as SDR should be output as sRGB.
That is false. Counterexamples:
A ProphotoRGB TIFF is SDR (TRC is “relative” to max brioghtness and not absolute as HDR) and should be handled according to display native gamut capabilities.
Same for eciRGBv2 image. Same for DisplayP3 HTML content. Same for whatever MelissaRGB variant used as working colorspace in my brand new RAW phoro camera software.Your statement is true only if content is sRGB and color management is not possible, and it is true for games for example. It’s false for everything else.
In other words, all monitors should be set to sRGB as ICC, monitors should be sRGB, SDR should be sRGB for computers, and REC.709 (including BT.1886 with different gamma values) for video.
Again, NO, that is false and a stupid way decision for the reasons explained above and in last part of my last message.
IDEALLY with reliable desktop color management monitor must be set/calibrated to NATIVE GAMUT, your desired whitepoint ant native gamma (or the one closest to most common content).
With imperfect color management at desktop level most people that own a widegamut monitor can “suffer” desktop wallpaper oversaturation (if user is so lazy to do not reencode it) as long as we use color managed applications:
-madVR
-Firefox, Edge
-Adobe suite
-almost all image editors to some extentAND use a sRGB-like calibration (software or HW, a LUT3D or a lut-matrix) for non color managed applications where you need to see things as intended, like games.
Whether or not Photoshop outputs AdobeRGB cannot be the subject of this effort, and in addition, I think that AdobeRGB is no longer important for still images.
From my actually dealt with HDR (ST2084/REC.2020), I think ICC, which does not define the display color space itself and depends on the production monitor, has been a source of confusion for a long time.No, it does not ok that way. It is a confusion for people who do not know how this stuff works.
Display is calibrated to native gamut, desired white, neutral grey. Measure how display behaves calibrated that way. Create an ICC profile with such description.
Now your display can show ALL content that fits in gamut from whatever source colorspace of your choice… which is not ONLY ONE (OR TWO) like in video but a miriad. Same for printing.I believe that it is preferable to use HDR (ST2084/REC.2020), which defines the huge color space impossible to display, as a standard.
No, that will be stupid because HDR defined that way is an ABSOLUTE brightness frame with all in gamut SDR content fixed to a max brightness.
It works as a container for SDR Rec709 video ~100nit, but it won’t work for all the other SDR content, like matching a print or playing a game at whatever ambient light level i wish to be.Outside of grading Rec709, SDR is brightness relative. I set the brightness to whatever I want. That way TRC is brightness relative, not absolute like in ST2084 and cannot be other way because it won’t fit user’s needs.
What you ask will make displays useless for everything that is not HDR content.I think MS seems in a stray state on Windows colour management in HDR mode (ST2084/REC.2020).
However, basically it is assumed that the output destination for HDR completely satisfies ST2084/REC.2020 (in other words, how it is displayed depends entirely on the monitor), and the SDR delivered as sRGB (80cd/m2) in the HDR(2084/2020) container.
This management is very appropriate and correct when viewed as a CMS.
(I know it frustrates people who are used to unmanaged, strange and gaudy SDR output.)
In the future, I think the app should support HDR (ST2084/REC.2020) and handle areas outside of sRGB.Win11 future colormanagement seems a hit & miss too, there was a thread about it
I don’t think the currently available ICCs are capable of fully managed saturation maps and excellent 1D corrections like a 65-point 3D LUT.
That’s false.
A 65x65x65 lut can correct grayscale with… 65 points. Other levels are interpolated.
VCGT in a display profile has 256 entry 1DLUT. 256>>>65. It’s 4x more
Argyll can measure up to 96 point grayscale and interpolate 256 correction to VCGT from that data.
When you create a LUT3D that transforms one colorspace to another and choose to add VCGT it gets reduced to 65 entry. If you do not add VCGT the 256/1024 entry TRC in ICC profile will be reduced to 65 points too.Another issue is that some GPUs cannot handle 16bit correction per entry properly (256 input -> 256 output with 256 “decimals”), causing truncation and leaving bands. That will happen on a LUT3D too and in an uglier way.
Dithering solves the banding.
Ledoge’s DWMLUT uses dithering runing on GPU Shaders, hence all GPUs can handle it. That’s cool, thats why we love DWMLUT and you can use it like in my linearization of a widegamut example in my last message, the last paragraphs.
Some GPU vendors have no dithering for VCGT, hence it is HW dependent, it will show smooth in AMD GPUs (since 2005?) but may show bands in others manufacturers.As I mentioned earlier, I don’t know of any ICC that can do that.
All of them.
VCGT & TRC tags in display profles
As you may be aware, in the display of HDR (ST2084/REC.2020), out-of-gamut and over-luminance are mapped on the monitor side, so it is impossible to calibrate simply by setting a simple vertex or 1D LUT, and without strict remapping by 3D LUT, the saturation correction and EOTF optimization in HDR shown here would not be possible.
My flow uses a 3D LUT for a certain system (sRGB/HDR (st2084/2020)) that the output device assumes.), it is a simulation of responding hardware calibration, like a Lightillusion suggestion
In other words, the DWM LUT is used as an external LUT BOX or as a simulation of LUT calibration function of professional monitors that support hardware calibration on HDR.In the example shown here, Windows assumes that the monitor supports HDR (st2084/rec.2020) and outputs the video signal, and the monitor reproduces it as a light as much as possible.
In this reproduction, the current situation is that mapping including inappropriate ones is applied for each monitor, and as a result, appropriate display cannot be obtained on many monitors and televisions.
To compensate for this problem, I need to disable monitor mapping (which of course, saturates outside the performance cap) and then do proper mapping as needed.IDNK of a monitor that allows HDR backlight “ON” and internal mapping from Rec2020 input to panel gamut “OFF”.
Most of them keep the internal mapping ON hence making more dificult to make the LUT3D for that OSD mode.
Such lut3D is actually REc2020 -> (Monitor’s internal rec2020 -> panel native). It’s like correcting a “white box” that you know that has another chain of transformations inside them.This requires DWM LUT, 3D LUT calibration with an external LUT BOX or monitor’s 3D LUT, but as I mentioned earlier, I do not know any ICC system that supports such 3D LUT correction.
For HDR it does not, since TRC in ICCs are brigtness relative, not referenced to an asbolute frame like st2084.
You need to provide device white level to map ICC TRC to st2084 like DisplayCAL does… if you know how to use it.When using DispCal, it was impossible to handle HDR (ST2084) in a system that relied on ICC.
It does (otherwise we can’t be able to create HDR LUT3D and we do) but you need to provide reference brightness for display ICC profile.
I think that all your misconceptions about calibration, HDR, SDR and ICC comes from this point. Let’s clarify it:
ST2084 is absolute
ICC is relative to whatever you want to set as white levelHence to make an HDR LUT3D you’ll need to provide device brightness so you can map display brihtness relative TRC & 3d mesh colorspace in an absolute way (brightness) and then map it to ST2084 & Rec2020 and compute transformation.
DisplayCAL LUT3D creator works that way, including the feature of puting a “fake” brightness so resulting calibration matchs ST2084 to X nit then “bend” response to provide something like perceptual rendering intent till some clipping value. That way you can consume (not grade) HDR content in a display that cannot go beyond some arbitrary nit value.
You can choose another path which is the most common and recomended for madVR: map display colorspace (ICC with relative TRC) to non SDR (relative too) Rec2020, hence brightness relative.
Then let madVR handle the scaling from Rec2020 at your display max white level to reference max white level in content.Surely, this is not the case with the latest other systems. (sorry for the repetition) but unfortunately i don’t know that.
I have posted all the steps and required files.
If you say that ICC can do same or better, please show me the detailed method and the result of HDR calibration on WIndows HDR mode, I want to try it.For Windows HDR mode or any other system ICC aware you’ll need to provide display brightness to provide the mapping. = You need to provide actual white level of display so you have absolute coordinates and with them you can try tio match to absolute brightness st2084/Rec2020
IDNK if WIndows HDR mode has such parameter, I do not use it.The important point is that as a result of measuring HDR (ST2084/REC.2020) using madTPG and DispCal from the settings for madVR, sufficient accuracy was not obtained with DisplayCal alone (4400 points were measured), especially the monitor response in the low luminance range was very unnatural.
This was a fatal problem in this effort.This is because most monitors (all of them) cannot disable HDR mapping and keep HDR backlight on. As explained before you’ll be characerizing with an ICC a “chained” system. With 5000 patches you are characterizing behavior with a 17 point 3d mesh per edge… on an absolute scale from 0.X nit to Y nit.
Your lower part of st2084 (all SDR content embeded in HDR) is corrected from a few nodes.
That’s why some guys recommed the other way for madVR, LUT3D to rec2020 relative (SDR) then run HDR mapping on shaders based on user input of display white level.In this example, I need an additional 1D correction to fix this problem.
Yes, it may be wise to do what you did, but because you were trying to characterize a chained system with too few points in the lower end (Rec709 SDR range). However internal maping in display from rec2020 input to panel native capabilities may hold a LUT3D-like mesh where high brightness high saturation colors behave in a diferent way and applying a LUT1D you are breaking it.
Here’s my verification with the method I explained above in SDR Rec.709, 2.4 gamma.
Display is a Sony A95K
Probes I used are Jeti 1501 & i1 Display Pro
I verified in DisplayCal and HCFR. And it’s all spot on accurate.
Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.I think you need for high-resolution spectroradiometer is particularly pronounced for recent wide-gamut displays with sharp-angle spectra like a quantom-dot .
When I comes to Quantum Dot OLED you do need a Hi Res spectro for accurate measurement. When I compared the i1 Pro 2 & Jeti 1501 on a CRT they both measure nearly exactly the same. But when I compared them on a QD-OLED they both measure very differently. i1 Pro 2 is not accurate enough.
