AVS Forum banner

341 - 360 of 1591 Posts

·
Registered
Joined
·
596 Posts
So you use an OFPS patchset but don't bother to mention that it's the product of ArgyllCMS's targen tool ?



(A bit of credit where credit is due always helps in balancing the Lightspace spin machine.)


You are totally right im sorry that I didn't mentioned that. The base was created with the testchart editor of Displaycal and the rest was edited by hand.
 

·
Registered
Joined
·
1,007 Posts
(A bit of credit where credit is due always helps in balancing the Lightspace spin machine.)
this is a tough and false attack on your part Graeme. Fabio and me are not part of any lightspace spin machine. Ask Steve if we've ever given him discounts. When we have to beat we don’t look at anyone’s face, just like when we have to give credit. We are a group of 4 guys (one of which does not participate in any forum) who invent and test FREE methods which then everyone will use for FREE. Fabio simply forgot to mention argyll and apologized. Among other things, personally, I do not believe that the patchset used is so important for the success of the calibration. We do not use DisplayCal (or Argyll) because two of us own a Discus that is not supported by Argyll, although some of us have offered to give you one so that you can add support. But you refused and you had your good reasons. Anyway, credits goes to the guys who wrote THIS document too.
 
  • Like
Reactions: BlackJoker

·
Registered
Joined
·
9,439 Posts
Discussion Starter #343 (Edited)
Hi.

I have a doubt about device control. Is it able to use the internal patterns of the LG C9 for calibration?

Thanks in advance.
Hi,

iTPG hasn't been added to current version of DeviceControl Interface because:

1) It has limitation to work only of you have Contrast @ 85, Brightness @ 50 and Color @ 50. With any other values of these controls it will not work for SDR patch generation.

The problem is that most of TV's are not having good near black, so it will require to adjust Brightness to 51-52 value most of times or up to 55-65 range when the panel has larger near black clipping issue.

You can say that keeping these default values, the issues of near black can be included to the 1D LUT generation, but in real world (not in feature/virtual world), by using 1D LUT has a lot of problems due to strange internal processing, so this has negative effect to the panel performance, as described here, for that reason we skip using completely the 1D LUT to prevent issue introduced.

2) We are interesting about the results coming only from HDMI Input patch generation or verification. For that reason we generate patterns only using the HDMI Input, so to include all the display internal processing/colorspace conversion during the patch generation.

When you are using iTPG, there video signal processing steps which are bypassed, so you will still need to generate patterns from the HDMI Input to evaluate the results.

For these 2 reasons its not so interesting feature to be added to DeviceControl, as we are interested to maximize and do proper calibration steps correctly.

Using PGeneration, which is bit-perfect solution and low cost solution to use for RGB 16-255/16-235 patch generation with LightSpace, its the recommended solution we suggest to LightSpace/ColourSpace users, as they will be able to use it as 'bit-perfect @ RGB triplet' patch generation to calibrate/verify any display/projector model they want.
 

·
Registered
Joined
·
1,148 Posts
this is a tough and false attack on your part Graeme. Fabio and me are not part of any lightspace spin machine.
The thread is "LG OLED's 3D LUT Profiling using LightSpace" - i.e. it's all about Lightspace. Saying what a wonderful result you got using Lightspace while not mentioning that one part of that success was using ArgyllCMS sure seems like aiding the Lightspace spin that it invented everything to do with display calibration/profiling.
We do not use DisplayCal (or Argyll) because two of us own a Discus that is not supported by Argyll, although some of us have offered to give you one so that you can add support.
No-one has ever offered to supply me with one on a permanent basis.
 

·
aka jfinnie
Joined
·
4,446 Posts
@gwgill

One of the things which is fairly unique to this patch set is that I made a patch list sorter that attempts to deal with the very significant drift experienced by these OLEDs from pixel activity. This works by looking over a rolling period and trying to keep the rolling average patch power for each of the total power and individual sub pixels (WRGB) constant.

This is important because unlike typical display drift which may be a gentle roll in response, the patch sequence induced drift that these displays experience has violent swings directly related to the patch sequence power at a given point.

I tested all the patch sequence sorting options in ArgyllCMS / displaycal (not sure where the division of labour happens there) and they all exhibit a characteristic shape which will show through in profiles. As the drift patches only happen periodically, drift correction won't always make a brilliant correction of a read patch. Lightspace also had this issue with the Ansiometric sequence until I pointed this out and they implemented a bit better algorithm (it's still not brilliant as there is a definite shape that comes through into the profile, but it is more manageable from a drift correction point of view).

Anyway, my utility is pretty rough and ready (I spend the day doing HW and for me once a piece of SW basically functions it is probably done enough!) and the algorithm I used I'm sure isn't optimal. I'll probably never do anything with it again but having that kind of option or a better variant of in ArgyllCMS / displaycal would be of great benefit. Maybe you might consider inclusion of something like this.

Of course there are some other bigger questions - like given that the display response is so largely content dependent, perhaps account needs to be taken during profiling of the average picture levels from the content the viewer actually watches, as a patch sequence may well not be a great representation of typical content average pixel / subpixel values).
 

·
Registered
Joined
·
9,439 Posts
Discussion Starter #346
After hours of testing and uncountable profile sessions I created with the help of our Calibration group a final version of a OFPS based patchset which contains 33p grayscale points such as 33p RGBCMY on top 16p RGBCMY saturation and edge points. This set is non grid based like the screens show and it's working very good.

The LightSpace engine seems to like this set as you can see on the final results. I've never achieved better near black performance and color accuracy before. I also run a 56p grayscale and 5% Sweeps run and on top of that the 1000p profile verification. There is nothing you can do further I guess.





Maybe @ConnecTEDDD can do further checks with ColourSpace.
ColourSpace visuals now, 1000 color points evaluation.

APNG (Animated PNG file) of 2D CIE1931 Chart, the 4 frame loop will display your results filtered to display the dE2000 points with:

All measured points without filtering of dE as frame 1.

Visible only measured points which have 0 - 0.5 dE2000 as frame 2.

Visible only measured points which have 0.5 - 1.0 dE2000 as frame 3.

Visible only measured points which have 1 - 1.5 dE2000 as frame 4.



APNG (Animated PNG file) of 3D CIE1931 Chart, with 4 frame explanation as 2D CIE1931 Chart APNG:



APNG (Animated PNG file) of Normalized RGB Cube, with 4 frame explanation as 2D CIE1931 Chart APNG:

 

·
Registered
Joined
·
1,007 Posts
The thread is "LG OLED's 3D LUT Profiling using LightSpace" - i.e. it's all about Lightspace. Saying what a wonderful result you got using Lightspace while not mentioning that one part of that success was using ArgyllCMS sure seems like aiding the Lightspace spin that it invented everything to do with display calibration/profiling.
Again, I personally do not believe that OFPS had any part of that success. Surely, James @bobof sorting algo had a big part. But, it has been recognized by Fabio @BlackJoker that he forgot to mention Argyll and the german guys that wrote the document about OFPS. He apologized for that.

No-one has ever offered to supply me with one on a permanent basis.
We did but probably we didn't understand each other. Nevermind, it's not something really important.
 
  • Like
Reactions: BlackJoker

·
Registered
Joined
·
1,007 Posts
I forgot instead to post my CalMAN verification charts. That way, also people not really familiar with LightSpace can truly understand the results I (we) obtained with LS.

I'll also update my previous post with these:








@jrref John, you gonna love the 9M at dE 0.65 :D
 
  • Like
Reactions: chunon

·
Registered
Joined
·
1,007 Posts
A very important thing that I forgot to write is that it took less than 2 hours and 30 minutes to achieve those results and to have all TV Picture Modes calibrated (!):
- 5 minutes to adjust SM WB
- 2h 18' to profile
- 3 minutes to create and upload the 3DLUT to the TV.

The goal now is to reduce measured points and to find a valid method to profile with full field patches to avoid stabilization patch, which I use at 0.35 sec only to avoid the (already low) risk of burn in. Very near to reach both.
 

·
Registered
Joined
·
2,211 Posts
If Farthest Point patch sets really bring an improvement, we will add them to LightSpace.
Nothing to do with any other calibration system, as the concept is well know, and has been for years.
(Credit to those that defined the concept in the first place, including the paper miki linked to.)
We have not bothered with it as yet, as any benefits have not previously shown to be worth while.
(For most, and Anisometric approach works very well.)

The WOLED tests LightSpace users are doing may show enough of a benefit...
Especially with the sorting approach bobof has implemented.

We will see.

Having said that, the fact LightSpace can work with any patch set a user wants is probably enough.
That allows the user to define whatever patch set they want, for themselves - sourcing from anywhere.

Steve
 

·
aka jfinnie
Joined
·
4,446 Posts
If Farthest Point patch sets really bring an improvement, we will add them to LightSpace.
Nothing to do with any other calibration system, as the concept is well know, and has been for years.
(Credit to those that defined the concept in the first place, including the paper miki linked to.)
We have not bothered with it as yet, as any benefits have not previously shown to be worth while.
(For most, and Anisometric approach works very well.)

The WOLED tests LightSpace users are doing may show enough of a benefit...
Especially with the sorting approach bobof has implemented.

We will see.

Having said that, the fact LightSpace can work with any patch set a user wants is probably enough.
That allows the user to define whatever patch set they want, for themselves - sourcing from anywhere.

Steve
I'm not sure how much benefit the patch sorting brings over the current ansio sequence in real testing. I don't actually have an OLED display - I only did this as the theory was interesting to me and it helped some friends out.

It is definitely possible to get better drift behaviour than the current revised ansio patch sequence by careful control of the preroll and patch order, but the current ansio sequence has a relatively soft curve to it I believe so the drift algo is likely able to deal with most of it.

For anyone interested one of the threads on this at the LS forum:
https://www.lightillusion.com/forums/index.php?action=vthread&forum=8&topic=485

This was drift from the original ansio sequence (no longer in use):


An analysis I did of what I thought was the original patch sequence power over the course of the sequence. This analysis puts the RGB patch values through gamma function to work out amount of light and has an algo to try and work out WRGB subpixel values (approx):


This is what I think the current sequence looks like through the same analysis - note the gentle curve trend. A bit spikey too.


This is a patch sequence for the same analysis after being pushed through my "algorithm" to try and keep the average total plus WRGB levels constant on a rolling basis through the patch sequence. (note - ignore the difference in y scale, just look at the shape)


Of course it is likely my very basic model for WRGB mixing is flawed, and really you should adjust for the deviance from native panel white point for the display in it's profiled state, as that will affect the WRGB mixing employed for a given patch value. The proof in the pudding though that this seems to be "enough" is that when appropriately pre-rolled these sets processed thus seem to exhibit very small levels of drift.

One other issue to be aware of - if you have variable patch display times (because you have longer integration times for darker patches, or averaging below certain nit levels) this algorithm won't work as well. Ideally you would understand the effect of the patch value on the patch display time and also use that as a factor in your sorting algorithm. However, that is beyond the scope of what I can probably be bothered with (not even having an OLED to play with!!! :) ). For some meters this can't be worked around - eg for the Basiccolor Discus the variable read times can't be defeated.

This is a typical drift plot for a sorted sequence measured with a K10A set up for constant patch display time. I think it is about as flat as you're likely to get for a consumer OLED without taking this to an extreme such as power profiling the actual display in advance of running the actual profile, and using that power profile to sort the patch set.
 

Attachments

·
Registered
Joined
·
822 Posts
One of the things which is fairly unique to this patch set ...
Since you are talking about this a lot, is it publicly available? I use DisplayCal (ArgyllCMS) with id3pro on B8.
 

·
aka jfinnie
Joined
·
4,446 Posts
Since you are talking about this a lot, is it publicly available? I use DisplayCal (ArgyllCMS) with id3pro on B8.
I'll leave it for @BlackJoker to link to - I don't actually know which sequence he used in the above. I just provided a script for sorting the patches.

I've attached the script here. It's Python 3.7 and you can either invoke it without arguments and it will give you a few prompts for what patch set you'd like it to generate (it has a built in basic cube + extra RGBCMYW patches generator) or you can put a patch CSV file in the same directory and run the script with the patch file name as an argument; it then processes the patch set and outputs it.

It additionally makes you a pre-roll set if you tell it when it asks. The pre-roll set is the first n patches of the sequence, with the order reversed, and with specified drift patches interspersed (LS doesn't put drift patches up for display during pre-roll, which can lead to a slightly different panel temp for preroll vs real profiling as the drift patches increase the average power of the patches).

This script is rough and don't expect fancy pants error handling - do something silly and you'll get an exception likely. But it does work and it is free... :) . Hope it is useful.
 

Attachments

·
Registered
Joined
·
9,557 Posts
For beginners like me:

"OFPS: Full spread patches are distributed according to the default or chosen algorithm. The default algorithm will optimize the point locations to minimize the distance from any point in device space, to the nearest sample point. This is called Optimized Farthest Point Sampling (OFPS)"

You keep mentioning a 0.35second stabilisation patch. Please can you explain, is this 0.35 of black between EVERY patch, or something else?

TIA
 

·
Registered
Joined
·
51 Posts
Hi,

iTPG hasn't been added to current version of DeviceControl Interface because:

1) It has limitation to work only of you have Contrast @ 85, Brightness @ 50 and Color @ 50. With any other values of these controls it will not work for SDR patch generation.

The problem is that most of TV's are not having good near black, so it will require to adjust Brightness to 51-52 value most of times or up to 55-65 range when the panel has larger near black clipping issue.

You can say that keeping these default values, the issues of near black can be included to the 1D LUT generation, but in real world (not in feature/virtual world), by using 1D LUT has a lot of problems due to strange internal processing, so this has negative effect to the panel performance, as described here, for that reason we skip using completely the 1D LUT to prevent issue introduced.

2) We are interesting about the results coming only from HDMI Input patch generation or verification. For that reason we generate patterns only using the HDMI Input, so to include all the display internal processing/colorspace conversion during the patch generation.

When you are using iTPG, there video signal processing steps which are bypassed, so you will still need to generate patterns from the HDMI Input to evaluate the results.

For these 2 reasons its not so interesting feature to be added to DeviceControl, as we are interested to maximize and do proper calibration steps correctly.

Using PGeneration, which is bit-perfect solution and low cost solution to use for RGB 16-255/16-235 patch generation with LightSpace, its the recommended solution we suggest to LightSpace/ColourSpace users, as they will be able to use it as 'bit-perfect @ RGB triplet' patch generation to calibrate/verify any display/projector model they want.
One more question, it is curiosity.

I see the most of the calibration are SDR but those TVs (in theory) are designed for HDR. Is it technical problems?

I am thinking about buy the LG C9, Samsung Q90R or TCL X10 (8 in USA), I know it is a mess but the market looks a mess, actually. I want to be sure, I make the correct choice, I don't want to have to change the next year.

Thanks in advance.
 

·
aka jfinnie
Joined
·
4,446 Posts
One more question, it is curiosity.

I see the most of the calibration are SDR but those TVs (in theory) are designed for HDR. Is it technical problems?

I am thinking about buy the LG C9, Samsung Q90R or TCL X10 (S in USA), I know it is a mess but the market looks a mess, actually. I want to be sure, I make the correct choice, I don't want to have to change the next year.

Thanks in advance.
I don't think any OLED is really "designed for HDR". Particularly when you consider the drift is so bad with just SDR luma levels, and the saturation colour volume shrinks so much as you go up through the luminance range.

Doesn't make them bad TVs though.
 

·
Registered
Joined
·
4,991 Posts
One more question, it is curiosity.

I see the most of the calibration are SDR but those TVs (in theory) are designed for HDR. Is it technical problems?

I am thinking about buy the LG C9, Samsung Q90R or TCL X10 (8 in USA), I know it is a mess but the market looks a mess, actually. I want to be sure, I make the correct choice, I don't want to have to change the next year.

Thanks in advance.
All of today's sets are capable of being calibrated for SDR. Sony sets even use their SDR settings as the underpinning for their HDR10 and DV picture modes. But HDR is much more difficult - and expensive - to calibrate separately for. Until relatively recently, there were no standards for HDR tonemapping, which is necessary because current displays cannot meet the requirements for gamut coverage or luminance specified. It has been up to each manufacturer to chart their own course.

With the current pace of development and range of technologies in home theater displays, I don't think there IS a "correct choice"...
 

·
Registered
Joined
·
5,163 Posts
Since you are talking about this a lot, is it publicly available? I use DisplayCal (ArgyllCMS) with id3pro on B8.
Isn't the above the same thing as DisplayCal/ArgyllCMS does if you set it up correctly, directing what percentage H/M/L light levels and making a patch set. Then rerunning the patch set that refines the patchset for the display you are working on and using the new patch set as your preference.

ss
 

·
Registered
Joined
·
1,148 Posts
@gwgill
I tested all the patch sequence sorting options in ArgyllCMS / displaycal (not sure where the division of labour happens there) and they all exhibit a characteristic shape which will show through in profiles. As the drift patches only happen periodically, drift correction won't always make a brilliant correction of a read patch. Lightspace also had this issue with the Ansiometric sequence until I pointed this out and they implemented a bit better algorithm (it's still not brilliant as there is a definite shape that comes through into the profile, but it is more manageable from a drift correction point of view).
That's interesting. By default targen will order display patches so as to minimize the change in color between the patches, so as to minimize any display settling time. This is probably opposite to an order that will minimize display auto power regulation effects. Unfortunately I don't have access to the types of displays that have this type of characteristic, so really haven't had the opportunity to develop algorithms to minimize such effects.
I'll probably never do anything with it again but having that kind of option or a better variant of in ArgyllCMS / displaycal would be of great benefit. Maybe you might consider inclusion of something like this.
Sure - can you outline what your code attempts to do ? (Perhaps email me directly).
 

·
Registered
Joined
·
1,148 Posts
We did but probably we didn't understand each other. Nevermind, it's not something really important.
Nothings turned up on my doorstep :-(

Seems like it's a bit moot now that basICColor have gone under...
 
341 - 360 of 1591 Posts
Top