.ti3 Parser / .3dlut Generator for madVR + .3dlut toolset

[nand chan]

Originally Posted by alph@

here too, same error message?i have the framwork 4,it's the last version of ti3 Parser
upload
http://www.mediafire.com/?rr2648w3ow9ftb4

I think I know what the issue may be, the culture information used to parse the values might be set to use a comma as decimal indicator (instead of a period) for your computer's locale.

I'll fix it in 0.6 by setting the culture used to parse to invariant.

Edit: Here's a preview release, see if that fixes it. http://www.mediafire.com/?04i9rct4be5q7pn

[Wile-E-Coyote]

Originally Posted by nand chan

I think I know what the issue may be, the culture information used to parse the values might be set to use a comma as decimal indicator (instead of a period) for your computer's locale.

I'll fix it in 0.6 by setting the culture used to parse to invariant.

Edit: Here's a preview release, see if that fixes it. http://www.mediafire.com/?04i9rct4be5q7pn

That did the trick, works fine for me now. Thanks a lot!

[leeperry]

Originally Posted by nand chan

Fair enough. What is it exactly that you want to do? Apply calibration information from a .cal file to a YCbCr LUT?

If so, it should be a simple process of going through the YCbCr LUT, converting each entry to RGB, running the RGB through the Calibration LUT, then converting the result back into YCbCr.

I can have a program for this running by 0.6, but I can't test it myself. You'll have to check for bugs yourself.

Glad to see that we agree, and I can certainly confirm that SmoothL() provides the most stunning TV>PC conversion I have ever seen...it's like the picture becoming even "deeper" subjectively speaking, and it kills two birds w/ one stone providing 10bit'ish performance within 8bit pipelines too.

Well, atm I use an 8bit VGA connection w/ a 10bit CLUT...so all is well, but soon or later I'll be upgrading to a 40" LCD from SONY/LG(I want at least 4K:1 native CR) so it'll be about a 8bit CLUT on top of a 8bit 3DLUT AFAIK...so ideally I would like Argyll's calibration to be embedded within the 3DLUT.

To avoid all those YCbCr>RGB>YCbCr lossy conversions, ideally I would like to input a 16bit RGB gamut mapping LUT from cr3dlut, merge it w/ a .cal file and output a BT.601/709 8bit YUY2 LUT to use w/ rgb3dlut() in ffdshow.

But this would very much require a "reset CLUT while playing" option in mVR, otherwise it'll end up useless....and maybe the flat screen I'll be buying will have serious 10/12bit calibration options so I won't have to use a .cal kludge anymore

So as I said earlier, it's all sheer brainstorming at this point from my side...still, I know some ppl already requested the ability to merge gamut mapping and .cal files together in order to avoid having the CLUT messing around w/ mVR's dithering, but I dunno how much of a PQ difference it would make. And at the end of the day, adding three 1D CLUT's on top of a 3DLUT is nothing more than a kludge at the price of a dispensable quality loss.

Originally Posted by nand chan

Can you run inspect3dlut on a YCbCr .3dlut and upload the output somewhere? (Or simply tell me what it reports for the two color encoding fields)

Sorry for lagging behind in the testing department, I will install a W7SP1 VM on my XPSP3 coz updating .net sounds like headaches.

Here's a 0-255 8bit YUY2 LUT from my CRT gamut to SMPTE-C: BT709_SMPTE-C.rar

[nand chan]

Originally Posted by leeperry

Well, atm I use an 8bit VGA connection w/ a 10bit CLUT...so all is well, but soon or later I'll be upgrading to a 40" LCD from SONY/LG(I want at least 4K:1 native CR) so it'll be about a 8bit CLUT on top of a 8bit 3DLUT AFAIK...so ideally I would like Argyll's calibration to be embedded within the 3DLUT.

Right, this is currently well-possible.

To avoid all those YCbCr>RGB>YCbCr lossy conversions, ideally I would like to input a 16bit RGB gamut mapping LUT from cr3dlut, merge it w/ a .cal file and output a BT.601/709 8bit YUY2 LUT to use w/ rgb3dlut() in ffdshow.

Except for the YUY2 part this is possible already: Create a 16-bit gamut mapping LUT from BT.601 to BT.709 using cr3dlut, merge it with a .cal file using applycal, then change the bit-depth down to 8-bits with changedepth.

Then you'd just have to use that 8-bit RGB lut in ffdshow. It won't be YUY2 though, the problem here would be that .cal doesn't work in YUY2 space - it works in RGB space, so you can't just “apply” a .cal to a YUY2 lut without converting all of the values back and forth. (These won't necessarily be lossy because conversions are performed with 64-bit precision)

But this would very much require a "reset CLUT while playing" option in mVR, otherwise it'll end up useless....and maybe the flat screen I'll be buying will have serious 10/12bit calibration options so I won't have to use a .cal kludge anymore

What you can do is set up a .bat script to run dispclut -d 1 --save file.txt --reset, run MPC-HC, then run dispclut -d 1 --load file.txt once it closes. That way, whenever you start MPC-HC, the LUTs should automatically be reset.

So as I said earlier, it's all sheer brainstorming at this point from my side...still, I know some ppl already requested the ability to merge gamut mapping and .cal files together in order to avoid having the CLUT messing around w/ mVR's dithering, but I dunno how much of a PQ difference it would make. And at the end of day, adding three 1D CLUT's on top of a 3DLUT is nothing more than a kludge at the price of a dispensable quality loss.

Mapping three 1D CLUTs onto a 16-bit 3DLUT using my methods should *always* be higher quality than loading them to the video card, because my calculations properly interpolate the 1d CLUTs to 16-bit space (they are normally 8 bit -> 16 bit on the display device and my program calculates them as 16 bit -> 16 bit). So that gives madVR 16 bits of information to work with after calibration, and it can dither this down properly.

It's certainly an advantage, but you are right, the PQ difference in real world scenarios is debatable.

Here's a 0-255 8bit YUY2 LUT from my CRT gamut to SMPTE-C: BT709_SMPTE-C.rar

I'll have a look, thanks

Edit: Alright, seems like cr3dlut ignores the Color Encoding field as well and just scans through the parameters file to figure out which value type to use.

You can take that YCbCr -> RGB .3dlut as-is and just apply a .cal onto it, should already be fully supported* because the .cal process only modifies the output value and not the input value. It's still a good reference file though, so I know what to scan for to detect ranges etc.

* Since my scripts only work with yCMS parameters at the moment, you'll have to tag your .3dluts as full range using tag3dlut --full -i BT709_SMPTE-C.3dlut, otherwise it will assume limited range and mess up the colors.

But after doing that, applycal -i BT709_SMPTE-C.3dlut your_cal_file.cal should work fine.

[tschi]

Thank you very much for your software
it was so boring to do calibration and after take measure with colorhcfr and after export to Excel and after make data for madvr.
Thank You !

edit : I use your pre 0.6 version because of decimal issue. If i do copy & paste of the result, the all the . are convert to , and I can not paste correctly into madVR (can not click on apply in madVR) Anyway, I was able to generate directly a 3dlut with ti3parser and ycms and use it in madVR

[nand chan]

Originally Posted by tschi

Thank you very much for your software
it was so boring to do calibration and after take measure with colorhcfr and after export to Excel and after make data for madvr.
Thank You !

edit : I use your pre 0.6 version because of decimal issue. If i do copy & paste of the result, the all the . are convert to , and I can not paste correctly into madVR (can not click on apply in madVR) Anyway, I was able to generate directly a 3dlut with ti3parser and ycms and use it in madVR

Thanks for mentioning this, I have to apply the correct culture information when /outputting/ numbers as well. >.<

I think I'll just set a global culture information for the entire application, reduce the amount of hassle.

[nand chan]

Originally Posted by nand chan

I think I'll just set a global culture information for the entire application, reduce the amount of hassle.

Can you tell me whether this version works or not?

http://www.mediafire.com/?ct1xzd6h492d6e3

[leeperry]

Originally Posted by nand chan

you'd just have to use that 8-bit RGB lut in ffdshow. It won't be YUY2 though, the problem here would be that .cal doesn't work in YUY2 space - it works in RGB space, so you can't just “apply” a .cal to a YUY2 lut without converting all of the values back and forth.

The whole point of going YUY2 is that the YCbCr>RGB32 conversion through a LUT hardly requires any CPU power, and it can be MT'ed. It also allows the use of yv12toyuy2() which has a lot of nifty features(like choosing the chroma interpolating algorithm). Using RGB LUT's in ffdshow is far from ideal, and same goes for 16bit LUT's because t3dlut() is required and it's far more CPU hungry than rgb3dlut(). They also double the loading time over 8bit, even off a ramdisk.

What you can do is set up a .bat script to run dispcal -d 1 --save file.txt --reset, run MPC-HC, then run dispcal -d 1 --load file.txt once it closes. That way, whenever you start MPC-HC, the LUTs should automatically be reset.

I'm really looking for a kludge-free HTPC at this point, I've got all my gamut mapping settings within automatic ffdshow profiles, that's how cool it's gotten

Hopefuly, madshi is reading this: an option to bypass the graphic card's CLUT when mVR is playing would be amazing

You can take that YCbCr -> RGB .3dlut as-is and just apply a .cal onto it, should already be fully supported* because the .cal process only modifies the output value and not the input value. [..] applycal -i BT709_SMPTE-C.3dlut your_cal_file.cal should work fine.

Alright, sounds like a plan! Whenever I'll find the courage to install a W7SP1 VM, I'll get back to you.

[nand chan]

Also keep in mind that some tools* may not work entirely correctly yet because I haven't written code for separately detecting the input depth and output depth (I'll add that by 0.7), so right now if the output range changes then the entire range changes.

I'll write code sooner or later to pulldown the input range and output range independently of each-other and detect both ranges correctly.

*This should probably just affect changedepth -r and imagecal -3

Alright, sounds like a plan! Whenever I'll find the courage to install a W7SP1 VM, I'll get back to you.

Is it that hard to install .NET 4.0 on XP? If it's a huge problem I may be able to find some way around it, but the way I'm generating lambda functions on the fly* right now requires 4.0.

* Since .3dLUTs can be so different (bytes, ushorts, floats, PC levels, TV levels, color encoding etc) I generate the correct function for an operation during runtime - or at least, I used to, I could probably reduce these lambdas to static delegates now that I'm just about finished outlying all logic to the unified 64-bit floating point pipeline.

What I'll probably doing by version 0.7 or 0.8 is abstracting all transformation operations behind an ITransformationProvider interface and compositing these objects together on the fly and packaging them into a TransformationFactory. That way you will be able to serialize a bunch of different composite operations into a loadable file and pass them around, or store them inside a .3dlut's meta-tags, allowing for rapid prototyping, modification and large-scale distribution of environment-tailored 3dLUTs through a common interface.

Then I could probably create a drag and drop UI front-end for it that allows you to visualize composite transformations and preview them on the fly.

But for now, the delegates shall suffice.

[leeperry]

It all sounds very appetizing, even though most of it flies way above my head...but I like the GUI part

I already tried to update .net from 2.0 to 4.0, it started downloading zillion updates, deleted all the files I had at the root of my C: drive, ended up claiming more than 1GB of hard drive space, and then whined right in the middle that some components couldn't be updated...duh. .net is great for coders, but it's a whole bunch of bloat as far as I can see.

[nand chan]

Originally Posted by leeperry

It all sounds very appetizing, even though most of it flies way above my head...but I like the GUI part

I already tried to update .net from 2.0 to 4.0, it started downloading zillion updates, deleted all the files I had at the root of my C: drive, ended up claiming more than 1GB of hard drive space, and then whined right in the middle that some components couldn't be updated...duh. .net is great for coders, but it's a whole bunch of bloat as far as I can see.

Well, .NET 3.5 comes pre-installed on Windows 7 afaik and updating to 4.0 on Win7 should work flawlessly.

Updating to 3.5 on Windows XP also worked fine back when I was using it.

Note: .NET is also great for end users because it allows processor-specific optimization on the target platform. It's the reason why I can distribute a single managed executable that will assemble down to the correct architecture (x86, AMD64 / Intel 64, SSE etc.) when you run it for the first time.

Here are some prerequisites:

• .NET 4.0 requires XP SP3, Win2k3 SP2, Vista, 7, or 2008(R2)
• .NET 3.5 requires XP SP2 or newer.
• .NET 2.0 requires Win2K SP(3?) or newer.

[cyberbeing]

Quick comment on dispclut.exe. Using --reset (Windows-default 8-bit CLUT?) doesn't do the desired behavior, since most calibration applications use a 16-bit linear CLUT.

--reset results in:

#GammaRamp
0	0	0	0
1	256	256	256
2	512	512	512
3	768	768	768
4	1024	1024	1024
5	1280	1280	1280
6	1536	1536	1536
7	1792	1792	1792
8	2048	2048	2048
9	2304	2304	2304
10	2560	2560	2560
11	2816	2816	2816
12	3072	3072	3072
13	3328	3328	3328
14	3584	3584	3584
15	3840	3840	3840
16	4096	4096	4096
17	4352	4352	4352
18	4608	4608	4608
19	4864	4864	4864
20	5120	5120	5120
21	5376	5376	5376
22	5632	5632	5632
23	5888	5888	5888
24	6144	6144	6144
25	6400	6400	6400
26	6656	6656	6656
27	6912	6912	6912
28	7168	7168	7168
29	7424	7424	7424
30	7680	7680	7680
31	7936	7936	7936
32	8192	8192	8192
33	8448	8448	8448
34	8704	8704	8704
35	8960	8960	8960
36	9216	9216	9216
37	9472	9472	9472
38	9728	9728	9728
39	9984	9984	9984
40	10240	10240	10240
41	10496	10496	10496
42	10752	10752	10752
43	11008	11008	11008
44	11264	11264	11264
45	11520	11520	11520
46	11776	11776	11776
47	12032	12032	12032
48	12288	12288	12288
49	12544	12544	12544
50	12800	12800	12800
51	13056	13056	13056
52	13312	13312	13312
53	13568	13568	13568
54	13824	13824	13824
55	14080	14080	14080
56	14336	14336	14336
57	14592	14592	14592
58	14848	14848	14848
59	15104	15104	15104
60	15360	15360	15360
61	15616	15616	15616
62	15872	15872	15872
63	16128	16128	16128
64	16384	16384	16384
65	16640	16640	16640
66	16896	16896	16896
67	17152	17152	17152
68	17408	17408	17408
69	17664	17664	17664
70	17920	17920	17920
71	18176	18176	18176
72	18432	18432	18432
73	18688	18688	18688
74	18944	18944	18944
75	19200	19200	19200
76	19456	19456	19456
77	19712	19712	19712
78	19968	19968	19968
79	20224	20224	20224
80	20480	20480	20480
81	20736	20736	20736
82	20992	20992	20992
83	21248	21248	21248
84	21504	21504	21504
85	21760	21760	21760
86	22016	22016	22016
87	22272	22272	22272
88	22528	22528	22528
89	22784	22784	22784
90	23040	23040	23040
91	23296	23296	23296
92	23552	23552	23552
93	23808	23808	23808
94	24064	24064	24064
95	24320	24320	24320
96	24576	24576	24576
97	24832	24832	24832
98	25088	25088	25088
99	25344	25344	25344
100	25600	25600	25600
101	25856	25856	25856
102	26112	26112	26112
103	26368	26368	26368
104	26624	26624	26624
105	26880	26880	26880
106	27136	27136	27136
107	27392	27392	27392
108	27648	27648	27648
109	27904	27904	27904
110	28160	28160	28160
111	28416	28416	28416
112	28672	28672	28672
113	28928	28928	28928
114	29184	29184	29184
115	29440	29440	29440
116	29696	29696	29696
117	29952	29952	29952
118	30208	30208	30208
119	30464	30464	30464
120	30720	30720	30720
121	30976	30976	30976
122	31232	31232	31232
123	31488	31488	31488
124	31744	31744	31744
125	32000	32000	32000
126	32256	32256	32256
127	32512	32512	32512
128	32768	32768	32768
129	33024	33024	33024
130	33280	33280	33280
131	33536	33536	33536
132	33792	33792	33792
133	34048	34048	34048
134	34304	34304	34304
135	34560	34560	34560
136	34816	34816	34816
137	35072	35072	35072
138	35328	35328	35328
139	35584	35584	35584
140	35840	35840	35840
141	36096	36096	36096
142	36352	36352	36352
143	36608	36608	36608
144	36864	36864	36864
145	37120	37120	37120
146	37376	37376	37376
147	37632	37632	37632
148	37888	37888	37888
149	38144	38144	38144
150	38400	38400	38400
151	38656	38656	38656
152	38912	38912	38912
153	39168	39168	39168
154	39424	39424	39424
155	39680	39680	39680
156	39936	39936	39936
157	40192	40192	40192
158	40448	40448	40448
159	40704	40704	40704
160	40960	40960	40960
161	41216	41216	41216
162	41472	41472	41472
163	41728	41728	41728
164	41984	41984	41984
165	42240	42240	42240
166	42496	42496	42496
167	42752	42752	42752
168	43008	43008	43008
169	43264	43264	43264
170	43520	43520	43520
171	43776	43776	43776
172	44032	44032	44032
173	44288	44288	44288
174	44544	44544	44544
175	44800	44800	44800
176	45056	45056	45056
177	45312	45312	45312
178	45568	45568	45568
179	45824	45824	45824
180	46080	46080	46080
181	46336	46336	46336
182	46592	46592	46592
183	46848	46848	46848
184	47104	47104	47104
185	47360	47360	47360
186	47616	47616	47616
187	47872	47872	47872
188	48128	48128	48128
189	48384	48384	48384
190	48640	48640	48640
191	48896	48896	48896
192	49152	49152	49152
193	49408	49408	49408
194	49664	49664	49664
195	49920	49920	49920
196	50176	50176	50176
197	50432	50432	50432
198	50688	50688	50688
199	50944	50944	50944
200	51200	51200	51200
201	51456	51456	51456
202	51712	51712	51712
203	51968	51968	51968
204	52224	52224	52224
205	52480	52480	52480
206	52736	52736	52736
207	52992	52992	52992
208	53248	53248	53248
209	53504	53504	53504
210	53760	53760	53760
211	54016	54016	54016
212	54272	54272	54272
213	54528	54528	54528
214	54784	54784	54784
215	55040	55040	55040
216	55296	55296	55296
217	55552	55552	55552
218	55808	55808	55808
219	56064	56064	56064
220	56320	56320	56320
221	56576	56576	56576
222	56832	56832	56832
223	57088	57088	57088
224	57344	57344	57344
225	57600	57600	57600
226	57856	57856	57856
227	58112	58112	58112
228	58368	58368	58368
229	58624	58624	58624
230	58880	58880	58880
231	59136	59136	59136
232	59392	59392	59392
233	59648	59648	59648
234	59904	59904	59904
235	60160	60160	60160
236	60416	60416	60416
237	60672	60672	60672
238	60928	60928	60928
239	61184	61184	61184
240	61440	61440	61440
241	61696	61696	61696
242	61952	61952	61952
243	62208	62208	62208
244	62464	62464	62464
245	62720	62720	62720
246	62976	62976	62976
247	63232	63232	63232
248	63488	63488	63488
249	63744	63744	63744
250	64000	64000	64000
251	64256	64256	64256
252	64512	64512	64512
253	64768	64768	64768
254	65024	65024	65024
255	65280	65280	65280

The per-calibration linear CLUT of ArgyllCMS, i1Profiler, basICColor, ColorEyes:

#GammaRamp
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

My suggestion would be keep both, but just add a 'dispclut.exe --linear' command.

[nand chan]

Originally Posted by cyberbeing

Quick comment on dispclut.exe. Using --reset (Windows-default 8-bit CLUT?) doesn't do the desired behavior, since most calibration applications use a 16-bit linear CLUT.

No, I'm actually generating the 16-bit ramp you posted manually.

I don't know how Windows (or rather, the graphics card) translates a 16-bit ramp down to an 8-bit display device.

I'll see if I can find out whether 65535 or 65280 is used for maximum white (255 signal).

In a somewhat unrelated note, I've now provided a common interface for color transformations (ITransformationProvider) as well as a way to combine these together (TransformationFactory) and sequence them (PipelineTransformer).

This allows a developer to create and arrange parameterized transformation construct, then “compute” a single 64bit->64bit function using .GetTransformer(), that can be re-used to look up a bunch of values.

For example, if I want to create an 8 bit -> 16 bit grayscale 3dlut with attached calibration data, I can do this:

new TransformationFactory(
    PulldownTransformer(8, Range.Full),
    GrayscaleTransformer(Recommendation.BT709),
    CalibrationTransformer(CalFile.FromFile("somecal.txt")),
    PullupTransformer(16, Range.Full)
    ).GetTransformer();

Now I just have to create a GUI for it.

Edit: I'll just assume ArgyllCMS, i1Profiler, basICColor and ColorEyes know what they're doing when they mean linear = linear and use the same.

[cyberbeing]

Running 'dispclut.exe --reset' results in an 8-bit ramp similar to hitting the 'Reset' button in Calibration Tester, Windows built-in lut loader, or using RivaTuner to forcibly reload your GPU driver.

If you run 'dispwin.exe -c' from the ArgyllCMS package, it loads the 16-bit ramp (as seen with Calibration Tester). All other Calibration applications do the same, loading a 16-bit linear ramp pre-calibration.

Other other hand, if I run 'dispclut.exe --load' pointing to an exported 16-bit ramp, it does load the 16-bit ramp correctly.

dispclut.exe --reset = 8-bit ramp
dispclut.exe --load = 16-bit ramp

I would conclude that the 8-but ramp is the Windows default, and 16-bit ramps need to be specially loaded. What differs between dispclut.exe --reset and --load?

[nand chan]

Originally Posted by cyberbeing

Running 'dispclut.exe --reset' results in an 8-bit ramp similar to hitting the 'Reset' button in Calibration Tester, Windows built-in lut loader, or using RivaTuner to forcibly reload your GPU driver.

If you run 'dispwin.exe -c' from the ArgyllCMS package, it loads the 16-bit ramp (as seen with Calibration Tester). All other Calibration applications do the same, loading a 16-bit linear ramp pre-calibration.

Other other hand, if I run 'dispclut.exe --load' pointing to an exported 16-bit ramp, it does load the 16-bit ramp correctly.

dispclut.exe --reset = 8-bit ramp
dispclut.exe --load = 16-bit ramp

I would conclude that the 8-but ramp is the Windows default, and 16-bit ramps need to be specially loaded. What differs between dispclut.exe --reset and --load?

No, there's no such thing as an 8-bit ramp. Windows only provides the 16-bit interface. There's also no “ResetGammaRamp” function. To reset anything, you have to generate a 16-bit ramp and load it.

The cause for the difference in results you are seeing is two different generation methods:

The “8-bit” ramp:
output = input << 8
Results in eg. 1010 1010 0000 0000

The “linear” ramp:
output = (input << 8) + input
Results in eg. 1010 1010 1010 1010

In both cases, a fresh gamma ramp is being created and then loaded. There's no such thing as a “windows default” gamma ramp.

[cyberbeing]

Good to know, but could explain it in a non-technical way?
It's always been a mystery to me why the "8-bit" ramp happens on Windows, yet lut loaders somehow are able to bypass this and load a 16-bit CLUT.

Why was --reset originally doing output = input << 8?
16-bit input=output CLUT loaded, but Windows (?) shifts it to 8-bit?

Why was --load doing output = (input << 8) + input
16-bit input=output CLUT loaded, Windows (?) shifts it to 8-bit, then a 16-bit input!=output linear ramp is loaded yet it sticks? I don't understand the + input part.

[nand chan]

Originally Posted by cyberbeing

Good to know, but could explain it in a non-technical way?
It's always been a mystery to me why the "8-bit" ramp happens on Windows, yet lut loaders somehow are able to bypass this and load a 16-bit CLUT.

Why was --reset originally doing output = input << 8?
16-bit input=output CLUT loaded, but Windows (?) shifts it to 8-bit?

Why was --load doing output = (input << 8) + input
16-bit input=output CLUT loaded, Windows (?) shifts it to 8-bit, then a 16-bit input!=output linear ramp is loaded yet it sticks? I don't understand the + input part.

Once again, there's no such thing as an 8-bit LUT. Windows doesn't shift anything.

It was previously “input << 8” because that's what I previously wrote in my ResetGammaRamp() code.

Some tools simply use the different logic. They're both loaded the same way (as 16 bit), and they stay that way once loaded.

Note: This is not entirely true, Windows does clamp the LUTs a bit to make sure they're “proper” gamma ramps. You can't do things like inverting the colors or drastically reducing one channel because it will fail windows' sanity check. But other than that, Windows should not modify it (or especially the bit-depth).

-- load was doing nothing, it was simply loading the information from a file.

[cyberbeing]

If I'm understanding you correctly, --reset was loading the exact 16-bit ramp CLUT you had it coded to use:

#GammaRamp
0	0	0	0
1	256	256	256
2	512	512	512
3	768	768	768
4	1024	1024	1024
...

Using --load resulted in a different CLUT, because the 16-bit linear ramp I was trying to load actually was a different CLUT than what -reset was using?

It makes me wonder if

#GammaRamp
0	0	0	0
1	256	256	256
2	512	512	512
3	768	768	768
4	1024	1024	1024
...

is more optimal than

#GammaRamp
0	0	0	0
1	257	257	257
2	514	514	514
3	771	771	771
4	1028	1028	1028
...

if your GPU only does CLUT processing in 8-bit, or if they would both ultimately result in the same thing.

[nand chan]

Originally Posted by cyberbeing

If I'm understanding you correctly, --reset was loading the exact 16-bit ramp CLUT you had it coded to use:

#GammaRamp
0	0	0	0
1	256	256	256
2	512	512	512
3	768	768	768
4	1024	1024	1024
...

Using --load resulted in a different CLUT, because the 16-bit linear ramp I was trying to load actually was a different CLUT than what -reset was using?

It makes me wonder if

#GammaRamp
0	0	0	0
1	256	256	256
2	512	512	512
3	768	768	768
4	1024	1024	1024
...

is more optimal than

#GammaRamp
0	0	0	0
1	257	257	257
2	514	514	514
3	771	771	771
4	1028	1028	1028
...

if your GPU only does CLUT processing in 8-bit, or if they would both ultimately result in the same thing.

Yes, that is correct. About your question, I don't know - I'm using the linear ramps for now, I figure they'll be correct.

There's probably no difference between the two because I'm guessing that windows just right shifts the values 8 places when on an 8-bit display device.

It will probably only make a difference for 10-bit and higher devices. Can you detect any visible change when switching between the two?

[tschi]

Originally Posted by nand chan

Can you tell me whether this version works or not?

http://www.mediafire.com/?ct1xzd6h492d6e3

it's ok