Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mattkhan]

as per subject, how exactly is this used in jrvr/libplacebo?

reason to ask is it seems like a lut produced from the same measurements (in cube for jrvr vs madvr formats) produces visibly different levels coming out of black (white looks normal) in that it is coming out of black much faster on jrvr. It makes me think I have this configured incorrectly.

[Hendrik]

The 3DLUT has to be generated with a certain (input) gamma curve, you have to tell JRVR which one that is, so it can properly prepare the data for it.

[mattkhan]

ok thanks

as far as I can see, displaycal has no explicit option for this, just the source colourspace (so rec709 or dci-p3 d65). I think that means 2.2 is the right setting but hard to be 100% certain about that. Having said that, not setting it to 2.2 is clearly off visually so I'm pretty sure 2.2 is the way to go

[mattkhan]

measuring in my room at this time of day/year is not perfect but measuring "the same" 3dlut (i.e. generated from same displaycal settings & measurements except the output format) and then measuring in room back to back & there's quite a difference (that is repeatable if I do this n times)

I'll measure again later in the week when it's properly dark (which should fix up the low end, my room has a tiny bit of light bleeding in during daytime which affects the very bottom end) to be sure but there's a difference here that is surprising and I think reflects what I'm seeing visually.

[mattkhan]

I measured without lut disabled in both cases for comparison, the differences are quite large again

options for where the problem lies

1) how jrvr applies the LUT
2) how I've created the LUT
3) how I've configured jrvr

any ideas on how to work out where the problem(s) lie?

[mattkhan]

just to note that, as previously posted, the lack of pattern generator support makes this is quite a time consuming process, even 10 point gamma is slightly painful (takes at least 4x as long as automated pattern generator approach). I don't think I could face doing any significant colour checking manually.

[Hendrik]

as far as I can see, displaycal has no explicit option for this

There should be an option on the 3DLUT creation page ("tone curve"). for madVR its typically set to rec.1886 by default. I'm not sure if you can set this setting after measurement, there is some wording on there about it being a fixed part of the data.
Note that rec.1886 is typically used as the "source gamma" for video, unless it indicates otherwise, so it would basically mean a no-op on gamma processing before the 3DLUT, all other settings would perform gamma processing in such a case.

[mattkhan]

There should be an option on the 3DLUT creation page ("tone curve"). for madVR its typically set to rec.1886 by default. I'm not sure if you can set this setting after measurement, there is some wording on there about it being a fixed part of the data.
Note that rec.1886 is typically used as the "source gamma" for video, unless it indicates otherwise, so it would basically mean a no-op on gamma processing before the 3DLUT, all other settings would perform gamma processing in such a case.

the settings page looks like the attached, docs are https://displaycal.net/#create-3dlut which become these options to collink -> http://www.argyllcms.com/doc/collink.html#Ib

I was under the impression "tone curve" here is the target (output) response but I do find the terminology used in displaycal quite obscure so it's quite possible I'm wrong about that. Ultimately I had functioning (as in accurate) 3dlut before when driving it into madvr and I get apparently inaccurate now so need to work out where the delta is in order to move forward with jrvr. No doubt the right incantation will be found in the end

[mattkhan]

https://www.avsforum.com/threads/madvr-argyllcms.1471169/post-48060585 says I'm wrong & it's the source
https://www.avsforum.com/threads/madvr-argyllcms.1471169/post-55191002 is one I now remember reading before and also goes into this

I'll regenerate my LUTs, remeasure and see what comes out the other end

[mattkhan]

on the HDR side of things, the input is the output of the tone mapping or the actual source content?

[Hendrik]

In some old posts, madVR claims to feed SDR signals untouched to the 3DLUT (eg. no gamma conversion, only conversion to RGB), based on that JRVR should be set to Rec.1886 source gamma to mimick a similar result.

[mattkhan]

does the same apply for tone mapped HDR? i.e. the input to the 3dlut is the output from tone mapping?

[Hendrik]

At that point its already SDR, yes.

You can read the OSD for this as well, the steps in the detail list are actually in order. 3DLUT should be after tone mapping.

[mattkhan]

ok so when using a 3DLUT, the relevant bits of the pipeline is

input -> JRVR transformation (colourspace/gamma) -> 3dlut

and the output of that 2nd step comes from the "3D LUT Gamma (tone curve)" (and colourspace) setting, I then need to make sure that I generated the 3dlut in displaycal using the same values and it should "just work"

the only problem here is that I'm fairly sure this is what I was actually doing in the 1st place yet coming out of black was visibly off (too bright) & hence this thread exists

I'll post back after I remeasure to be sure

[Hendrik]

And if you want to get as close to madVR behavior as possible, as I understand it anyway, set the 3DLUT Gamma in JRVR to Rec. 1886, as that will result in no change to gamma from the original video - at least for SDR. For HDR obviously it has to convert from PQ to Gamma.

Oh and one final thing to note, madVR 3DLUTs are limited range (tv range). .cube LUTs should be full range.

[Hendrik]

I did some checking on how the 3DLUT is applied right now, and its always applied after literally everything else, right before output. Only dithering ever is done after. The only problem I can see with this position is that the new "apply gamut after 3dlut" option does not actually work, and I might have to remove it again. But otherwise I don't think we ever would want to apply the 3DLUT any earlier, because its mean to calibrate for the output, so doing it as close as possible to the output seems sensible to me.

[mattkhan]

thanks for checking

a quick visual inspection (see attached, filenames indicate the gamma setting) shows that changing the jrvr option + the displaycal option in tandem does not produce the same output which, if I've understood the processing involved correctly, is an unexpected result

NB: this is just a screen cap, is there any shortcut built in so jrvr dumps guaranteed raw output to some lossless format?

[mattkhan]

for comparison, previous madvr based setup is much darker

NB: no comment on accuracy of any individual option implied, just sharing this to indicate that this is obviously different to the naked eye

[Hendrik]

Makes me wonder if thats a result of using a different color range, because in your madVR screenshot line 17 is cut off, as its literal black, that doesn't seem desirable either.

Applying the 3DLUT itself is not really magic. It indexes into the 3DLUT based on the colors (r,g,b forming the coordinates) and returns the result. Not sure what size madVR 3DLUTs usually are, but i think 65x65x65 is the biggest DisplayCal lets you make for .cube

[mattkhan]

fwiw 17 is just about perceptible in a completely dark room

my setup is full range all the way, the cube lut is also 0-255 & 65^3,  I believe madvr lut is also 65^3 (but 16-235 range)

[Hendrik]

At least on the screenshot, 17 is pure black.

Can you share the .cube 3DLUT file you are using? Maybe I can spot something in the way its being applied, or by analyzing the raw values.

[Hendrik]

I had a peek at the 3DLUT cube files you shared, and this is what the raw data says. Just for the first data points.

Normalized to a 0-1 floating point scale, we get this. Since we are dealing with greyscale in these examples, going to simplify a bit and leave out all but the first color component.
The LUT is 65x65x65 (0-64),  so normalizing its input is dividing by 64, and video in this example would come from 0-255, divided by 255.

Code: [Select]

Input          Output
0.0000        0.0000         < actual LUT value (LUT index 0/0/0), pixel value 0
0.0039        0.0119         < pixel value 1 (1/255), LUT interpolated => Output pixel value 3
0.0078        0.0239         < pixel value 2 (2/255), LUT interpolated => Output pixel value 6
0.0118        0.0361         < pixel value 3 (3/255), LUT interpolated => Output pixel value 9
0.0156        0.0477         < actual LUT value (LUT index 1/1/1)

Looking at the corresponding screenshot above (1886 in this case), these values match exactly what the screenshot captured.

The 17 bar has an average RGB value of 3 (some dithering applies), the 18 bar 6, and the 19 bar ~10 (since the original was limited range and expansion happens, the bars are not perfectly 1 value apart either).

So ... from this it appears the LUT is applied properly. The question that remains would be if the madVR 3DLUT is just made different by the tool, or if madVR does something very different when applying it.
Can you also send me a madVR 3DLUT of the same measurement, ideally? Might be able to look at the first few values at least in a hex editor, not sure there are any tools to convert 3DLUT formats.

I was also checking ArgyllCMS for clues on how it writes LUTs, and apparently madVR LUTs are always 256x256x256. I don't think the precision makes a huge difference, but still curious.

[mattkhan]

I sent the madvr versions to you

I still don't understand why the 2 cube LUTs differ in their output *if* the correct course of action is to match the displaycal tonecurve gamma with the corresponding setting in JRVR. The fact that changing this option does produce different output seems to suggest matching these two values is not correct (or there is something else going on).

[Hendrik]

Looking at the madVR 3DLUT file, the values seem to also match your madVR screenshot. For some reason the LUTs are just very different. I can try to add support for madVR 3DLUTs, but there was a reason I didn't do it in the past .. i forgot exactly what it was. Maybe I'll remember when I work on it. Them being limited range is a bit annoying, but maybe something I can work around.

[mattkhan]

I remeasured using the LUTs I sent you just to be sure what I was seeing

I retract my statement about JRVR LUT handling differing with the gamma setting. At least just from looking at gamma, I think they are the same (pics attached). I'm working on some method to automate measurement using JRVR but, until then, this will have to suffice.

The response is totally different to the madvr lut though and I think that one is correct (as the no LUT measurement has a gamma similar to this response so the cube LUTs are "bad" in some way even if they are being applied accurately)

Unfortunately I'm not aware of another tool that generates a cube lut or can convert from one format to another so it's a bit hard for me to dig deeper on this.

[mattkhan]

Looking at the madVR 3DLUT file, the values seem to also match your madVR screenshot. For some reason the LUTs are just very different. I can try to add support for madVR 3DLUTs, but there was a reason I didn't do it in the past .. i forgot exactly what it was. Maybe I'll remember when I work on it. Them being limited range is a bit annoying, but maybe something I can work around.

certainly that would be great from the perspective of maintaining a known to work workflow, thanks for considering it, seems a shame if the native format doesn't work though. I wonder if it's a displaycal or argyllcms issue here? I'll dig around the code to see.

[mattkhan]

checked the commands displaycal uses to generate the lut, it's all done by argyllcms (https://www.argyllcms.com/doc/collink.html) and the only different switches are the input/output encoding & the lut type. I'd hope it's just a Q of finding the right settings to use to make it compatible with jrvr.

[Hendrik]

So I made madVR 3DLUTs work. And interesting result, both the cube and the madVR LUT produce basically the same adjustment for me, I certainly can't tell a visual difference. Both drastically raise the brightness of those 17-25 test bars.

[mattkhan]

curious, perhaps I can try that build and see if I can reproduce? perhaps I can some difference in settings here then that is causing the difference?

the curve in these luts does have a lift at the low end btw so the impact on 17-25 is expected

[Hendrik]

I sent you a test build.

Looking at your previous madVR shot, it looks as dark as no adjustment, if not darker. Makes me wonder if there is a difference in other gamma settings somewhere.

[mattkhan]

thanks, will try it out this afternoon

[Hendrik]

One other thought I had, do you have a ICC profile with gamma ramps loaded, and instructed madVR to clear them?

[mattkhan]

I measured using the test build and the madvr 3dlut format, the good news is it measures the same as the cube format, the bad news is the low end roll off still exists.

re ICC profile, I thought it was set to linear and I've never knowingly installed one but I will check this

[Hendrik]

Apparently madVR 3DLUT files can contain gamma ramps that get loaded into the GPU. This seems rather undocumented and I only found out about it in the ArgyllCMS source code. Although it still makes me wonder that you would expect the DisplayCal to produce a .cube 3DLUT without also needing gamma ramps to get loaded...

[mattkhan]

I'm not familiar with windows ICC but I think there is nothing loaded except system defaults, attached pic of colour management dialogs in case that helps

[mattkhan]

displaycal will show you the relevant curves that are available to the 3dlut, as far as I can see, those are linear

[mattkhan]

any idea how to look at what is actually loaded in windows?

[mattkhan]

I used the displaycal profile loader to force it to reset the gamma tables for "Media Center 31.exe" and remeasured, same result so I think that rules that out (though would be nice to be able to "see" what is loaded directly somehow so I can be sure)

[Hendrik]

Looks like displaycal always make ArgyllCMS apply the calibration to the 3DLUT, and write a linear gamma ramp. So I guess I don't need to worry about supporting that for now.

[mattkhan]

I generated a new lut with the vcgt turned off, loaded into both jrvr and madvr & remeasured, same result (low end rolloff in jrvr) again

[Hendrik]

I loaded your 3DLUT (the rec1886 one) into madVR and compared to the same 3DLUT in JRVR, and the result on that black clipping test is identical, both visually and actually taking pixel values.

The difference you are seeing must be from some other madVR configuration thats further impacting it. Or another unknown factor. The application of the 3DLUT itself seems identical to me.

[mattkhan]

thanks for investigating this, shame we can't yet get to the bottom of it.

I can see no user selectable option in either JRVR or madvr that would impact this, I appear to have ruled out all things I can control and yet I'm still left with a fundamental difference between madvr and jrvr with the same LUT & where madvr appears to be behave correctly and jrvr doesn't.

I'm obviously happy to try anything else & share any settings that may be relevant given that not having 3D LUT support is a bit of a showstopper.

[Hendrik]

Just to rule out any funny business, I created a tiny commandline tool to just dump the gamma ramps from all connected display adapters. Mine seem to be linear, which should be 257 per step (sounds like an odd value, but its because its a full range 16 bit value, it makes sense)

Considering however that your JRVR shots look like my JRVR shots, and your madVR shot is the different one, I don't think this is it. If anything your madVR shot looks much closer to not applying the 3DLUT at all, with how dark it is.

[mattkhan]

linear steps all the way

Code: [Select]

X:\>GammaRamp.exe
Device: \\.\DISPLAY1
   0      0      0      0
   1    257    257    257
   2    514    514    514
   3    771    771    771
   4   1028   1028   1028
   5   1285   1285   1285
   6   1542   1542   1542
   7   1799   1799   1799
   8   2056   2056   2056
   9   2313   2313   2313
  10   2570   2570   2570
  11   2827   2827   2827
  12   3084   3084   3084
  13   3341   3341   3341
  14   3598   3598   3598
  15   3855   3855   3855
  16   4112   4112   4112
  17   4369   4369   4369
  18   4626   4626   4626
  19   4883   4883   4883
  20   5140   5140   5140
  21   5397   5397   5397
  22   5654   5654   5654
  23   5911   5911   5911
  24   6168   6168   6168
  25   6425   6425   6425
  26   6682   6682   6682
  27   6939   6939   6939
  28   7196   7196   7196
  29   7453   7453   7453
  30   7710   7710   7710
  31   7967   7967   7967
  32   8224   8224   8224
  33   8481   8481   8481
  34   8738   8738   8738
  35   8995   8995   8995
  36   9252   9252   9252
  37   9509   9509   9509
  38   9766   9766   9766
  39  10023  10023  10023
  40  10280  10280  10280
  41  10537  10537  10537
  42  10794  10794  10794
  43  11051  11051  11051
  44  11308  11308  11308
  45  11565  11565  11565
  46  11822  11822  11822
  47  12079  12079  12079
  48  12336  12336  12336
  49  12593  12593  12593
  50  12850  12850  12850
  51  13107  13107  13107
  52  13364  13364  13364
  53  13621  13621  13621
  54  13878  13878  13878
  55  14135  14135  14135
  56  14392  14392  14392
  57  14649  14649  14649
  58  14906  14906  14906
  59  15163  15163  15163
  60  15420  15420  15420
  61  15677  15677  15677
  62  15934  15934  15934
  63  16191  16191  16191
  64  16448  16448  16448
  65  16705  16705  16705
  66  16962  16962  16962
  67  17219  17219  17219
  68  17476  17476  17476
  69  17733  17733  17733
  70  17990  17990  17990
  71  18247  18247  18247
  72  18504  18504  18504
  73  18761  18761  18761
  74  19018  19018  19018
  75  19275  19275  19275
  76  19532  19532  19532
  77  19789  19789  19789
  78  20046  20046  20046
  79  20303  20303  20303
  80  20560  20560  20560
  81  20817  20817  20817
  82  21074  21074  21074
  83  21331  21331  21331
  84  21588  21588  21588
  85  21845  21845  21845
  86  22102  22102  22102
  87  22359  22359  22359
  88  22616  22616  22616
  89  22873  22873  22873
  90  23130  23130  23130
  91  23387  23387  23387
  92  23644  23644  23644
  93  23901  23901  23901
  94  24158  24158  24158
  95  24415  24415  24415
  96  24672  24672  24672
  97  24929  24929  24929
  98  25186  25186  25186
  99  25443  25443  25443
 100  25700  25700  25700
 101  25957  25957  25957
 102  26214  26214  26214
 103  26471  26471  26471
 104  26728  26728  26728
 105  26985  26985  26985
 106  27242  27242  27242
 107  27499  27499  27499
 108  27756  27756  27756
 109  28013  28013  28013
 110  28270  28270  28270
 111  28527  28527  28527
 112  28784  28784  28784
 113  29041  29041  29041
 114  29298  29298  29298
 115  29555  29555  29555
 116  29812  29812  29812
 117  30069  30069  30069
 118  30326  30326  30326
 119  30583  30583  30583
 120  30840  30840  30840
 121  31097  31097  31097
 122  31354  31354  31354
 123  31611  31611  31611
 124  31868  31868  31868
 125  32125  32125  32125
 126  32382  32382  32382
 127  32639  32639  32639
 128  32896  32896  32896
 129  33153  33153  33153
 130  33410  33410  33410
 131  33667  33667  33667
 132  33924  33924  33924
 133  34181  34181  34181
 134  34438  34438  34438
 135  34695  34695  34695
 136  34952  34952  34952
 137  35209  35209  35209
 138  35466  35466  35466
 139  35723  35723  35723
 140  35980  35980  35980
 141  36237  36237  36237
 142  36494  36494  36494
 143  36751  36751  36751
 144  37008  37008  37008
 145  37265  37265  37265
 146  37522  37522  37522
 147  37779  37779  37779
 148  38036  38036  38036
 149  38293  38293  38293
 150  38550  38550  38550
 151  38807  38807  38807
 152  39064  39064  39064
 153  39321  39321  39321
 154  39578  39578  39578
 155  39835  39835  39835
 156  40092  40092  40092
 157  40349  40349  40349
 158  40606  40606  40606
 159  40863  40863  40863
 160  41120  41120  41120
 161  41377  41377  41377
 162  41634  41634  41634
 163  41891  41891  41891
 164  42148  42148  42148
 165  42405  42405  42405
 166  42662  42662  42662
 167  42919  42919  42919
 168  43176  43176  43176
 169  43433  43433  43433
 170  43690  43690  43690
 171  43947  43947  43947
 172  44204  44204  44204
 173  44461  44461  44461
 174  44718  44718  44718
 175  44975  44975  44975
 176  45232  45232  45232
 177  45489  45489  45489
 178  45746  45746  45746
 179  46003  46003  46003
 180  46260  46260  46260
 181  46517  46517  46517
 182  46774  46774  46774
 183  47031  47031  47031
 184  47288  47288  47288
 185  47545  47545  47545
 186  47802  47802  47802
 187  48059  48059  48059
 188  48316  48316  48316
 189  48573  48573  48573
 190  48830  48830  48830
 191  49087  49087  49087
 192  49344  49344  49344
 193  49601  49601  49601
 194  49858  49858  49858
 195  50115  50115  50115
 196  50372  50372  50372
 197  50629  50629  50629
 198  50886  50886  50886
 199  51143  51143  51143
 200  51400  51400  51400
 201  51657  51657  51657
 202  51914  51914  51914
 203  52171  52171  52171
 204  52428  52428  52428
 205  52685  52685  52685
 206  52942  52942  52942
 207  53199  53199  53199
 208  53456  53456  53456
 209  53713  53713  53713
 210  53970  53970  53970
 211  54227  54227  54227
 212  54484  54484  54484
 213  54741  54741  54741
 214  54998  54998  54998
 215  55255  55255  55255
 216  55512  55512  55512
 217  55769  55769  55769
 218  56026  56026  56026
 219  56283  56283  56283
 220  56540  56540  56540
 221  56797  56797  56797
 222  57054  57054  57054
 223  57311  57311  57311
 224  57568  57568  57568
 225  57825  57825  57825
 226  58082  58082  58082
 227  58339  58339  58339
 228  58596  58596  58596
 229  58853  58853  58853
 230  59110  59110  59110
 231  59367  59367  59367
 232  59624  59624  59624
 233  59881  59881  59881
 234  60138  60138  60138
 235  60395  60395  60395
 236  60652  60652  60652
 237  60909  60909  60909
 238  61166  61166  61166
 239  61423  61423  61423
 240  61680  61680  61680
 241  61937  61937  61937
 242  62194  62194  62194
 243  62451  62451  62451
 244  62708  62708  62708
 245  62965  62965  62965
 246  63222  63222  63222
 247  63479  63479  63479
 248  63736  63736  63736
 249  63993  63993  63993
 250  64250  64250  64250
 251  64507  64507  64507
 252  64764  64764  64764
 253  65021  65021  65021
 254  65278  65278  65278
 255  65535  65535  65535


[mattkhan]

the madvr OSD reports it is on and there is a small but visually perceptible shift when you toggle it on/off
there is certainly a more obvious shift when you do the same in JRVR (which I think is just going back to the gamma point, it is washed out)

[Hendrik]

Maybe upload your madVR config as well? If that doesn't make it change for me either, I'm even more lost. Because I certainly see that obvious shift in madVR right now.

[mattkhan]

emailed my settings to you

[mattkhan]

tried the same test on a different machine that has never seen madvr before so it has whatever the default settings are, checked the gamma and that was linear as well

plugged in the same jrvr lut and then used https://learn.microsoft.com/en-us/windows/powertoys/color-picker to get a quick view on what colours the bars are

without a lut, each step (from 16-22) is ~+1 on the grey scale which is as expected
with the lut, this becomes more like 4-8-10-13-15-17 so quite a big lift

using madvr, 17 is really close to zero on a 8bit colour picker (but is non zero) then it comes out by approx +1 pre step

for me, the results are unambiguous on 2 different machines, 1 of which has totally default MC settings

[karmat63]

I can confirm the same behaviour on my desktop PC and HTPC. JRVR has a much brighter 17-25 levels then MadVr (i use to test the same - I think - AVS calibration suite). Visually MadVr looks right.

[Hendrik]

without a lut, each step (from 16-22) is ~+1 on the grey scale which is as expected
with the lut, this becomes more like 4-8-10-13-15-17 so quite a big lift

This matches my observation - except, it also does that for me when I use madVR with one of the LUTs you shared. I can't explain why we see so different results. I reset my madVR settings, just added the rec.1886 LUT from your mail to the screen config, and the black bars mirror your "with lut" results.
I doubt madVR version matters, and it changed the way LUTs work? I'm sure we would have heard about something like that.

I have no clue what shenanigans madVR might be doing in the background, but at least for JRVR its pretty clear cut, the 3DLUT is actually designed to lift the values that much - the analysis of the raw values confirmed that earlier, too.