INTERACT FORUM
More => Old Versions => JRiver Media Center 31 for Windows => Topic started by: mattkhan on May 29, 2023, 08:30:22 am
-
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.
-
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.
-
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
-
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.
-
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?
-
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.
-
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.
-
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 :)
-
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
-
on the HDR side of things, the input is the output of the tone mapping or the actual source content?
-
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.
-
does the same apply for tone mapped HDR? i.e. the input to the 3dlut is the output from tone mapping?
-
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.
-
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
-
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.
-
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.
-
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?
-
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
-
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
-
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)
-
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.
-
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.
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.
-
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).
-
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.
-
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.
-
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.
-
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.
-
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.
-
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
-
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.
-
thanks, will try it out this afternoon
-
One other thought I had, do you have a ICC profile with gamma ramps loaded, and instructed madVR to clear them?
-
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
-
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...
-
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
-
displaycal will show you the relevant curves that are available to the 3dlut, as far as I can see, those are linear
-
any idea how to look at what is actually loaded in windows?
-
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)
-
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.
-
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
-
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.
-
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.
-
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.
-
linear steps all the way
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
-
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)
-
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.
-
emailed my settings to you
-
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
-
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.
-
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.
-
.cube LUTs just being text files is rather useful. I threw it into a spreadsheet and visualized it (the greyscale axis only, assuming I didn't screw up).
(https://i.imgur.com/OUt56jN.jpg)
I have been testing with the Rec.1886 LUT only until now, so this is interesting.
Red is a linear response, blue is the rec.1886 cube lut, and yellow the 2.4 cube lut.
Blue/rec.1886 seems to massively boost the black level, as I'm also experiencing, while 2.4 actually reduces it slightly but is otherwise pretty linear.
One thing to note is that madVR always behaves as if the "3DLUT Gamma" in JRVR is set to Rec.1886 (eg. "no-op for SDR content"), no matter how the LUT was generated.
With that setting, and using the 2.4 .cube LUT, I get a nice dark image. Its probably a result of measuring in that particular mode. Rec.1886 is designed to boost brightness of low levels, because the black response of old SDR screens is a bit terrible. It may not be ideal to use that for better displays that have a good black point. And I believe madVR also doesn't use it, so madTPG probably presented your test pattern with a 2.2 or 2.4 gamma, without the black offset of Rec.1886.
If the gamma selection for the LUT gets too complicated to consider in all of this, I suppose I could even kill it, and just have it do what madVR does, eg. always put SDR content unmodified through it (which is equal to always setting it to Rec.1886 in 99.9% of all cases)
-
fwiw this is what displaycal says the lut looks like
-
What I would suggest to test now is this:
- Set JRVR "3DLUT Gamma" to BT.1886 and don't touch it again, regardless of how the LUT was made (this is how madVR behaves)
- Use your standard madVR 3DLUT
This should match madVR behavior and at least with the provided 2.4 LUT, I do not get a brightness increase.
-
I think it really *should* be quite simple for end users, just add a few lines to the wiki saying exactly what is required and how it is used, give a few pics from displaycal as examples of how to do.
One thing to note is that madVR always behaves as if the "3DLUT Gamma" in JRVR is set to Rec.1886 (eg. "no-op for SDR content"), no matter how the LUT was generated.
With that setting, and using the 2.4 .cube LUT, I get a nice dark image. Its probably a result of measuring in that particular mode. Rec.1886 is designed to boost brightness of low levels, because the black response of old SDR screens is a bit terrible. It may not be ideal to use that for better displays that have a good black point. And I believe madVR also doesn't use it, so madTPG probably presented your test pattern with a 2.2 or 2.4 gamma, without the black offset of Rec.1886.
do you mean you set 3D LUT gamma in JRVR to Rec.1886 and selected the 2.4 lut I sent? at first glance this does seem to be similar to madvr (but I'd have to measure it tomorrow to be sure)
I don't see any options in madtpg to select gamma so I don't know how it behaves exactly
I can't tell if you're saying the above is good or bad (right or wrong) btw, I *think* it's much the same topic as in https://www.avsforum.com/threads/madvr-argyllcms.1471169/page-238#post-55193072 though and that conversation doesn't actually end in anything concrete. On rereading I think it's saying that the tone curve in displaycal should be set to rec.1886, if so is that going to work for JRVR?
What I would suggest to test now is this:
- Set JRVR "3DLUT Gamma" to BT.1886 and don't touch it again, regardless of how the LUT was made (this is how madVR behaves)
- Use your standard madVR 3DLUT
This should match madVR behavior and at least with the provided 2.4 LUT, I do not get a brightness increase.
OK I'll check this in the morning. I think I want to measure again though and it would be nice to understand how the displaycal tone curve option & JRVR's configuration interact as this part remains unclear to me so I'm not sure how to handle it to get correct results without trial and error (measuring takes so long that you really need to have a repeatable process otherwise it's just extremely painful)
-
Ideally, after understanding how madVR handles the 3DLUT and what fhoech recommended to madshi in that same thread you linked, the 3DLUT Gamma option would just go away. Afterall madVR never had it. And we can stop thinking about it.
Without that option, the setup is essentially the same as madVR, and with support for madVR 3DLUT files you can use all the same instructions.
Assuming the result is OK after you tested again.
-
What I would suggest to test now is this:
- Set JRVR "3DLUT Gamma" to BT.1886 and don't touch it again, regardless of how the LUT was made (this is how madVR behaves)
- Use your standard madVR 3DLUT
This should match madVR behavior and at least with the provided 2.4 LUT, I do not get a brightness increase.
I can confirm using the madvr lut with jrvr gamma set to BT.1886 produces the same results as that same lut in madvr
note that the same lut in cube format with the same settings produces a different response, is there some difference internally to how you handle the madvr lut vs a cube lut that explains this or is this unexpected behaviour? not sure it matters but thought it worth mentioning.
-
There is no difference in how its applied, other then that the cube LUT is full range rather then limited, and is generally lower precision (65 vs 256 points). This may be mostly obvious in the near-black parts, because with 65 points you have no data between bands 0 and 4 (or 16 and 20 the typical chart), and its interpolated instead.
How different is the response? Drastically? A bit?
Either way, for people already setup with madVR 3DLUTs and a workflow to measure those, using those will likely be preferable in all cases. At least in SDR the behavior should match now, as I understood madshi's statements i found.
Will have to think about HDR calibration next. Might be as simple as requiring a PQ in/PQ out LUT, but I have to check if there is metadata in the madVR LUT format that actually indicates this for a HDR LUT.
-
ah ok, I didn't realise the madvr lut format had so many more points (though did notice the files are relatively massive). Definitely preferable to go with the madvr format in that case then.
it's an obvious difference near black for me, blacks become grey extremely quickly basically so everything looks a bit washed out. Forgot to save a pic of the gamma curve this time but it was similar to those posted yesterday.