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

[nand chan]

TI3 Parser (v0.16)

http://img705.imageshack.us/img705/8360/linkiccgui.png

Information

I hereby present my TI3 Parser toolset. This collection of programs is intended to provide a somewhat easier front-end for color management (http://en.wikipedia.org/wiki/Color_management) using ArgyllCMS¹, yCMS and madVR, as well as a small collection of command line tools. The motivation for creating this was due to the steps involved in locating, opening and extracting the information from a .ti3 file, then properly formatting them so madVR or yCMS accept them was a bit too daunting to explain well in my madVR CMS guide. This program initially started out as a script to simply format the values properly, but I decided to refactor it and enlarge the scope to include a largely automatized 3dLUT generation process. This also makes it easy to generate multiple .3dLUTs for different environments and choose a certain one easily using madVR (instead of having to copy/paste over the new primaries + re-generate it every time).

All logic is also abstracted into a managed .dll so that those who wish to use it in other projects can do so, and there is a collection of (somewhat) useful command line tools included.

1. At the moment, ArgyllCMS is still not automatized - you will have to calibrate+profile manually using dispcalGUI (http://hoech.net/dispcalGUI/)

Features:

This program will:

Read and parse a .ti3/.cal file as generated by ArgyllCMS (http://www.argyllcms.com/)
Present the gamut/grayscale measurements in madVR (http://forum.doom9.org/showthread.php?t=146228)-friendly form
Provide a yCMS (http://forum.doom9.org/showthread.php?t=154719) generation script
Create a madVR-compatible .3dlut file (http://thr3dlut.sourceforge.net/)
Modify an existing .3dlut by swapping channels, inverting it or applying calibration data from an ArgyllCMS .cal file
Create new .3dluts
Allow inspection and modification of .3dluts (to check for errors etc)
Automatically update yCMS
Scale/adapt the output bit depth or value range of .3dluts
Merge multiple .3dluts into a single one
Inspect, Reset, Load or Save the device adapter's CLUT tables
Allow application of 3dlut files to images manually
Create .3dluts from linking ICC profiles together
Perform, gamma correction, gamut mapping, chromatic saturation (eg. to increase the gamut range while preserving colors) and chromatic adaptation
Join together .3dluts using a composite algorithm (eg. to fix the black levels)
Work with both .3dlut and .3dl2 (http://pastebin.com/raw.php?i=kQ1btFtW) files
Be fully accessible from the command line console


Usage guide:

I intend for this section to be obsolete by version 1.0, but for now, a quick guide towards calibrating your monitor / profiling it properly can be found here (http://haruhichan.com/wpblog/?p=323) or here (http://haruhichan.com/wpblog/?p=364).

If you just want the GUI (shown in the screenshot), after extracting, run TI3Parser\bin\LinkICCGUI.exe.

A list of current command line utilities:


applycal: Applies an ArgyllCMS .cal/.ti3 or a CLUT file to a .3dlut, thus calibrating it for a specific display device
changedepth: Changes the output bit depth of a .3dlut or adjusts the levels (PC or TV) - note that this transformation is lossy
dispclut: Allows inspection, changing, resetting, saving or loading of a display adapter's CLUT tables (globally or per-monitor)
gen3dlut: Generates a new, linear or grayscale .3dlut
genscript: Generates a yCMS script from .ti3 source value, using the same base as madVR
imagecal: Apply a .cal file or .3dlut to a bitmap image manually, useful for proofing
inspect3dlut: Inspects a .3dlut and prints information about the meta-tags or creation script
join3dlut: Composites together two .3dluts, switching between the two based on luminance.
linkicc: Links two ICC profiles together and generates a .3dlut from the result
lutscript: Generates a 3dlut from a provided .3ls file (http://forum.doom9.org/showthread.php?p=1522819#post1522819) or .3ls2 file (https://forum.doom9.org/showthread.php?p=1529672#post1529672)
make3dlut: Generates a .3dlut from a .ti3 file, using yCMS (can also apply calibration data)
merge3dlut: Merges multiple .3dluts together into a single file
parseti3: Opens a .ti3 file and presents the primaries / grayscale information in madVR-friendly form. Also allows copying to clipboard
swapchan: Allows swapping or inverting channels of a .3dlut
tag3dlut: Modifies a 3dlut's attached parameters to change the declared levels or primaries (this does not modify the 3dlut itself, unlike changedepth)
updateycms: Updates this toolset's copy of yCMS
version: Prints the overall packaging version number


Help for each program can be obtained by running <program name> --help.

To-do (planned features list):


Find a better name for the project, since soon it won't be limited to just parsing TI3 files
Integration and updating of the binaries provided by ArgyllCMS
Automation for ArgyllCMS, similar in nature to dispcalGUI but tailored for video playback
Self-update system (will likely need a decent web host for this first)
If possible, interface with madVR and set the .3dlut files automatically (perhaps per display device)


Download and license information

All code is currently in public domain but I withhold the rights to change this license at any time (license changes will not apply retroactively).


Executables and source code: Download from mediafire (packaging v0.16) (http://www.mediafire.com/?d8wmeqlx7dd378y)


All executables can be found in the TI3Parser\bin folder. The program requires the .NET library version 4.0 or above to run.

Feedback

Please post any bugs, issues, suggestions or other sorts of feedback in this thread. If you want to submit source code patches you can do that too.

I'm also not quite satisfied with the current interface. What would you prefer - the current, a tab-based layout or a bunch of buttons like it was before? I'm also probably going to make the interface much larger, add more regions for everything, allow loading multiple files and generally expand the program into a larger, fullscreen management studio instead of a simple tool.

I'm also taking suggestions for a better name, since it is no longer a simple TI3 Parser

Changelog

Moved to second post due to length issues

[alph@]

very good,when you use 'rec709' curve, you use an adjustement of ambient light level ?

[nand chan]

very good,when you use 'rec709' curve, you use an adjustement of ambient light level ?

No, instead, I make sure my ambient light level is as close to zero as possible. In other words, I watch anime in a nearly perfectly dark room.

In fact, I've discovered that calibrating to a Rec.709 level makes madVR adjust more using its 3dlut than calibrating to an sRGB or even 2.35 tone curve, so I'm thinking of changing that. I have it calibrated to the D65 sRGB curve right now and the 3dlut doesn't make a huge difference, so I know it's only minor corrections.

I'm thinking of having the program calibrate to a set gamma instead (allowing you to choose between “bright, medium and dark” room or something)

Changelog

Version numbers refer to the packaging version, not the version numbers of the individual components.
*all new changes will be in the release post, vBulletin caps the length of posts unfortunately*

Version 0.10:
! Added basic support for ICC profiles
+ Color space information is extracted from the ICC profiles and written into the resulting .3dl2
+ New program: linkicc.exe
+ New LutScript function: IccTransform(String, String, Intent), intents: Perceptual, Relative, Saturation or Absolute
+ New LutScript function: !Filetype(Type), possible values: 3DL2 or 3DLUT
+ New LutScript function: !Parameters(String), overrides the parameters data (not recommended for 3DLUT filetype)
+ Added support for LZO compression (CompressionMethod=1). This is used by default.
? Note: Legacy LUTs do not support compression, it will always be disabled when using --legacy mode in tag3dlut
+ Added a --compression (-c) flag to tag3dlut, valid values are: None, LZO
+ New LutScript function: !Compression(Method), possible values: None, LZO
+ LutScript now computes the intermediate gamut after each step (this changes when using eg. IccTransform())
It is recommended to *NOT* set the !Input_Primaries or !Output_Primaries tags when performing gamut mapping!
LutScript will auto-detect these correctly for you, eg. when mapping together multiple ICC profiles
~ LutScript now defaults to Limited range when not specified, since it just makes more sense for video content
? Changelog v0.9 was flawed, !Input_Primaries did not accept a string but an /enum/
(eg. “!Input_Primaries(BT709)” and not “!Input_Primaries("BT709")”)

Version 0.9:
! Created and added support for the new .3dl2 format, changes include:
+ Added support for 64-bit floating point LUTs
+ Added support for color-space aware LUTs
+ Added support for RGB/YCbCr -> XYZ LUTs for profiling purposes, similar to how ICC device profiles work
+ Added support for file-encoded value ranges
* Utilities such as gen3dlut and changedepth which create new LUTs now use the 3dl2 by default,
so you no longer need to fix tagging using tag3dlut
? Note: Since programs such as madVR still only support .3dluts, you need to “convert” these files for those programs
+ --legacy (-l) tag added to tag3dlut in order to convert to a legacy .3dlut, this also overwrites the params
in order to correctly tag everything for madVR etc.
+ --color-space (-c) flag added to inspect3dlut
+ !Input_Primaries(rx, ry, gx, gy, bx, by, wx, wy) tag added to LutScript
+ !Input_Primaries(ColorSpace) overload added to LutScript, acceptable values are currently: BT709 and None
+ Same as above for !Output_Primaries() added as well
? I aim to make the input_primaries and output_primaries tags obsolete sooner or later though, when I introduce
gamut conversion functions
+ --ycbcr (-y) flag added to gen3dlut to generate a blank YCbCr LUT
* ColorTriple<T> is now aware of its encoding, in order to ensure transformations are properly chained
eg. the grayscale filter now simply sets Cr and Cb to 0 if the input is already YCbCr
~ Significantly increased performance here and there by operating on a single value in memory instead of copying it
over and over, however the old style of doing it is still available for cases where it's needed
- Removed the static methods .FromFile() and .FromStream(), moved logic into constructor instead
* !Pixel() no longer has to be the last function in a .3ls, meta-tags can appear after it
* make3dlut now automatically converts the yCMS output to a .3dl2, use tag3dlut to convert it back if desired
* Disabled the “Update program” field of the GUI, this is not supposed to do anything yet

Version 0.8:
* 3dluts now detect input and output range independently, allowing for a TV -> PC or PC -> TV 3dlut.
* Limited range floating point 3dluts work correctly now, the white level was set too high
- Removed the level override flag from applycal, it was in the wrong place - if you want to override levels, use
tag3dlut to modify the parameters data
- Removed many functions from _3dLut since transformation factories deprecate them, changes affect:
.Map(), .Assign(), .Modify(), .ChangeDepth(), .ChangeRange(), .Transform()
- Removed all of the overloaded Pulldown / Pullup functions from ColorTriple (which has been renamed Color). Instead of
using these functions, the proper method is to create a Pulldown or Pullup transformer (available in Triple variants)
+ Due to the above changes, level limits for pulldown/pullup are now precomputed on demand instead of at program start
+ LUTs are now theoretically unlimited, you could create a 32-bit LUT if you wanted to (and had 950737 YB of RAM)
- Removed the CalFileTransformer and _3dLutTransformer classes, implemented ITransformationProvider instead
To transform an arbitrary color, first get the transformation using .GetTransformer(), then .Invoke() that
* Updated changedepth to use a transformer to handle range conversions which uses the internal transformer; due
to this change, range conversions will *no* longer result in banding.
? Do note that since interpolation is still linear you will encounter macro-banding when performing extreme interpolation
If you're pulling up something like a 3-bit LUT to an 8-bit LUT, you should encounter it. With a 4-bit LUT (16x16x16)
I noticed no significant banding in a fullscreen gradient, but it might be more pronounced with less steep ramps
? Note that changedepth does not correctly tag the resulting LUT (in fact it strips all parameters). I won't change this
until the version 2 spec of .3dlut comes out, for now just use tag3dlut.
- Tags --full and --limited removed from tag3dlut
+ Tags --input-range and --output-range added to tag3dlut instead.

Version 0.7:
! Addition of LutScript, a scripting language for generating .3dluts from scratch. Documentation will follow.
? Transformation facility now also works in per-channel mode, as opposed to per-color (for the multiplexer)
* 3d LUTs now interpolate their values (linearly), this allows for full 64-bit floating point precision
Note that I have not yet done any gamma detection and curve adjustment, so this will still generate minor aliasing
+ Added logic to transform .3dluts further (that is, operate on its /output/)
+ New program: lutscript.exe
+ New program: merge3dlut.exe
~ More programs updated to use the transformation factory instead of hard logic

Version 0.6:
! All .3dlut code is now multi-threaded and will run many times faster
(do note that loading and saving a 100 MB file still takes around a second on modern hard drives)
! Transformations are now abstracted behind ITransformationProvider and can be assembled into TransformationFactories
Most program logic has been rewritten to use this functionality, and a GUI version for .3dlut creation
should be coming sometime soon
? dispclut can save and modify the CLUT at the same time now,
eg. dispclut -d 1 --save old.txt --reset before playback and dispclut -d 1 --load old.txt afterwards
+ New program: imagecal.exe
+ Beta functionality for 3dlut color transformations using 3dLutLib added, note that does not yet properly
interpolate the values. Once I've rewritten it to do so, I'll rewrite .ChangeRange to use this, thus
eliminating its current banding as well - which will affect changedepth.exe (when using the -r flag)
* make3dlut's built-in --calibrate option now works properly
* All tools now work with limited-range floating point values as well (0.0625 as black and 0.918 as white, approximately)
* 3dLutLib correctly detects full-range LUTs created with the RGB_PC format flag (instead of Output_Range 0 255)
* gen3dlut no longer prints luma information to screen with --grayscale, was left over from debugging
* The parser for .ti3/.cal files is now culture-invariant, to solve an issue where it would fail to
parse the values in some european locales which used a comma instead of a period to specify decimals
+ dispclut now has an “--reset-all” flag
* dispclut now uses the linear 0-65535 levels

Version 0.5:
! Re-worked entire .3dlut code base, much cleaner now (at the cost of a tiny speed loss)
* Detection for range (full or limited) is now handled by the 3dLUT loader itself and should be more consistent
In addition, this information will be displayed by the inspect3dlut program
+ applycal can load .ti3 files as well, and...
+ ..make3dlut can automatically apply .cal data from a .ti3 if found
+ applycal now supports Calibration Tester's #GammaRamp format
+ 32-bit floating point LUTs are now supported in all applicable programs
+ New program: changedepth.exe
Do note that while changedepth can pull values up/down to full or limited, this introduces a lot of banding
+ New program: dispclut.exe
+ New program: tag3dlut.exe

Version 0.4:
* Saving/loading to stdin or stdout now works properly
* Applycal now (attempts to) correctly detect the input value range, and also works for 8-bit LUTs (not just 16-bit)
* The TI3 parsing process now actually converts the entries to numbers,
removing the need for ugly string detection hacks - should fix the duplicate key bug also
+ It's now possible to generate new .3dluts from scratch using the TI3ParserLib
+ New program: inspect3dlut.exe
+ New program: gen3dlut.exe
? Speed improvements here and there

Version 0.3:
+ New program: applycal.exe
+ New program: swapchan.exe
+ New program: version.exe

Version 0.2:
? Now requires the .NET version 4.0 to run properly
~ Updated UI, removed ugly buttons and added a menu
+ New program: genscript.exe
+ New program: make3dlut.exe
+ New program: parseti3.exe
+ New program: updateycms.exe
* Temporary files are properly removed now
* Updating yCMS now correctly downloads the 64-bit or 32-bit versions depending on your processor architecture

Version 0.1:
? Initial release

Legend:
! Major modification
+ New feature
- Removed feature
* Fixed bug
~ Sideways change
? Information

[alph@]

ok,what values you use in ambient light level,Have you tried the 'black point correction'. I usually made ​​a calibration (d6500-120cd/m-gama 2.35- black level native-calbration quality high-testchart 124)and i check with color hcfr.

[leeperry]

looks good! if you could allow merging LUT's like one for gamut mapping and one from Argyll off a .cal file, that'd be full of win :)

and if you could allow importing the primaries/secondaries saturations from Color HCFR, then it'd be :eek:

http://thumbnails46.imagebam.com/14590/995122145896247.jpg (http://www.imagebam.com/image/995122145896247)

maybe none of this is technically possible though, and I need to document myself on the .ti3 file format :o

An option to output 8bit 3DLUT's could be useful for the happy few using rgb3dlut() within the Avisynth filter of ffdshow.

[nand chan]

looks good! if you could allow merging LUT's like one for gamut mapping and one from Argyll off a .cal file, that'd be full of win :)

and if you could allow importing the primaries/secondaries saturations from Color HCFR, then it'd be :eek:

http://thumbnails46.imagebam.com/14590/995122145896247.jpg (http://www.imagebam.com/image/995122145896247)

maybe none of this is technically possible though, and I need to document myself on the .ti3 file format :o

An option to output 8bit 3DLUT's could be useful for the happy few using rgb3dlut() within the Avisynth filter of ffdshow.

Calibration is done using the TI1 files, I could do that though - just generate two .3dluts and link them together.

Also the 8 bit 3DLUTs is also possible.

[nand chan]

looks good! if you could allow merging LUT's like one for gamut mapping and one from Argyll off a .cal file, that'd be full of win :)

and if you could allow importing the primaries/secondaries saturations from Color HCFR, then it'd be :eek:

http://thumbnails46.imagebam.com/14590/995122145896247.jpg (http://www.imagebam.com/image/995122145896247)

maybe none of this is technically possible though, and I need to document myself on the .ti3 file format :o

An option to output 8bit 3DLUT's could be useful for the happy few using rgb3dlut() within the Avisynth filter of ffdshow.

While thinking about this, I realized that it would be pretty hard without manual adjustment because ArgyllCMS works with 0-255 values, and madVR works with 16-235 levels. You can't simply generate a .3dlut off the .cal and combine it to the madVR .3dlut due to that reason.

I could possible morph the 3dlut by transforming it from 0-255 to 16-235, but that's significantly beyond the scope of this project and I don't intend to do any complex color management logic myself - just tie together existing tools (like yCMS).

Merging noncompatible 3dluts would be something yCMS would have to do, and you should request for that feature there.

ok,what values you use in ambient light level,Have you tried the 'black point correction'. I usually made ​​a calibration (d6500-120cd/m-gama 2.35- black level native-calbration quality high-testchart 124)and i check with color hcfr.

I've never used black point correction, mainly because my black point is dark enough and doesn't show any noticeable color distortion.

I usually use 6504K (I enter the X/Y points manually) - 6500K is a bit redder than D65 - and 120 cd/m², sRGB tone curve, native black level, native black point and massive LUT testchart.

[yesgrey]

Congratulations for your tool! :)

[leeperry]

While thinking about this, I realized that it would be pretty hard without manual adjustment because ArgyllCMS works with 0-255 values, and madVR works with 16-235 levels. You can't simply generate a .3dlut off the .cal and combine it to the madVR .3dlut due to that reason.

I could possible morph the 3dlut by transforming it from 0-255 to 16-235, but that's significantly beyond the scope of this project and I don't intend to do any complex color management logic myself - just tie together existing tools (like yCMS).

Merging noncompatible 3dluts would be something yCMS would have to do, and you should request for that feature there.
TBH I use 0-255 LUT's using an old version of cr3dlut, but I'm quite sure yCMS could create them as well...the only problem would be mVR that might expect 16-235 LUT's indeed, but if you want automatic gamut mapping depending on the frame rate/resolution, the only solution atm is to use rgb3dlut(8bit) or t3dlut(16bit) within ffdshow automatic profiles.

Several ppl already requested the feature of embedding together within the same 3DLUT both the Argyll calibration and the gamut mapping, so mVR's dithering wouldn't be messed around by the graphic card's CLUT...this would require an option in mVR to disable the latter, though.

Anyway this was just some plain brainstorming, and you're the author...making you the final judge in the end ;)

[nand chan]

Version 0.1.1 is out now that I have gained yesgrey's acceptance of the yCMS download method

TBH I use 0-255 LUT's using an old version of cr3dlut, but I'm quite sure yCMS could create them as well...the only problem would be mVR that might expect 16-235 LUT's indeed, but if you want automatic gamut mapping depending on the frame rate/resolution, the only solution atm is to use rgb3dlut(8bit) or t3dlut(16bit) within ffdshow automatic profiles.

True, but I dislike the usage of ffdshow because it does not yet have a native 10-bit pipeline, also that would require working with YUV LUTs instead of RGB luts unless you want to use ffdshow's piss poor RGB conversion. I'll still consider adding 3dLUT combining as a future feature but it's not high on the priority list because there are too many variables to be careful of when combining them, and it's not easily doable with madVR LUTs. (unless madVR allows working with 0-255 LUTs in the future)

It's fairly straightforward to /create/ the correct LUTs using yCMS, it's just that madVR will reject the .3dlut.

Several ppl already requested the feature of embedding together within the same 3DLUT both the Argyll calibration and the gamut mapping, so mVR's dithering wouldn't be messed around by the graphic card's CLUT...this would require an option in mVR to disable the latter, though.

This would indeed be very important since iirc the CLUTs are only one-dimensional. The main problem would be generating a proper 16-235 .3dlut from .cal data, which probably lies within the domain of a tool such as yCMS. I do not (yet) have the necessarily technical knowledge to interpolate and generate tables like that.

My first priority now though is getting a working, automatized front-end for Argyll and yCMS in place to bridge the process from profiling to .3dlut creation.

[leeperry]

Oops yeah, indeed I use YUY2 LUT's in ffdshow so I guess merging them w/ a .cal file would turn into headaches, if even possible.

And tbh I'm very happy w/ tritical's yv12toyuy2() because it allows you to choose what resizing algorithm to use for the YV12>YUY2 interpolation. I've finetuned all thoses settings to get the crispiest non-ringing PQ I've ever seen. I use SmoothL() to dither nicely and avoid banding, I'm not hung up on 10bit processing anymore...especially when dealing w/ 16-235 SMPTE-C content, because it might be a different story w/ xvYCC but we're not quite there yet.

[nand chan]

This would indeed be very important since iirc the CLUTs are only one-dimensional. The main problem would be generating a proper 16-235 .3dlut from .cal data, which probably lies within the domain of a tool such as yCMS. I do not (yet) have the necessarily technical knowledge to interpolate and generate tables like that.

My first priority now though is getting a working, automatized front-end for Argyll and yCMS in place to bridge the process from profiling to .3dlut creation.

Update: Just realized that Argyl''s .cal files are one-dimensional LUTs as well, so the practical gains of this are questionable. It would only serve to eliminate the video card's CLUTs, which are potentially sub-optimal.

Applying a .cal to a .3dlut seems like a simple process then, I'll write the code for it sooner or later.

Generating a .3dlut from a .ti1 however would be much harder since it requires significant interpolation.

Updated the UI slightly also: http://img805.imageshack.us/img805/7990/ti3parserdemo.png

[nand chan]

Bumping with a semi-big update, version 0.2 is now out. See the initial posts for a changelog.

Download link: http://www.mediafire.com/?9by785si95tu73b (source is included)

[madshi]

Thank you, nice work... :)

[ryrynz]

Thank you. just a minor issue, the about box for 0.2 shows version number 0.1.1.4186.

[Audionut]

Spent about an hour last night trying to get everything working again with madVR after not using it for awhile.

Then come across this one-click solution this morning :)

Nice work and thanks.

the about box for 0.2 shows version number 0.1.1.4186.

I see version 0.2.0.36408

[ryrynz]

Different naming (no space) for the new version, must have deleted the wrong folder. All good, thanks.

[nand chan]

HUGE SUCCESS

I've finally finished writing all of the code for loading, editing (mapping a function over each entry) and saving .3dlut files, as well as the code for loading and properly interpolating a .cal file. All of this takes place in little under a second of processing time (and they said C# was slow).

As proof of concept, I've edited my existing .3dlut and swapped the red and blue channels just for fun. Here's the somewhat amusing result: http://img5.imageshack.us/img5/5215/chanswap.jpg

Expect to see a fully working version that will apply .cal calibration data to a .3dlut sometime tomorrow, as well as a few utilities to swap channels for fun.

For now, more fun stuff:
chanswap.exe -i test.3dlut --invert produces: http://img192.imageshack.us/img192/2923/chaninvert.jpg

Thank you. just a minor issue, the about box for 0.2 shows version number 0.1.1.4186.

While this was not intentional, do note that the packaging version (0.2) is not necessarily the version of the GUI program (in this case, 0.2.0.36408) - I'll update it in the future to include both. The packaging version is merely a version number for the overall collection and will get increased with every release (similarly to madVR's current 0.74 version number). The versions of the individual programs (eg. the GUI) will be following a more traditional major.minor.iteration.build version number based on features on that specific program.

[Audionut]

Expect to see a fully working version that will apply .cal calibration data to a .3dlut sometime tomorrow

Excellent. Can't wait to try it out.

[nand chan]

Another small update, 0.3 is out.

With this release, it's now possible to directly alter .3dlut files by applying a .cal file or swapping the levels around (for fun).

Unfortunately, there is currently no GUI front-end for this functionality - I am waiting until I've come up with a better GUI design before I add this. However, it's easily done via the command line:

applycal.exe -i source.3dlut -o destination.3dlut calibrationfile.cal

Edit: I just realized this technique has another advantage. Since I'm interpolating the values to a 16-bit LUT, it transcends the precision of the graphics card's built-in 8-bit CLUTs. So if you have a 10-bit monitor (like I do), and an appropriate graphics card (like I don't), your calibration corrections will preserve that depth when merged onto a .3dlut.

[Audionut]

No problems opening the original TI3 file I originally opened, but trying to process any other TI3 file is giving me this error.

http://farm7.static.flickr.com/6084/6072851162_dec4f46ea3.jpg


Getting the same error message with,

genscript:
make3dlut:
parseti3:

[nand chan]

No problems opening the original TI3 file I originally opened, but trying to process any other TI3 file is giving me this error.

http://farm7.static.flickr.com/6084/6072851162_dec4f46ea3.jpg


Getting the same error message with,

genscript:
make3dlut:
parseti3:

Can you upload the .ti3 file somewhere so I can have a look at it?

[nand chan]

Big update, version 0.4 is out
See the original post for a full list of changes

Download link: http://www.mediafire.com/?5f7mid5m131rjxb

The main new addition is that of gen3dlut.exe, which allows the creation of custom 3dluts. Currently, only two modes are supported - flat (output=input) and grayscale (output=luminosity).

Some fun things:
gen3dlut.exe --grayscale -o test.3dlut: http://img189.imageshack.us/img189/3889/bnwp.jpg
or
gen3dlut.exe --grayscale -o - | swapchan --invert -i - -o test.3dlut: http://img641.imageshack.us/img641/5039/invertgray.jpg

Note: This utility also allows you to create generic .3dluts that just include calibration data from a .cal, eg. like so:
gen3dlut.exe -o - | applycal -i - -o output.3dlut calibration.cal

[Audionut]

Here are 5 of my results.
http://www.mediafire.com/?szmzpi50gao1mco

Version 0.4 can open the ones that weren't working before. And I can see what the problem is. Luminance values are screwed.

From what I can see, the consistancy between the ones that don't work are that they have greyscale values going up in incriments of 5 where I have created my own testchart file.
The one that works, from memory I just selected the large testchart.

[nand chan]

Here are 5 of my results.
http://www.mediafire.com/?szmzpi50gao1mco

Version 0.4 can open the ones that weren't working before. And I can see what the problem is. Luminance values are screwed.

From what I can see, the consistancy between the ones that don't work are that they have greyscale values going up in incriments of 5 where I have created my own testchart file.
The one that works, from memory I just selected the large testchart.

Which one was working fine before version 0.4?

[Audionut]

VK266H 2011-08-22 80cdm² 0.3127x 0.3291y 0.35cdm² native 1.85 LQ-HQ 1xCurve+MTX

[leeperry]

OMG, he's unstoppable! So I can take a 0-255 gamut mapping 16bit LUT from cr3dlut, merge it w/ a .cal file and output a 8bit LUT to feed rgb3dlut() in ffdshow? :eek:

I'm asking instead of trying coz my .net crapola is not up to date I'm afraid...but if that's the case I might have an urgent need for a "reset CLUT while playing" in mVR http://forum.slysoft.com/images/smilies/agreed.gif

But I guess you can't get it to output a YUY2 LUT, can you? :o

[nand chan]

OMG, he's unstoppable! So I can take a 0-255 gamut mapping 16bit LUT from cr3dlut, merge it w/ a .cal file and output a 8bit LUT to feed rgb3dlut() in ffdshow? :eek:

There is currently no utility for changing the bit-depth of a LUT (eg. from 16-bit down to 8-bit) but I can add a program for that by version 0.5.

Note: This would obviously only work for the /output/ bit-depth of a LUT. Changing the input bit depth is unfeasible because anything about 3x8-bit would take such obscene amounts of storage that you couldn't even load it. For example, a fully 10-bit .3DLUT will take 4 GB of memory, more than the average video card can handle. A 16-bit LUT will take several petabytes.

However, what you can do is transform a 8->16 bit LUT down to a 8->8 bit LUT (or the reverse), though at the cost of precision (in the former).

But yes, you can basically take a 8->16 bit LUT gamut mapping (like the type madVR uses) and apply .cal data to it.

I'm asking instead of trying coz my .net crapola is not up to date I'm afraid...but if that's the case I might have an urgent need for a "reset CLUT while playing" in mVR http://forum.slysoft.com/images/smilies/agreed.gif

Agreed on this. :) It's such a hassle to reset the CLUTs manually using dispcalGUI all the time.

But I guess you can't get it to output a YUY2 LUT, can you? :o

That wouldn't be in the realm of impossibility as far as I know how YUY2 LUTs work, then I'll also have to do the RGB->LUT conversion since .cal files work in RGB space. (You'd have to choose which reference decoding matrices to use). I wouldn't expect anything resembling YUV support for at least another version or two though, maybe 0.6 or 0.7, mainly because I'm only primarily concerned with madVR which uses RGB LUTs and this simplifies things greatly.

[nand chan]

There is currently no utility for changing the bit-depth of a LUT (eg. from 16-bit down to 8-bit) but I can add a program for that by version 0.5.

Updated, added this, in addition to re-coding most of the .3dlut code to make it much, much cleaner.

All 3dlut processing is now done using 64-bit floating point calculations at every step, and they are only converted to/from their appropriate lower-bit-depth representations when saving/loading to memory.

The .3dlut processing pipeline now only accepts functions that use normalized 0-1 doubles.

This has the advantage of: 1. Allowing for seamless interaction of .3dluts with any bit-depth and 2. level detection is now done in the .3dlut library instead of in the program, and the .3dlut lib correctly compensates for full or limited range values when pulling down the levels to 0-1 doubles.

It also removes about 70% of the code size, which was previously full of “Transform16, Transform8, Transform32” or “Pullup16, Pullup8, Pullup32” and so forth. All of these duplicate versions have now been removed and replace by generic versions that work on any-bitdepth.

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).

Edit: For the curious, a comparison of 16-bit LUT vs 8-bit LUT (to make madVR load it, I first converted it down to 8-bit and then converted that back up to 16-bit which is simply a bit-shift, the same way madVR converts levels). You can clearly see the advantage of greater-than-8-bit precision processing even on 8-bit devices. So if you want to use a .3dlut with avisynth be wary of this difference:

http://screenshotcomparison.com/comparison/75573

If you do want to create an 8-bit 3dLUT for avisynth etc, you can do something like this:
gen3dlut -o - -b 8 | applycal -i - -o output.3dlut calibration.cal

[madshi]

Yeah, an 8bit 3dlut is probably not good enough. yCMS also internally uses 64bit floats for calculation and then rounds that down to 16bit integer for output. I wouldn't use anything less than 16bit integer output. It's debatable, though, whether input must be 8bit. madVR/yCMS can also use 7bit or 6bit input, to save space and improve performance, on the cost of a very small (probably not visible) drop in quality.

[cyberbeing]

Can you add more format support for applycal?

CAL data from a TI3 file (Argyll Device Calibration State)?
Calibration Tester (http://www.xrite.com/product_overview.aspx?ID=795&Action=Support&SoftwareID=546)'s 0-65535 format?
An ICC profile vctg tag?
The currently loaded CLUT?

applycal from version 0.4 is now extremely slow. Is that because of working in 64-bit floating point or is it a bug? After 30 minutes went by I just gave up and killed it. If it's going to be that slow, I hope you can optimize or multi-thread it. Maybe you could port it to OpenGL GLSL shader code and run it on the GPU.

madVR/yCMS can also use 7bit or 6bit input, to save space and improve performance, on the cost of a very small (probably not visible) drop in quality.
Just don't use a 6bit 3dlut with applycal or you'll get crappy results.

[madshi]

Just don't use a 6bit 3dlut with applycal or you'll get crappy results.
Have you found the time to measure madVR/yCMS's 7bit and 6bit 3dluts yet to check if there's any difference (worth nothing) between 8bit and lower bitdepths?

[nand chan]

Can you add more format support for applycal?

CAL data from a TI3 file (Argyll Device Calibration State)?

I never realized this differed from the .cal file. I'll add support for it soon enough.

Note: As a “feature” of the current coding, all you have to do is change the first line of a .ti3 file to “CTI3” to “CAL” and applycal will accept it.

Calibration Tester (http://www.xrite.com/product_overview.aspx?ID=795&Action=Support&SoftwareID=546)'s 0-65535 format?

Would depend on the format in question. If I don't have access to a freely available documentation and a few sample cases for it, it's unlikely.

An ICC profile vctg tag?

I'm probably adding ICC profile support sometime around version 1.0.

The currently loaded CLUT?

I don't know how to access those.

applycal from version 0.4 is now extremely slow. Is that because of working in 64-bit floating point or is it a bug? After 30 minutes went by I just gave up and killed it. If it's going to be that slow, I hope you can optimize or multi-thread it. Maybe you could port it to OpenGL GLSL shader code and run it on the GPU.

That has to be a bug, it runs in a few seconds on my CPU. How many entries does your .cal file have?

Yeah, an 8bit 3dlut is probably not good enough. yCMS also internally uses 64bit floats for calculation and then rounds that down to 16bit integer for output. I wouldn't use anything less than 16bit integer output. It's debatable, though, whether input must be 8bit. madVR/yCMS can also use 7bit or 6bit input, to save space and improve performance, on the cost of a very small (probably not visible) drop in quality.

How do you properly pull down to a limited range 6-bit or 7-bit integer? I can't right shift 235 any further without cutting bits off. Is that just what I should do?

[madshi]

How do you properly pull up to a 6-bit or 7-bit integer? I can't right shift 235 any further without cutting bits off. Is that just what I should do?
I've no idea. I only know how to use 3dluts, not how to create them. You'll have to ask yesgrey about that.

[e-t172]

The currently loaded CLUT?
I don't know how to access those.

http://msdn.microsoft.com/en-us/library/dd316946%28v=VS.85%29.aspx

[cyberbeing]

Have you found the time to measure madVR/yCMS's 7bit and 6bit 3dluts yet to check if there's any difference (worth nothing) between 8bit and lower bitdepths?
It's about what you'd expect for a lut with 4x4 accuracy, interpolated to 1x1. Using a 6-bit lut results in an ever so slightly, smoother histogram. Though at least on a standard gamut monitor, it's not really visible unless you pixel peek, since the skew is often 0.1-0.5 dE. The trade-off is worth it to me, to avoid the occasional 3dlut showstopper causing massive dropped frames, but unless someone is in a similar situation, I don't know why they'd choose to use a 6-bit lut. I don't use yCMS Grayscale Measurements, a Wide Gamut monitor, or madVR gamma correction, so I have no idea if the results would be similar mine while using those things.

Anyway, not relavant to this thread, but here are some comparison screenshots for you madshi:
http://www.mediafire.com/?74lk6yli3l7n7cx
The random noise + pattern image with 6 semi-transparent colored blocks overlayed, is just something I made on-the-fly as a torture test for the 6-bit lut.

Would depend on the format in question. If I don't have access to a freely available documentation and a few sample cases for it, it's unlikely.
It's just a text file 0-255 with 16bit integer CLUT values (vs the normalized 16bit floating point value in a TI3). It's one of the few tools to load, dump, modify, an re-load the active CLUT.
The layout is always the same. "#GammaRamp" on first line identifying the format. 0-255 in first column, RED, GREEN, BLUE.

#GammaRamp
0 1599 1305 1270
1 2161 1923 1791
2 2722 2538 2310
3 3280 3150 2825
4 3835 3760 3338
5 4383 4365 3846
6 4908 4949 4342
7 5398 5494 4813
8 5847 5991 5256
9 6255 6439 5667
10 6629 6843 6047
11 6976 7211 6402
12 7300 7550 6734
13 7605 7864 7050
14 7894 8159 7350
15 8171 8440 7639
16 8438 8709 7919
17 8696 8967 8191
18 8945 9217 8454
19 9187 9459 8712
20 9423 9697 8963
21 9653 9929 9206
22 9879 10155 9448
23 10102 10377 9683
24 10319 10596 9916
25 10531 10812 10143
26 10741 11026 10368
27 10949 11237 10590
28 11155 11446 10809
29 11359 11653 11027
30 11562 11858 11243
31 11763 12063 11457
32 11962 12268 11668
33 12162 12474 11880
34 12362 12680 12093
35 12562 12887 12306
36 12762 13093 12519
37 12962 13299 12732
38 13162 13505 12945
39 13362 13711 13156
40 13561 13918 13367
41 13757 14127 13578
42 13954 14338 13786
43 14152 14548 13995
44 14351 14759 14206
45 14550 14970 14416
46 14749 15182 14627
47 14949 15392 14836
48 15149 15603 15046
49 15350 15812 15256
50 15552 16019 15466
51 15755 16226 15676
52 15958 16430 15885
53 16164 16635 16095
54 16369 16841 16303
55 16576 17050 16514
56 16784 17261 16724
57 16996 17474 16936
58 17211 17689 17152
59 17429 17904 17369
60 17651 18118 17587
61 17873 18333 17805
62 18097 18549 18023
63 18321 18765 18242
64 18546 18982 18459
65 18772 19199 18678
66 18998 19417 18900
67 19224 19636 19120
68 19451 19854 19343
69 19677 20074 19564
70 19904 20292 19787
71 20132 20508 20011
72 20358 20722 20232
73 20584 20935 20453
74 20808 21147 20675
75 21032 21360 20897
76 21256 21572 21118
77 21480 21783 21342
78 21703 21996 21565
79 21927 22209 21787
80 22151 22424 22011
81 22374 22640 22236
82 22599 22859 22462
83 22824 23079 22689
84 23049 23300 22917
85 23275 23522 23144
86 23500 23744 23370
87 23724 23965 23596
88 23947 24188 23820
89 24169 24410 24043
90 24391 24633 24268
91 24612 24855 24492
92 24834 25077 24717
93 25057 25299 24940
94 25281 25521 25164
95 25506 25746 25389
96 25732 25972 25616
97 25962 26202 25847
98 26196 26432 26080
99 26432 26665 26315
100 26672 26898 26551
101 26913 27133 26787
102 27154 27370 27026
103 27397 27608 27266
104 27639 27846 27505
105 27879 28080 27742
106 28115 28312 27976
107 28347 28540 28208
108 28577 28767 28440
109 28804 28992 28668
110 29031 29217 28899
111 29259 29444 29130
112 29487 29671 29360
113 29717 29898 29591
114 29948 30126 29823
115 30179 30355 30054
116 30411 30582 30286
117 30643 30809 30518
118 30876 31036 30752
119 31110 31264 30987
120 31344 31492 31221
121 31578 31719 31456
122 31812 31947 31692
123 32046 32175 31929
124 32280 32404 32168
125 32513 32632 32404
126 32745 32861 32643
127 32977 33091 32881
128 33208 33322 33123
129 33441 33557 33366
130 33676 33794 33610
131 33914 34032 33856
132 34151 34271 34101
133 34389 34510 34347
134 34627 34751 34593
135 34867 34991 34840
136 35108 35234 35089
137 35351 35477 35339
138 35595 35721 35590
139 35841 35964 35840
140 36087 36209 36090
141 36333 36454 36342
142 36578 36699 36593
143 36823 36943 36844
144 37069 37187 37093
145 37314 37432 37343
146 37561 37676 37593
147 37807 37921 37841
148 38053 38165 38089
149 38298 38409 38337
150 38541 38651 38580
151 38782 38891 38822
152 39021 39129 39061
153 39258 39365 39299
154 39494 39601 39538
155 39729 39835 39776
156 39967 40072 40014
157 40205 40309 40254
158 40444 40546 40494
159 40685 40784 40734
160 40926 41024 40977
161 41168 41264 41219
162 41411 41505 41464
163 41656 41749 41711
164 41903 41996 41960
165 42153 42246 42212
166 42408 42502 42468
167 42667 42764 42729
168 42931 43030 42993
169 43197 43298 43259
170 43466 43566 43526
171 43735 43833 43794
172 44005 44100 44063
173 44277 44367 44332
174 44549 44635 44602
175 44819 44901 44869
176 45087 45165 45136
177 45351 45426 45398
178 45609 45682 45657
179 45862 45932 45912
180 46110 46177 46164
181 46357 46418 46413
182 46602 46657 46661
183 46844 46894 46909
184 47086 47131 47156
185 47329 47369 47404
186 47573 47610 47655
187 47817 47852 47905
188 48062 48097 48157
189 48308 48346 48409
190 48554 48596 48663
191 48799 48847 48917
192 49045 49099 49171
193 49293 49354 49428
194 49542 49611 49685
195 49792 49871 49942
196 50041 50133 50199
197 50291 50396 50455
198 50541 50659 50710
199 50792 50921 50965
200 51043 51183 51219
201 51295 51445 51470
202 51549 51708 51722
203 51807 51973 51974
204 52068 52237 52226
205 52331 52500 52479
206 52596 52762 52730
207 52861 53024 52982
208 53125 53283 53232
209 53387 53540 53480
210 53646 53794 53727
211 53904 54044 53975
212 54159 54292 54223
213 54414 54540 54472
214 54667 54788 54720
215 54920 55036 54972
216 55175 55289 55225
217 55431 55544 55481
218 55690 55802 55738
219 55950 56065 55996
220 56211 56329 56252
221 56471 56595 56506
222 56732 56861 56760
223 56991 57128 57010
224 57249 57392 57258
225 57510 57656 57504
226 57772 57920 57751
227 58035 58187 57998
228 58297 58453 58244
229 58559 58717 58489
230 58820 58981 58734
231 59080 59243 58980
232 59339 59506 59226
233 59598 59770 59474
234 59854 60034 59722
235 60110 60299 59971
236 60364 60564 60220
237 60619 60829 60469
238 60872 61094 60719
239 61124 61357 60968
240 61377 61620 61217
241 61629 61881 61465
242 61881 62144 61716
243 62134 62407 61966
244 62386 62670 62216
245 62639 62932 62465
246 62892 63194 62713
247 63144 63455 62963
248 63397 63716 63212
249 63648 63978 63462
250 63899 64239 63712
251 64150 64500 63961
252 64399 64762 64211
253 64648 65023 64461
254 64897 65284 64712
255 65146 65535 64963



That has to be a bug, it runs in a few seconds on my CPU. How many entries does your .cal file have?
It's just a normal ArgyllCMS .cal file, so 256. Process monitor appears to show applycal apparently stuck in a loop reading the .cal file around 1,600 times per second.

[nand chan]

It's just a text file 0-255 with 16bit integer CLUT values (vs the normalized 16bit floating point value in a TI3). It's one of the few tools to load, dump, modify, an re-load the active CLUT.
Oh, that exists? I've just finished writing my own :P

Oh well, my version will work for .ti3 files, .cal files and those funky calibration tester formats.

The layout is always the same. "#GammaRamp" on first line identifying the format. 0-255 in first column, RED, GREEN, BLUE.

#GammaRamp
0 1599 1305 1270
1 2161 1923 1791
2 2722 2538 2310
3 3280 3150 2825
4 3835 3760 3338
5 4383 4365 3846
6 4908 4949 4342
7 5398 5494 4813
8 5847 5991 5256
9 6255 6439 5667
10 6629 6843 6047
11 6976 7211 6402
12 7300 7550 6734
13 7605 7864 7050
14 7894 8159 7350
15 8171 8440 7639
16 8438 8709 7919
17 8696 8967 8191
18 8945 9217 8454
19 9187 9459 8712
20 9423 9697 8963
21 9653 9929 9206
22 9879 10155 9448
23 10102 10377 9683
24 10319 10596 9916
25 10531 10812 10143
26 10741 11026 10368
27 10949 11237 10590
28 11155 11446 10809
29 11359 11653 11027
30 11562 11858 11243
31 11763 12063 11457
32 11962 12268 11668
33 12162 12474 11880
34 12362 12680 12093
35 12562 12887 12306
36 12762 13093 12519
37 12962 13299 12732
38 13162 13505 12945
39 13362 13711 13156
40 13561 13918 13367
41 13757 14127 13578
42 13954 14338 13786
43 14152 14548 13995
44 14351 14759 14206
45 14550 14970 14416
46 14749 15182 14627
47 14949 15392 14836
48 15149 15603 15046
49 15350 15812 15256
50 15552 16019 15466
51 15755 16226 15676
52 15958 16430 15885
53 16164 16635 16095
54 16369 16841 16303
55 16576 17050 16514
56 16784 17261 16724
57 16996 17474 16936
58 17211 17689 17152
59 17429 17904 17369
60 17651 18118 17587
61 17873 18333 17805
62 18097 18549 18023
63 18321 18765 18242
64 18546 18982 18459
65 18772 19199 18678
66 18998 19417 18900
67 19224 19636 19120
68 19451 19854 19343
69 19677 20074 19564
70 19904 20292 19787
71 20132 20508 20011
72 20358 20722 20232
73 20584 20935 20453
74 20808 21147 20675
75 21032 21360 20897
76 21256 21572 21118
77 21480 21783 21342
78 21703 21996 21565
79 21927 22209 21787
80 22151 22424 22011
81 22374 22640 22236
82 22599 22859 22462
83 22824 23079 22689
84 23049 23300 22917
85 23275 23522 23144
86 23500 23744 23370
87 23724 23965 23596
88 23947 24188 23820
89 24169 24410 24043
90 24391 24633 24268
91 24612 24855 24492
92 24834 25077 24717
93 25057 25299 24940
94 25281 25521 25164
95 25506 25746 25389
96 25732 25972 25616
97 25962 26202 25847
98 26196 26432 26080
99 26432 26665 26315
100 26672 26898 26551
101 26913 27133 26787
102 27154 27370 27026
103 27397 27608 27266
104 27639 27846 27505
105 27879 28080 27742
106 28115 28312 27976
107 28347 28540 28208
108 28577 28767 28440
109 28804 28992 28668
110 29031 29217 28899
111 29259 29444 29130
112 29487 29671 29360
113 29717 29898 29591
114 29948 30126 29823
115 30179 30355 30054
116 30411 30582 30286
117 30643 30809 30518
118 30876 31036 30752
119 31110 31264 30987
120 31344 31492 31221
121 31578 31719 31456
122 31812 31947 31692
123 32046 32175 31929
124 32280 32404 32168
125 32513 32632 32404
126 32745 32861 32643
127 32977 33091 32881
128 33208 33322 33123
129 33441 33557 33366
130 33676 33794 33610
131 33914 34032 33856
132 34151 34271 34101
133 34389 34510 34347
134 34627 34751 34593
135 34867 34991 34840
136 35108 35234 35089
137 35351 35477 35339
138 35595 35721 35590
139 35841 35964 35840
140 36087 36209 36090
141 36333 36454 36342
142 36578 36699 36593
143 36823 36943 36844
144 37069 37187 37093
145 37314 37432 37343
146 37561 37676 37593
147 37807 37921 37841
148 38053 38165 38089
149 38298 38409 38337
150 38541 38651 38580
151 38782 38891 38822
152 39021 39129 39061
153 39258 39365 39299
154 39494 39601 39538
155 39729 39835 39776
156 39967 40072 40014
157 40205 40309 40254
158 40444 40546 40494
159 40685 40784 40734
160 40926 41024 40977
161 41168 41264 41219
162 41411 41505 41464
163 41656 41749 41711
164 41903 41996 41960
165 42153 42246 42212
166 42408 42502 42468
167 42667 42764 42729
168 42931 43030 42993
169 43197 43298 43259
170 43466 43566 43526
171 43735 43833 43794
172 44005 44100 44063
173 44277 44367 44332
174 44549 44635 44602
175 44819 44901 44869
176 45087 45165 45136
177 45351 45426 45398
178 45609 45682 45657
179 45862 45932 45912
180 46110 46177 46164
181 46357 46418 46413
182 46602 46657 46661
183 46844 46894 46909
184 47086 47131 47156
185 47329 47369 47404
186 47573 47610 47655
187 47817 47852 47905
188 48062 48097 48157
189 48308 48346 48409
190 48554 48596 48663
191 48799 48847 48917
192 49045 49099 49171
193 49293 49354 49428
194 49542 49611 49685
195 49792 49871 49942
196 50041 50133 50199
197 50291 50396 50455
198 50541 50659 50710
199 50792 50921 50965
200 51043 51183 51219
201 51295 51445 51470
202 51549 51708 51722
203 51807 51973 51974
204 52068 52237 52226
205 52331 52500 52479
206 52596 52762 52730
207 52861 53024 52982
208 53125 53283 53232
209 53387 53540 53480
210 53646 53794 53727
211 53904 54044 53975
212 54159 54292 54223
213 54414 54540 54472
214 54667 54788 54720
215 54920 55036 54972
216 55175 55289 55225
217 55431 55544 55481
218 55690 55802 55738
219 55950 56065 55996
220 56211 56329 56252
221 56471 56595 56506
222 56732 56861 56760
223 56991 57128 57010
224 57249 57392 57258
225 57510 57656 57504
226 57772 57920 57751
227 58035 58187 57998
228 58297 58453 58244
229 58559 58717 58489
230 58820 58981 58734
231 59080 59243 58980
232 59339 59506 59226
233 59598 59770 59474
234 59854 60034 59722
235 60110 60299 59971
236 60364 60564 60220
237 60619 60829 60469
238 60872 61094 60719
239 61124 61357 60968
240 61377 61620 61217
241 61629 61881 61465
242 61881 62144 61716
243 62134 62407 61966
244 62386 62670 62216
245 62639 62932 62465
246 62892 63194 62713
247 63144 63455 62963
248 63397 63716 63212
249 63648 63978 63462
250 63899 64239 63712
251 64150 64500 63961
252 64399 64762 64211
253 64648 65023 64461
254 64897 65284 64712
255 65146 65535 64963


Seems simple enough, I'll just pull down values to 64-bit doubles and use my existing logic. Confirmed for 0.5.

It's just a normal ArgyllCMS .cal file, so 256. Process monitor appears to show applycal apparently stuck in a loop reading the .cal file around 1,600 times per second.

I'll try to figure out what's going wrong. How are you running the command, btw?

[cyberbeing]

I'll try to figure out what's going wrong. How are you running the command, btw?

Windows XP SP3 x86.
Command Prompt.

cd "C:\Program Files\TI3Parser\"
applycal -i 8bit.3dlut GDM-F520_2011-08-23_rec709_Matrix.cal

[nand chan]

Oh, that exists? I've just finished writing my own :P

Oh well, my version will work for .ti3 files, .cal files and those funky calibration tester formats.

I spoke too soon, SetDeviceGammaRamp is seemingly independent of the device-specific gamma ramps that tools such as dispcalGUI or the CalibrationTester load. Those are per-monitor, and SetDeviceGammaRamp applies globally. In fact, the tool doesn't even detect any SetDeviceGammaRamp changes.

Do you know a way around this limitation? I haven't been able to find out the correct functions for loading a monitor-specific gamma ramp other than the DirectX ones.

Either way, you can use CalibrationTester to save the CLUT to a file and applycal will be able to apply it.

[cyberbeing]

You probably forgot to specify a hardware device context. The following I assume are the relevant imported functions for what you want to do, since all lut loaders contain them.

User32.dll
GetMonitorInfoA
EnumDisplayMonitors
MonitorFromWindow

GDI32.dll
CreateDCA
GetICMProfileA
SetDeviceGammaRamp
GetDeviceGammaRamp
DeleteDC

[nand chan]

You probably forgot to specify a hardware device context. The following I assume are the relevant imported functions for what you want to do, since all lut loaders contain them.

User32.dll
GetMonitorInfoA
EnumDisplayMonitors
MonitorFromWindow

GDI32.dll
CreateDCA
GetICMProfileA
SetDeviceGammaRamp
GetDeviceGammaRamp
DeleteDC

Done.

[leeperry]

For the curious, a comparison of 16-bit LUT vs 8-bit LUT (to make madVR load it, I first converted it down to 8-bit and then converted that back up to 16-bit which is simply a bit-shift, the same way madVR converts levels). You can clearly see the advantage of greater-than-8-bit precision processing even on 8-bit devices. So if you want to use a .3dlut with avisynth be wary of this difference:

http://screenshotcomparison.com/comparison/75573
fair enough, but here's a real world banding test pattern going through LAV CUVID: Banding 720p.rec709.mkv (http://www.mediafire.com/?wbmyif3yf2mijti)

no post-processing in ffdshow, simply bypassing as 16-235 YV12, and mVR taking care of TV>PC conversion and dithering on top(no LUT enabled in there): http://thumbnails39.imagebam.com/14649/351a4a146483981.jpg (http://www.imagebam.com/image/351a4a146483981)

and now SmoothL() plus an 8bit YUY2 LUT in ffdshow, outputting 0-255 RGB32 to mVR, only taking care of dithering: http://thumbnails41.imagebam.com/14649/4ff1f3146483972.jpg (http://www.imagebam.com/image/4ff1f3146483972)

on my semi-10bit CRT, the latter looks much smoother.

[nevcairiel]

Its an artificial pattern, how is that real world? :D

Anyhow, while the first shows very minor 1px bands (no severe macro bands), the second shows very strong dithering noise.
Personally, on this LCD screen, i prefer the first. But of course, that may just be a matter of taste, and/or different screen technologys.

[Wile-E-Coyote]

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.

[leeperry]

Its an artificial pattern, how is that real world? :D

Anyhow, while the first shows very minor 1px bands (no severe macro bands), the second shows very strong dithering noise.
Personally, on this LCD screen, i prefer the first. But of course, that may just be a matter of taste, and/or different screen technologys.
Well, real world as in "going through the whole video pipeline".

I'll give you that I was using SuperSampling and Grainfactory4()....now w/ only SmoothL+YUY2 LUT: http://thumbnails49.imagebam.com/14649/8f5e97146487017.jpg (http://www.imagebam.com/image/8f5e97146487017)

any better on your LCD? Hopefully not a 6bit TN? :o

I could also disable dithering in mVR, but I like a grainy picture tbh: http://thumbnails42.imagebam.com/14649/99ded0146487520.jpg (http://www.imagebam.com/image/99ded0146487520)

[nand chan]

Well, real world as in "going through the whole video pipeline".

I'll give you that I was using SuperSampling and Grainfactory4()....now w/ only SmoothL+YUY2 LUT: http://thumbnails49.imagebam.com/14649/8f5e97146487017.jpg (http://www.imagebam.com/image/8f5e97146487017)

any better on your LCD? Hopefully not a 6bit TN? :o

I could also disable dithering in mVR, but I like a grainy picture tbh: http://thumbnails42.imagebam.com/14649/99ded0146487520.jpg (http://www.imagebam.com/image/99ded0146487520)

The third pattern looks identical to the first pattern on my monitor. The second pattern has awful dithering noise as mentioned.

10-bit H-IPS with 12 bit internal LUTs.

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.

Upload the .ti3 you get errors with.

[Wile-E-Coyote]

Here you go (http://petiflo.free.fr/profil.ti3)

[nand chan]

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.

Here you go (http://petiflo.free.fr/profil.ti3)

Works fine for me in version 0.5, try it.

[nevcairiel]

The third pattern looks identical to the first pattern on my monitor. The second pattern has awful dithering noise as mentioned.

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)

[leeperry]

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.