- This topic has 78 replies, 4 voices, and was last updated 7 years ago by
.
-
Posts
-
I think that was a good move regardless of how things work out with this LUT. Not only does it have good dark readings and is respectable all around, but it’s one of the most heavily supported.
It might not be your meter though. I finally gave up on DisplayCAL for making an eecolor LUT for an OLED. I thought I had it working at one point but thenI kept finding one problem or another – always in the darks.
The sad thing is that it works better than CalMAN which I ended up using all-around. The calibration is PERFECT, better than I’ve gotten from CalMAN… except in the darks. It’s not the meter because CalMAN does fine in the darks, but like last time I tried there was all this weird banding if you look at a gradient pattern which eventually shows up in content.
I even went as far as to write code to fix up the generated LUT table before burning it to the eecolor and interpolate from no correction to whatever correction was in the file over a few percent. But that just wasn’t right in the darks, the CalMAN result was better.
I finally gave up on DisplayCAL for making an eecolor LUT for an OLED. I thought I had it working at one point but thenI kept finding one problem or another – always in the darks.
Argyll currently has problems if the device response has concave regions, i.e. where increasing R, G, or B does not increase luminance, but lower it – note that this should normally not happen on an additive device like a display, and my general feeling is that this is caused by bad internal color management of the LG OLED TVs (and possibly also to some extent ASBL). The solution is to fix the underlying device response, by resetting any color management controls exposed in the TV’s OSD to default values, and making sure to profile it in its true native gamut.
I finally gave up on DisplayCAL for making an eecolor LUT for an OLED. I thought I had it working at one point but thenI kept finding one problem or another – always in the darks.
Argyll currently has problems if the device response has concave regions, i.e. where increasing R, G, or B does not increase luminance, but lower it – note that this should normally not happen on an additive device like a display, and my general feeling is that this is caused by bad internal color management of the LG OLED TVs (and possibly also to some extent ASBL). The solution is to fix the underlying device response, by resetting any color management controls exposed in the TV’s OSD to default values, and making sure to profile it in its true native gamut.
Interesting. Do you have any suggestions on how to verify that it’s (probably) correct before doing the calibration?
I have no changes in the CMS. I think with Argyll I’ve only used gamma 2.4 (which measure about 2.3 or less) rather than the default 2.2 (which measure 2.1 or less).
Finally the postman arrived with my i1 Display pro. 🙂 I set up a quick profiling on my laptop to test the device and guess what? – Same reddish result as before on my projector. It comes in different levels with the icc loaded in kodi, the madvr-3dlut loaded in kodi and the calibration preview of displaycal (and kodi started afterwords).
OK, the laptop-screen is pretty bad anyway, but what is strange is that I get the same reddish picture as before.
Now what? Forget tje nice colors? Im a little out of ideas now.. Last thing I can do is try with the projector and prey for it to work.
Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.I – I – got no answer if you’re asking me. I recalibrated the monitor I’m using right now this morning with i1Display and displayCal and it’s lovely.
Let me ask you this: Does reality appear to have a reddish hue in the darks? Just sayin’ if it does then it could be your eyeballs.
It is very visible using the AVSHD test videos “black clipping” and “white clipping”. In both of them I can see the blinking parts are reddish. It appears to be stronger with the black clipping video. Turning the icc or lut off the reddish tone is gone.
Well, I will try this tomorrow (actually tonight) with the projector and see what comes out. It really might be an issue of its own with the laptop-screen that shows a similar effect for different reasons.
Ran profiling with the new meter on the projector last night, and it is simply MUCH BETTER!
The red coloration in the dark area is gone. Strangely it is still there in the very bright areas, visible with the “white clipping” testchart from AVSHD. Watching a movie though, I cannot see anything indicating something wrong, so that is ok for now.
The meter is way faster than the spider, so I can take measurements now and check the results right away.
Black levels are pretty much where they should be, the black clipping chart gives me distinguishable flashing bars down to 18 or so. The bars in the white clipping chart though flash all the way up to 254. The notice below the image reads “Adjust contrast, so bars up until 235 or above flash”. I know the testchart contains levels from 0 to 255, but shouldn’t the LUT adjust it, so that 235 and above equals white (255)? Regular video should never contain anything that bright. Not sure what to make of it.
Great, now I can get my hands dirty with this equipment. Measuring my screen is a demanding task, since it is of the retroflective kind – Dalite model C high-power. These come with a high gain leading to very vivid images at the cost of discoloration introduced by the varying viewing angle across the screen. While practically no problem when viewing movies (execpt for desert scenes 😉 ) throwing uniform test patterns at it makes the effect clearly visible. Setting up the meter is challenging, since it can not simply be set close to the screen pointing upwards, but ideally should sit right in the incoming light-beam, which would lead to a shadow. I found out that these meters have a rather small opening angle for the incoming light and set it up nearly at my seating position. Still, pointing it a few centimeters more here or there leads to changes in the distribution of R, G and B, very nicely visible using the “Interactive display adjustment” of Displaycal. I went for a position where R, G and B would be distributed evenly, since the projector itself was adjusted to give me neutral looking images, beforehand.
The result is stunning. While the projector/screen combination was impressive before, especially in the darker areas, it now really blows you away! 🙂 I watched a very dark scene, only illuminated by red lights and could not believe the vividness and detail one can see now. Viewing that scene on my notebook shows me a black screen with some movement, haha.
I made a second measurement with the meter pointing slightly elsewhere, and the outcome was noticeably different. It will take some time, measurements and comparison to make the best out of it. Of course it will never be “right”, due to the nature of the screen, but it is not intended for correctness, it is for watching movies.
Does anyone have any hints on what Displaycal switches I should give a try? I didn’t use any correction, I will try the “projector” correction soon, as well as the “-E” trick in combination with FULL RGB output on my graphics card.
Happy regards and a big Thank You to Florian Höch!
Interesting. Do you have any suggestions on how to verify that it’s (probably) correct before doing the calibration?
You could run a quick profile with a few hundred patches and view imagery through it (e.g. granger rainbow) to check for artifacts.
I set up a quick profiling on my laptop to test the device and guess what? – Same reddish result as before on my projector.
If you’re using white point “As measured” (or any target other than 0.3127 0.329), set 3D LUT rendering intent to “relative colorimetric” to keep the measured white and not correct it via the 3D LUT.
The bars in the white clipping chart though flash all the way up to 254. The notice below the image reads “Adjust contrast, so bars up until 235 or above flash”. I know the testchart contains levels from 0 to 255, but shouldn’t the LUT adjust it, so that 235 and above equals white (255)?
Has nothing to do with the LUT, madVR passes through WtW, but it’s not a concern really.
I will try the “projector” correction soon, as well as the “-E” trick in combination with FULL RGB output on my graphics card.
If you don’t mind waiting a day or two, I will make a DisplayCAL beta available that allows selecting the output levels in the UI, as well as automatic output level detection.
I meant to ask how I can verify that it’s not concave in response before calibration, but it doesn’t matter. I used the higher gamma and it worked!
I’ve become very hesitant to announce that, but I measured with Calman test grayscales, saturations, lum sweep, and their “color checker” – everything nicely in range (with the exception of a gamma “spike” at the bottom nothing can help). Visually ramps look great (slight banding in darks, but nothing like before and not colorful, and no worse than calman – probably better). Also checked known problematic content and saw no problems.
Since we were talking about issue in the dark it’s worth mentioning that the lum sweep showed great color accuracy in the dark. Most colors get a couple of DE off at the very darkest but I expect that and am not sure I’d be comfortable with trying to force them into place. Without calibration they’re all over the chart.
Just a side note, this was only ~1100 patches. I’ve noticed that Calman seems to tighten the accuracy the patches are used, but Argyll is just more likely to get banding and glitches. Weirdly on tests like the “color check” I see better results from the ~1100 patch DisplayCal LUT than a Calman ~3000 patch LUT (shrug).
This could be placebo, but I’ve always sworn the Argyll LUT is visibly better in content (other than the errors in the dark that were unacceptable but I have now worked around). It’s possible that Calman’s test is somehow more geared towards calibration test results – but I dunno. I think it’s possible. For example, the fleshtone colors in the color checker are not accurate with Calman unless I use 3-4K patches at least, the more I use the better it gets. Argyll shows it right in the box with just 1,100 patches.
BTW, I’ve always used DisplayCAL for my computer monitor calibrations. Since you mostly get complaints here let me say that I appreciate it very much, think it’s excellent, and am very thankful for it! In fact, after I click submit here I think I’ll go donate….
I meant to ask how I can verify that it’s not concave in response before calibration
Not really possible unless the underlying device response is so botched that artifacts show up even without any 3D LUT or adjustments in place. Other than that, you have no choice but to characterize the display and analyze the response.
Argyll allows for various compile time switches to generate diagnostic 3D meshes of the gamut, but unless you are firm with modifying and compiling C code, it’s not something I would burden you with.
But to give an example, this is the concave blue region in your TV’s response as shown by the Argyll diagnostics:
Just a side note, this was only ~1100 patches.
Not a surprise, if the underlying device response is not linear, reducing the number of patches increases interpolation and thus smoothness, and if the sampling is coarse enough, it may not even pick up on the problematic region.
I’ve noticed that Calman seems to tighten the accuracy the patches are used
That is true for any profiler – accuracy gets tighter as number of patches go up, until you hit the point of diminishing returns.
but Argyll is just more likely to get banding and glitches.
But only if the underlying display response is not very linear, because with higher patch count, any problematic areas will be characterized with more detail and thus be more visible to the profiler. I can run 5K profiling patches and higher on my LCD TV because it reacts linearly to the input signal (increasing RGB leads to increasing luminance of the displayed pixel), as is usually the case.
The workaround in any case is to just use Argyll 1.8.3 for problematic devices, because that smooths more.
the workaround in any case is to just use Argyll 1.8.3 for problematic devices, because that smooths more.
Oh I did. Otherwise you get the purple blotches as the other guy here experienced as well.
Look under displaycal.net and find the “contribute” button..
Meanwhile I am measuring and measuring, always a little red left, getting better, though..
Of course I would “wait” for a version with the announced features! 🙂
WIll measure more and report again…
