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

[Wile-E-Coyote]

Going to go ahead and release version 0.5 as-is because the software is still alpha either way and I don't want to delay the current release/feedback cycle too much.
Might still be some bugs, I haven't extensively tested every single tool after the code re-write. Everything should be a lot, lot cleaner though.

In version 0.6 I am going to be adding multi-threaded .3dlut processing to speed up execution time on multi-core processors.

As usual, see the first post for a changelog: http://www.mediafire.com/?wwbuu5vhau5x6jm

I'm still trying to think of a new name for the project.



Works fine for me in version 0.5, try it.
I did. Same error.

[nand chan]

I agree, third and first look pretty much identical.
The 4th shows more banding then the others.

Also H-IPS 10bit with 12bit LUT (Dell U3011)

Dell U2410 here :rolleyes:

I've finished writing the multi-threading code now, applycal.exe completes /calculation/ in about 0.6 seconds. Saving/loading the .3dlut still takes about 1 second overall.

CPU usage spikes nice and high at 100%. :)

I did. Same error.

I can't reproduce it. It works fine here, even using the GUI. Are you sure you're using the latest version?

[Wile-E-Coyote]

I can't reproduce it. It works fine here, even using the GUI. Are you sure you're using the latest version?
Yes, .NET framework is also up to date. I'll guess I have no choice but sit through another 2 hours of calibration to try again.

[nand chan]

Yes, .NET framework is also up to date. I'll guess I have no choice but sit through another 2 hours of calibration to try again.

Does running
genscript.exe -i profil.ti3 -o -
work?

It works here and it should output the following: http://pastebin.com/pmei93qL

You can go ahead and copy/paste that into a .txt file, run it using yCMS and it should give you a working .3dlut.
(You already have a copy of yCMS in %AppData%\TI3Parser\yCMS if you've been using this program)

It's not dithering at all, it's grain added on purpose via the GrainFactory4() Avisynth script(I'm a movie grain whore :p). But you can see that 10bit untouched mVR processing and SmoothL+8bit YUY2 LUT in ffdshow+mVR dithering look identical, which was my original point...so to me that still leaves the ffdshow LUT option very much open.

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.

[Wile-E-Coyote]

Does running
genscript.exe -i profil.ti3 -o -
work?

It works here and it should output the following: http://pastebin.com/pmei93qL

You can go ahead and copy/paste that into a .txt file, run it using yCMS and it should give you a working .3dlut.
(You already have a copy of yCMS in %AppData%\TI3Parser\yCMS if you've been using this program)

No running that command line gives me the same error message. I'll try your advice later. Thanks.

EDIT : yCMS gives me an error message as well
Error! Invalid Command: '109.8925'.

[nand chan]

No running that command line gives me the same error message. I'll try your advice later. Thanks.

EDIT : yCMS gives me an error message as well

Very odd, I get:
The file '..\test.3dlut' was successfully created.
Running time: 4449ms; Computation time: 1765ms (39.7%)

When you're saving the file do you have some sort of word wrap enabled maybe? Also what operating system are you on? Maybe it's detecting the line breaks incorrectly, which would explain both issues.

@leeperry: 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)

[Wile-E-Coyote]

Very odd, I get:
The file '..\test.3dlut' was successfully created.
Running time: 4449ms; Computation time: 1765ms (39.7%)

When you're saving the file do you have some sort of word wrap enabled maybe? Also what operating system are you on? Maybe it's detecting the line breaks incorrectly, which would explain both issues.
Word wrap? Not that I know of. I pasted the text on notepad.

I'm running Win 7 Ultimate x64

[nand chan]

Word wrap? Not that I know of. I pasted the text on notepad.

I'm running Win 7 Ultimate x64

See “Format -> Word Wrap”.

Regardless, I don't know what else could be causing the problems.

[Wile-E-Coyote]

See “Format -> Word Wrap”.

Regardless, I don't know what else could be causing the problems.
Word wrap is deactivated, but I decided to open the file in Notepad++ and re-save it, and it worked, at least for yCMS.

I'm trying to use that method for the 3ti files but without success so far.

[alph@]

Hello.

I just successfully calibrated my TV with dispcalGUI and wanted to create a 3Dlut file with it but when I open my ti3 file I get an error message saying the input string format is incorrect.
here too, same error message?i have the framwork 4,it's the last version of ti3 Parser
upload
http://www.mediafire.com/?rr2648w3ow9ftb4

[nand chan]

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]

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]

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 :o

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.

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 (http://www.mediafire.com/?ana45biwywbhej4)

[nand chan]

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 :o

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 (http://www.mediafire.com/?ana45biwywbhej4)

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 :thanks:
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]

Thank you very much for your software :thanks:
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]

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]

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 :D

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

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. :thanks:

[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. :thanks:

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. :rolleyes:

[leeperry]

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

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]

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

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]

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]

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]

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]

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]

Can you tell me whether this version works or not?

http://www.mediafire.com/?ct1xzd6h492d6e3
it's ok :thanks:

[cyberbeing]

Can you detect any visible change when switching between the two?

Hard to say, but interestingly using the 'reset' one, dispcalGUI reports it as only 99.6% of grayscale values. For 0-128 output=input. For 129-255 output=input-1. Using the 'linear' shows 100% of grayscale input=output 0-255. For all we know, that could just be a bug in dispcalGUI though.

I'm thinking the 'reset' style ramp one must be a legacy thing or misinterpretation, since looking back, that is what older calibration programs like ProfileMaker 5 use.

Maximum value for each color is 65280 instead of 65535. Why? Maximum number of 8-bit number is 0xFF (255). Maximum number of gradations for each channel is 256.

255 * 256 = 65280
A Google search came up with the above by a forum poster, but I'm not sure that is correct logic. 8-bit values range from 0-255 (256) which matches up with the 0-255 (256) gradations. Maybe there was a bug in old GPU hardware or drivers which made 8-bit 0x0 null and mapped 0x1 to 0 or was it just a case of poor documentation by Microsoft confusing people? Not something I think you need to worry about now, since there seems to have been a transition at some point to using 65535 as the maximum value in modern calibration software.

[alph@]

version 0,6 work , no error message,the function 'save as 3dlut ' is not available,only 'save ycms script',it's normal?
http://www.zimagez.com/miniature/sanstitref38ddb19fd2dfab78bb276f842638899.png (http://www.zimagez.com/zimage/sanstitref38ddb19fd2dfab78bb276f842638899.php)

[nand chan]

Hard to say, but interestingly using the 'reset' one, dispcalGUI reports it as only 99.6% of grayscale values. For 0-128 output=input. For 129-255 output=input-1. Using the 'linear' shows 100% of grayscale input=output 0-255. For all we know, that could just be a bug in dispcalGUI though.

I'm thinking the 'reset' style ramp one must be a legacy thing or misinterpretation, since looking back, that is what older calibration programs like ProfileMaker 5 use.


A Google search came up with the above by a forum poster, but I'm not sure that is correct logic. 8-bit values range from 0-255 (256) which matches up with the 0-255 (256) gradations. Maybe there was a bug in old GPU hardware or drivers which made 8-bit 0x0 null and mapped 0x1 to 0 or was it just a case of poor documentation by Microsoft confusing people? Not something I think you need to worry about now, since there seems to have been a transition at some point to using 65535 as the maximum value in modern calibration software.

I'm just going to follow along with it for now, I have higher things on my priority list (such as getting version 0.6 out) than breaking my head over an imperceptible difference.

version 0,6 work , no error message,the function 'save as 3dlut ' is not available,only 'save ycms script',it's normal?
http://www.zimagez.com/miniature/sanstitref38ddb19fd2dfab78bb276f842638899.png (http://www.zimagez.com/zimage/sanstitref38ddb19fd2dfab78bb276f842638899.php)

Tried Update -> Update yCMS? If that doesn't work, it may be a restriction with Windows' security policy. I'll see if I can find a way around that.

[alph@]

ok work,i have updated ycms and launch the 'TI3ParserGUI.exe' with administrator Rights,you are correct:),this week end I start the test with my sony lcd 46 hx 700 and the combo xrite -colorhcfr,thank very match.

[nand chan]

Going to release version 0.6 as-is for now, so you don't get caught up in the delays of a bunch of behind the scenes changes. I will be making greater use of the improved pipeline in 0.7.

Download link for 0.6: http://www.mediafire.com/?112ct1ijm2e2edz

[nand chan]

http://img13.imageshack.us/img13/3766/guir.png

Experimental mock-up design of my proposed 3dLUT Creation Studio.

What do you think? I could also allow stuff like YCbCr -> RGB conversion blocks, or gamut mapping blocks. Then we wouldn't even need yCMS anymore.

Or you could do fun stuff like this:

http://img850.imageshack.us/img850/4587/chanswap.png

[yesgrey]

Which means that I am now being bottlenecked by the limited capacity of the .3dlut file standard, even though my code is perfectly capable of processing something irregular like 10-bit LUTs (as opposed to 8, 16 or 32).
That "limited" capacity you referred was intentional.

The benefit of allowing bit depths other than those would be only a lower 3DLUT file size. We think that a 96 MB (8/16 3DLUT) is a pretty manageable size according to current computer standards, so we favoured a simpler file format structure. In addition to that, I performed some precision tests that showed which input/output bit depth combinations would be useful. For an 8 bit input bit depth using more than 16 bit output is not worth it. The 32 FP was added for future use, when/if we decide to use 9/32 3DLUT files (1.5 GB), but before that we need to have graphic cards with a minimum of 2 GB ram to contain the 3DLUT... ;)

Furthermore, 32 bit FP was preferred over 32 bit integer because the precision is almost the same but 32 FP is much more compressible than 32 bit integer.

[nand chan]

That "limited" capacity you referred was intentional.

The benefit of allowing bit depths other than those would be only a lower 3DLUT file size. We think that a 96 MB (8/16 3DLUT) is a pretty manageable size according to current computer standards, so we favoured a simpler file format structure. In addition to that, I performed some precision tests that showed which input/output bit depth combinations would be useful. For an 8 bit input bit depth using more than 16 bit output is not worth it. The 32 FP was added for future use, when/if we decide to use 9/32 3DLUT files (1.5 GB), but before that we need to have graphic cards with a minimum of 2 GB ram to contain the 3DLUT... ;)

Furthermore, 32 bit FP was preferred over 32 bit integer because the precision is almost the same but 32 FP is much more compressible than 32 bit integer.

Yeah, it's reasonable enough. Something like a 8->10 bit LUT would be horrendously hard to work with if you just write 10 bits into the file at a time, and if you pad the data to 16 bit to make reading easier, might as well just use 16 bit precision.

That being said, the .3dlut file format has some other, ridiculously major flaws imo, because it's lacking a lot of meta-tags.

While these tags are not strictly speaking necessary for the operation of a LUT as such, many tools *do* want to be more content-aware (eg. is the input or output range 0-255 or 16-235?), a prime example being madVR itself - which scans through the parameters file to find out information.

Of course, this breaks as soon as it encounters a .3dlut not created by any known tool, even if the LUT itself would be in the correct format, simply because it isn't searching for the correct strings.

The result is that I have to pad my parameters data with “madVR compatibility hacks”.

Inclusion of this information, as well as stuff like gamut, gamma, and white point would be *critical* to a fully functional 3dLUT format.

Ps. Floating point can have another advantage: Since value ranges are normalized from 0 to 1, that makes gamut mapping independent of the level range. madVR arguably already works this way because it only works with limited range /output/ LUTs (and transforms these further), but it's a bit silly regardless.

Floating point has another advantage of that you're strictly limited to 0-1, you can introduce whiter than white / blacker than black information.

Edit: Also, what about 9->16 bit LUTs for eg. Hi10P content? Though I suppose it doesn't matter because madVR doesn't dither down to 8 bit precision, it interpolates the .3dlut results up to 10 bit instead.

I don't suppose it should make a significant difference.

[nand chan]

Concept of a proposed scripting language I was toying with, as an analog to the above flowchart GUI:

!Input_Range 16 235
!Input_Depth 8 8 8
!Output_Range 0 255
!Output_Depth 16

# Import the CalFile namespace, which gives us access to the CalFile() filter
!Import(Files.CalFile)

# Example .3dlut generation script
!Pixel {

# Since this is going to be a YCbCr script, first convert to RGB using the BT.709 primaries
ConvertToRGB(BT709)

# Now we want to adjust for our screen's somewhat darker gamma curve
Gamma(2.2,2.35)

# And apply the calibration info from an argyll file
CalFile("path_to_file.ti3")

# And just for fun, grayscale it
Grayscale()

}

Things to consider:

- Allow custom scripting logic or not? Eg. declaration of variables, creation of custom transform filters or just allow loading these via managed assemblies
- Maybe include the pixel pulldown / pullup logic into the !Pixel pipeline itself? The reason doing this might be bad though is it would disencourage creation of meta-data, which renderers such as madVR would rely on.

Interesting realization:

If I went through with this scripting language, it obviously wouldn't be limited to just .3dluts. I could, for example, save them as transformation pipeline packages (.tpp?) and apply these to images etc. manually.

I could also introduce filters such as ChangeGamut() or ChangeWhitepoint().

I've also put some thought into how to do multiplexing. In the most basic idea, single-pixel filters would be distinguished by some sort of extra markup in the name, for example a period or $ or _ or something.

# Single filters could be applied like this
Multiplex(BlockR, BlockG, BlockB)

# For example
Multiplex($Gamma(1.0), $Gamma(0.9), $Gamma(0.8))

# A null or noop operation could either be represented as “null”..
Multiplex($Gamma(0.5), null, null)
# ..left out..
Multiplex($Gamma(0.5), ,)
# or perhaps done with $Cat() or $Default() or something
Multiplex($Gamma(0.5), $Cat(), $Cat())

# Larger blocks of multiple filters would be joined by { }
Multiplex({ $Gamma(0.5) $Add(0.1) }, { $Gamma(0.8) $Add(0.2) }, $Cat())

# Which can be stretched over several lines
Multiplex({
$Gamma(0.5)
$Add(0.1)
}, $Cat(), $Cat())

# The basic idea here is that newlines are ignored
Gamma(
2.2,
2.35 )

Further thoughts: Maybe extend my scripting format to custom amounts of channels? For example, a 3 -> 4 channel convertor that would convert from RGB to CMYK.

This obviously wouldn't be saveable as a .3dlut due to the limitation of the file format, but I could still save them as .tpp and use for proofing or something.

Feedback / thoughts?

[yesgrey]

That being said, the .3dlut file format has some other, ridiculously major flaws imo, because it's lacking a lot of meta-tags.
...
Inclusion of this information, as well as stuff like gamut, gamma, and white point would be *critical* to a fully functional 3dLUT format.
3DLUT format spec is not complete yet. In the beginning the current state was more than enough, but now I'm perfectly aware that it's not. Unfortunately I currently don't have time to finish it, so we have to discuss it later.

Ps. Floating point can have another advantage: Since value ranges are normalized from 0 to 1, that makes gamut mapping independent of the level range.
No, it's not. The black and white with FP is not always 0.0 and 1.0. That happens only with levels 0-255.

Also, what about 9->16 bit LUTs for eg. Hi10P content?
Using a 9/16 (768MB) 3DLUT for a small increase in precision it's not worth it. The 9/32 (1536MB) shows a significant theoretical increase, but probably no one would be able see any difference, so it might not be worth it too...

[nand chan]

No, it's not. The black and white with FP is not always 0.0 and 1.0. That happens only with levels 0-255.

I don't see what the motive for this decision is (I've included support for it regardless), any reason?

Since you're pulling down from 16-235 in the first place, why not go all the way and just pull them into 0-1? You actually increase precision instead of losing it, since values don't have to be rounded. The only motive for not normalizing integer 3dLUTs to full range is because you lose WTW/BTB information that way, but with FP it's not an issue.

Using a 9/16 (768MB) 3DLUT for a small increase in precision it's not worth it. The 9/32 (1536MB) shows a significant theoretical increase, but probably no one would be able see any difference, so it might not be worth it too..

Depends on how good the interpolation algorithm is I suppose. I'm currently using linear interpolation (between individual steps) which causes aliasing, but if you were to find out the gamma curve (again, meta-tags) and do a correct non-linear interpolation, the quality of interpolation should be significantly better.

I suppose it would make less of a difference the better the screen is.

[alph@]

i create a 3dlut file for ycms (curve +matrice-120cd-gamma2,35 -testchart 912-profil hight quality) Here are the results
http://www.zimagez.com/miniature/mesures7.png (http://www.zimagez.com/zimage/mesures7.php)
left no ycms-right with,the deltaE after is best
http://www.zimagez.com/miniature/courbes1.png (http://www.zimagez.com/zimage/courbes1.php)

http://www.zimagez.com/miniature/gamma6.png (http://www.zimagez.com/zimage/gamma6.php)
the correction of gamma is very good

http://www.zimagez.com/miniature/color19.png (http://www.zimagez.com/zimage/color19.php)
color correction is different,the delta luma red is very good,but the blue going from 9 to 15??,

http://www.zimagez.com/miniature/color24.png (http://www.zimagez.com/zimage/color24.php)

[nand chan]

color correction is different,the delta luma red is very good,but the blue going from 9 to 15??

Might just be a limitation of the screen, eg. you can't get correct colors unless you set a certain channel to be too bright (especially for black point correction).

At any rate, this would probably be more appropriate in the yCMS topic.

[alph@]

I use a gamma of 2,35 instead of 709 bt,it's a probleme? and why the diagramme cie is out in the green,ycms must compromise?
'you can't get correct colors unless you set a certain channel to be too bright (especially for black point correction)'
Excuse me, but what is the relation with the black point:helpful:

[nand chan]

I use a gamma of 2,35 instead of 709 bt,it's a probleme? and why the diagramme cie is out in the green,ycms must compromise?

I don't know this.

'you can't get correct colors unless you set a certain channel to be too bright (especially for black point correction)'
Excuse me, but what is the relation with the black point:helpful

Well, when you're on an LCD monitor, you have a certain level range (0-255) which you can't go outside of.

So if your black point (of 0/0/0) is too red, the logical thing you'd have to do is decrease the red channel (-5/0/0). However, this is simply physically not possible.

To compensate, to fix the tone balance, you have to increase the other channels instead, eg. (0/5/5).

However, this results in a “brighter” black than 0/0/0. In other words, fixing the black point's tone balance can offset its luminance (brightness).

That's why the luma error increases.

[nand chan]

Version 0.7 is out!

Changelog is in the first post as usual.

Download link: http://www.mediafire.com/?ugaa1y0o5a1452g

Since this release introduces LutScript files (.3ls), I will post an example file here until the formal documentation is complete:

######################################
## Example .3dlut generation script ##
######################################

# Set the properties properly
!Input_Range(Limited)
!Input_Depth(8,8,8)
!Output_Range(Limited)
!Output_Depth(16)

# An example transformation pipeline. Note that this !Pixel pipeline applies pulldown and range adjustment
# so you don't have to do it manually. All numbers are normalized to the range 0-1 within here.
!Pixel( {

# Load the logic from an existing .3dlut
LutFile("some_3dlut.3dlut")

# And apply the calibration info from an argyll file
CalFile("path_to_file.ti3")

# And just for fun, grayscale it
Grayscale()

} )

List of current functions: (All are case-insensitive)

Meta / top-level functions:
!Input_Range(Full | Limited): Sets the range appropriately
!Input_Depth(Number, Number, Number): Sets the depth appropriately
!Output_Range(Full | Limited): Sets the range appropriately
!Output_Depth(Number): Sets the depth appropriately
!Pixel(Function): Creates a pixel transformation pipeline (with appropriate adjustments) from the given function.
Multiple of these can be “glued” together to form a block by using { and }

Pixel functions:
Grayscale(): Converts to grayscale
CalFile(String): Applies calibration information from a given .cal or .ti3 file
LutFile(String): Applies a LUT transformation using a given .3dlut
Constant(Number, Number, Number): Outputs a constant value, for example (1, 1, 1) to create a LUT that blanks to white
Invert(): Inverts the input

The .3dlut is calculated by appending each !Pixel() function together (without further transformations), then mapping each possible value through the list.

Do note that to use the generated .3dlut with madVR you need to tag it with BT.709 primaries first using tag3dlut -7

All LutFile() functions are completely independent of each other and detect ranges/depth for their own .3dlut, that is, you could mix a 16-bit 3dlut with a 10-bit 3dlut and an 8-bit 3dlut freely, or mix together limited and full range .3dluts. It really doesn't matter one bit, as long as they are tagged correctly.

To-do / planned functions:

ConvertFromYCbCr(Primaries): Would convert from YCbCr to RGB
Gamma(): Would adjust values using a given gamma coefficient
Swap(Number, Number): Would swap the two channels
Cat(): Would return the input as output, useful for where you want a .3dlut to do nothing

To show how this LutScript format gradually replaces the dedicated functions for .3dlut generation / modification, I have shown some example !Pixel scripts that implement the functionality currently found in other programs:

applycal.exe:
!Pixel({
LutFile("input.3dlut")
CalFile("calfile.cal")
})

merge3dlut.exe:
!Pixel({
LutFile("file1.3dlut")
LutFile("file2.3dlut")
LutFile("file3.3dlut")
# ...
})

changedepth:
# Set the appropriate range/depth for the new .3dlut

!Pixel(LutFile("old.3dlut"))

[alph@]

'Do note that to use the generated .3dlut with madVR you need to tag it with BT.709 primaries first using tag3dlut -7'

it gets complicated,So you can not use the 3dlut directly in madvr?a small tuto would cool,because I'm confused:rolleyes:
Your software is great,but utilities annexes are mysterious,I wish I could use it if necessary.

[nand chan]

'Do note that to use the generated .3dlut with madVR you need to tag it with BT.709 primaries first using tag3dlut -7'

it gets complicated,So you can not use the 3dlut directly in madvr?a small tuto would cool,because I'm confused:rolleyes:
Your software is great,but utilities annexes are mysterious,I wish I could use it if necessary.

It's an issue with madVR and the .3dlut format in particular rather than the programs, so I'm waiting on madshi to add native compatibility checking so you won't have to do it manually. I've chosen to not add madVR compatibility hacks for now because I don't want to botch up the format further than it has to be.

If he still hasn't added support for it, then I'll add a flag to lutscript.exe to add madVR compatibility (or maybe include it by default).

For now, just do this:

lutscript.exe -i input.3ls -o output.3dlut
tag3dlut.exe -i output.3dlut -7

Or for a shorter version:

lutscript -i input.3ls -o - | tag3dlut -7 -i - -o output.3dlut

The command line utilities are meant for power users that know exactly what they're doing and delivers programs to support the necessary logic so even those people who aren't programmers with free time can benefit from it.

The GUI is intended for simple usage. It's just that I haven't gotten around to actually updating it yet due to lack of interest. I have far more planned for the GUI.

[alph@]

thank,
is what you plan to support icm files in TI3Parser,It would be very convenient.

[nand chan]

thank,
is what you plan to support icm files in TI3Parser,It would be very convenient.

I am planning on that, yes. An estimate would be around version 0.9.