mva.pl

Ad. 1 Monitor był kalibrowany do specyficznych zastosowań, stąd wyższy punkt czerni. Normalnie czerń ma znacznie niższą, kontrast znamionowy ok 1000-1100:1.
Ad. 2 Pomyłka walidacji wynika z braku korekcji widmowej luminoforu PFS tego konkretnie typu matrycy w programie ArgyllCMS. Błąd jest tylko interpretacyjny, bowiem zapisana kalibracja jest mierzona z korekcją.

Tom01 pisze: ↑

25 lipca 2019, 15:57 - czw

No dobra, poszedłem po rozum do głowy, trochę Painta, trochę Gimpa i jest:


Zrzut ekranu 2019-07-25 o 15.52.03.png


PS. Oszukiwałem, ta piękna walidacja pochodzi z prawdziwego monitora, który zaraz idzie do pudła i w drogę do jednej sympatycznej użytkowniczki o imieniu Olga, która czyta to forum, ale się nie ujawnia.

I know it XD, you are validating a profile, not a calibration.

Calbration is broken in that PA271Q. That one is a totally useless monitor, I would return it for refund untill I get a PA271Q that works... and that one is not working as expected for a monitor of its price.

Look at those a* errors from a*=0, that gives you an a* range over 1.x an this is only in green-magenta axis. TOTALLY UNACEPTABLE.

Ad. 1 Monitor był kalibrowany do specyficznych zastosowań, stąd wyższy punkt czerni. Normalnie czerń ma znacznie niższą, kontrast znamionowy ok 1000-1100:1.
Ad. 2 Pomyłka walidacji wynika z braku korekcji widmowej luminoforu PFS tego konkretnie typu matrycy w programie ArgyllCMS. Błąd jest tylko interpretacyjny, bowiem zapisana kalibracja jest mierzona z korekcją.

That is false.

ArgyllCMS has EXACTLY the proper correction for this monitor..,. and it is the one you used: HP Deramcolor Z24x G2 (1nm resolution)

If you integrate SPD of each channel multiplyed by standard observer you get almost full AdobeRGB and very high P3 (bigger than GB-LED) and it is exacly what a PA271Q is

(3nm or maybe 5nm resolution from chiphell)

(10nm resolution from ChipHell)

https://www.chiphell.com/thread-1950286-1-1.html

ArgyllCMS & DisplayCAL can measure a PA271Q out of the box with an i1d3 colorimeter using bundled corrections ( http://displaycal.net/i1d3 ). In fact... you won't be able to measure it more accurately with an i1Pro2 spectrophotometer as we see in 3nm and 10nm resolution plots.
The problem is in NEC Spectraview II 1.1.39 that still has no WLED PFS (AdobeRGB flavor) correction... and that is NEC's fault.

(also there is that issue with Spectraview Engine not working as expected)


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

Some PA271Q have SEVERE issues, unaceptable IMHO. I would not buy them unless store guarantees that if Spectraview Engine ("factory calibration" + engine for modifying calibration target) or Spectraview II do not work properly they are going to return your money tou you.

Otherwise get a old & tested CS2730 with its lut-matrix & 1000:1 contrast ratio.... or try luck with W-LED PFS from Eizo and their CGs. They are more expensive.

Przeczytałem cały ten wątek + dodatkowo „Benq SW2700PT kalibracja”.

Te dwa wątki to olbrzymia ilość wiedzy i informacji. Wiedzy, która powinna pozwolić zweryfikować jakość/czy nawet „obecność” kalibracji sprzętowej i porównać pod tym kątem chociażby monitory, które w tych wątkach się przewijają.

Vincent – serdeczna prośba o weryfikację czy dobrze zrozumiałem i opisałem jak sprawdzić jakość kalibracji HW za pomocą DisplayCal:

1. Reset krzywych z kary video – na wypdek wszelki aby się upewnić że na wyniki pomiaru nie wpływa nic poza tym co 'wewnątrz” monitora
Tools->VideoCard Gamma Table->Reset Video Card Gamma Table

2. Ustawiamy „systemowy” profil kolorystyczny zgodny z przestrzenią monitora (jeżeli jeszcze coś to prośba o info, a może to nie ma znaczenia)

3. Generownie raportu kalibracji
Tools->Report->Report on uncalibrated display device

W raporcie ważne są odchyłki od 0 dla parametrów a i b dla szarych próbek.

Przy powyższych krokach te odchyłki pokazują „jakość kalibracji” samego sprzętu. I teraz:
1. jeżeli monitor ma możliwość sprzętowej kalibracji - to dane pokazują jak dobrze się udało sprzętowo skalibrować monitor (powinno być jak rozumiem „prawie idealnie” dla dobrej klasy monitorów)
2. jeżeli monitor nie ma możliwości sprzętowej kalibracji - to odchyłki moga być większe lub mniejsze ale to jest punkt startu do kalibracji SW w GPU bo nie ma możliwości zmian w HW (i przy tej wersji posiadacze kart Radeon mogą otrzymać lepsze rezultaty)

Z powyższego wynika, że aby wiedzieć że monitor jest prawidłowo sprzętowo skalibrowany nie wystarczy standardowy raport po procesie kalibracji i profilowania z DisplayCal bo on pokazuje dane po zastosowaniu również profilowania, a więc nie wiadomo ile z tego to rezultat poprawnej kalibracji HW a ile dodatkowy wpływ kalibracji SW i profilowania.

W przypadku PA271Q zatem warto wykonać taki proces, aby się upewnić że super wyniki z raportów to nie są błędy producenta „naprawione” (zamaskowane) profilowaniem.

Jeżeli cos poplątałem to prośba o poprawienie.

W największym skrócie. Wykonujesz kalibrację sprzętową programem firmowym. W programie ArgyllCMS/DisplayCAL robisz tylko walidację, czyli od razu przechodzisz do zakładki Veryfication. Ważne: u góry w Settings wybierasz Current, czyli bieżący profil monitora, to będzie ten po kalibracji sprzętowej (powinien być w systemie już ustawiony jako domyślny). Dla pewności możesz tam kliknąć na ikonkę "i" , będą tam informacje o profilu, sprawdzisz czy będzie weryfikowany ten po kalibracji sprzętowej, choćby po nazwie profilu.
Jeśli wszystko OK, zamykasz to okno i klikasz w głównym oknie DisplayCal na dolny przycisk: Measurement report... po czym nastąpi przebieg weryfikacji wyświetlania monitora (oczywistym jest iż należy posiadać kalibrator, np. X-Rite i1Display Pro) i zostanie wygenerowany raport.
(jeszcze trzeba będzie wskazać w jakiej lokalizacji na dysku ma być ten raport zapisany, można zostawić domyślną lokalizację lub wybrać swoją)
Tak już robiłem ostatnio, np. przy sprawdzeniu jakości kalibracji fabrycznej trybu Adobe RGB. Tylko wówczas monitor ustawiłem w tryb Adobe RGB i w systemie windows jako domyślny ustawiłem ten uniwersalny profil AdobeRGB1998. Chyba nic nie pokręciłem

Crest pisze: ↑

27 lipca 2019, 16:16 - sob

W raporcie ważne są odchyłki od 0 dla parametrów a i b dla szarych próbek.

Ye. Look at Tom01 report because it is very good as example:
-there is variation across magenta--green axis in greys, which is very bad for B&W work.
-error (deltaE/deltaC, etc) is very low because profile stores that deviation in TRC curves. Monitor grey and the "not good" grey that profile stores MATCH (profile & monitor match)

By default a Profile verification in DisplayCAL validates if profile & monitor match. If you want to see actual errors in a*b* axis (ignoring gamma brightness error) then click in combo box "evaluate gray balance through calibration only". If that option is active reference a* & b* values are 0 (and reference L* if display itselft).
-Profiles with 1 TRC or equal TRC curves have a=b=0 by default (NEC software AFAIK, ColorNavigator, i1Profile variant with "matrix profiles" etc).
-Profiles with 3 TRC like some matrix profiles in DisplauyCAL or "table" profiles in i1Profiler & variants, or XYZLUT profiles in Displaycal may not have a=b=0 for grey reference.

Z powyższego wynika, że aby wiedzieć że monitor jest prawidłowo sprzętowo skalibrowany nie wystarczy standardowy raport po procesie kalibracji i profilowania z DisplayCal bo on pokazuje dane po zastosowaniu również profilowania, a więc nie wiadomo ile z tego to rezultat poprawnej kalibracji HW a ile dodatkowy wpływ kalibracji SW i profilowania.

By default a Profile verification in DisplayCAL validates if profile & monitor match. If you want to see actual errors in a*b* axis (ignoring gamma brightness error) then click in combo box "evaluate gray balance through calibration only". If that option is active reference a* & b* values are 0 (and reference L* if display itselft).

With 1 HTML report you can verify all these issues.

There are other check boxes like you see in Tom01 example:
download/file.php?id=2048&mode=view

"Aditional statistics" is useful to see if it is a GPU calibration because unique grel levels will be under 100%. That does not mean that there will be steps or bands in non color managed gradients becasue some GPUs use dithering at their outputs

"Use absolute values" is more complex to explain... By default verifications are done in transformed colorspace, PCS, profile conection space, a "ligua franca" that all profiles know and it is the way applications can transform colors from a profile to other. PCS is a D50 white colorspace, so if you change L*a*b* to xyY coordinates in a D65 calibration you'lls see weird values in xy coordinates of grey: you'll see transformed values to D50.
You can use "absolute value" to see actual xy values (but L*a*b* may be wrong out of PC with a delta B of 20 and delta a about 1, that is the difference between D65 and D50)

Huge b* variations are common in cheap Rec709/sRGB LED TVs

If a*/b* errors in verification were almost 0, there can be banding in gradients and green-magenta cast in greys because of 8bit correction in LUTs (rounding errors) if you calibrate in graphics card. For that situations if youcalibrate in graphics card, you need a visual inspection of a NON COLOR MANAGED gradient, like lagom lcd gradent test in MS paint.

--------------------------

NEC validation with their own software validates deltaE errors. That is brightness error (L*), a* error and b* error in ONE VALUE.
A deltaE of 2 cal be gamma error (brightness) or a magenta cast in grey. So you cannot trust it. Same for i1Profiler deltaE.
-Basicolor limited verification showed a*b* errors but there was no "visual" way to evaluate how severe it was, since it was done in deltaE.
-DisplayCAL can be used to do that in a more detailed way.
Future software or newer versions of existing oen may incorporate that a*b* verification for greys.

Is this a brightness error (gamma) or a color cast in greys?
download/file.php?id=2044
With that graph we do not know.

Vicent,

Everything starts to be more clear
Many thanks for sharing knowledge and experience.

Returning to PA271Q.
Based on your comment, Tom has chosen right color correction in DisplayCal, but still got these relatively big errors for grey patches (v.s. expectations).
1. Could it mean that PA271Q has bigger problem than it was assumed and maybe that is the reason of non existing fix?
2. And good results for this "prepared for specific conditions" PA271Q are just good because are read after profile was applied?

What is your opinion?

BTW. Still - with Radeon + GPU lut + profiling, results can be great for PA271Q but..... I have "old" EIZO S2243W and got results as in attached file - yes they are worse but truly said I expected better results from PA271Q. I do not claim s2243W is better - in fact it is terrible in terms of uniformity (green cast on left and magenta cast on right) and that is why I thought of buying PA271Q. But now, it looks that it is better to wait.....

S2243W (against true neutral grey)
RGB gray balance (>= 1% luminance) combined Δa*00 and Δb*00 range 2.05 NOT OK
GREY 64 1.08 delta a (pink)
GREY 115 -0.75 delta a (green)
Recalibrate using the slowest speed (12, 24, 48 then 96 steps in grey calibration). It's about 30-40 min in with a i1displaypro and black level about 0.15cd/m2 (it may be slower with barker black point)

I do not know the source of Tom01 calibration.

a ) Was it generated with Spectraview II?
One of the possible causes is a low quality panel which when uncalibrated has those tints/waves in a* axis.
SpectraviewII does not seem to take 96 x 4 (RGBW) like Argyll to do a full grayscale correction (like a physiotherapist when you have a muscle injury) since one would expect that NEC panels are somehow "preconditioned", with neutral grey. SV2 just takes a reasonable amount of patches for what a NEC display quality would need (actual number is in sv2 manual).
If that is what it happened, we are in a situation similar to DUCCS/PME.

b) Was it generated using Spectraview Engine (OSD on the fly calibration based on factory measurements of uncalibrated display + display processor computation of LUT values based on these data)?
Then it may be caused by:
-wrong display processor software, a FW update may solve that
-wrong uncalibrated measurements stored in firmware (which is the basis of Spectraview Engine calibration, like ArgyllCMS uncalibrated measurements is the basis of the GPU LUT data generated by argyll). SInce this data is UNIQUE for a display a generic "pac" FW update cannot solve this. SV2 can update this raw, native uncalibrated response in FW, but AFAIK it does not work fro PA271Q. Enio or other user showed that option "greyed", unselectable. An update from SV2 allowing this FW update by user data + WLED PFS EDR from NEC + user i1d3 may solve this issue.
Take a look in SV2 manual for further details. This way "internal data" used by spectraview Engine will be generated from a "reliable source" (i1d3 + custom EDR), so with proper software for internal processor DisplayCAL measurements and spectraview engine o the fly "predictions" (on the fly calibration without measurement) should match by a reasonable low error.

The problem with "b-2" option would be if there is a low quality panel too. A not neutral one. In that situation the number of pathces measured by SV2 to update native raw uncalibrated state may be not eough, like in DUCCS/PME.

So if you buy a PA271Q and Spectraview engine results or SV2 calibration show a* waves/oscilations in grey ramp compared against white (whatever it is, do not care about white) then RETURN to store (do not keep it) and consider a CS2730 or CG279X (I would skip CG2730, it may be good but IMHO it it not in features/price against the other two)




There was a disturbing report from a CG279X too, that kind of a* errors:
https://www.youtube.com/watch?v=klDxwZALvis
11min 18sec
But this review was done by a unexperienced user... so there is a possibility of user error , like colorimeter misplacement... etc.
I asked Tom01 and he did not see these errors in any CG279X.

Also some CS2730 have a weird white point with some i1d3 after Color Navigator(CN), like requesting D65 and displaycal seeing a "white" (not green , not magenta) "cool white" about 6800K+.
Maybe CN is using a matrix correction instead of spectral ones (there are no EDRs in CN)... and because generic matrices ARE NOT PORTABLE between units of the same colorimeter model (EDRs are portable because there is set of "supossed unique" spectral sensivity curves in firmware for each i1d3), so there is an intrinsic error in some i1d3 slighty different that the one used by Eizo to generate a 3x3 matrix correction..... or maybe there is a EDR-like data hidden in DLLs and that "white error" is not actually an error, it just happen to be using CIE 2º 2012 observer (and its D65 sould be placed close to that). Argyll command line tools can be used to verify that (an updated 2 degree observer), but DisplayCAL report (HTML report) uses a hard coded CIE 2º 1931 observer.
CN is a very very dark "black box"... so unless you are a hacker that can dump & inspect DLL contents (and I am not)... is hard to tell what is happening, just educated guessing based on results.
Basiccolor/Spectraprofiler and Spectraview II being based on EDR are more easier to understand what they do without that deep inspection. It's easier to setup for them an equivalent enviroment in Argyll.
Same for DUCCS or PME: we know that PME is using a WRONG rgbled EDR, let's use the same wrong EDR in Argyll and check if using the same measurement ruler grey is OK (the task AndN11 did a week ago).

Podbijam temat w górę, aby NEC czerwienił się burakiem Zainteresowani wiedzą o co chodzi.

Crest pisze: ↑

27 lipca 2019, 19:48 - sob

I do not claim s2243W is better - in fact it is terrible in terms of uniformity (green cast on left and magenta cast on right)

Dziwię się, że nie oddałeś takiego bubla (przy EIZO takie zafarby dla mnie niedopuszczalne). Mam starszy model S2231W i myślałem, że pechowy, bo nieco ciemniejszy w pewnym obszarze z brzegu, ale innego zafarbu po jednej stronie, a innego po drugiej to nie miałem.

ps. raport mojego egz. : https://ufile.io/8f2lxk7g

2marekm pisze: ↑

05 września 2019, 18:48 - czw

Podbijam temat w górę, aby NEC czerwienił się burakiem Zainteresowani wiedzą o co chodzi.

Lepiej stracić pieniądze niż zaufanie ktoś kiedyś powiedział, ale czy ktoś kto nie ma honoru by chociaż przyznać się do błędu, będzie się przejmował użyszkodnikami...

Danny pisze: ↑

06 września 2019, 04:24 - pt

2marekm pisze: ↑

05 września 2019, 18:48 - czw

Podbijam temat w górę, aby NEC czerwienił się burakiem Zainteresowani wiedzą o co chodzi.

Lepiej stracić pieniądze niż zaufanie ktoś kiedyś powiedział, ale czy ktoś kto nie ma honoru by chociaż przyznać się do błędu, będzie się przejmował użyszkodnikami...

Poniekąd, przyznanie się do błędu (czy znajomość problemu) było. Specjalista NEC (Wojciech Kosek) w tym wątku pisał rok temu:

Wojciech Kosek pisze: ↑

29 września 2018, 13:49 - sob

Szanowni Forumowicze,
Problem liniowości TrcG w monitorach PA271Q jest nam znany i wspólnie z kolegami odpowiedzialnym za SVE oraz SVII pracujemy nad jego rozwiązaniem. ...

Były też zapowiedzi, że do końca stycznia 2019 problem będzie rozwiązany:

Czornyj pisze: ↑

11 grudnia 2018, 16:29 - wt

Tu nie ma co wierzyć albo i nie wierzyć - tu są proste, łatwo potwierdzalne empirycznie fakty - liniowości w monitorach do zastosowań o krytycznym znaczeniu koloru (PA, CG itp.) fizycznie NIE DA się poprawić. Oficjalnie informował o tym Wojtek Kosek, "nieoficjalnie" przekonali się o tym użytkownicy PA271Q z błędem w FW.
Problem zostanie oficjalnie wyeliminowany w styczniu, tyle w temacie.

Wojciech Kosek pisze: ↑

07 stycznia 2019, 13:47 - pn

Witam serdecznie,
Do końca miesiąca powinien być gotowy FW który usuwać będzie wspominany wielokrotnie błąd trc.
Obecnie prowadzone są testy i ostatnie adjustacje. FW będzie poprawiał linearyzację oraz wprowadzał możliwość update silnika SVE z poziomu aplikacji SVII - ta otrzyma osobą aktualizację.

Styczeń 2019 minął (dość dawno temu) i już zdaje się Specjalista NEC się więcej nie odezwał, a nowsze FW (wynika z wątku), które się pojawiło, problemu nie usunęło. Widać problem jest poważniejszy i możliwe, że nie do naprawy poprzez FW i oprogramowanie (bo jakby było możliwe, to chyba nie byłoby tematu, czy był dawno zakończony i zapomniany)

Nowe oprogramowanie rozwiązuje problem, ale tylko w niektórych egzemplarzach. To jest coś analogicznego, jak raportowany rok temu przeze mnie błąd w oprogramowaniu monitorów serii EA. Jest to ewidentna niedoróbka, utrudniająca zwykłą eksploatację i zmuszająca w pewnym sensie do zakupu droższych wersji "poprawionych" poza fabryką.

Tom01 pisze: ↑

06 września 2019, 19:11 - pt

Nowe oprogramowanie rozwiązuje problem, ale tylko w niektórych egzemplarzach. ...

To jest dla mnie bardzo dziwne..., dlaczego tylko w niektórych egzemplarzach. Część użytkowników (pewnie nie mała) nie ma żadnej szansy na rozwiązanie problemu przez producenta, tak by wynikało z powyższego cytatu. Otrzymali towar za nie małe pieniądze nie w pełni funkcjonalny tak jak ma w opisie i trzeba się z tym pogodzić (przymknąć oko)

Taa.. Poprawionych dziwnym trafem przez p. T ;] NEC nie dał, Czornyj nie dał rady, a magicznie T01 maskuje coś, co nie da się naprawić. Oczywiście nikt nie może tego sprawdzić i zweryfikować,

Nie mówię, że nikt nie potrafi. Sęk w tym, że się nie chce dłubać, grzebać, testować. Niedawno trafiłem na problematyczny egzemplarz i ustawienie go poprawnie zajęło tyle czasu, że ustawiłbym kilka innych. Kwestie ekonomiczne.

Pozostaje upewnić sie że mówimy o tym samym, aby wykluczyć niedopowiedzenia, tzn.

Czy monitory PA271Q skalibrowane przez Tom01, są SKALIBROWANE SPRZĘTOWO, tzn. że BEZ zaczytania/działania przygotowanego w ramach profilowania przez Tom01 PROFILU i bez wczytania korekty do karty graficznej będą rzeczywiście skalibrowane (piekny szary gradient bez zafarbów i o zadanej gammie).

Oczywiście, że sprzętowo. Tylko i wyłącznie.

Czyli po zresetowniu krzywych w karcie graficznej i raport kalibracji z Argylla (Report on uncalibrated display device) wykaże praktycznie zerowe odchyłki delta a i delta b dla szarych próbek?

Dzieki - w pytaniu byłem precyzjny, ale jak widzę kręcimy się w kółko w tym wątku odpowiadając na inne pytania niż zadane - jak w polityce
Chodziło konkretnie o delta a i delta b z dokładnie takiego raportu z Argylla (nie innego, nie inne wykresy, nie inne tabelki, nie inne programy itp.) - takiego raportu jak ten

viewtopic.php?f=31&t=3498&start=1000#p57115

ale z zaznaczoną opcją "Evaluate gray balance through calibration only".