- This topic has 10 replies, 4 voices, and was last updated 1 year, 8 months ago by
.
-
Posts
-
Hi everyone, I would like to share my experience of calibrating Benq SW240 using PME with modified EDR file (merged from HP_DreamColor_Z24x_NewPanel.edr) and DisplayCal on top of that HW calibration.
So this is what i found out in the process of calibration with Benq PME:
- PME will accept HP_DreamColor_Z24x_NewPanel.edr (just renaming the file to RGBLEDFamily_07Feb11.edr in your device folder in Program Files (x86)\BENQ\PaletteMaster\Resources\Instruments\) – BUT – with this EDR file calibration accuracy and repeatability are very low – I did several dozens of calibrations and ALWAYS got poor relults – even sometimes PME reported fail of calibration check (high delta E).
- This led me to modify existing RGBLEDFamily_07Feb11.edr – HP EDR has less fields and data sets: 351 vs 402 and 4 vs 8 data sets. So I converted both EDRs to CCSS and moved HP fields to original Benq EDR but adding more field with 0.0000 to match overal number of 402. I did not modify any headers, just the fields data. I also doubled the sets to 8 with the same data to match original file. Then I converted custom ccss to edr.
- I replaced the file again, PME also accepted it and this time calibration results got much better – I got good profile on my second try.
- It seems PME only accepts EDRs with 1nm measurements – I tried my own 3.3 EDR from Colormunki Photo – if you convert it to EDR and replace original file PME just reports colorimeter is not connected.
- You should repeat PME calibration several time to get acceptable results – number of patches is not enough to get consistent results.
Here I attach my calibration results and uniformity test:
- just PME calibration – native gamut D65 L75 and L100 G2.2
- PME+DisplayCal profile on top – native gamut D65 L75 and L100 G2.2
- Uniformity tests for L75 and L100 profiles
Personally I think the results are OK for the price of this monitor – where I live closest alternative Eizo CS2420 is twice the price of Benq.
So what do you think about these results? Should I keep the monitor or return it back?
Calibrite ColorChecker Studio on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.1 & 2: Usually when the EDR is not loaded Xrite SDK uses std CMF (aka “No correction”) => it uses as CCSS/EDR the colorimeter curves like if they were a sample display. With this hint you can test if EDR replacement/forging is working.
Regarding a* shifts in greyscale in PME-Only-L100-Measurement-Report-3.8.9.3 and the resulting unwanted high a*b*/grey range you may want to test DWMLUT as as way to get HW like calibration (dithered bandless). These errors are not EDR related but related to hardware QC: you need to take more measuremenst to fully describe uncalibrated display behavior so it can be corrected in these displays with lower QC.
Anyway: do a test in MS paint (non color managed ) with lagom LCD gradient PNG, if that 1.6 grey range (report) looks visially good you are done. If you think it should be improved and traditional 1D grey calibration in GPU with DisplayCAL prodices banding in your GPU, try DWMLUT since it will remove it (dither).
Native gamut HW-like calibration is obtanied using as source colorspace an ideal description of your display rated with synth profile editor (put custom profile primaries, desired white and desired gamma) then as dstination profile the customprofile you made with DisplayCAL, embed VCGT calibration and use as display profile in OS the ideal profile used as source colorspace. => Smooth gradients like if you had HW calibration even on intel iGPUs.Native gamut HW-like calibration is obtanied using as source colorspace an ideal description of your display rated with synth profile editor (put custom profile primaries, desired white and desired gamma) then as dstination profile the customprofile you made with DisplayCAL, embed VCGT calibration and use as display profile in OS the ideal profile used as source colorspace. => Smooth gradients like if you had HW calibration even on intel iGPU
Thanks for you reply, Vincent. It is interesting – so should I use Illuminant-relative XYZ from profile generated by PME to create an ideal icc? And when creating 3D LUT should I leave Gamma 2.2 and black output offset 100% enabled or do I need to set to unmodified?
Also, what do you think of uniformity test results of this unit?
Native gamut HW-like calibration is obtanied using as source colorspace an ideal description of your display rated with synth profile editor (put custom profile primaries, desired white and desired gamma) then as dstination profile the customprofile you made with DisplayCAL, embed VCGT calibration and use as display profile in OS the ideal profile used as source colorspace. => Smooth gradients like if you had HW calibration even on intel iGPU
Thanks for you reply, Vincent. It is interesting – so should I use Illuminant-relative XYZ from profile generated by PME to create an ideal icc?
Yes
And when creating 3D LUT should I leave Gamma 2.2 and black output offset 100% enabled or do I need to set to unmodified?
You can create ideal icc to 2.2, then with same iCC try to generate several LUT3D using LUT3D creator config , or several ideal profiles and unmodified.
Also, what do you think of uniformity test results of this unit?
Expected (<3dC but corners), usable.
So I tried this method and it really improves a*b*/grey range compared to PME profile – thanks for your wisdom, Vincent.
But why do I get same Maximum ΔE*00 as in PME? DisplayCal profile shows better maximum values (1.53 vs 3.24), is it possible to improve Maximum ΔE*00 in DVM_LUT profile? Or is it just a measurement error.
I attached 3 measurements (ignore corrections name, it is modified HP data inside):
– PME icc
-DisplayCal icc (medium speed with 596 patches)
-DVM_LUT profile
A profile, a custom one, is justa description of display behavior, hence you can predict how display will behave upon some RGB input. Error in prediction results in dE in profile verification. Measurement report is just that, compare how profile predist display and actual behavior.
A LUT3D is just a crystalized “fixed” transformation between some ICC and another ICC and can be as accurate as you want. Put more nodes and more decimals and you’ll have it.
The error comes from the custom profile you use to predict display. It didn’t match display to that level error so resulting LUT3D carries the same inaccuracy.
Maybe a more detailed XYZLUT profile with more patches can capture behavir better, it’s a cube so 10x10x10 =1000 patches, 17x17x17= about 5000 patches!!! Find a sweet spot for your unit. If largest dE error is on some boundary near primary or near black maybe you can skip that and live with it as it is now.The error in PME HW calibration grey range comes from extremely simple description made by PME before computing HW calibration. A non ideal display may need more patches for accurate description.
When you make a custom profile with Argyll in slow or medium speed your are taking 48-96 grey (x4 = W + R+ G+B) measurements of uncalibrated ramp (and its correction) hence the non ideal behavior in your HW is capured with much detail, this results in an accurate 1D LUT in VCGT. But some GPU like intel iGPU, at least older ones, truncate that correction to 8bit without dither. This make an very accurate correction(VCGT) into a bumpy one (8bit undithered).
The trick in DWMLUT is to run that VCGT correction as part of LUT3D nodes (the diagonal, 65 in a 65x65x65) and then dither results. That’s the reason of no banding. And AMD card can do the same with 256 entries instead of 65 diagonal (from 65x65x65 cube) all dithered, but thats just 1D for grey, not full gamut correction, and all users do not have an AMD card, so DWMLUT is more generic and very good as long as grey ramp can be described by 65 points…. which is expected for all these IPS/VA monitors.Perhaps with 30 point ramp (x4) in PME grey range could be superb on that SW240, but AFAIK and regarding CALIBRATION PATCHES (not profiling) its a black box, non customizable.
Older Dell HW calibration software had same issues regarding grey range (10 patches x4) untill they moved to 20 pint grey ramp (x4) and still is not as good as Argyll on slow/medium. A simple lagom test in MS paint with you eyes is enough to see it.
A NEC Spectraview or an Eizo coloredge can run HW with 10-15 patches on grey ramp (x4) because out of the box display has am extremely good neutral grey (QC) so you actually just correct White point and gamma and all grey ramp moves with them without much drift.If these ***** from Dell or Benq or Asus or Viewsonic or LG opened configuration a little to add a custom patch set for CALIBRATION (not profiling) and since we know how to build/forge EDRs, those grey range issues can be erased… BUT at the cost of longer calibration time (more patches). I’m afraid that their PR department is more afraid of a youtube video showing a lengthly 30min full of calibration patches that to an actual measurement report as yours.
… but thanks to LeDoge/Dogelition we have DWMLUT, so to the hell with them 😀Edit: your error is in black boundary of one channel… you can see it in the listing. Do not care about it even with PME only HW cal. It’s more likely that you’ll notice a 1.5-6 rey grange working with B&W than such error in near black boundary.
Please i want to use one of your EDR modified in my SW240 benq. Can you post it here or send me ?
Thank You
If he cannot answer and PME is too picky, you’ll need to expand some WLED PFS (AdobeRGB green flavor, like HP Z24x CCSS bundled in displaycal) to cover the same wavelegths as RGBLED CCSS(the wrong one sed by Benq software)
After that there are several ways , from adding the same headers as RGB LED and reply the number of samples then converto EDR with CCSS2EDR python tool then file replace, to convert to EDR then open an hex exitor and replace + reply all binary samples from your newly generated EDR.Another option is to change in ini file one EDR filename with the good one, but if PME is too picky and tries to load data with hardcoded offset it won’t work. Same if you edit RGBLED EDR, remove binary samples, add the one from HP and change binary headers for size/wavelengths.
It is not as simple as with Eizo ColorNavigator RG_phosphor because wavelengths in sample are different.
So if you want to play safe is better to expand sample in text then EDR and since now you’ll have series of same length you can binary replace without modifiying headers.If your forged file is bad it may crash PME or make its Xrite SDK to fall to default CMF. This 2nd scenario can be verified with displaycal because this wrong behaviour will behave lile “no correction”.
Problems with Palette Master Element for Win 10, 11 – V1.3.18
The latest version (1.3.18 – 2022/08/31) of Palette Master Element Win 10, 11 causes problems on BenQ SW240.
I have updated from version 1.3.17. hoping to solve problems with spectral correction in the calibration, as the deepest blacks were tinted red.
Calibration attempts with the following parameters: White Point: D65 – RGB Primaries: native mode – Luminance: 90cd – Range: 2.2 – Black Point (two attempts): Absolute Zero and 0.5nits. They result in an absolutely blue screen, where titles and addresses are barely perceptible. Trying to calibrate with AdobeRGB primaries works, but the white point deviation is greater than DeltaE 7.
