- This topic has 14 replies, 2 voices, and was last updated 6 years, 9 months ago by
.
-
Posts
-
Hi Florian, how can I modify or create the displaycal testchart to improve the grayscale result in creating a 3dlut with resolve? I have a monitor that using the testchart auto gets good results on all patches except on the grayscale 🙁
Sorry if I ask again, does anyone know a way to modify the test chart in order to get the best results on the grayscale? I would like to focus reading on the patches involved in the grayscale without having to repeat each time thousands of points readings correct the colors (which are already fine).
In the documentation I did not understand how to proceed.Sorry if I ask again, does anyone know a way to modify the test chart in order to get the best results on the grayscale?
Whatever the problem is you’re having, this approach would be very unlikely to improve the situation. You’d be better off figuring out why you do not get the results you expect (e.g. is it the instrument/display stability/repeatability?). The nature of the problem is also not clear because you didn’t provide any details, making it hard for anyone to help you remotely.
Sorry Florian, you’re right. I attached my profile to show you the results I get specifically. As you can see the values of the various colors are good while the ones in the gray scale are much higher and I do not understand the reason. That’s why I was wondering if there was a way to improve them.
Infact, when in the report enabled the evaluation criterion “RGB + gray balance” the result is negative and always higher than 2 🙁As you can see the values of the various colors are good while the ones in the gray scale are much higher and I do not understand the reason. That’s why I was wondering if there was a way to improve them.
I can see from the report that device link profile (= 3D LUT) wasn’t enabled, enable this and “Use simulation profile as target”. Note that I wouldn’t recommend 3D LUT resulutions with even numbers (i.e. 16^3, 24^3, 32^3, 64^3) as neutral values will never fall on a cLUT grid point with these resolutions and will always be interpolated. Use 65^3 for best accuracy.
Dear Florian,
I forgot to notice you about that on the attached results, the function device link was disable because the 3d lut realized by displaycal (resolve but output and input encoding 16-235 is correct?) is exported and converted to be loaded inner the monitor odyssey 7q. So, the results to be valuted are based on a 3d lut even if on the report you cannot see it.
Concerning it, I would notice you I tried to change the profile exporting the 3d lut in different dimensions (from 17 to 65x) obtening very different results.
Strangely the 3d lut 65x are not always the best, maybe because odyssey accepts lut with max. 17x, so maybe the program I use to convert (CD3dLUTConverter_v1.3) could determinate some different informations.
However, the only thing common between the use of several dimensions lut, is the bad result obtained on the grey scale.
So, my question is the same. Why it happen?the 3d lut realized by displaycal (resolve but output and input encoding 16-235 is correct?) is exported and converted to be loaded inner the monitor odyssey 7q. So, the results to be valuted are based on a 3d lut even if on the report you cannot see it.
In that case, I would disable the 3D LUT inside the monitor and verify using the device link through Resolve.
I have attached the results of 3dlut made with over 4000 points and finalized with both dimensions of 17x and 65x. I then checked with device link and then without, ie converting luts and then uploading them internally to the monitor.
As you can see the results with or without device links are very similar, I do not think the results 65x are better than those of the 17x
But the real problem is always the result of rgb gray balance compared to the values I get on the colors.
Why are not they just as good?In terms of de grayscale values are not high? When I expanding the rgb grig balance sum the value is greater than 2 and is marked in red, i do not seem good at all
Hi Florian, contrary to what I said, I realized that the results between the lut read through the device link and the same convert to be loaded inside the monitor are very different.
I attach both reports to a 65x lut to show you how the result is degraded when converted.
However, I do not understand what to impute the loss of precision or quality.
Perhaps it is just a hardware limit of how my monitor processes the luts? or the problem is related to something wrong with setting displaycal?
Maybe my settings are wrong? Can you tell me from the screenshots of my settings if there is something wrong? I use resolve as pattern generator but then export the lut for upload to the monitor.Thanks
I attach both reports to a 65x lut to show you how the result is degraded when converted. However, I do not understand what to impute the loss of precision or quality.
When using the internal LUT, I wouldn’t downconvert. Use the natural resolution of the device (17x17x17) directly.
Can you tell me from the screenshots of my settings if there is something wrong?
Looks fine, although black level drift is unnecessary for colorimeters.
Florian, thank you for all the answers. I would like to ask you again if you can indicate a way to modify the testchart in order to narrow down the patches involved in improving the gray scale.
I would like to test by varying the contrast and brightness of the monitor without using the auto testchart of at least 1553 patches, but only a custom testchart to test the outcome on the gray scale.Florian, thank you for all the answers. I would like to ask you again if you can indicate a way to modify the testchart in order to narrow down the patches involved in improving the gray scale.
You can’t know what combination of RGB produces achromatic color unless you have a dense enough sampling around the actual gray axis, and this is exactly what the “Auto” patch generation does for you (equal RGB does not necessarily produce a neutral result on any given display device).
You can probably safely reduce the number of auto-generated patches to 425 and still have the benefit of actually establishing what “gray” is in the process.
