[nand chan]

Originally Posted by alph@

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