LightSpace 3D LUT Home Cinema Calibration Software - Page 66 - AVS Forum | Home Theater Discussions And Reviews
Forum Jump: 
 1103Likes
Reply
 
Thread Tools
post #1951 of 2392 Old 02-16-2019, 08:53 AM
aka jfinnie
 
Join Date: Aug 2015
Location: Norwich, UK
Posts: 3,268
Mentioned: 53 Post(s)
Tagged: 0 Thread(s)
Quoted: 2640 Post(s)
Liked: 1738
Quote:
Originally Posted by omarank View Post
Thanks for such a detailed analysis of my display profile. It is quite helpful and interesting. I will have a deeper look later.

But alas, it is like that in all the different modes that I tried. I can't do a better pre-conditioning using the TV's controls, apparently. But yes, maybe I can set the output range as 63-255 in madVR and then do the profiling. I will have to set TV brightness in such a way then that levels upto 63 get clipped (not sure if the brightness control is that flexible). Perhaps, I will get much better results then. What do you think?
Don't do that. 0-63 was only the example in the particular direction in the gamut. In other places the smallest value will be less (if you move along the edge of the triangle towards the secondary, and look at the secondary clipping points, you'd see they're only 2 or 3 clipping). You need to be thinking about this unfortunately in 3 at least 2 dimensions if not 3, which is why it is hard for end users to get their head round this.

I'm surprised there isn't a mode or setting which could get you there (though of course I don't have a suitable mode on my PJ). But you're doing something much simpler; REC709 on a TV that basically covers REC709. I'm sure there must be a better mode there somewhere... I'd try reducing colour below where it is, or looking at the other preset modes. What model Sony TV is it?

Having said that, as you said, you have been able to get useable LUTs out of other SW, so it is a shame not to be able to get something at least useable (if not optimal) out of it as it is.
bobof is offline  
Sponsored Links
Advertisement
 
post #1952 of 2392 Old 02-16-2019, 09:40 AM
Member
 
Join Date: Mar 2016
Posts: 56
Mentioned: 5 Post(s)
Tagged: 0 Thread(s)
Quoted: 36 Post(s)
Liked: 30
Ok, I see your point.

I will have to do a deep dive analysis of the profile data, to find an optimal output range, which then may or may not help.

It's a Sony KDL W800B LED TV. I have tried calibrating in Cinema mode, Game mode, Graphics mode and Standard mode. LS LUTs had the same issues in all the modes (and so, basically TV has the same issues across these modes). During the pre-calibration setup, I analyzed the other modes too for gamut coverage, it was all the same. Next time, I will be lowering the color control from the neutral setting to see if that helps.
omarank is offline  
post #1953 of 2392 Old 02-16-2019, 10:21 AM
AVS Forum Special Member
 
Manni01's Avatar
 
Join Date: Sep 2008
Posts: 9,109
Mentioned: 329 Post(s)
Tagged: 0 Thread(s)
Quoted: 5439 Post(s)
Liked: 5639
Quote:
Originally Posted by Light Illusion View Post
Professional, or home TV - makes no difference.

If a display clips/crushes luma, in either black or white, no-one would accept it.

And if there were no user controls to fix the clipping/crushing before the display was profiled for calibration, it would be rejected out of hand.

That is what the ContrastCal/BrightnessCal images are for. To setup the display before profiling.

We have never made saturation/gamut versions as it was never expected any display would be so bad as to need them.

But, this is exactly the situation with the JVC, with saturation/gamut clipping.

It is clipping in exactly the same way as the above description for luma.

If the problem can't be fixed within the display prior to profiling, it is totally unacceptable.

The display is not fit for purpose.

It is that simple.

Go shout at JVC, and demamd they fix their appaling display.

As for a LightSpace solution, I have given it to you.
Target a colour space that is below the threshold of the issue, and then concatenate with the desired colour space.

That is why LightSpace has such tools.

Steve
This is complete nonsense and pure FUD. If I was JVC, I would sue Light Illusion for libel.

You either don't know what these displays are capable of, or don't understand what we are after as consumers using these projectors for playback, not grading content.

Again, Lightspace is perfectly able to deliver excellent results with JVC and other projectors, as long as they do reach close to the target gamut. It's only with those that don't (either from the start, or after a while, mine had no issue until after 2000 hours), that Lightspace fails to produce acceptable results without using the convoluted LUT concatenation procedure.

I have no idea why you keep dismissing the fact that:

1) Lightspace is perfectly able to produce excellent results with many if not most JVCs, and only fails with those not able to meet 100% of the target
2) Even in this case, Lightspace is able to produce excellent results with the LUT concatenation procedure
3) Other calibration software produce excellent results using the same LS profile even with these extreme cases (Bobof's, my old rs500) without having to go through a convoluted procedure.

You can twist it any way you can, these are facts. No wonder JVC are not replying to you, they do have far more important issues to solve than making their projectors "better" so that Light Illusion don't have to improve their software!

I have obtained excellent results on my new rs2000 after setting 100% white to D65 and running a Lightning LUT in Calman (101 points, 10 minutes with my Discus trained to my i1pro2).

0.6 dE average / 1.8 dE max in colorchecker SG, no visible posterization on cyan or near black, or on red as this unit is slightly undersaturated on red (it still covers close to 99% of P3). I've posted detailed measurements in the new JVC calibration thread.

This is only possible because the unit is very linear. Otherwise, it would need a larger LUT.

It throws a stunning picture, both accurate and film-like, and I would be mad to send it back just because Light Illusion have decided that JVC was where to point the finger at.

I really don't have the time at the moment as when I can get good results like this, I'd rather watch content than posting in a forum, but when I find the time, I will measure the baseline (it's a user3 calibration using the DCI-P3 color profile, the 6500K color temp profile, a gamma 2.2 preset, the P3 filter in low lamp, delivering 120nits peak brightness and 30,000:1 native on/off contrast calibrated). I'll also measure the results of the Calman Lightning LUT, and I'll measure the results of a Lightspace 17x17x17 LUT (which I expect will be better, as it will be using close to 5000 points instead of just 101). Just to prove that there is nothing wrong with the JVCs, or even with Lightspace, when the software doesn't meet a situation for which it can't find a compromise as good as other solutions.

What is very clear is that improving the software for JVC or MadVR users isn't worth Light Illusion's time. You've made it very clear over the last few months.

I hope that users of both will take note.

I also hope that Light Illusion will either support these situations better, or make it clear on their website that they don't support displays that don't meet professional standards.

Batch Utility V4.02 May 16 2019 to automate measurements files for madVR with support for BD Folders

Last edited by Manni01; 02-16-2019 at 02:56 PM.
Manni01 is online now  
Sponsored Links
Advertisement
 
post #1954 of 2392 Old 02-16-2019, 10:22 AM
aka jfinnie
 
Join Date: Aug 2015
Location: Norwich, UK
Posts: 3,268
Mentioned: 53 Post(s)
Tagged: 0 Thread(s)
Quoted: 2640 Post(s)
Liked: 1738
Quote:
Originally Posted by omarank View Post
Ok, I see your point.

I will have to do a deep dive analysis of the profile data, to find an optimal output range, which then may or may not help.

It's a Sony KDL W800B LED TV. I have tried calibrating in Cinema mode, Game mode, Graphics mode and Standard mode. LS LUTs had the same issues in all the modes (and so, basically TV has the same issues across these modes). During the pre-calibration setup, I analyzed the other modes too for gamut coverage, it was all the same. Next time, I will be lowering the color control from the neutral setting to see if that helps.
I'm just working on a basic tool to try and find these things almost automatically. When I have something working I'll try it with your profile and see if it works, might be quicker. FYI you can usually spot the issue with fairly small profiles. In your case you were doing 21^3 profile, which obviously takes a long time, You had at least 6 pts of duplicates out of 21pts at that direction I mentioned, 10^3 will almost certainly show it and take almost 1/10th the time to run.
omarank likes this.
bobof is offline  
post #1955 of 2392 Old 02-16-2019, 09:11 PM
AVS Forum Special Member
 
Light Illusion's Avatar
 
Join Date: Aug 2010
Posts: 1,833
Mentioned: 28 Post(s)
Tagged: 0 Thread(s)
Quoted: 779 Post(s)
Liked: 1144
James, what would probably work best it to build a .CSV profile set that just has gamut edge points, and then a coupe of rows inwards from the gamut edge.

So if looking at green, 0,255,0, would be gamut edge, and then 1,255,1 would be the next step inwards, and then 2,255,2, and so on.

That way you can quickly see where the gamut clipping starts, and define the best target colour space.

No need for any more central volumetric colours in the profile at all, but I would plot the full luma range, as well as various colours on each gamut edge, probably use the gamut edge colours from a 21^3 profile as the starting colours.

Steve
bobof likes this.

Steve Shaw
LIGHT ILLUSION

Light Illusion is offline  
post #1956 of 2392 Old 02-16-2019, 09:31 PM
AVS Forum Special Member
 
Light Illusion's Avatar
 
Join Date: Aug 2010
Posts: 1,833
Mentioned: 28 Post(s)
Tagged: 0 Thread(s)
Quoted: 779 Post(s)
Liked: 1144
Oh -Janes - you could actually use the new Remote Control and Secondary Execution capabilities, inherited from ColourSpace and in the present LightSpace Beta, to automatically run such a profile, and generate a new colour space target...

This should streamline the whole process, and enable any external processing and action to be taken on measurements LightSpace takes - either under direct 'point read' control from the external program, or as a program call on a set of data immediately after a profile.

Basic info is now within the website user guides (Profiling Manual), and there are .pdfs and an example .bat file available for further info.

You really should be able to automate anything you want now.

Steve
bobof likes this.

Steve Shaw
LIGHT ILLUSION

Light Illusion is offline  
post #1957 of 2392 Old 02-17-2019, 02:22 AM
aka jfinnie
 
Join Date: Aug 2015
Location: Norwich, UK
Posts: 3,268
Mentioned: 53 Post(s)
Tagged: 0 Thread(s)
Quoted: 2640 Post(s)
Liked: 1738
Quote:
Originally Posted by Manni01 View Post
1) Lightspace is perfectly able to produce excellent results with many if not most JVCs, and only fails with those not able to meet 100% of the target
2) Even in this case, Lightspace is able to produce excellent results with the LUT concatenation procedure
3) Other calibration software produce excellent results using the same LS profile even with these extreme cases (Bobof's, my old rs500) without having to go through a convoluted procedure.
For what it is worth, I think this probably affects anyone with a 2017 or earlier X series trying to build P3 LUTs in anything other than the non-wide-gamut "Profile Off" mode. I'm yet to see evidence anyone has been able to do this. I think your profile through the most basic concatenation process as described on the web previously (not sure if it has been updated in light of the discussions) would probably result in an OK LUT, but probably with some odd points in the middle of space. The only reason I can think that you might not have clipped points would be if the profile going in was very small, and so the clipped points are very minimal.

Quote:
Originally Posted by Light Illusion View Post
James, what would probably work best it to build a .CSV profile set that just has gamut edge points, and then a coupe of rows inwards from the gamut edge.

So if looking at green, 0,255,0, would be gamut edge, and then 1,255,1 would be the next step inwards, and then 2,255,2, and so on.

That way you can quickly see where the gamut clipping starts, and define the best target colour space.

No need for any more central volumetric colours in the profile at all, but I would plot the full luma range, as well as various colours on each gamut edge, probably use the gamut edge colours from a 21^3 profile as the starting colours.

Steve
Hi Steve,
Indeed, that is what "you" (I'm (almost) joking, but you know what I mean) need to do to find the regions that are problematic. Most folk can't look at a CIE diagram and know the relationships between the RGB values that make each point without headscratching, so creating such a CSV is going to be over their head.. If that is the workflow you suggest, you'll probably need to make the patch set and explain to folk how to inspect it. Having done it, it is still a pain in the &£$*& because the UI makes it quite hard to inspect. This isn't really a solution for all but the hardcore.

Even when you do that, as I say I'm pretty sure that because you have to size the gamut to cut out all these points as they are stacked, I believe you've artificially shrunk the gamut by one patch step ish. (how much depends on how unlucky you are with your patch step size and exactly where it breaks between patches).

I really do think some kind of automation is the only option here. It really isn't practical for all but the very most knowledgeable folk to work this stuff out; you are not selling this >here< in the main to folk who are calibrating day in day out and know this all inside out, and even then, show me a calibrator who'd want to spend that kind of time on this aspect of a display. That mode isn't getting calibrated with anything other that fit LUT and that's what they're getting...!

Anyway, here is the output of something I've been hacking together to parse the profile and find the duplicates at the gamut border. It now flattens the drift data (luma only for now) onto the values also. Too rough to be useful to anyone other than me though.

The secondary execution stuff looks interesting, but this is a pretty big project for something that should just (arguably) happen as one of the first steps in the LUT creation process - size the useable RGB extents of the output values and latch the LUT to that, then fill in the detail.

Code:
checkprofile.py
inspect a Lightspace builder_color_space for likely issues for LUT generation
(c)2019 Auvien Limited, all rights reserved
20190216  James Finnie        Initial version
---------------------------------------------------------------------
Profile embedded name: 0211 10^3 drift 25 jeti lens  1d x7900 -5 reference low 2.4 d65 
---------------------------------------------------------------------
Create drift coeficients
---------------------------------------------------------------------
  Red values: 10 [0, 28, 56, 85, 113, 141, 170, 198, 226, 255]
Green values: 10 [0, 28, 56, 85, 113, 141, 170, 198, 226, 255]
 Blue values: 10 [0, 28, 56, 85, 113, 141, 170, 198, 226, 255]
---------------------------------------------------------------------
blue
---------------------------------------------------------------------
cyan
  372 ( 28,113,113)   4480.471 0.2099 0.3158       vs         252 (  0,113,113)   4508.484 0.2099 0.3156
  678 ( 28,141,141)   7606.253 0.2096 0.3131       vs         480 (  0,141,141)   7542.872 0.2096 0.3133
  770 ( 56,141,141)   7610.490 0.2096 0.3129       vs         678 ( 28,141,141)   7606.253 0.2096 0.3131
  904 ( 28,170,170)  11955.482 0.2105 0.3148       vs         796 (  0,170,170)  12021.091 0.2104 0.3150
  837 ( 28,198,198)  16973.535 0.2106 0.3141       vs         941 (  0,198,198)  17163.081 0.2109 0.3147
  569 ( 56,198,198)  17052.200 0.2105 0.3136       vs         837 ( 28,198,198)  16973.535 0.2106 0.3141
  519 ( 85,198,198)  16954.068 0.2106 0.3135       vs         569 ( 56,198,198)  17052.200 0.2105 0.3136
  287 ( 28,255,255)  31118.410 0.2119 0.3126       vs         391 (  0,255,255)  30813.069 0.2118 0.3126
  217 ( 56,255,255)  31408.092 0.2119 0.3127       vs         287 ( 28,255,255)  31118.410 0.2119 0.3126
  139 ( 85,255,255)  31201.788 0.2118 0.3126       vs         217 ( 56,255,255)  31408.092 0.2119 0.3127
  105 (113,255,255)  31588.561 0.2119 0.3128       vs         139 ( 85,255,255)  31201.788 0.2118 0.3126
11 duplicate(s) 11.0 %
---------------------------------------------------------------------
green
---------------------------------------------------------------------
green->yellow
   22 ( 28, 56,  0)    769.514 0.2912 0.6589       vs          10 (  0, 56,  0)    762.428 0.2911 0.6587
   60 ( 28, 85,  0)   2080.959 0.2915 0.6593       vs          38 (  0, 85,  0)   2059.206 0.2914 0.6600
  230 ( 56,141,  0)   6806.025 0.2929 0.6600       vs         134 ( 28,141,  0)   6779.215 0.2930 0.6596
  194 ( 28,170,  0)  10701.924 0.2938 0.6597       vs         120 (  0,170,  0)  10732.512 0.2941 0.6600
  246 ( 56,170,  0)  10661.241 0.2940 0.6598       vs         194 ( 28,170,  0)  10701.924 0.2938 0.6597
  268 ( 28,198,  0)  15538.440 0.2956 0.6595       vs         226 (  0,198,  0)  15552.635 0.2954 0.6594
  360 ( 28,226,  0)  21049.023 0.2973 0.6586       vs         274 (  0,226,  0)  21169.628 0.2977 0.6583
  448 ( 56,226,  0)  20831.640 0.2974 0.6585       vs         360 ( 28,226,  0)  21049.023 0.2973 0.6586
  662 ( 85,226,  0)  21229.901 0.2974 0.6585       vs         448 ( 56,226,  0)  20831.640 0.2974 0.6585
  542 ( 28,255,  0)  27757.057 0.2999 0.6566       vs         436 (  0,255,  0)  27668.979 0.2999 0.6573
  580 ( 56,255,  0)  28083.476 0.2999 0.6572       vs         542 ( 28,255,  0)  27757.057 0.2999 0.6566
  814 ( 85,255,  0)  28183.166 0.2998 0.6570       vs         580 ( 56,255,  0)  28083.476 0.2999 0.6572
  998 (113,255,  0)  28073.443 0.2998 0.6573       vs         814 ( 85,255,  0)  28183.166 0.2998 0.6570
13 duplicate(s) 13.0 %
---------------------------------------------------------------------
omarank likes this.

Last edited by bobof; 02-17-2019 at 02:53 AM.
bobof is offline  
post #1958 of 2392 Old 02-17-2019, 10:21 AM
AVS Forum Special Member
 
Manni01's Avatar
 
Join Date: Sep 2008
Posts: 9,109
Mentioned: 329 Post(s)
Tagged: 0 Thread(s)
Quoted: 5439 Post(s)
Liked: 5639
Quote:
Originally Posted by bobof View Post
For what it is worth, I think this probably affects anyone with a 2017 or earlier X series trying to build P3 LUTs in anything other than the non-wide-gamut "Profile Off" mode. I'm yet to see evidence anyone has been able to do this. I think your profile through the most basic concatenation process as described on the web previously (not sure if it has been updated in light of the discussions) would probably result in an OK LUT, but probably with some odd points in the middle of space. The only reason I can think that you might not have clipped points would be if the profile going in was very small, and so the clipped points are very minimal.
One last time:

Lightspace (at least with V8) could produce excellent results with my RS500. I never had to use profile off, which in my case always provided worse results with P3 because it can't use the filter (unless you use arcane commands every single time you want to enable the profile, so no thanks). The results attached below, with my RS2000, are very similar to those I used to get with the RS500 when it was linear enough to be calibrated with a Lightning LUT.

By excellent, I don't mean perfect. I mean making the most of the capability of the display, providing a significant improvement vs using no LUT, without causing artifacts (such as posterization) that would negate those improvements. If I get this, I'm happy. Projectors drift, you have to recalibrate every 300-500 hours if you want a close to reference calibration, so "perfect" wouldn't stay "perfect" for very long anyway. I'm not grading content with these, I only want to watch content knowing that I'm reasonably close to the filmmakers's intent, so that I can both enjoy and evaluate their work. No more, no less.

I'm glad to see that Steve is starting to provide support for the LUT concatenation procedure. I see it makes engineers such as yourself happy, which is great.

I personally prefer to spend more time watching films than watching patterns, so my limit is around 3-4 hours per calibration session. A bit more when I get a new projector and do a deep dive, but that's about it.

Hopefully at some point Lightspace will reach a stage where we (non-engineers) can get good results without spending a day doing manually what the software should be doing automatically. This is what DisplayCAL does from the same set of data.

If DisplayCAL was supporting the Discus, I would no doubt be using it when I need larger LUTs. Maybe the new remote control feature in Lightspace would be a way for DisplayCAL to control the Discus and other meters not supported by Argyll? I'll ask Florian.

In the meantime, as I said, I'm getting results I'm very happy with using a Lightning LUT in Calman. It takes me 10 minutes (101 points) and the interface is much better, especially for MadVR users. the post-cal measurements are good enough for me, and there this LUT doesn't produce any visual artifacts such as posterization. Not on cyan, not on red, not near black. The before measurements are taken after setting 100% white to D65.

I have to use Calman anyway for all my pre and post calibration measurements due to the limitations in Lightspace in this area, so until I need a larger LUT and need to investigate again which tool will give me the best results, I'm out
Attached Thumbnails
Click image for larger version

Name:	Manni-discuss.avscience.com-RS2000-DCI-P3 Colorchecker SG Before Lightning LUT.PNG
Views:	46
Size:	1.72 MB
ID:	2527024   Click image for larger version

Name:	Manni-discuss.avscience.com-RS2000-DCI-P3 Colorchecker SG After Lightning LUT.jpg
Views:	35
Size:	476.0 KB
ID:	2527026   Click image for larger version

Name:	Manni-discuss.avscience.com-RS2000-DCI-P3 Gamut Linearity Before Lightning LUT.jpg
Views:	34
Size:	468.5 KB
ID:	2527028   Click image for larger version

Name:	Manni-discuss.avscience.com-RS2000-DCI-P3 Gamut Linearity After Lightning LUT.jpg
Views:	30
Size:	470.0 KB
ID:	2527030   Click image for larger version

Name:	Manni-discuss.avscience.com-RS2000-DCI-P3 Greyscale & RGB Balance Before Lightning LUT.PNG
Views:	42
Size:	1.34 MB
ID:	2527032  

Click image for larger version

Name:	Manni-discuss.avscience.com-RS2000-DCI-P3 Greyscale & RGB Balance After Lightning LUT.PNG
Views:	35
Size:	1.27 MB
ID:	2527034  
omarank likes this.

Batch Utility V4.02 May 16 2019 to automate measurements files for madVR with support for BD Folders

Last edited by Manni01; 02-17-2019 at 10:31 AM.
Manni01 is online now  
post #1959 of 2392 Old 02-17-2019, 11:32 AM
aka jfinnie
 
Join Date: Aug 2015
Location: Norwich, UK
Posts: 3,268
Mentioned: 53 Post(s)
Tagged: 0 Thread(s)
Quoted: 2640 Post(s)
Liked: 1738
Quote:
Originally Posted by Manni01 View Post
One last time:

Lightspace (at least with V8) could produce excellent results with my RS500. I never had to use profile off, which in my case always provided worse results with P3 because it can't use the filter (unless you use arcane commands every single time you want to enable the profile, so no thanks). The results attached below, with my RS2000, are very similar to those I used to get with the RS500 when it was linear enough to be calibrated with a Lightning LUT.

By excellent, I don't mean perfect. I mean making the most of the capability of the display, providing a significant improvement vs using no LUT, without causing artifacts (such as posterization) that would negate those improvements. If I get this, I'm happy. Projectors drift, you have to recalibrate every 300-500 hours if you want a close to reference calibration, so "perfect" wouldn't stay "perfect" for very long anyway. I'm not grading content with these, I only want to watch content knowing that I'm reasonably close to the filmmakers's intent, so that I can both enjoy and evaluate their work. No more, no less.

I'm glad to see that Steve is starting to provide support for the LUT concatenation procedure. I see it makes engineers such as yourself happy, which is great.

I personally prefer to spend more time watching films than watching patterns, so my limit is around 3-4 hours per calibration session. A bit more when I get a new projector and do a deep dive, but that's about it.

Hopefully at some point Lightspace will reach a stage where we (non-engineers) can get good results without spending a day doing manually what the software should be doing automatically. This is what DisplayCAL does from the same set of data.

If DisplayCAL was supporting the Discus, I would no doubt be using it when I need larger LUTs. Maybe the new remote control feature in Lightspace would be a way for DisplayCAL to control the Discus and other meters not supported by Argyll? I'll ask Florian.

In the meantime, as I said, I'm getting results I'm very happy with using a Lightning LUT in Calman. It takes me 10 minutes (101 points) and the interface is much better, especially for MadVR users. the post-cal measurements are good enough for me, and there this LUT doesn't produce any visual artifacts such as posterization. Not on cyan, not on red, not near black. The before measurements are taken after setting 100% white to D65.

I have to use Calman anyway for all my pre and post calibration measurements due to the limitations in Lightspace in this area, so until I need a larger LUT and need to investigate again which tool will give me the best results, I'm out
Improvements to the concatenation process don't make me particularly happy, but working processes are a start to getting things better. Some progress is better than none. However, I'm not even sure all license levels have access to LUT concatenation, so I'm not sure it is an option for HTL users? Steve?

The output from the v8 engine for these profiles is quite different. It wasn't as good in other ways (greyscale was often a bit sucky) but in the specific case of posterisation with this kind of profile it was different. As I say, I think your unit characterisations with V9 (which is all anyone is using these days) are likely wrong.

The v8 is lost in history now, but I did actually install it the other day to verify the above. It still wasn't really "right" in those areas where the profile exhibits gamut clipping within the target colourspace, but it was better and I'm sure for many input profiles that cause issue in V9 it wouldn't have a problem.

FWIW I actually spend very little "useful" time calibrating; these units don't really need much in the way of pre-condition setting if you can run everything through a LUT. The dedicated room means I can run long profiles in the daytime while at work, outside of viewing hours. This case here has admittedly turned into a bit of a project, but I'm thinking about it philosophically for now as spending a little time on something I'm quite interested in and learning a few new tools.

Anyway, time to enjoy some flicks
Manni01 likes this.
bobof is offline  
post #1960 of 2392 Old 02-17-2019, 11:42 AM
AVS Forum Special Member
 
Manni01's Avatar
 
Join Date: Sep 2008
Posts: 9,109
Mentioned: 329 Post(s)
Tagged: 0 Thread(s)
Quoted: 5439 Post(s)
Liked: 5639
Quote:
Originally Posted by bobof View Post
Improvements to the concatenation process don't make me particularly happy, but working processes are a start to getting things better. Some progress is better than none. However, I'm not even sure all license levels have access to LUT concatenation, so I'm not sure it is an option for HTL users? Steve?

The output from the v8 engine for these profiles is quite different. It wasn't as good in other ways (greyscale was often a bit sucky) but in the specific case of posterisation with this kind of profile it was different. As I say, I think your unit characterisations with V9 (which is all anyone is using these days) are likely wrong.

The v8 is lost in history now, but I did actually install it the other day to verify the above. It still wasn't really "right" in those areas where the profile exhibits gamut clipping within the target colourspace, but it was better and I'm sure for many input profiles that cause issue in V9 it wouldn't have a problem.

FWIW I actually spend very little "useful" time calibrating; these units don't really need much in the way of pre-condition setting if you can run everything through a LUT. The dedicated room means I can run long profiles in the daytime while at work, outside of viewing hours. This case here has admittedly turned into a bit of a project, but I'm thinking about it philosophically for now as spending a little time on something I'm quite interested in and learning a few new tools.

Anyway, time to enjoy some flicks
I was talking figuratively when I said watching patterns, I use Teamviewer to control my calibrating PC and I do other things while it runs long profiles in my cinema room, but still, it takes a long time and I'd rather spend 2.5 hours of lamp time on the projector with a film than with patterns.

Even if you spend 2.5 hours out of the room, it still takes 3-4 hours overall provided you do a proper set-up and spend some time afterwards to verify and validate the LUT and its results. That's my limit as I have to do this every 2-3 months.

But right now, it takes me 30 minutes max, and I'm very happy with that
bobof likes this.

Batch Utility V4.02 May 16 2019 to automate measurements files for madVR with support for BD Folders
Manni01 is online now  
post #1961 of 2392 Old 02-17-2019, 03:16 PM
aka jfinnie
 
Join Date: Aug 2015
Location: Norwich, UK
Posts: 3,268
Mentioned: 53 Post(s)
Tagged: 0 Thread(s)
Quoted: 2640 Post(s)
Liked: 1738
Quote:
Originally Posted by omarank View Post
Surprisingly, I have had the same experience. On email conversations, I always got to hear that my TV is a bad display. Not that I say that it is not true. The thing is that despite the display being bad, Argyll/DisplayCAL produces a better looking LUT from the LS profile data. And practically too, I have always ended up using Argyll/Display CAL LUT (for other reasons as well) while watching movies despite slightly higher color accuracy of LS LUTs.

I tried creating fresh LUTs using Map Space, Fit Space, LUT Concatenation and Argyll/DisplayCAL from the Sony TV profile data, and as I visualized them in LS Cube View, I found Map Space one looked pathetic and Argyll/DisplayCAL one looked the neatest. Below are the screenshots:
FYI I ran your profile through an early version of something that attempts to find the gamut extents by looking at the profile data, then chooses the next patch along which should mean the error points are cropped off the LUT. Have a look below. If you scroll to the end, it spits out a suggestion of the x y to use for your intermediate concatenate LUT process (last two columns). I believe they will be slightly inside the edge of the gamut though, which is less than ideal. Be interested to know if that works out for you. I did run this through the LUT concatenation process myself with your profile and though it looked good in the cube view there was still a small area that was a little nasty in the far red corner. I haven't played around with this much.

I'll probably make it output the gamut file to stop having to type it in every time.

Note how many clipped points you have...

Code:
checkprofile.py
inspect a Lightspace builder_color_space for likely issues for LUT generation
(c)2019 Auvien Limited, all rights reserved
20190217  James Finnie        Initial version
---------------------------------------------------------------------
Profile embedded name: Sony GameMode LS-DC Null Lut 21Point Cube
---------------------------------------------------------------------
Create drift coeficients
---------------------------------------------------------------------
  Red values: 21 [0, 12, 25, 38, 51, 63, 76, 89, 102, 114, 127, 140, 153, 165, 178, 191, 204, 216, 229, 242, 255]
Green values: 21 [0, 12, 25, 38, 51, 63, 76, 89, 102, 114, 127, 140, 153, 165, 178, 191, 204, 216, 229, 242, 255]
 Blue values: 21 [0, 12, 25, 38, 51, 63, 76, 89, 102, 114, 127, 140, 153, 165, 178, 191, 204, 216, 229, 242, 255]
Profile has identical axis
---------------------------------------------------------------------
Red extent:
 3204 255   0   0     17.658 0.6178 0.3274
Green extent:
 3174   0 255   0     56.657 0.3015 0.5891
Blue extent:
 3268   0   0 255      7.659 0.1603 0.0764
White extent:
 9261 255 255 255     80.680 0.3113 0.3282
---------------------------------------------------------------------
green->red
 2620 ( 12,216,  0)     39.903 0.3011 0.5894       vs        2228 (  0,216,  0)     39.853 0.3002 0.5901
 3008 ( 12,229,  0)     45.471 0.3014 0.5891       vs        2506 (  0,229,  0)     45.365 0.3005 0.5896
 3118 ( 12,242,  0)     51.284 0.3017 0.5887       vs        2854 (  0,242,  0)     51.246 0.3011 0.5892
 3562 ( 12,255,  0)     56.686 0.3021 0.5887       vs        3174 (  0,255,  0)     56.657 0.3015 0.5891
4 duplicate(s) 0.9 %
---------------------------------------------------------------------
green->blue
---------------------------------------------------------------------
red->green
  372 (102, 12,  0)      2.563 0.6019 0.3199       vs         328 (102,  0,  0)      2.545 0.6022 0.3195
  536 (114, 12,  0)      3.235 0.6040 0.3211       vs         374 (114,  0,  0)      3.222 0.6047 0.3204
  594 (127, 12,  0)      4.077 0.6063 0.3210       vs         498 (127,  0,  0)      4.071 0.6062 0.3211
  860 (140, 12,  0)      5.014 0.6071 0.3214       vs         600 (140,  0,  0)      5.008 0.6073 0.3217
 1034 (153, 12,  0)      6.070 0.6080 0.3221       vs         856 (153,  0,  0)      6.057 0.6079 0.3223
 1150 (165, 12,  0)      7.137 0.6089 0.3225       vs        1060 (165,  0,  0)      7.132 0.6087 0.3225
 1550 (178, 12,  0)      8.387 0.6099 0.3229       vs        1316 (178,  0,  0)      8.411 0.6096 0.3230
 1710 (191, 12,  0)      9.800 0.6108 0.3234       vs        1570 (191,  0,  0)      9.812 0.6106 0.3237
 2006 (191, 25,  0)      9.889 0.6102 0.3241       vs        1710 (191, 12,  0)      9.800 0.6108 0.3234
 1990 (204, 12,  0)     11.329 0.6115 0.3239       vs        1796 (204,  0,  0)     11.329 0.6115 0.3239
 2448 (204, 25,  0)     11.360 0.6116 0.3240       vs        1990 (204, 12,  0)     11.329 0.6115 0.3239
 2460 (216, 12,  0)     12.775 0.6130 0.3249       vs        1954 (216,  0,  0)     12.758 0.6131 0.3248
 2852 (216, 25,  0)     12.776 0.6130 0.3249       vs        2460 (216, 12,  0)     12.775 0.6130 0.3249
 2946 (229, 12,  0)     14.432 0.6145 0.3256       vs        2450 (229,  0,  0)     14.401 0.6145 0.3255
 3484 (229, 25,  0)     14.441 0.6145 0.3255       vs        2946 (229, 12,  0)     14.432 0.6145 0.3256
 3530 (242, 12,  0)     16.217 0.6163 0.3265       vs        2870 (242,  0,  0)     16.216 0.6163 0.3265
 4036 (242, 25,  0)     16.195 0.6163 0.3264       vs        3530 (242, 12,  0)     16.217 0.6163 0.3265
 3920 (255, 12,  0)     17.663 0.6179 0.3274       vs        3204 (255,  0,  0)     17.658 0.6178 0.3274
 4276 (255, 25,  0)     17.639 0.6180 0.3273       vs        3920 (255, 12,  0)     17.663 0.6179 0.3274
19 duplicate(s) 4.3 %
---------------------------------------------------------------------
red->blue
  130 ( 63,  0, 12)      0.875 0.5892 0.3140       vs          96 ( 63,  0,  0)      0.883 0.5898 0.3145
  238 ( 76,  0, 12)      1.325 0.5957 0.3164       vs         126 ( 76,  0,  0)      1.326 0.5954 0.3166
  360 (102,  0, 12)      2.544 0.6024 0.3196       vs         328 (102,  0,  0)      2.545 0.6022 0.3195
  480 (114,  0, 12)      3.220 0.6045 0.3203       vs         374 (114,  0,  0)      3.222 0.6047 0.3204
  596 (127,  0, 12)      4.065 0.6060 0.3212       vs         498 (127,  0,  0)      4.071 0.6062 0.3211
  868 (127,  0, 25)      4.059 0.6058 0.3213       vs         596 (127,  0, 12)      4.065 0.6060 0.3212
  862 (140,  0, 12)      4.996 0.6069 0.3218       vs         600 (140,  0,  0)      5.008 0.6073 0.3217
 1092 (140,  0, 25)      4.989 0.6068 0.3219       vs         862 (140,  0, 12)      4.996 0.6069 0.3218
 1012 (153,  0, 12)      6.058 0.6078 0.3222       vs         856 (153,  0,  0)      6.057 0.6079 0.3223
 1194 (153,  0, 25)      6.056 0.6079 0.3223       vs        1012 (153,  0, 12)      6.058 0.6078 0.3222
 1130 (165,  0, 12)      7.131 0.6089 0.3227       vs        1060 (165,  0,  0)      7.132 0.6087 0.3225
 1444 (165,  0, 25)      7.131 0.6089 0.3227       vs        1130 (165,  0, 12)      7.131 0.6089 0.3227
 1546 (178,  0, 12)      8.408 0.6098 0.3231       vs        1316 (178,  0,  0)      8.411 0.6096 0.3230
 1816 (178,  0, 25)      8.404 0.6095 0.3231       vs        1546 (178,  0, 12)      8.408 0.6098 0.3231
 2070 (178,  0, 38)      8.382 0.6099 0.3230       vs        1816 (178,  0, 25)      8.404 0.6095 0.3231
 1808 (191,  0, 12)      9.808 0.6105 0.3237       vs        1570 (191,  0,  0)      9.812 0.6106 0.3237
 2012 (191,  0, 25)      9.799 0.6108 0.3234       vs        1808 (191,  0, 12)      9.808 0.6105 0.3237
 2492 (191,  0, 38)      9.777 0.6106 0.3235       vs        2012 (191,  0, 25)      9.799 0.6108 0.3234
 2216 (204,  0, 12)     11.321 0.6120 0.3243       vs        1796 (204,  0,  0)     11.329 0.6115 0.3239
 2510 (204,  0, 25)     11.304 0.6122 0.3241       vs        2216 (204,  0, 12)     11.321 0.6120 0.3243
 2844 (204,  0, 38)     11.287 0.6120 0.3242       vs        2510 (204,  0, 25)     11.304 0.6122 0.3241
 2472 (216,  0, 12)     12.742 0.6130 0.3248       vs        1954 (216,  0,  0)     12.758 0.6131 0.3248
 2688 (216,  0, 25)     12.742 0.6130 0.3248       vs        2472 (216,  0, 12)     12.742 0.6130 0.3248
 3440 (216,  0, 38)     12.743 0.6130 0.3248       vs        2688 (216,  0, 25)     12.742 0.6130 0.3248
 2912 (229,  0, 12)     14.419 0.6144 0.3256       vs        2450 (229,  0,  0)     14.401 0.6145 0.3255
 3126 (229,  0, 25)     14.428 0.6144 0.3256       vs        2912 (229,  0, 12)     14.419 0.6144 0.3256
 3728 (229,  0, 38)     14.410 0.6146 0.3254       vs        3126 (229,  0, 25)     14.428 0.6144 0.3256
 4066 (229,  0, 51)     14.411 0.6146 0.3254       vs        3728 (229,  0, 38)     14.410 0.6146 0.3254
 3240 (242,  0, 12)     16.198 0.6163 0.3264       vs        2870 (242,  0,  0)     16.216 0.6163 0.3265
 3576 (242,  0, 25)     16.193 0.6163 0.3264       vs        3240 (242,  0, 12)     16.198 0.6163 0.3264
 4364 (242,  0, 38)     16.172 0.6162 0.3265       vs        3576 (242,  0, 25)     16.193 0.6163 0.3264
 4738 (242,  0, 51)     16.166 0.6162 0.3265       vs        4364 (242,  0, 38)     16.172 0.6162 0.3265
 3930 (255,  0, 12)     17.636 0.6179 0.3273       vs        3204 (255,  0,  0)     17.658 0.6178 0.3274
 4232 (255,  0, 25)     17.653 0.6178 0.3274       vs        3930 (255,  0, 12)     17.636 0.6179 0.3273
 4968 (255,  0, 38)     17.631 0.6179 0.3273       vs        4232 (255,  0, 25)     17.653 0.6178 0.3274
 5384 (255,  0, 51)     17.624 0.6179 0.3273       vs        4968 (255,  0, 38)     17.631 0.6179 0.3273
36 duplicate(s) 8.2 %
---------------------------------------------------------------------
blue->green
---------------------------------------------------------------------
blue->red
  376 ( 12,  0,102)      0.837 0.1598 0.0714       vs         240 (  0,  0,102)      0.832 0.1601 0.0717
  466 ( 12,  0,114)      1.092 0.1598 0.0716       vs         330 (  0,  0,114)      1.093 0.1600 0.0721
  688 ( 25,  0,114)      1.089 0.1594 0.0711       vs         466 ( 12,  0,114)      1.092 0.1598 0.0716
  598 ( 12,  0,127)      1.440 0.1598 0.0723       vs         440 (  0,  0,127)      1.432 0.1602 0.0723
  888 ( 25,  0,127)      1.426 0.1596 0.0715       vs         598 ( 12,  0,127)      1.440 0.1598 0.0723
  734 ( 12,  0,140)      1.843 0.1600 0.0727       vs         572 (  0,  0,140)      1.843 0.1600 0.0728
 1074 ( 25,  0,140)      1.829 0.1599 0.0722       vs         734 ( 12,  0,140)      1.843 0.1600 0.0727
 1162 ( 38,  0,140)      1.845 0.1601 0.0720       vs        1074 ( 25,  0,140)      1.829 0.1599 0.0722
 1070 ( 12,  0,153)      2.267 0.1598 0.0718       vs         728 (  0,  0,153)      2.267 0.1598 0.0719
 1276 ( 25,  0,153)      2.267 0.1598 0.0719       vs        1070 ( 12,  0,153)      2.267 0.1598 0.0718
 1554 ( 38,  0,153)      2.267 0.1598 0.0717       vs        1276 ( 25,  0,153)      2.267 0.1598 0.0719
 1198 ( 12,  0,165)      2.752 0.1595 0.0722       vs         910 (  0,  0,165)      2.768 0.1596 0.0725
 1378 ( 25,  0,165)      2.745 0.1597 0.0720       vs        1198 ( 12,  0,165)      2.752 0.1595 0.0722
 1772 ( 38,  0,165)      2.738 0.1594 0.0719       vs        1378 ( 25,  0,165)      2.745 0.1597 0.0720
 1496 ( 12,  0,178)      3.299 0.1597 0.0729       vs        1120 (  0,  0,178)      3.300 0.1597 0.0729
 1686 ( 25,  0,178)      3.299 0.1597 0.0729       vs        1496 ( 12,  0,178)      3.299 0.1597 0.0729
 2206 ( 38,  0,178)      3.292 0.1594 0.0728       vs        1686 ( 25,  0,178)      3.299 0.1597 0.0729
 1918 ( 12,  0,191)      3.895 0.1598 0.0733       vs        1360 (  0,  0,191)      3.905 0.1596 0.0733
 2040 ( 25,  0,191)      3.895 0.1598 0.0732       vs        1918 ( 12,  0,191)      3.895 0.1598 0.0733
 2468 ( 38,  0,191)      3.888 0.1596 0.0731       vs        2040 ( 25,  0,191)      3.895 0.1598 0.0732
 2734 ( 51,  0,191)      3.924 0.1604 0.0732       vs        2468 ( 38,  0,191)      3.888 0.1596 0.0731
 2246 ( 12,  0,204)      4.570 0.1599 0.0739       vs        1656 (  0,  0,204)      4.570 0.1599 0.0739
 2484 ( 25,  0,204)      4.563 0.1597 0.0738       vs        2246 ( 12,  0,204)      4.570 0.1599 0.0739
 2936 ( 38,  0,204)      4.554 0.1598 0.0737       vs        2484 ( 25,  0,204)      4.563 0.1597 0.0738
 3526 ( 51,  0,204)      4.548 0.1596 0.0737       vs        2936 ( 38,  0,204)      4.554 0.1598 0.0737
 2296 ( 12,  0,216)      5.230 0.1599 0.0742       vs        2142 (  0,  0,216)      5.229 0.1599 0.0743
 2782 ( 25,  0,216)      5.229 0.1599 0.0742       vs        2296 ( 12,  0,216)      5.230 0.1599 0.0742
 3168 ( 38,  0,216)      5.220 0.1600 0.0742       vs        2782 ( 25,  0,216)      5.229 0.1599 0.0742
 3774 ( 51,  0,216)      5.212 0.1598 0.0742       vs        3168 ( 38,  0,216)      5.220 0.1600 0.0742
 2828 ( 12,  0,229)      6.072 0.1602 0.0755       vs        2624 (  0,  0,229)      6.056 0.1602 0.0755
 3230 ( 25,  0,229)      6.072 0.1602 0.0756       vs        2828 ( 12,  0,229)      6.072 0.1602 0.0755
 3732 ( 38,  0,229)      6.055 0.1602 0.0754       vs        3230 ( 25,  0,229)      6.072 0.1602 0.0756
 4148 ( 51,  0,229)      6.040 0.1602 0.0753       vs        3732 ( 38,  0,229)      6.055 0.1602 0.0754
 4930 ( 63,  0,229)      6.103 0.1611 0.0756       vs        4148 ( 51,  0,229)      6.040 0.1602 0.0753
 3226 ( 12,  0,242)      6.914 0.1602 0.0761       vs        3036 (  0,  0,242)      6.913 0.1602 0.0762
 3578 ( 25,  0,242)      6.912 0.1602 0.0761       vs        3226 ( 12,  0,242)      6.914 0.1602 0.0761
 4152 ( 38,  0,242)      6.896 0.1602 0.0760       vs        3578 ( 25,  0,242)      6.912 0.1602 0.0761
 5012 ( 51,  0,242)      6.872 0.1602 0.0759       vs        4152 ( 38,  0,242)      6.896 0.1602 0.0760
 5470 ( 63,  0,242)      6.843 0.1601 0.0757       vs        5012 ( 51,  0,242)      6.872 0.1602 0.0759
 3932 ( 12,  0,255)      7.658 0.1603 0.0763       vs        3268 (  0,  0,255)      7.659 0.1603 0.0764
 4358 ( 25,  0,255)      7.640 0.1603 0.0763       vs        3932 ( 12,  0,255)      7.658 0.1603 0.0763
 4634 ( 38,  0,255)      7.624 0.1603 0.0762       vs        4358 ( 25,  0,255)      7.640 0.1603 0.0763
 5374 ( 51,  0,255)      7.595 0.1602 0.0760       vs        4634 ( 38,  0,255)      7.624 0.1603 0.0762
 5856 ( 63,  0,255)      7.566 0.1601 0.0759       vs        5374 ( 51,  0,255)      7.595 0.1602 0.0760
44 duplicate(s) 10.0 %
---------------------------------------------------------------------
Custom colour space suggested extents
Red extent:
 8242 255  38  63     18.009 0.6104 0.3274
Green extent:
 4250  25 255   0     56.806 0.3033 0.5876
Blue extent:
 6492  76   0 255      7.883 0.1641 0.0778
White extent:
 9261 255 255 255     80.680 0.3113 0.3282
---------------------------------------------------------------------
omarank likes this.

Last edited by bobof; 02-17-2019 at 03:23 PM.
bobof is offline  
post #1962 of 2392 Old 02-17-2019, 10:35 PM
Member
 
Join Date: Mar 2016
Posts: 56
Mentioned: 5 Post(s)
Tagged: 0 Thread(s)
Quoted: 36 Post(s)
Liked: 30
Wow, nice! I created a custom gamut with the gamut co-ordinates as you calculated and then did the LUT concatenation. It's a much cleaner LUT, but with stray points around the red.

Click image for larger version

Name:	Concatenated LUT_Image 1.png
Views:	37
Size:	131.3 KB
ID:	2527280
Click image for larger version

Name:	Concatenated LUT_Image 2.png
Views:	34
Size:	137.5 KB
ID:	2527282

If a slightly more inward red co-ordinate was used to create the custom gamut, it would give a perfectly clean LUT I suppose. The gamut will obviously shrink a lot though. Well, is it possible to refine the red co-ordinate further with your calculations?

Are you going to create a utility which can spit out the custom gamut co-ordinates or maybe the bcs file directly, for such displays? That will be quite interesting. Ideally, LightSpace should be doing all these calculations and automatically create the cleanest LUT.
bobof likes this.

Last edited by omarank; 02-17-2019 at 10:47 PM.
omarank is offline  
post #1963 of 2392 Old 02-17-2019, 11:53 PM
aka jfinnie
 
Join Date: Aug 2015
Location: Norwich, UK
Posts: 3,268
Mentioned: 53 Post(s)
Tagged: 0 Thread(s)
Quoted: 2640 Post(s)
Liked: 1738
Quote:
Originally Posted by omarank View Post
Wow, nice! I created a custom gamut with the gamut co-ordinates as you calculated and then did the LUT concatenation. It's a much cleaner LUT, but with stray points around the red.

Attachment 2527280
Attachment 2527282

If a slightly more inward red co-ordinate was used to create the custom gamut, it would give a perfectly clean LUT I suppose. The gamut will obviously shrink a lot though. Well, is it possible to refine the red co-ordinate further with your calculations?

Are you going to create a utility which can spit out the custom gamut co-ordinates or maybe the bcs file directly, for such displays? That will be quite interesting. Ideally, LightSpace should be doing all these calculations and automatically create the cleanest LUT.
Thanks, I saw that too. Out of interest, did you try it out? I'm trying to understand the relationship between observed banding and whether the LUT has these obvious "stray" points trying to escape the LUT. Did this LUT have banding when uploaded in content or test images like the Granger rainbow?

This result is obviously much better that the original MAP LUT, or original web concatenate LUT process (just use extreme gamut points), but still not perfect. If I get some time later I'll have a look and see; but you can see there is probably a problem here; I believe what is happening is that I am checking out the gamut corners in the algorithm and moving them in to the point where it seems the duplicates don't exist at the corners, but there are still some duplicates along the gamut edge when you re-define the gamut this way. What you'd have to do to be sure is draw this new triangle and then plot all the remaining profile points and see if you still have duplicate points inside or outside.

This really shows the problem of this as a manual process. To expect an end user to keep iterating over the profile to try and work out the useable gamut is a load of work, there is nothing about LS that can make this easy - especially in the case of your profile here. I harnessed the power of a script to do it for me but it is still difficult.

Outputting the XML is easy, I'm just not sure it is worth it. I'll probably do it later though to stop me having to copy the co-ordinates across. I'm probably not going to do the checking all the gamut points along the edge thing for a while, I might make the script output 3 custom gamuts as LS files - the original LS suggestion, this minimum suggestion, and one that is slightly smaller again to try and catch any "stragglers" without going to the effort of checking for them all. Of course, if your profile doesn't have many points, choosing the next point along could be a substantial gamut reduction, so there is good reason to use the biggest gamut you can without seeing this artifact in the LUT.

I already made another script that edits a profile to delete duplicate points, but you can quite easily make a profile that doesn't build in map space as map space has some requirements for exactly what points it needs which are not clear (it sometimes errors when the cube is sparse), so it's not clear there is any future really in editing the profile data itself.

Although this approach will eventually get you to a "working" gamut for the LS algorithms and the LUT concatenation process, I'm pretty firmly of the view that it is not the right approach. There will be a load of colours at these edges that the display could have displayed that will be cropped by this approach. I really do believe that the behaviour around these duplicate gamut points is just a bit too dumb and should be improved, and that can only happen within the LS engine.
Manni01 and omarank like this.

Last edited by bobof; 02-18-2019 at 01:35 AM.
bobof is offline  
post #1964 of 2392 Old 02-18-2019, 12:09 AM
aka jfinnie
 
Join Date: Aug 2015
Location: Norwich, UK
Posts: 3,268
Mentioned: 53 Post(s)
Tagged: 0 Thread(s)
Quoted: 2640 Post(s)
Liked: 1738
If anyone else has profiles that result in these stray LUT points with map / peak (particularly JVC ones, but also other displays) I'd be really keen to see them to feed into the tool and then manually inspect.
Manni01 likes this.
bobof is offline  
post #1965 of 2392 Old 02-18-2019, 01:33 AM
Senior Member
 
KarlKlammer's Avatar
 
Join Date: Apr 2010
Location: Germany
Posts: 318
Mentioned: 7 Post(s)
Tagged: 0 Thread(s)
Quoted: 266 Post(s)
Liked: 257
@bobof
If you want to feed your tool some data, you could take some of my older profiles for the X9500. They were made before I started using the DCI filter for Rec.709.
Attached Thumbnails
Click image for larger version

Name:	LS9_Rec709.JPG
Views:	27
Size:	194.3 KB
ID:	2527300  
Attached Files
File Type: zip test.zip (39.6 KB, 5 views)
bobof likes this.

Projection: JVC DLA-NX9
VP/Calibration: Lumagen Radiance Pro, LightSpace CMS, x-rite i1 Pro 2, x-rite i1 Display 3
KarlKlammer is offline  
post #1966 of 2392 Old 02-18-2019, 01:45 AM
aka jfinnie
 
Join Date: Aug 2015
Location: Norwich, UK
Posts: 3,268
Mentioned: 53 Post(s)
Tagged: 0 Thread(s)
Quoted: 2640 Post(s)
Liked: 1738
Quote:
Originally Posted by KarlKlammer View Post
@bobof
If you want to feed your tool some data, you could take some of my older profiles for the X9500. They were made before I started using the DCI filter for Rec.709.
I'll have a look. So these are with the projector in Reference mode, right?
I don't think there is much I can do with the QP profile (there is no gamut edge to find because you just have the RGBW axis).

Could maybe make a custom patch set that was only the 12 outside edges of the cube + GS, which would be enough to work with.

Do you note banding in any / all of these results?
bobof is offline  
post #1967 of 2392 Old 02-18-2019, 02:14 AM
Senior Member
 
KarlKlammer's Avatar
 
Join Date: Apr 2010
Location: Germany
Posts: 318
Mentioned: 7 Post(s)
Tagged: 0 Thread(s)
Quoted: 266 Post(s)
Liked: 257
That was the X9500 with a user profile in standard mode.

I can't remember what these LUTs did look like. So I can't tell if there was banding.


You don't need to find a solution for my specific issues. I am waiting for my NX9 and don't want to invest more time in my current setup.

I attached the profiles so your tool has some unknown data to play with. Maybe they help you to find or confirm a pattern to what is happening with LS and our unfit displays.
bobof likes this.

Projection: JVC DLA-NX9
VP/Calibration: Lumagen Radiance Pro, LightSpace CMS, x-rite i1 Pro 2, x-rite i1 Display 3
KarlKlammer is offline  
post #1968 of 2392 Old 02-18-2019, 03:29 AM
Member
 
Join Date: Mar 2016
Posts: 56
Mentioned: 5 Post(s)
Tagged: 0 Thread(s)
Quoted: 36 Post(s)
Liked: 30
Quote:
Originally Posted by bobof View Post
Thanks, I saw that too. Out of interest, did you try it out? I'm trying to understand the relationship between observed banding and whether the LUT has these obvious "stray" points trying to escape the LUT. Did this LUT have banding when uploaded in content or test images like the Granger rainbow?
Yes, there is banding, both when viewing real content and test images. Below are some screenshots:

Ted's Pattern (Red Linearization):

3DLUT OFF
Click image for larger version

Name:	TP1_3DLUT OFF.png
Views:	36
Size:	423.4 KB
ID:	2527314
3DLUT ON
Click image for larger version

Name:	TP1_3DLUT ON.png
Views:	40
Size:	469.5 KB
ID:	2527316


Ted's Pattern (Red Tunnel):

3DLUT OFF
Click image for larger version

Name:	TP2_3DLUT OFF.png
Views:	36
Size:	465.0 KB
ID:	2527318
3DLUT ON
Click image for larger version

Name:	TP2_3DLUT ON.png
Views:	35
Size:	655.0 KB
ID:	2527320


Color Ramp 1:

3DLUT OFF
Click image for larger version

Name:	ColorRamp1_3DLUT OFF.png
Views:	51
Size:	1.14 MB
ID:	2527322
3DLUT ON
Click image for larger version

Name:	ColorRamp1_3DLUT ON.png
Views:	52
Size:	1.24 MB
ID:	2527324


Color Ramp 2:

3DLUT OFF
Click image for larger version

Name:	ColorRamp2_3DLUT OFF.png
Views:	33
Size:	1.13 MB
ID:	2527326
3DLUT ON
Click image for larger version

Name:	ColorRamp2_3DLUT ON.png
Views:	42
Size:	1.23 MB
ID:	2527328

(While taking these screenshots, I set madVR output levels such that WTW was preserved as Ted's patterns have content there).

Quote:
Originally Posted by bobof View Post
This really shows the problem of this as a manual process. To expect an end user to keep iterating over the profile to try and work out the useable gamut is a load of work, there is nothing about LS that can make this easy - especially in the case of your profile here. I harnessed the power of a script to do it for me but it is still difficult.
...
Although this approach will eventually get you to a "working" gamut for the LS algorithms and the LUT concatenation process, I'm pretty firmly of the view that it is not the right approach. There will be a load of colours at these edges that the display could have displayed that will be cropped by this approach. I really do believe that the behaviour around these duplicate gamut points is just a bit too dumb and should be improved, and that can only happen within the LS engine.
I completely agree. I really hope to see improvements in LS engine so that the end users aren't required to go through this recursive process.
mikela, Manni01 and bobof like this.

Last edited by omarank; 02-18-2019 at 03:36 AM.
omarank is offline  
post #1969 of 2392 Old 02-18-2019, 04:07 AM
aka jfinnie
 
Join Date: Aug 2015
Location: Norwich, UK
Posts: 3,268
Mentioned: 53 Post(s)
Tagged: 0 Thread(s)
Quoted: 2640 Post(s)
Liked: 1738
Quote:
Originally Posted by omarank View Post
Yes, there is banding, both when viewing real content and test images.
...
I really hope to see improvements in LS engine so that the end users aren't required to go through this recursive process.
I guess that answers that question, seems in your case and my case the correlation between observing "dumb looking" points in the LUT cube view and seeing banding in specific test images holds true. Stands to reason, the response of these displays, while not perfect, is at least linear(ish) in the regions of the input values that correspond to output colour changes.

I'll make the version this evening probably that outputs 3 different variants of the colourspace file. What I'll do is in the case where an issue is detected at any direction, in that direction I'll make colourspaces which have the colourspace defined as both one and two patches away, plus the original "web process" colourspace at the gamut extents. Any directions which don't need correction will be left as-is.
Manni01 and omarank like this.
bobof is offline  
post #1970 of 2392 Old 02-18-2019, 03:51 PM
aka jfinnie
 
Join Date: Aug 2015
Location: Norwich, UK
Posts: 3,268
Mentioned: 53 Post(s)
Tagged: 0 Thread(s)
Quoted: 2640 Post(s)
Liked: 1738
Quote:
Originally Posted by omarank View Post
Yes, there is banding, both when viewing real content and test images. Below are some screenshots:

...

I completely agree. I really hope to see improvements in LS engine so that the end users aren't required to go through this recursive process.
See attached, I've got it writing out the custom colourspaces. It's not until you get to the smallest (2 patches in from the measured clipped gamut extents) that you get to a seemingly artifact free LUT.

Red gamut has gone from 0.6178 0.3274 to 0.5846 0.3230, reasonably large difference there. I'm not quite sure where the gamut clip ends up yet (I've not measured one of these after running it through this process) but there has got to be a better way to do this than this...

Code:
---------------------------------------------------------------------
Red extent:
 3204 255   0   0     17.658 0.6178 0.3274
Green extent:
 3174   0 255   0     56.657 0.3015 0.5891
Blue extent:
 3268   0   0 255      7.659 0.1603 0.0764
White extent:
 9261 255 255 255     80.680 0.3113 0.3282
---------------------------------------------------------------------
Custom colour space suggested extents
Red extent:
 8242 255  38  63     18.009 0.6104 0.3274
Green extent:
 4250  25 255   0     56.806 0.3033 0.5876
Blue extent:
 6492  76   0 255      7.883 0.1641 0.0778
White extent:
 9261 255 255 255     80.680 0.3113 0.3282
---------------------------------------------------------------------
Custom colour space suggested extents
Red extent:
 8943 255  51  76     18.961 0.5846 0.3230
Green extent:
 4966  38 255   0     56.993 0.3051 0.5863
Blue extent:
 6984  89   0 255      8.422 0.1715 0.0817
White extent:
 9261 255 255 255     80.680 0.3113 0.3282
---------------------------------------------------------------------
Attached Files
File Type: zip SonyTVcs.zip (886 Bytes, 3 views)
omarank likes this.
bobof is offline  
post #1971 of 2392 Old 02-19-2019, 11:02 AM
Member
 
Join Date: Mar 2016
Posts: 56
Mentioned: 5 Post(s)
Tagged: 0 Thread(s)
Quoted: 36 Post(s)
Liked: 30
Thanks, bobof! There is no visible banding/posterization now with the concatenated LUT created using your provided custom gamut cs2. But yes, the under-saturation in red is quite significant and visible on real content. I haven't had a chance to take measurements with this LUT active, but I will probably do a fresh profiling and calibration when I get on to that. While creating a LUT then, I will still be able to use your provided custom gamut for LUT concatenation. I will share my results when I do the calibration next.

By the way, the Argyll LUT still looks better on real content. It also does not suffer from the severe under-saturation. I will have to take measurements again to compare the accuracy of both the LUTs, but nonetheless the point remains that LS needs to improve its handling of displays like these. The minimum that is expected is the kind of result that we have with the concatenated LUT using your calculated custom gamut.
Manni01 likes this.
omarank is offline  
post #1972 of 2392 Old 02-19-2019, 01:30 PM
aka jfinnie
 
Join Date: Aug 2015
Location: Norwich, UK
Posts: 3,268
Mentioned: 53 Post(s)
Tagged: 0 Thread(s)
Quoted: 2640 Post(s)
Liked: 1738
Quote:
Originally Posted by omarank View Post
Thanks, bobof! There is no visible banding/posterization now with the concatenated LUT created using your provided custom gamut cs2. But yes, the under-saturation in red is quite significant and visible on real content. I haven't had a chance to take measurements with this LUT active, but I will probably do a fresh profiling and calibration when I get on to that. While creating a LUT then, I will still be able to use your provided custom gamut for LUT concatenation. I will share my results when I do the calibration next.

By the way, the Argyll LUT still looks better on real content. It also does not suffer from the severe under-saturation. I will have to take measurements again to compare the accuracy of both the LUTs, but nonetheless the point remains that LS needs to improve its handling of displays like these. The minimum that is expected is the kind of result that we have with the concatenated LUT using your calculated custom gamut.
I was pretty sure it would be massively undersaturated; you can see in the LUT cube views how much of the RGB input values space that Lightspace was previously able to map fine is now cut off the cube, it is huge. But this is it seems the necessary amount you have to bring in the gamut to avoid all the issues along the gamut edge.

If I get some time at the weekend I'll try and tidy the tool to the point where I could let you play with it yourself. You'd need to have Python on your PC to run it.

Steve @Light Illusion - are you following these posts? I guess you can see that reducing the gamut to the point where all these clipped points that result in the wonky LUT points are cropped off isn't really a practical solution - at least for @omarank 's profile. I saw similar on my own profile as I copied you in on previously. Hopefully you can consider looking into a better "solution" than this.
mikela, Manni01 and omarank like this.
bobof is offline  
post #1973 of 2392 Old 02-19-2019, 01:40 PM
AVS Forum Special Member
 
Join Date: Dec 2014
Location: Mississauga, ON, Canada
Posts: 6,946
Mentioned: 130 Post(s)
Tagged: 0 Thread(s)
Quoted: 4883 Post(s)
Liked: 1847
Quote:
Originally Posted by bobof View Post
I guess you can see that reducing the gamut to the point where all these clipped points that result in the wonky LUT points are cropped off isn't really a practical solution
Dare I suggest switching to a non-JVC projector as a practical solutions?
Manni01 likes this.
Dominic Chan is online now  
post #1974 of 2392 Old 02-19-2019, 01:53 PM
aka jfinnie
 
Join Date: Aug 2015
Location: Norwich, UK
Posts: 3,268
Mentioned: 53 Post(s)
Tagged: 0 Thread(s)
Quoted: 2640 Post(s)
Liked: 1738
Quote:
Originally Posted by Dominic Chan View Post
Dare I suggest switching to a non-JVC projector as a practical solutions?
From the safety of behind your keyboard, sure. It's always the first thing I think when a bit of software doesn't do quite what I want... must change this hardware... Said the hardware designer, never.
mikela, Manni01 and omarank like this.
bobof is offline  
post #1975 of 2392 Old 02-20-2019, 12:34 AM
Member
 
Join Date: Mar 2016
Posts: 56
Mentioned: 5 Post(s)
Tagged: 0 Thread(s)
Quoted: 36 Post(s)
Liked: 30
Quote:
Originally Posted by bobof View Post
If I get some time at the weekend I'll try and tidy the tool to the point where I could let you play with it yourself. You'd need to have Python on your PC to run it.
That would be cool.
omarank is offline  
post #1976 of 2392 Old 02-24-2019, 12:24 AM
Senior Member
 
venkatesh_m's Avatar
 
Join Date: Oct 2007
Location: Penang, Malaysia
Posts: 461
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 78 Post(s)
Liked: 52
Since it's been explained by Lightspace that JVC projectors are not ideal for use with Lightspace 3D LUT as is, and I believe the WOLED hv also been discussed as not suitable, what consumer display would be recommended to be used ideally with Lightspace. Maybe with the list of Lightspace approved displays for consumer use being published would make it better for people like me when we look to buy the next display.

PS I'm currently 2 for 2 in getting the wrong display and it's put me in a spot as I look for a new calibration software options.

Sent from my ALP-L29 using Tapatalk
venkatesh_m is online now  
post #1977 of 2392 Old 02-24-2019, 03:28 AM
AVS Forum Special Member
 
Light Illusion's Avatar
 
Join Date: Aug 2010
Posts: 1,833
Mentioned: 28 Post(s)
Tagged: 0 Thread(s)
Quoted: 779 Post(s)
Liked: 1144
I would have to disagree with that.

A lot f the JVC projectors are OK, as they do not suffer the volumetric issues the X7900 seems to have when in wide gamut mode.

I have passed all our findings on to JVC, and our initial contact has shown genuine interest in the issues we have raised.
But, no idea if the powers-that-be within JVC will take this any further, or not.

As for WOLEDs, the results gained with LightSpace have proven to be the best the displays are capable of.
Certainly better than Calman's calibration results.
That has been discussed at length within these forums, so worth having a read through the threads..

Steve

Steve Shaw
LIGHT ILLUSION

Light Illusion is offline  
post #1978 of 2392 Old 02-24-2019, 04:02 AM
aka jfinnie
 
Join Date: Aug 2015
Location: Norwich, UK
Posts: 3,268
Mentioned: 53 Post(s)
Tagged: 0 Thread(s)
Quoted: 2640 Post(s)
Liked: 1738
Quote:
Originally Posted by Light Illusion View Post
A lot f the JVC projectors are OK, as they do not suffer the volumetric issues the X7900 seems to have when in wide gamut mode.
It doesn't appear to be limited to the X7900 in the wider gamut modes. There are posts above I see at least from owners of X9500 and RS500 (X7000), so this behaviour goes back at least 3 model years now of JVC eShift DLA-X series projectors. And whatever disaster afflicts the modes on @omarank 's Sony display.

Will be interesting to see how the new 4K N7 and NX9 units fair as they've gained a bit more gamut coverage it seems and just about squeeze 100% DCI-P3 coverage, though again they don't appear to have any modes that engage the colour filter and disable internal colour management - has anyone sent a profile to you yet? There is now a specific built-in P3 colourspace option I recall, but it will be colour managed to some extent. @Manni01 reports good results with Calman LUTs on his N7 but so far I'm unaware of anyone generating an LS profile for one (I'd do it, but I don't have access to one of these units). Looks like @KarlKlammer might be the first to generate an LS profile for one, then we'll see what it looks like through the LS engine.

There is an undocumented hack for at least my own X7900 which appear to trick the unit into putting the WCG filter in circuit in the non-colour managed "profile off" mode, though the hack is not practical for most uses / users of the projector.
Quote:
Originally Posted by Light Illusion View Post
As for WOLEDs, the results gained with LightSpace have proven to be the best the displays are capable of.
Certainly better than Calman's calibration results.
That has been discussed at length within these forums, so worth having a read through the threads..
Unless I'm mistaken, isn't the only full LUT upload for the current LG displays limited (by LG) to a REC709 LUT? It's matrix corner values only for HDR I believe. Are there any folk out there doing WCG LUTS for the LG units in external LUT holders? I'm eyeing up my next TV still.
mikela, venkatesh_m and omarank like this.

Last edited by bobof; 02-24-2019 at 05:39 AM.
bobof is offline  
post #1979 of 2392 Old 02-24-2019, 09:50 AM
Advanced Member
 
Anger.miki's Avatar
 
Join Date: Jan 2018
Posts: 671
Mentioned: 20 Post(s)
Tagged: 0 Thread(s)
Quoted: 400 Post(s)
Liked: 418
There’s no custom HDR LUT capability on any WOLED except the Panasonic EZ1000, if I remember correctly, but the panel drifts like a drunk man without food in Dubai august. No appreciable results.
bobof likes this.

TVs: Pioneer PDP-LX5090H, LG OLED55C8PLA | SintoAmp: Pioneer VSX-921 | BD Player: Panasonic DMP-BDT260EG | External LUT box: Entertainment Experience eeColor | Softwares: Light Illusion Lightspace HTP, Portrait Displays CalMAN Home Enthusiast 2018 R3, HCFR, DisplayCAL | Probes: x-rite i1 Pro 2 - i1 Display Pro OEM B-02, basICColor DISCUS | Test Pattern Generator: DVDO AVLab TPG
Anger.miki is offline  
post #1980 of 2392 Old 02-24-2019, 02:02 PM
Senior Member
 
KarlKlammer's Avatar
 
Join Date: Apr 2010
Location: Germany
Posts: 318
Mentioned: 7 Post(s)
Tagged: 0 Thread(s)
Quoted: 266 Post(s)
Liked: 257
Quote:
Originally Posted by bobof View Post
Looks like @KarlKlammer might be the first to generate an LS profile for one, then we'll see what it looks like through the LS engine.
I probably won't be the first, as long as I keep hearing 'hopefully soon' from my dealer. It seems not even JVC Germany has a clue when those units are going to arrive.

Besides this little delivery issue, I plan to do some things differently with the NX9.
For SDR, I hope the native gamut results in a usable LUT without being forced to use a profile with DCI filter.
And for HDR the reference profile is hopefully good enough for a working P3-LUT. If not, I'm generating a user defined profile with DCI filter based on measured white, max. blue and max. red from the native gamut and max. green from reference profile. I guess that RGB separation will be fairly good this way, because I already tried this with the X9500.
I will leave the conversion for BT.2020 to the Radiance and use Intensity Mapping.
loggeo likes this.

Projection: JVC DLA-NX9
VP/Calibration: Lumagen Radiance Pro, LightSpace CMS, x-rite i1 Pro 2, x-rite i1 Display 3
KarlKlammer is offline  
Sponsored Links
Advertisement
 
Reply Display Calibration

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off