| Age | Commit message (Collapse) | Author |
|---|
|
Some discussion of this on #892. Also influenced by discussions
with Dennis (email Tue, 30 Jun 2015) on how the oft-quoted
(e.g. by Wikipedia) gamma functions are camera transforms and not
intended for uses like ours.
Also see ITU-r BT1886 which talks about a gamma of 2.4.
|
|
|
|
|
|
|
|
|
|
Dennis points out that `there definitely *is* no right answer for
BT.709 gamma' and `your formula [the DCP-o-matic v2 gamma function
before this commmit] is what I'm calling the inverse of the BT.709
camera transfer function. The EBU would not have bothered to write:
"Therefore the monitor gamma is not, and never has been, the inverse
of the camera gamma." if no-one ever thought of using it'.
At least the 2.2 gamma of v1 should not surprise anybody.
|
|
|
|
|
|
|
|
everything is specified as something_to_xyz and then you can get
an inverse LUT if you want one.
|
|
correction, as per fnordware DCIconverter.
|
|
I'm getting this from fnordware DCIconverter.
https://github.com/fnordware/DCIconverter/blob/master/src/DCIconverter.cpp
|
|
|
|
|
|
|
|
- move the essence of GammaLUT into TransferFunction and handle
different bit depths more neatly
- add ColourConversion to describe input gamma correction, colour
transformation and then output gamma correction in one class.
- add default ColourConversions for sRGB->XYZ, Rec709->XYZ and
XYZ->RGB.
|
