Benq SW2700PT kalibracja

[Vicent]

@AndN11 by the way, I just checked PME v1.3.7 and they did not include new spectral corrections, so ALL Benq SW still lack of proper spectral correction. All Benq SW when measured with a i1d3 return WRONG color data with ALL PME versions, including this v1.3.7. Your report is not strictly valid because you use the wrong correction too for validating (that white point is not actual whiepoint) ... but you can use it in DisplayCAL (the same WRONG correction) to evaluate grey range, which is very good and the main concern.

NEC lack of proper corrections for PA271Q and PA311D is very disapointing, since it's paid software, but it still works for other PA series.
Benq PME software NEVER worked properly since ALL SW monitors (all of them) are out of support. Shame.

[AndN11]

@Vicent, tak wiem o tym, że w wersji 1.3.7 PME nie ma tej właściwej korekty widmowej i dalej jest RGB LED to najbardziej zbliżone. Pytanie na ile to powoduje błędy w wyświetlanym obrazie. Wizualnie używając monitora (na różnych obrazkach testowych także) nie dostrzegam problemów z szarościami, czy bielą. Oczywiście wolałbym aby wszystko było dopracowane, tak jak być powinno.

W wątku porównawczym Benq SW2700PT i NEC PA271Q CLOR odnośnie benka padły takie słowa :

...Brak jakichkolwiek mechanizmów znanych z branży monitorów fotograficznych, powoduje też bardzo małą stabilność parametrów. Czas rekalibracji to maksymalnie kilka tygodni. ...

Postanowiłem sprawdzić jak to jest naprawdę z utrzymywaniem stabilności parametrów w sw2700pt. W tym wątku przeprowadzałem sprawdzenie przy pomocy DisplayCAL (i X-Rite i1DP) jak wyświetla ten monitor w trybie fabrycznym Adobe RGB i było to w lipcu tego roku. Po 4 miesiącach (nie tygodniach ), można powiedzieć intensywnego użytkowania, powtórzyłem dziś tą procedurę.

Oto rezultaty.
Raport z 20 lipca 2019 :


to z 21 listopada:


Porównanie błędów Delta E:


Inne parametry monitora z raportu w DisplayCAL
z lipca:


z listopada:


z lipca:


z listopada:


z lipca:


z listopada:


Moim zdaniem jest bardzo dobra stabilność parametrów. Niektóre ΔE są nieco większe, niektóre mniejsze. Ociera się to prawie o błędy pomiarowe. Także stwierdzenie jakoby Benek bardzo słabo trzyma parametry nie mają w rzeczywistości (pomiarach) żadnego potwierdzenia. Sądzę, że rozjechanie parametrów o 2 ΔE nastąpi nie prędzej jak po roku, a raczej później (zależy oczywiście od przepracowanych godzin), czego nie omieszkam sprawdzić i się tym podzielić na forum.

PS.
Do wglądu pełne raporty w formacie HTML spakowane do zip.
z lipca 2019:

Tryb fabryczny Adobe RGB_Measurement Report 3.8.3 — BenQ SW2700 @ 0, 0, 2560x1440 — 2019-07-20 08-19.zip

(36.76 KiB) Pobrany 120 razy

z listopada 2019 :

Sprawdzenie trybu fabrycznego Adobe RGB_Measurement Report 3.8.8 — BenQ SW2700 @ 0, 0, 2560x1440 — 2019-11-21 15-09.zip

(36.8 KiB) Pobrany 119 razy

można sprawdzić czy się zgadza z zrzutami z ekranu.

[Vicent]

@Vicent, tak wiem o tym, że w wersji 1.3.7 PME nie ma tej właściwej korekty widmowej i dalej jest RGB LED to najbardziej zbliżone. Pytanie na ile to powoduje błędy w wyświetlanym obrazie. Wizualnie używając monitora (na różnych obrazkach testowych także) nie dostrzegam problemów z szarościami, czy bielą. Oczywiście wolałbym aby wszystko było dopracowane, tak jak być powinno.

We talked about this in the past. The error that you are going to suffer because not using proper CCSS/EDR depends on your colorimeter actual sensivity curves stored in firmware.
An i1d3 with those curves extremely close to CIE 1931 2 degree observer in red wavelengths region is going to behave well if you measure a GB-LED o a QLED with a RGBLED CCSS/EDR correction. An i1d3 not so good, not so close in firmware curves, is going to have an error in white point , a little more pink or a little more green than reference.

RGBLED is not the closest one to Benq SW QLEDs, if you find to difficult to "clean" by yourself user submited CCSS corrections (most of them are sRGB or AdobeRGB emulations measured into a CCSS), current bundle of corrections for i1d3 in DisplayCAL should include a sample for a Samsung TV QLED (http://displaycal.net/i1d3). This is very close to your QLED.
There is a thread in DisplayCAL where we plotted them (Power vs wavelength) and there was a match between that TV and user made CCSS for a SW2700PT (it was me & Mr. Höch). If you want to test if YOUR i1d3 is affected by a tiny or big error because of using wrong spectral correction in THAT backlight... test it against this CCSS reference. Then you can calculate color distance between those 2 measurements. NOTE: it's important, between them (one with RGBLED, onw with QLED), not against D65. Shift about less or equal to +-2 a* with a synthetic test and a few i1d3.

The cool thing about using proper spectral corrections is that to do not have to worry so much about your actual colorimeter: all of the i1d3 should be very accurate. That's why Xrite made its i1d3 that way... but display manufacturers do not care about quality at all.

[AndN11]

Potrzebowałbym raczej sprawdzonego, przetestowanego pliku EDR (z korekcją QLED) do programu Palette Master Element.
Plik CCSS z odpowiednią korekcją (?) już mam w DisplayCAL:

PS.
Posiadam X-Rite i1Display Pro, używasz określenia i1d3. To te same urządzenia ?

[Vicent]

1- RGBLEDFamily_07Feb11.ccss is proven wrong for a QLED. Red channel does not match by far, so depending on your i1d3 it can result in noticeable differences.
2- Benq does not care at all
3- Yes, that CCSS looks OK. I'm happy that now there is a native gamut CCSS. In the past most of them were sRGB or AdobeRGB gamut emulations. You can see this because the other CCSS have one channel that was a mix of 2-3 of native primaries of that CCSS you ploted.
4- "i1d3" is a generic name for all the colroimeter family that uses the same HW: i1displaypro, i1displaypro OEM, color munki disolay i1display studio, NEC spectrasensor v3, the one from HP, the one from Wacom, the one from SpectraCAL, viewsonic colorbration, the one from Bassicolor... They are the same for DisplayCAL (different unlock codes -and speeds for 2 of them- but same operation by ArgyllCMS)

5- I hope that *your* particular i1d3 has a red channel sensivity stored in firmware that is close to CIE 1931 2, so error RGBLED vs QLED will be low in whitepoint. Other i1d3 may behave a little different ( +- 2 a* in white, greenish or pinkish )

[AndN11]

RGBLEDFamily_07Feb11.ccss is proven wrong for a QLED. Red channel does not match by far, so depending on your i1d3 it can result in noticeable differences. ...

Cóż, również nie byłem/jestem przekonany do tej konkretnej korekcji, stąd też był znak zapytania w nawiasie.
Wcześniej jednak doczytałem coś takiego:
viewtopic.php?f=6&t=3963&start=120#p57067
nie żebym miał jakieś pretensje Zawsze podchodzę z rezerwą do "leków na całe zło"

I hope that *your* particular i1d3 has a red channel sensivity stored in firmware that is close to CIE 1931 2, so error RGBLED vs QLED will be low in whitepoint. Other i1d3 may behave a little different ( +- 2 a* in white, greenish or pinkish

Tak sądzę, po kalibracji i wynikach wizualnych, że korekcja RGBLED z moim i1DPro przynosi mały błąd w punkcie bieli.

[Czornyj]

3- Yes, that CCSS looks OK. I'm happy that now there is a native gamut CCSS. In the past most of them were sRGB or AdobeRGB gamut emulations. You can see this because the other CCSS have one channel that was a mix of 2-3 of native primaries of that CCSS you ploted.

No, it doesn't look OK. i1Pro has too small spectral resolution to create proper CCSS. Furthermore, even ccss done with high res spectroradiometer (FWHM 5nm or less) doesn't really work well for some mysterious reason, so paradoxically native x-rite edr's usually work better, even if they don't match the backlight SPD curve precisely.

[Vicent]

3- Yes, that CCSS looks OK. I'm happy that now there is a native gamut CCSS. In the past most of them were sRGB or AdobeRGB gamut emulations. You can see this because the other CCSS have one channel that was a mix of 2-3 of native primaries of that CCSS you ploted.

No, it doesn't look OK. i1Pro has too small spectral resolution to create proper CCSS. Furthermore, even ccss done with high res spectroradiometer (FWHM 5nm or less) doesn't really work well for some mysterious reason, so paradoxically native x-rite edr's usually work better, even if they dont' exactly match the backlight SPD curve.

And you are wrong...

RGBLED correction is not even close to that QLED red. That CCSS is OK for a QLED. The whole purpose of a CCSS/EDR is to compute a RGB raw i1d3 values to CIE XYZ. It's totally useless to recomend a spectral correction with is very different in some wavelength to actual device ***if we have a better one*** and ***if devis is not close to chosen observer in that wavelength region***.
For your claim to be a slightly sensible one, ANdN11 should dump his i1DisplayPro spectral sensivities (Argyll can do that, but right now I'm not sure if it is enable d by default your you should recompile it with a preprocessor directive. Only then comparing that 2 CCSS and colorimeter "observer" (spectral sensity curves) we could see if your claims do not introduce a bigger error. But this approach is out of most Benq SW owners. In the past DisplayCAL did not have a graphical SPD feature so most of them were blind when choosing a CCSS (and some of them were gamut emulation CCSS), but that does not hold right now.

The CCSS plotted by DisplayCAL that ANdN11 shows is a QLED like, at native gamut, so it's fine.

We can debate about which one we use when actual device SPD has so tiny narrow spikes that the go unnoticed with a "graphic arts" spectrophotometer (i1Pro family)... like in WLD PFS. Do we use the one bundled with Xrite i1profiler (95% P3 multimedia withot 9x% AdobeRGB) for a WLED PFS AdobeRGB display or do we use some 3.3nm made with ArgyllCMS? IN THAT SITUATION we can apply your objections... but in the end we will be hinding display manufaturer fault regarding software support like Benq (SW240 is supposed to use that backlight) or your beloved NEC and its shameful fail called PA271Q+SV2.

[Vicent]

Sorry, AndN11, I cannot find that CCSS in your screenshot in displayCAL database:
https://colorimetercorrections.displayc ... er4&html=1
The ones in database show AdobeRGB-like gamut emulation, yours does not show it. Would you mind to post its text contents here or upload it to pastebin.com, dopbox or another server? Just for plotting RGB led and that one.
Thanks in advance

[Vicent]

It should be something like this, but my test QLED sample is not very good, 10nm, not 3.3 form Argyll:

red=QLED (SW2700PT sample) orange=Xrite RGBLED, both of them are exactly D65 samples.
From 600nm (x-bar max value) to 650nm (about x-bar 25% form its maximum) any significative difference between i1d3 spectral sensivities (manufacturer data, stored in firmware) and CIE 1931 2º are going to be corrected by a CCSS/EDR capable software... and 625-650nm correction for that difference is not going to be small.

[Vicent]

Also we can see NEC SV2 correction for GB-LEDs and an actual WLED PFS AdobeRGB 9x%P3 9x%:

red=NEC_64_690E_PA242W_2013-02-28 (a GB-LED) orange=HP_DreamColor_Z24x_NewPanel (WLED PFS AdobeRGB type, green SPD is the difference this one and iMacs or common multimedia 95% P3 displays)

Hmm... that is going to hurt too...poor NEC guys.

In those WLED PFS with almost full AdoberGB like SW240 is supposed to be, RGBLED is not "very" good but is much better than in SW2700PT (it fits better to actual backlight):

red= the same WLED PFS as above, orange=RGBLED from xrite
But 600 to 620-630nm mismatch happens when x-bar from standrad observer is near its max, and y-bar at 50%... so other errors could arise from this "not so big" mismatch, it would be better to test with i1d3's firmware spectral sensivity curves as a sample and see actual error.

All samples are D65 ("RGB-gained" to be D65 from Xrite data) and 1nm

[AndN11]

...Sorry, AndN11, I cannot find that CCSS in your screenshot in displayCAL database:
https://colorimetercorrections.displayc ... er4&html=1
The ones in database show AdobeRGB-like gamut emulation, yours does not show it. Would you mind to post its text contents here or upload it to pastebin.com, dopbox or another server? Just for plotting RGB led and that one.
Thanks in advance

Plik ccss pobrałem, (jeśli dobrze pamiętam) poprzez program DisplayCal , w ten sposób:

mogę go tu wrzucić spakowany do .zip

BenQ SW2700 (i1 Pro)2.zip

(1.17 KiB) Pobrany 138 razy

[Czornyj]

And you are wrong...

...and you're wasting your time explaining something that for me was completely obvious -long before DisplayCAL had ccss graph feature I made my own graphs from ccss, just after Graeme introduced ccxxmake tool that converts .edr's to XML.

What you don't understand is that Argyll created ccss simply doesn't work as intended, no matter how cool the graph looks. There's either a bug or something you need to know to make it work.

[Vicent]

And you are wrong...

...and you're wasting your time explaining something that for me was completely obvious -long before DisplayCAL had ccss graph feature I made my own graphs from ccss, just after Graeme introduced ccxxmake tool that converts .edr's to XML.

What you don't understand is that Argyll created ccss simply doesn't work as intended, no matter how cool the graph looks. There's either a bug or something you need to know to make it work.

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...

**************

Now back to AndN11's topic:

Since they are not close, you have an error. How bad is it for THAT colorimeter you have? You can measure that error for colorimeter:
-dump an i1d3 spectral sensivities (ArgyllCMS code)
-use a XXX.ccss sample to compute a correction (A) for that colorimeter
-use a YYY.ccss sample to compute a correction (B) for that colorimeter
-synthetic measure a ZZZZ.ccss sample with colorimeter spectral sensivities (=no CCSS correction), this will play the role of actual backlight measured with an imperfect colorimeter (C)
-synthetic measure a ZZZZ.ccss sample with standard observer (D), this will play the role of actual backlight and actual color coordinates.
-compare C corrected with A vs D and C corrected with B vs D for our sample colorimeter.

A) clould be user/community provided CCSS
B) clould be calibration vendor correction like RGBLED or the GB-LED from NEC
ZZZZ.ccss) could be an actual high res sample for that backlight or A/B with some noise added

This way you can argue which one is better for that colorimeter and in which condition this happens (ZZZZ.ccss actual backlight sample).
Otherwise (Czornyj posts) it is just hiding the limited supply of bundled corrections in Xrite SDKs for currect backlights, and the differences in Xrite EDR bundle from one display vendor to another.
But since we have DisplayCAL and we can make these calculations... we do not care about what an Xrite person can or cannot say unless he provides data.

[Vicent]

...Sorry, AndN11, I cannot find that CCSS in your screenshot in displayCAL database:
https://colorimetercorrections.displayc ... er4&html=1
The ones in database show AdobeRGB-like gamut emulation, yours does not show it. Would you mind to post its text contents here or upload it to pastebin.com, dopbox or another server? Just for plotting RGB led and that one.
Thanks in advance

Plik ccss pobrałem, (jeśli dobrze pamiętam) poprzez program DisplayCal , w ten sposób:
pobrana korekcja.jpg

mogę go tu wrzucić spakowany do .zip
BenQ SW2700 (i1 Pro)2.zip

Ok, that looks like a native gamut sample, thanks.

Does displayCAL detect its as an error CCSS? new DisplayCAL version has that feature (and will delete it). If DisplayCAL can load it and you can run a verification... it's fine. It will be better if it was a 3.3 sample but this is what you have.

I hope that *your* particular i1d3 has a red channel sensivity stored in firmware that is close to CIE 1931 2, so error RGBLED vs QLED will be low in whitepoint. Other i1d3 may behave a little different ( +- 2 a* in white, greenish or pinkish

Tak sądzę, po kalibracji i wynikach wizualnych, że korekcja RGBLED z moim i1DPro przynosi mały błąd w punkcie bieli.

And that is possible, -2 < x < 2 includes "x is close to 0"

If visually looks white, keep it. If you want to do maths and check numerically for whatever backlight and whatever correction... the procedure is written above.

[Czornyj]

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.

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.

[Vicent]

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.

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.

[Czornyj]

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

TLDR

You can verify the effectiveness of ccss ONLY with reference instrument. To make story short and spare you another pointless explanations - I'll measure the accuracy of various ccss on my PA311D using spectroradiometer as soon as I'll have some time and access to it.

[Tom01]

Panowie, wydaje mi się, że mówicie o różnych rzeczach. Jest jasne, że poprawność, lub bardziej powtarzalność zdjęcia widma będącego podstawą korekcji, można zweryfikować tylko przyrządem o rząd wielkości dokładniejszym niż użyty do pomiaru. To podstawowa zasada miernictwa. Jednakże trafienie kolorymetru z korekcją można zweryfikować, wiedząc jaki wynik ma wyjść.

[Czornyj]

Panowie, wydaje mi się, że mówicie o różnych rzeczach. Jest jasne, że poprawność, lub bardziej powtarzalność zdjęcia widma będącego podstawą korekcji, można zweryfikować tylko przyrządem o rząd wielkości dokładniejszym niż użyty do pomiaru. To podstawowa zasada miernictwa. Jednakże trafienie kolorymetru z korekcją można zweryfikować, wiedząc jaki wynik ma wyjść.

Rzecz opiera się na teoretycznym i poniekąd słusznym założeniu, że stworzenie indywidualnej korekty ccss poprawia dokładność pomiaru i1D3, tylko że aby zweryfikować tą tezę należy dokonać jej walidacji przy pomocy sensora referencyjnego. I o ile w teorii powinno być pięknie, to niestety w praktyce dlaczegoś wychodzi lipa...