Quote:
Originally Posted by 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.
|
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.