- This topic has 116 replies, 12 voices, and was last updated 1 year, 6 months ago by
.
-
Posts
-
Make an hybrid ti3
Sorry, but I don’t know what that means. Could you explain it to me?
Measurements while profiling are dumped to a ti3 file. Let’s assume that i1d3 measurements are close to reality (excluding black clipping near black red).
As long as i1d3 and munki do not differ too much near missing measurements from i1d3, you can hybrid those 2 ti3 files into a new ti3. Use that ti3 to create an ICC, use icc to create LUT3D. Manually replace missing 000 reasings from o1d3 with munki part in a text editor. Not noob friendly.Of course if munki tracked gamma in an accurate way this won’t be needed, but as I showed before it was measuring higher output than i1d3… which is expected due to poor low light performance of such low cost spectrophotometers (noise).
Or maybe just happens that that LG RGB OLED has poor stability over time (hence different dark readings with munki photo)… it that case display is not reliable and you can do nothing about it.Attached is a verification with the iDisplay Plus WITHOUT the Spectral Correction / verify_xxxl.ti1
Missing one report using refresh mode. That’s all the things ArgyllCMS can do regarding treatment of RGB counters outputed by HID command requested to i1d3 HW. If it still shows black clipping …then Ted’s theory is bullshit (as expected). And we all would have saved time if he just read the i1d3 argyll code instead of writing bullshit to support LightNonsense Inc.
i1d3 are HID devices, application requests a command for reading and HW returns RGB counters. If counters are bellow certain threshold for all RGB counters, ArgyllCMS tries to re read. It does more things but that’s short explanation.
It would be more useful for you to request direct assitance regarding these RGB OLED in ArgyllCMS maillist, so Graeme Gill, ArgyllCMS creator, can write a set calls to HID command for measurement with modified parameters trying to find a better threshold for this SPD at very low light readings tweaking HID command for measurement, rather that read bullshit theories in heavily advertised forums.
If parameters in HID command for measurement (time, edges) can be improved for those RGB OLEDs, Graeme can find it out for all us if you provide him testing.
Easiest way is to read MS paint patches (like RGB 50, 0, 0) with a modified “spotread” command with or without ccss param (-X path_to_ccss_file).DisplayCAL is just a frontend, a GUI. All translates to command line calls to argyllCSM commands. You have to report your issues there, not here. Better feedback than xrite or calibrite as long as you are going to actively test “beta versions” and graeme is willing to do it of course-
Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.Make an hybrid ti3
Sorry, but I don’t know what that means. Could you explain it to me?
Measurements while profiling are dumped to a ti3 file. Let’s assume that i1d3 measurements are close to reality (excluding black clipping near black red).
As long as i1d3 and munki do not differ too much near missing measurements from i1d3, you can hybrid those 2 ti3 files into a new ti3. Use that ti3 to create an ICC, use icc to create LUT3D. Manually replace missing 000 reasings from o1d3 with munki part in a text editor. Not noob friendly.OK, thanks for the explanation. I tried and had a look at both files, but I honestly don’t know where to start.
Of course if munki tracked gamma in an accurate way this won’t be needed, but as I showed before it was measuring higher output than i1d3… which is expected due to poor low light performance of such low cost spectrophotometers (noise).
Or maybe just happens that that LG RGB OLED has poor stability over time (hence different dark readings with munki photo)… it that case display is not reliable and you can do nothing about it.As far as I understand, this JOLED panel is supposed to have a very good stability.
Attached is a verification with the iDisplay Plus WITHOUT the Spectral Correction / verify_xxxl.ti1
Missing one report using refresh mode. That’s all the things ArgyllCMS can do regarding treatment of RGB counters outputed by HID command requested to i1d3 HW. If it still shows black clipping …then Ted’s theory is bullshit (as expected). And we all would have saved time if he just read the i1d3 argyll code instead of writing bullshit to support LightNonsense Inc.
There is one report using refresh mode. And the some more (see attached) are also in refresh mode. In general, refresh mode is the mode to use, when profiling an OLED, right?
i1d3 are HID devices, application requests a command for reading and HW returns RGB counters. If counters are bellow certain threshold for all RGB counters, ArgyllCMS tries to re read. It does more things but that’s short explanation.
It would be more useful for you to request direct assitance regarding these RGB OLED in ArgyllCMS maillist, so Graeme Gill, ArgyllCMS creator, can write a set calls to HID command for measurement with modified parameters trying to find a better threshold for this SPD at very low light readings tweaking HID command for measurement, rather that read bullshit theories in heavily advertised forums.
If parameters in HID command for measurement (time, edges) can be improved for those RGB OLEDs, Graeme can find it out for all us if you provide him testing.I already presented this problem in the ArgyllCMS mailing list. I only heard once from him, but since then nothing. Maybe he is quite busy at the moment, which I can totally understand.
Easiest way is to read MS paint patches (like RGB 50, 0, 0) with a modified “spotread” command with or without ccss param (-X path_to_ccss_file).
DisplayCAL is just a frontend, a GUI. All translates to command line calls to argyllCSM commands. You have to report your issues there, not here. Better feedback than xrite or calibrite as long as you are going to actively test “beta versions” and graeme is willing to do it of course-
I know. Well, let’s hope he will find the time to do some testing. I would be happy to make the readings. It would be a shame to buy expensive Windows-Software if a correct calibration/calibration could be done with ArgyllCMS.
Please find attached a couple of more verifications:
- I verified the Colormunki Photo calibration with the i1D3 (spectral correction with Colormunki Photo) yesterday.
-> the result is not as good as before with the Colormunki Photo, but still kind of acceptable. So this means, that the Colormunki Photo isn’t completely off, right?
2. Today I did a calibration with the i1D3 (matrix correction) and then verified it once with the i1D3 and with the Colormunki Photo.
Please see for yourself.
At the moment, I would stick to the Colormunki Photo calibration until I figured out how to correctly measure with the i1D3.
Honestly, my belief is that you cannot if you are seeing the same phenomenon I saw — except maybe laying it flat on a table?. See my video with the iPhone….. Or you can stay with a simple matrix and trust the linearity of the display — the few samples in dark reds are too few to throw it off, in my opinion.
Actually, I did a calibration in horizontal mode 🙂 But the result was exactly the same within the reds. What a shame, this would have been a very easy solution. By the way, did you check that the iPhone sensor wasn’t interfering by putting out less light within your testing?
One more thing regarding spectral vs. matrix corrections. As far as I understood, a matrix correction should be more accurate, if I have the display and both the colorimeter and spectrometer at hand.
Well, I did 3x matrix corrections right after another, and 3x spectral corrections right after another. But what concerns me, is that the matrix corrections always show very different measurements, whereas the spectral corrections all seems to be quite equal. My logical thinking tells me, that the matrix corrections should be less trusted. Or am I wrong? That’s just why I tend to use spectral corrections, as the i1d3 has the spectral sensitivity built into, according to ArgyllCMS https://www.argyllcms.com/doc/ccxxmake.html :
“For Colorimeters that have sensor spectral sensitivity calibration information built into them (ie. the X-Rite i1d3, and DataColor Spyder4 & Spyder5), ccxxmake allows a creation of a calibration spectral sample (ccss) for a particular Display, by making use a reference Spectrometer instrument.”
Make an hybrid ti3
Sorry, but I don’t know what that means. Could you explain it to me?
Measurements while profiling are dumped to a ti3 file. Let’s assume that i1d3 measurements are close to reality (excluding black clipping near black red).
As long as i1d3 and munki do not differ too much near missing measurements from i1d3, you can hybrid those 2 ti3 files into a new ti3. Use that ti3 to create an ICC, use icc to create LUT3D. Manually replace missing 000 reasings from o1d3 with munki part in a text editor. Not noob friendly.OK, thanks for the explanation. I tried and had a look at both files, but I honestly don’t know where to start.
Of course if munki tracked gamma in an accurate way this won’t be needed, but as I showed before it was measuring higher output than i1d3… which is expected due to poor low light performance of such low cost spectrophotometers (noise).
Or maybe just happens that that LG RGB OLED has poor stability over time (hence different dark readings with munki photo)… it that case display is not reliable and you can do nothing about it.As far as I understand, this JOLED panel is supposed to have a very good stability.
If that is true your munki isn’t. In one report from the past days you got L*9 and L*11 for the same color.
At the moment, I would stick to the Colormunki Photo calibration until I figured out how to correctly measure with the i1D3.
Since no correction shows clipping, “if there is something that could be done” would imply changing params in re-read try as I explained in previous post, hence it will need Argyll code modification.
One more thing regarding spectral vs. matrix corrections. As far as I understood, a matrix correction should be more accurate, if I have the display and both the colorimeter and spectrometer at hand.
No = not 100% true.
A matrix makes corrected devide measure the same (the same = RGB primaries & white) as reference device. If reference device is not accurate corrected device will carry the same inaccuracy as the reference.
A CCSS uses a reference spectral power distrubution to self correct itselft based on firmware sensivity curves. This last part is the key to accuracy although accurate CCSS sample may help depending on where colorimeter sensivity curves are off from std observer.
Since WOLED or RGB oled spectral power distrubution shows no narrow spikes (excluding some roll off in munki readings of shorter wavelengths), a matrix shuld be accurate if you make it for your own devices.
With very narrow spectral power distrubution even 3nm readings may not be enough and some 1nm CCSS may be more accurate…. although such displsy will show observer metameric failure with some people.Well, I did 3x matrix corrections right after another, and 3x spectral corrections right after another. But what concerns me, is that the matrix corrections always show very different measurements, whereas the spectral corrections all seems to be quite equal. My logical thinking tells me, that the matrix corrections should be less trusted. Or am I wrong? That’s just why I tend to use spectral corrections, as the i1d3 has the spectral sensitivity built into, according to ArgyllCMS https://www.argyllcms.com/doc/ccxxmake.html :
“For Colorimeters that have sensor spectral sensitivity calibration information built into them (ie. the X-Rite i1d3, and DataColor Spyder4 & Spyder5), ccxxmake allows a creation of a calibration spectral sample (ccss) for a particular Display, by making use a reference Spectrometer instrument.”
As explained above a matrix matches RGB primaries and whitre from one device to another. if uncorrected i1d3 are consistent (under some dE for repeatability) for several display types, the source of error comes from:
a) display itseft, not consistent over time (tremor/shivering in light emited)
b) munki readings are not consistent
If a) uncorrected i1d3 should show the same tremor.*****************************
Also please notice that your issues has NOTHING TO DO with corrections. Corrections try to match RGB poriaries & white to some refernce and expect some linearity (al the other colors being a linear combination of spectral power distribution of primaries).
The issues with red black clipping breaks this premise and no correction will solve it.
I mean, you can try whatever corrections you want, but your test will be useless.If it can be fixed in some way as Ted implies, then edge/threshold params in USB HID command needs ti be modified for very low light readings in OLED. Then USB will read “something”, some RGB counter value and you can appli correction after.
If there is no software tweak that can overcome red sensor clipping near blakc in very low light readings fro this spectral power distribution, then it cannot be fixed.If Graeme is not answering maybe you may try with Arthur liebermann or soem of the new guys developing HCFR that embeds ArgyllCMS measurement code and ask them for slightly modifed versions when after measurement re try due to RGB counters reported by USB being=000, modify edges/theshold/timeout params for USB “measure” HID command.
If the issue in newer i1d3 can be fixed, it would need to be fixed there.It is unfortunate that the positioning theory did not hold. I didn’t actually test that with my panel bec it’s on a mount and is difficult to unmount/remount.
FWIW Graeme spent probably 2 wks working with me through various debug builds and I was getting no readings at all on dark reds. He even purchase (on his own funding) a revised firmware i1 display pro to match my firmware version. After getting success with the positional theory on iPhone, we agreed that this is really an x-rite issue.
The reality is — this is such a legacy product for x-rite that they’ve spun it off via Calibrite.
I wonder what CalMan does to compensate, as this (and its successors) is (are) a semi-popular monitor amongst studios — which almost all (I have not heard of any exceptions) use CalMan here in the U.S. (To enforce standardization, a CalMan workflow is designed for each studio’s standards and the creator simply executes the workflow at the prescribed frequency.)
There is a post on LiftGammaGain where TED calibrates this monitor and says that with the default settings the colours are clipping (especially red). Could this be the cause for all the weird behaviour of the reds?
He mentions it here and also some posts further down the thread: https://liftgammagain.com/forum/index.php?threads/lg-32-oled-32ep950.15817/page-9
There is a post on LiftGammaGain where TED calibrates this monitor and says that with the default settings the colours are clipping (especially red). Could this be the cause for all the weird behaviour of the reds?
He mentions it here and also some posts further down the thread: https://liftgammagain.com/forum/index.php?threads/lg-32-oled-32ep950.15817/page-9
No, you’re absolutely right. This could be the solution. I didn’t see that statement about saturation. Thank you!
There is a post on LiftGammaGain where TED calibrates this monitor and says that with the default settings the colours are clipping (especially red). Could this be the cause for all the weird behaviour of the reds?
I think he is talking about near 100% saturation patches at a given signal encoding format (example: 255, 0, 0 and 254,0,0 and 253,0,0, all clipping, same coords), not about your issue.
What correction are you using btw? I returned my Oled a while a go because of bad side bleed so I can’t check my old calibration if it has the same problem.
Do you have the same side bleeding? I saw it very clearly at almost black dark gray areas near the side of the monitor..
As explained above a matrix matches RGB primaries and whitre from one device to another. if uncorrected i1d3 are consistent (under some dE for repeatability) for several display types, the source of error comes from:
a) display itseft, not consistent over time (tremor/shivering in light emited)
b) munki readings are not consistent
If a) uncorrected i1d3 should show the same tremor.So just to make sure: You also think that the difference in those three matrices shows that there must be a problem somewhere?
If yes, how can I find out which component gives me bad results?
