- This topic has 40 replies, 3 voices, and was last updated 2 years, 8 months ago by
.
-
Posts
-
These is double issue, b* “coolness” of white and a* “not actually white”. It’s Asus software fault.
About Asus’s calibration software and hardware chip, would I even need a Photoshop correction if the monitor (being the last piece of the pipeline) makes all the corrections? Actually, I just realized that I have no idea if it’s a 1DLUT or a 3DLUT that it makes, and either way, without an associating icm to attach to a file, how the heck do I make sure it prints correctly at the place I get my work printed at!? The only thing I can think to do is calibrate it to exactly AdobeRGB 1998 and include that file in the photo.
You do not need a “photoshop correction”. You need a display profile (a decription about how display behaves). Mandatory.
With a display profile with your current calibration images show as intented… but relative to your white (cool not actually white).
You can solve this applying a grey calibration on GPU on top of your HW cal. White is just the brightnest of greys. Side effect: banding (depending on GPU vendor & connection) and loose some contrast. Contrast is fine, you should be able to keep >850:1.
If white seems fine to you, do nothing.With Displaycal profile only you’re done.If asus calibration is fast you can try to figure some “offset” in x & y white coordinates so results are closer to D65. Trial & error.
Also for direct print copy (under normalized light) comparison to display images warmer whitepoints taht D65 are more common. YMMV. Daylight 5000K (D50) or 5500K daylight are some common starts (+- minor tweaks till actual match if you do not use or cannot trust printer profile whitepoint simulation in Photoshop or other tools)
I can force Asus’s software to calibrate to 6500K, 2.2 and set the brightness and colour space. Such as AdobeRGB, sRGB, DCI-P3, etc, but I’m not sure how it’s changing (or if it’s changing) the RGB values from their default to do it.
Hopefully last question.
What do you make of the image in the first post that shows that when the Asus uniformity compensation crashed, it left a visible area where the brightness was different? Asus says this thing only has 16 brightness zones, but if that’s true, how could the program do this?
BTW I looked at the uniformity file from DisplayCal, and here is a screenshot of the page with the only other option in the centre drop down menu.
Thanks
UC is not correctable by GPU LUTs, hence Asus software is all you have and acts like a black box. Whatever weirdness is produced by Creatour Hub… I cannot help.
C:\Program Files\WindowsApps\********.ProArtCreatorCenter_1.0.21.0_x64__****\
i1d3SupportFiles
16/01/2021 19:53 43.868 CCFLFamily_07Feb11.edr
16/01/2021 19:53 12.456 OLEDFamily_20Jul12.edr
16/01/2021 19:53 48.024 PFS_Phosphor_Family_31Jan17.edr
16/01/2021 19:53 12.456 PlasmaFamily_20Jul12.edr
16/01/2021 19:53 39.068 ProjectorFamily_07Feb11.edr
16/01/2021 19:53 30.412 RGBLEDFamily_07Feb11.edr
16/01/2021 19:53 59.880 RG_Phosphor_Family_25Jul12.edr
16/01/2021 19:53 30.412 WGCCFLFamily_07Feb11.edr
16/01/2021 19:53 43.868 WLEDFamily_07Feb11.edrBold row is a worse than HP Z24x G2 bundled (or at least in the past) in Lightscape software. It has a mix of several PFS displays, nome of them with a naitive gamut like yours. Some have green primary “cut” like only 95% gaming displays, others with red cut to AdobeRGB.
Anyway in an i1d3 very close to std observer 2 degree… readings should be close in primaries.
It should be bundled with i1d3 corrections for DIsplayCAL PFS_Phosphor_Family_31Jan17.ccss. You can plot it since it’s text, also you can plot it with Argyll/DIsplaYCAL, although it may be easier to split in groups of 4 so you can see displays samples separatedly.
Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.OK
I’ll try to do this short and sweet, but also have some more info that may or may not help.
When I first got the odd readings, I contacted X-Rite and ended up speaking to someone there that is… well the first CSR called him “The” guru of colour science. I guess he even writes some of the blogs that are there.
While talking to him about the white point being pretty far off for factory calibrated and him telling me that the chances that this is a sensor error are almost nil, we got to adjusting the kelvin to 6500K. He said something that took me by surprise. He said to not adjust the RGB values in the monitor, because usually monitors aren’t actually changing the actual signal (maybe from a physical sense) but instead they have software that tells the monitor to mimic less or more of a colour.
I’m not sure if Asus’s monitors do that, but I’m guessing the answer is yes.
What I was trying to find out with that first image on the first page of the partly completed display uniformity is if there was any way to tell if the change is an actual change in the backlight panel, or if it’s software mimicking a change by changing the pixels colour?
I used all the tricks in my camera bag to get 2 photos close enough to see the RGB on each pixel in the brighter and darker areas and the camera does read a drop in light, but that could be from the pixel being darker in colour and that changing the amount of light that gets through. I don’t know.
If you think you can make sense of that, I do have the photos and the RGB and Lum histograms for both photos.
On the same note, here is a photo I took with a totally dark grey screen with nothing else on it. W….T….H…?
I’d show you the 9×9 uniformity test I did, but I don’t think you need it. lol
In the end I’m now talking to some manager in Asus’s tech department about all of this, including the glaring gaps in their software, not that I expect it to change much. I actually asked them why they don’t release their SDK when other companies that sell “Pro” monitors do. We’ll see what answer I get for that. lol
Last thing I wanted to tellyou was something else I found out. The calibrations through their software, always have high DE’s in the red and green channels while the grey and blues are fine. Just because you mentioned the red looked like an sRGB red, I did a calibration in sRGB mode and the monitor didn’t have a single DE over 1. Most were .6 or so. In AdobeRGB the red and greens have DE’s of 4 or more.
I asked them about that too, but if you have an answer to why this is, I’d love to hear it before I hear whatever they tell me.
Because of the odd screen uniformity issue after the program crashed, I learned that the screen uniformity change is applied to both of the 2 custom calibration slots the monitor has. It shares the same uniformity on both, and making a new profile that doesn’t ask to change the uniformity, doesn’t reset the one that has the error. This means the uniformity is saved completely separately from the actual display calibration data.
I’m thinking of using this knowledge to try a screen uniformity at 5×5 (the highest you can do) and purposely crashing the program before we get the the calibration part. If it works, and it doesn’t destroy the DE’s in the spots it corrected, I should be able to use DisplayCal for the calibration and Asus for the uniformity. If it works right. lol
I posted all of this, both to hear if you have any thoughts Vincent, and to have it down in case anyone else comes here with this monitor.
DM
While talking to him about the white point being pretty far off for factory calibrated and him telling me that the chances that this is a sensor error are almost nil, we got to adjusting the kelvin to 6500K. He said something that took me by surprise. He said to not adjust the RGB values in the monitor, because usually monitors aren’t actually changing the actual signal (maybe from a physical sense) but instead they have software that tells the monitor to mimic less or more of a colour.
The “gain” control on backlight panel tech (LED, CCFL) acts on panel occlusion. I does not change spectral power distribution (SPD) of backlight, just “darkens” it, SPD height is lowered. It’s like sending for 255 input other lower value like 248.
If you do not act on OSD, white has to be corrected on GPU…which is going do the same: altering input signal to monitor which translates to the same lowered signal to panel.
White has to be modified on gain OSD or display internal luts (which in the end translates to modifying panel input RGB number), otherwise you do not make use of the potential dithering features of display and may end with banding.
If modifying RGB gain controls on OSD causes issues is because monitor and its electronics are a pile of trash. Anything else is a poor excuse.It’s a very weird way of explaning it from Xrite, but as everybody knows (or should know) all colors that a RGB display can render are a combination of native gamut at native white, where each color (including alternative white points) are just a combination of three RGB values feed to panel that acts on its backlight occlusion.
(Thats the very reason CCSS correction neeed to be at native gamut although white point on SPD does not matter since its just a “spectral gain” value)What I was trying to find out with that first image on the first page of the partly completed display uniformity is if there was any way to tell if the change is an actual change in the backlight panel, or if it’s software mimicking a change by changing the pixels colour?
Uniformity compensation acts on pixel RGB input values of panel. Or several pixels on a zone. If a zone has a native white too red and another is too green compared to center:
-red zone lower max input at red (panel input acts as backlight occlusion)
-green zone the same… etc
-central zone (“reference white”) lower all its output to match the sidesThat’s the reason UC kills contrast. Black signal is still leaking light at fixed rate (IPS panel with finite native contrast) and white max ouput is lowered. So if quality control is non existent and certain vendor puts in their monitor lowcost trash you may end with ~500:1 after UC from native 1000:1
Some vendor may change LED backlight output too (per zone), but it does not change individual led SPD “shape”, just lowers or raises its height so they (all the leds) output the same light intensity (or overall brightness after crossing panel) but this should be done at factory. It’s part of QC
Last thing I wanted to tellyou was something else I found out. The calibrations through their software, always have high DE’s in the red and green channels while the grey and blues are fine.
Against what? It was discussed previously. Set a target in Asus software. Calibrate. Validate results against THAT PARTICULAR TARGET YOU SET in displaycal.
OK? congratulations
BAD? It is actually bad. Period.Just because you mentioned the red looked like an sRGB red, I did a calibration in sRGB mode and the monitor didn’t have a single DE over 1. Most were .6 or so. In AdobeRGB the red and greens have DE’s of 4 or more.
AdobeRGB & sRGB CIE xy red coords are the same, just google it. I think you did not understood what I wrote, or maybe i did not explain it properly.
Anyway as said previously whatever Asus report says does not matter. If you calibrate to an AdobeRGB target in asus, then validate in displaycal with AdobeRGB as simulation profile and use simulation profile as display profile. OK? OK! Bad? it is actually bad.
Same using no simulation profile and validating resulting ICC computed by Asus (or Dell, or Benq or LG), if it actually exists.I asked them about that too, but if you have an answer to why this is, I’d love to hear it before I hear whatever they tell me.
I wrote it days ago. It is pointless to repeat it again but again: previous paragraph
Because of the odd screen uniformity issue after the program crashed, I learned that the screen uniformity change is applied to both of the 2 custom calibration slots the monitor has. It shares the same uniformity on both, and making a new profile that doesn’t ask to change the uniformity, doesn’t reset the one that has the error. This means the uniformity is saved completely separately from the actual display calibration data.
Makes sense. It has nothing to do with your desired white and gamut simulation. It’s making panel behave as it should be: uniform.
Hey, just an update.
Luckily, it’s good news! Asus is giving me a refund! I may never buy an Asus monitor, or at least, not until they take the pro monitor market seriously, but I got to hand it to there customer service. I’ll still look at Asus hardware, just not monitors. 🙂
So, Vincent, if you’ve dared to open this thread, I wanted to tell you that you were pretty much spot on for… well, everything.
Their uniformity is just RGB, as you said. They do have some segmentation of their back light, which I did know before hand, but only 16, with 8 along the top, and 8 at the bottom. Not nearly enough to really use their HDR, which really relies on the dynamic contrast.
Their response to the regular uniformity? It’s a known issue with the technology.
So, I need to get me an Eizo, and honestly, I can see why they can demand top dollar. 🙂
I actually think I will go back to UHD. While I liked the screen space, 4K at 32″ needs 150% DPI in Windows, which can create problems. I don’t think I used any DPI scaling with my PG279Q, which was UHD. Also, as a photographer, I don’t really need 4K to do my job. A 2nd monitor would probably suit me better. I doubt Eizo has any ultra-wide UHD monitors, but I could be wrong. Content creation takes up a lot of room. 🙂
If I do decide to look at NEC, which I think is the other one you mentioned, below Eizo but good, what would you recommend at the UHD 27″ range? I don’t think UHD would look good at 32″, unfortunately. 🙂
Thanks again to Vincent, whether he chooses to venture into hell one last time or not, and anyone who can offer some help!
DM
If I do decide to look at NEC, which I think is the other one you mentioned, below Eizo but good, what would you recommend at the UHD 27″ range? I don’t think UHD would look good at 32″, unfortunately.
sRGB or widegamut?
Widegamut ther is only one, CS2740. very good but a slightly subpar contrast ~800:1 calibrated to D65. See reviews. Compensation for colorimeter off in CN.
In sRGB you have the EA271U (maybe older model EA275UHD on a bargain in some store) series in NEC, although they are slightly bigger than sRGB, but there is an sRGB mode. HW calibration for grey if you pay SV2 software, compatible with i1displaypro.
Honestly, I don’t know anymore… I will be going Nvidia simply because they’re 2nd gen raytracing is quite a bit better then AMD’s first attempt, and I do do some 3D modeling as well.
That said, I know Nvidia doesn’t like dithering… Why Nvidia? Why? lol
I will say that, obviously, it takes more horsepower to output 10bit, but does it really matter if it’s a “true” 10bit monitor if it has built in 8bit + FRC? I don’t know anymore…
Oh, one more thing. I remember reading a post where you said you had a fix for a monitor showing only 1/4 of the screen, in the top left, when it comes off of a screensaver, and some other times. I thought I had subscribed to it, but apparently not. My PA329C does it, and while I’ll be sending it back, I’d like to know in case I run into the same problem in the future.
Thanks,
DM
10bit output from GPU is NOT for the purposes you think. It is irrelevant to actual bitdepth in panel. It has been discussed many times. It’s just to avoid undithered truncation ON SOME APPS (and only a few).
So, would you say that an 8bit + FRC would be more or less as good as 10bit in most situations? I’m not working for National Geographic or anything… lol
DM
Any thoughts on 10bit vs 8bit + FRC? They want this monitor back so I need to make a call on a new one asap. lol
Sorry, but I don’t trust the help from other places nearly as much as I trust it here. 🙂
DM
It’s a SDR display (even ifthey accept HDR signal they are SDR) => Constast will be between 600:1 on a cr*ppy Benq SW-C to 1500:1 in one of those new CG Eizos
Hence 8+FRC vs 10bit AT PANEL is a pointess discussion. It does not matter at all.
I would like to use native gamut for editing in ProPhoto RGB, so i have o more wider playground for colors in phtoshop, but there is no target for it in ASUS Creator Hub like in EIZO software. So i was thinking i will just use Standart mode in OSD and i will make a ICC profile.
In new version ProArtCreatorCenter_1.1.20.0, i found “20201016_KFS_Phosphor.edr” can i use it for correction in displaycal? and it´s better than “PFS_Phosphor_Family_31Jan17” or “HP Z24x G2 WLED PFS WLED PFS AdobeRGB+P3 flavor” ?
