Version 0.14:
* LinkICCGUI now automatically updates yCMS on first run as well
* imagecal.exe clamps the levels to 0-255 properly now, before it would overflow
* Another attempt at fixing the locale bug, this time by forcing en-US explicitly instead of the invariant culture
(* Gamma encoding for values under 0 works “properly” now)
* Fixed a very slight error in the predefined BT709 primaries
+ LutScript scripts can now be directly dragged onto lutscript.exe instead of having to run it from the console
  You can also assign the program as default program for the .3ls file extension, so you just need to double click it
+ Added new gamuts (usable in LutScript):
  BT709 (aliases: HDTV, sRGB, scRGB)
  ROMM (aliases: ProPhotoRGB)
  AdobeRGB (aliases: AdobeRGB98)
  AppleRGB
  NTSC (aliases: NTSC53, FCC1953, BT470M)
  NTSC87 (aliases: SMPTEC, SMPTE_C, SMPTE_RP_145, SMPTE_170M)
  SECAM (aliases: PAL, EBU_Tech_3213, BT470_B)
  AdobeWide
  CIE1931
  CIEXYZ (note: The *GAMUT*, not the color space!)
  ACES

Version 0.13:
* ICC profiles without added primaries information no longer get rejected (the color space gets set as “unknown”)
* Calibration files no longer have swapped primaries, bug introduced in version 0.12
  This fix affects: CalFile(), applycal, imagecal and --calibrate in make3dlut

Version 0.12:
* Fixed a bug in the merge3dlut description
~ Internal ColorTriple<T> structure re-ordered to have the same channel order for BGR and YCbCr, most tools are now channel
  agnostic unless they need to be otherwise. This might cause some issues where the channels end up swapped - please report
  them asap.
+ New LutScript functions: GammaDec(Number), GammaEnc(Number), ColorDec(Primaries), ColorEnc(Primaries) - these add primitive
  gamma and gamut adjustment. The proper procedure is to first decode gamma, then colors, then encode colors and encode gamma.
  “Primaries” can be either of the form BT709 or it can be 8 separate numbers, referring to the x/y values of the primaries'
  Red, Green, Blue and White points - in that order. For example:
  !Pixel({
    GammaDec(2.2)   # This converts from weighted R/G/B to linear r/g/b
    ColorDec(BT709) # This converts from linear r/g/b to absolute X/Y/Z
    ColorEnc(0.682, 0.304, 0.1975, 0.7036, 0.1457, 0.0486, 0.313, 0.3308) # This converts from X/Y/Z to some other linear r/g/b
    GammeEnc(2.35)  # This converts from linear r/g/b back to weighted R/G/B, here scaled slightly differently
  })
+ New LutScript function: Scale(Number, Number) - this scales to a given value range, for example Scale(0.2, 0.8)
  It is important to note here that this is relative to the input range - the above function in a Limited range .3dl2 will scale
  to something like 59.8 - 198.4.
+ New LutScript function: Clamp(Number, Number) - this clamps output to a certain value range. Useful when you get artifacts
  in madVR when dealing with BTB/WTW levels in Limited range .3dluts (my own code does not exhibit this behavior, so it is not
  needed for usage with progams like imagecal.exe)
* LinkIccGUI no longer locks up the interface while it is processing

Version 0.11:
- IccTransform() was removed
+ IccSingle(String, [Intent]) added. Intent is optional and defaults to Relative.
  This IccSingle filter decodes between a profiles PCS and ColorSpace and can go both ways (eg. XYZ->RGB, RGB->XYZ)
+ IccLink(String, String, [Intent]) added - this links two profiles together and can only go one way (no PCS support)
* Missing ICC profiles no longer result in a crash
* Comments after LutScript lines with strings in them get filtered out properly now
* Fixed a bug where tag3dlut would still mark a lut as compressed even in legacy mode (the actual output wasn't
  compressed, but the tag was incorrectly set)
* linkicc.exe now automatically assumes the input to be BT.709 instead of detecting the primaries from the ICC profile,
  due to a strange issue in LittleCMS where the input tags will be completely incorrect.
+ New tag --auto-detect (-a) reverses this behavior [linkicc]
+ New program: join3dlut.exe, this program joins together two .3dl2s, switching between the two depending on
  the luminance of the input.
+ New program: LinkICCGUI.exe. This is the new preferred front-end for everything. It accepts both an .icc and a .ti3,
  and applies the following steps automatically:
   make3dlut
   linkicc (auto-generates a BT.709 / 2.2 profile in memory)
   join3dlut
   applycal
   tag3dlut
  The result is a fully functional v1 .3dlut ready for madVR compatibility. No further steps are needed.

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