Czornyj pisze: ↑25 listopada 2019, 18:10 - pn
Vicent pisze: ↑25 listopada 2019, 14:57 - pn
And you are wrong again...
-User made CCSS work as intened (given the limited resolution of some samples)
-Default bundle work as intended:
https://displaycal.net/i1d3 and can be compared to measurements made with binary EDR files for the ones that have an EDR match. And their measurements DO match.
-
You try to mistake mva.pl readers about "general DisplayCAL/ArgyllCMS behavior" regarding whatever bug you found in "oeminst" (the EDR to CCSS generic translation application). That is why DisplayCAL uses that URL bundle, to avoid use oeminst.
And your reply is just a pathetic way of hinding to mva.pl readers that:
-RGBLED backlight is not close to QLED backlight used in photo monitors
-WLED PFS backlight (AdobeRGB type) is not close to generic GB-LED, NEC-GB-LED or RGBLED backlight... which unfortunatelly includes PA271Q+SV2, among
all the other errors that plague that model, errors that some mva.pl users try hide/talk down while their owners despair for a solution.
But your strawman (oeminst) is not going to work here...
Users who make ccss have no idea of how good it's working, because they don't have spectroradiometers to validate the results. I'm not trying to hide something, that's obvious for anyone who has access to a cheap X-Rite spetrometer, or a DisplayCAL.
CCSS correction is not related ONLY to a reference instrument that provides spectral sample, it is related to firmware spectral sensivity curves of that colorimeter. That is what you try to hide.
The difference between choosing one CCSS/EDR to another and how good/how bad is going to perform depends on firmware sensivity curves too.
If a particular instrument is extremely close to reference observer in some wavelengths, or to be precise "it's firmware says that is very close to that reference observer" the correction applied in that wavelength will be none, the overall RGB RAW to CIE XYZ matrix that you have to multiply by raw measurements will not vary if you change EDR/CCSS in that particular wavelegth region.
In the same way if there is a significative difference between "observer in firmware" and "actual reference observer" in some wavelegths region there will be huge differences in results if you choose one EDR/CCSS that is VERY different from another CCSS.
This is what you try to hide making strawmans.
Hence, if AndN11 i1d3 colorimeter is close to a near perfect CIE 1931 2º in that 600-700nm region, it will not matter if he chooses RGBLED to a community QLED CCSS, at least relative to teh amount of X and Y contributed by those wavelegth regions.
And if it is not close, a significative difference will arise. Happy to read that he sees little difference = it's colorimeter behave very good on tose wavelegths even uncorrected.
And this is not related at all to measure against a reference spectroradiometer because the huge diference uses the same RAW RGB readings from his i1d3 as source
but DIFFERENT RAW RGB to CIE XYZ matrices. That is what causes such difference in XYZ coordinates.
To measure which CCSS of the two is more accurate or to see how result vary with changes in a hypotetical reference spectral sample you apply what I wrote: either you use a reference sample or add noise where you want to test how critical is that region for THAT colorimeter.
That's why your previous post is a total nonsense.
Using a RGBLED correction in a QLED IS NOT GOING TO BE BETTER just because it was taken at 1nm,
it could be better if it matches actual spectralpower distribution of a QLED (which DOES NOT happen as we have seen) and at the same time a community spectral sample DID NOT match a QLED in wavelegths where THAT PARTICULAR i1d3 colorimeter differs from reference observer. And it matches a QLED.
That's the cool thing about DisplayCAL. If Xrite stoped to release new spectral corrections for i1Profiler (just an example)... we can move on with 3.3nm CCSS community support as long as new backlight types do not have to narrow spectral power distributions... which happens with WLED PFS (we were not lucky there) but does not happen with QLED.
A QLED can be measured with an i1pro2 to make a CCSS correction. Unfortunately community contributors (people) make errors, uploading emulated gamut CCSS like in SW2700PT making extremely difficult for "common users" to get a proper one.
Thats why some users suggested than DisplayCAL should add a SPD 2D plot, not because it was "fancy", it was added to see very quickly if that particular CCSS was made from an emulated gamut = some channel is a combination of some other underlying 3 primaries.
Some users suggested some kind of auto detect but Mr. Höch considered it difficult when new backlights appear, so right now is up to user to visually inspect them.
It is not about "fancy plots", it is about to see if that other user contribution is wrong (like sRGB emulated gamut).
For example AndN11 sample against the ones here:
https://colorimetercorrections.displayc ... er4&html=1
Xrite's i1d3 family are very good colorimeters but THEY HAVE critical regions where they differ significatively form standard CIE 1931 2 degree. That is why if you measure a GB-LED with and without correction you see a significative difference. That is the same reason why if you apply a WG CCFL correction and a WLED correction you see difefrent readings on the same backlight.
Hence using CCSS that matches some backlight at those particular critical regions for that colorimeter is important.
Hence recomending "bundled 1nm" samples to very diferent backligt type is a TOTAL NONSENSE unless you check that your colorimeter has not that kind of observer mismatch where those 2 CCSS differ.
Czornyj pisze: ↑25 listopada 2019, 18:10 - pn
An error that plagues PA271Q has nothing to do with .edr, it's only a matter of factory calibration that was screwed up by NEC.
There eare 2 kind of errors: the most severe is calibration issue you name, the other one is caused by lack of EDR for PA271Q backlight in Spectraview II 1.1.40
How bad is this second issue? It depends on your i1d3 unit, in its spectral sensivity curves stored in firmware.
As we see in my previous post in GB-LED vs WLED PFS and RGBLED vs WLED PFS if ***YOUR colorimeter*** , its spectral curves in firmware, are very different from standard observer in the wavelengths where those 2 pair of sampes differ... you are going to suffer a significative error. If they are very close, then you won't.
i1d3 colorimeters were a game changer because of things like this, to solve the problem that colorimeter corrections were not "portable" between colorimeters measuring the same backlight. That's why we use EDR/CCSS, a very clever design from those guys.
If display vendor or colorimeter vendor DO NOT provide spectral samples for new backlights and their colorartti recommend to "re use" very different backlight samples instead of a good one... then we go back in time since tow i1d3 using a WRONG spectral correction may differ more between them than if they use a good spectral correction.
The good part is that we can analyze how they will vary in a numerical way like I wrote, because we have that info stored in firmware, so we can know where are these "critical zones" placed in a wavelegth line.
And the missing EDR for PA271Q is just NEC fault...they don't care and we take note about it.
), można powiedzieć intensywnego użytkowania, powtórzyłem dziś tą procedurę.
