I encountered a problem when generating a 1DLUT.
I have a monitor with a JOLED panel that has an inaccurate EOTF in HDR mode and cannot turn off the mapping to restore the native gamma 2.2.
I tried many combinations of LUT generation Settings, but none of them could handle such an EOTF correctly.I never had this problem..... when I started gamma2.2 before.
I will upload the .bcs file for troubleshooting.

HDR Mode RGB Balance	LUT Generation	HDR Mode EOTF
LUT verification	Attached file: 32Q1U_HDR Grayscale.zip

I select LUT for verification in "settings" - "active LUT"

Sorry - what is the issue?
Please describe - it's difficult to tell from the graphs alone.

Steve

You can look at the fourth picture. The rgb lines represent the grayscale response of the HDR mode of the display, and the white lines represent the target response.
May I ask how I should generate a LUT to make the grayscale response close to the standard pq(white line).

Sorry - I can see the result in the graph, but I have no idea what workflow you have used in the calibration.
Please be far more specific.

But, if the previous graph with the tone mapping is the profile, that will not work.
The tone mapping will cause issues when you try to map to a Clipped target, with no tone mapping.
You should get a better result if you make the target the same tone mapping.

Steve

Sorry. Let me describe my workflow and the goals I hope to achieve in detail.
I'm going to calibrate the HDR gray-scale tracking (1DLUT) of a JOLED monitor. The default HDR EOTF of this monitor is brighter than the PQ EOTF in the first half and darker than the PQ at 65% gray-scale. Moreover, it doesn't have a calibration mode, so it cannot be restored to gamma EOTF like the LG EP950. But the good thing is that JOLED is very stable and there is no dynamic mapping. Everything is static.
I used the method from the official website "Guides - Advanced Operation - PQ (ST2084) based HDR - Initial Power Law EOTF" for calibration. First, I collected the complete 256-point grayscale +RGB, totaling 259 points, and stored the profile. Then I used the slider to find the brightness of the target white point (0.3067, 0.318) at 512nits, modified the target white point (0.3067, 0.318) of the "ST2084 REC2020"Profile and set the "nits" to 490nits. Next, I entered LUT Generation, Select "limit luminance max 490", disabled color gamut mapping, and selected peak chroma. Finally, generate the LUT.
Before uploading, the verification result in ColourSpace was that neither RGB balance nor PQ tracking was good. I once did a mapping LUT from gamma2.2 to PQ, and it was almost perfect. My question is why CS cannot correct such an inaccurate HDR throughout the process, and whether there are any other operation methods that can improve the results.
thank you

If the graph "HDR Mode EOTF" is the profile being used for calibration, there is tone mapping active.

Steve

Yes, the display has tone mapping, but it's not dynamic. I think it can simply be called "inaccurate".
I attempted to perform the same work using the calman 1dlut workflow, and the result ran well. The luminance perfectly tracked the PQ, and the chromaticity was also aligned with the target white point. This is the 1dlut calculated by calman:
I hope colourspace can fix it or have a workflow for "inaccurate HDR"

Sorry - the Calman results look basically the same.
Their graphing can be less precise though, especially as it is not plotting the EOTF for RGB independently.
It also appears you have not used the same patch sets, so difficult to compare.
But you will need to define the best patch sets and overall workflow for a display that already has tone mapping active.
Dynamic tone mapping is not the issue.

Steve

I've now looked your profile....

A 256 step Grey Only profile is not going to work, as it is far beyond the valid size for a Quick Profile.
You can see that in the Library, as the profile is Saved as a 'Profile', not a 'Quick Profile'.

To give you an understanding, a 256 grey scale profile would require permuting to a Cube that is 16,777,216 in size...
(For info, every time you double the Grey Scale patch count you will increase the required processing/memory for LUT Generation by approx. 8x.)

The default maximum for a Quick Profile is 33, with an Env. Variable that can be user adjusted.
But going much beyond 33 will likely cause PC processing/memory issues.
(We will add a Warning Message when saving such profiles in the next ColourSpace update.)

So, you basically have far too many grey scale points for a valid 'Profile' to generate a LUT from, with only the three RGB patches.
(There are even issues in the Profile, as you have non monotonic readings - the patch value has gone up, but the measured value has gone down. That is not valid, so means something is 'iffy' with the display or the probe setup.)

You may be able to get such a profile to work IF you have more volumetric points.
But far better to use a profile with a grey scale patch count that is at or below the set Permuted Cube value.

Steve