Curve mapping implemented in display transform GLSL shader

This patch adds support of curve mapping applied on GPU when having image draw method set to GLSL. This also makes rendered viewport aware of display's transform curve mapping.

Almost all of the new code in the shader is a 1:1 copy of evaluation functions from colortools.c.

Passing curve mapping to a GLSL shader is not as small and easy how i would imagine it to be, but couldn't find easier way to do it. So for now it's like dozen of uniform parameters to be filled in.

As an addition, made it so display transform GLSL shader is data-to-c'ed instead of being hardcoded as a string to the .cc file.

TODO:
- curvemapping_evaluateRGBF could be zapped from the shader.
- texelFetch works awesome, but doesn't exist on my intel card. texture1D gives some darkening which i couldn't figure out yet.

[sergey.vfx, 2013-09-30 12:12:34]

Darkening seems to be solved

[brechtvl, 2013-10-01 19:03:04]

Some comments, looks good to me overall.

https://codereview.appspot.com/13810046/diff/5001/intern/opencolorio/gpu_shad...
File intern/opencolorio/gpu_shader_display_transform.glsl (right):

https://codereview.appspot.com/13810046/diff/5001/intern/opencolorio/gpu_shad...
intern/opencolorio/gpu_shader_display_transform.glsl:30: +	 *               But
is it actually correct to subtract 1 here?
I think it is correct, it's quite normal for lookup tables that need to cover a
[0, 1] range.

https://codereview.appspot.com/13810046/diff/5001/intern/opencolorio/gpu_shad...
intern/opencolorio/gpu_shader_display_transform.glsl:107: +	if
(use_curve_mapping) {
Ideally this kind of thing would be a compile time switch, but not sure how
difficult that is to implement. As far as I can tell there is already some code
to recompile the shader on OCIO changes, I think it would be good if
enabling/disabling curve mapping would do the same thing. Adding this code on
the GPU can have effects on performance even if you would expect the if test to
be fast, so best to not have it at all when not used.

[sergey.vfx, 2013-10-02 08:22:58]

Move curve mapping into #ifdef

[sergey.vfx, 2013-10-02 08:24:22]

On 2013/10/01 19:03:04, brechtvl wrote:
> Some comments, looks good to me overall.
> 
>
https://codereview.appspot.com/13810046/diff/5001/intern/opencolorio/gpu_shad...
> File intern/opencolorio/gpu_shader_display_transform.glsl (right):
> 
>
https://codereview.appspot.com/13810046/diff/5001/intern/opencolorio/gpu_shad...
> intern/opencolorio/gpu_shader_display_transform.glsl:30: +	 *              
But
> is it actually correct to subtract 1 here?
> I think it is correct, it's quite normal for lookup tables that need to cover
a
> [0, 1] range.

Yeah, also seems fine. Guess we'll just give it a try and see how it goes :)

>
https://codereview.appspot.com/13810046/diff/5001/intern/opencolorio/gpu_shad...
> intern/opencolorio/gpu_shader_display_transform.glsl:107: +	if
> (use_curve_mapping) {
> Ideally this kind of thing would be a compile time switch, but not sure how
> difficult that is to implement. As far as I can tell there is already some
code
> to recompile the shader on OCIO changes, I think it would be good if
> enabling/disabling curve mapping would do the same thing. Adding this code on
> the GPU can have effects on performance even if you would expect the if test
to
> be fast, so best to not have it at all when not used.

Moved all the curve mapping GLSL code into #ifdef block. Guess this solved
possible GPU slowdowns?

[brechtvl, 2013-10-02 12:20:27]

LGTM

[sergey.vfx, 2013-10-04 12:23:48]

Initial dIther implementation :)

[sergey.vfx, 2013-10-04 12:26:19]

Brecht, will bother you  bit more..

Added some kind of dither to gpu. Uses some magic pseudo-random which is
actually a texture coordinate hashing function.

TODOs:
- Dither noise is the same for all the frames.
- It's different from Floyd's dither we've been using before.
- Currently CPU and GPU dithering used different implementation. Ideally we need
to use the same dither in CPU.


Do you think it's the way to go? And couple of Qs:

- What is the criteria of how dither good?
- I guess when rendering animation dither noise shall be different for different
frames?

P.S. It's not so much changes comparing to previous patchset actually. Just a
bit of functions in the shader and piping dither to OCIO c-api.

[brechtvl, 2013-10-09 14:26:15]

On 2013/10/04 12:26:19, sergey.vfx wrote:
> Brecht, will bother you  bit more..
> 
> Added some kind of dither to gpu. Uses some magic pseudo-random which is
> actually a texture coordinate hashing function.
> 
> TODOs:
> - Dither noise is the same for all the frames.
> - It's different from Floyd's dither we've been using before.
> - Currently CPU and GPU dithering used different implementation. Ideally we
need
> to use the same dither in CPU.
> 
> 
> Do you think it's the way to go? And couple of Qs:
> 
> - What is the criteria of how dither good?

Well, I don't know too much about the technical terms here, and most papers seem
to be about dithering to very few bits, which I guess has more complicated
requirements. As far as I know you want to remove banding while introducing as
little noise as possible. For example in a file like this you want the banding
to be gone.

http://www.pasteall.org/blend/24503

The nice thing about floyd-steinberg is that it isn't going to introduce much
noise where it isn't needed, but on the other hand not many people will care
about 1 bit of noise, especially for cycles renders which have noise anyway. So
if I had to guess, I think it's an acceptable replacement.

> - I guess when rendering animation dither noise shall be different for
different
> frames?

I think that might be ideal, although probably it will be difficult to see any
difference in practice.

[brechtvl, 2013-10-09 14:28:06]

This GLSL shader didn't work on my macbook with pretty new GT 650M. It seems OS
X doesn't support GLSL version 1.3 yet here (only with OpenGL core profile for
which we can't use any deprecated OpenGL functions ...). Maybe it should pass
the texture size as uniforms instead of using textureSize.

[sergey.vfx, 2013-10-09 15:59:24]

On 2013/10/09 14:28:06, brechtvl wrote:
> This GLSL shader didn't work on my macbook with pretty new GT 650M. It seems
OS
> X doesn't support GLSL version 1.3 yet here (only with OpenGL core profile for
> which we can't use any deprecated OpenGL functions ...). Maybe it should pass
> the texture size as uniforms instead of using textureSize.

Yeah, but passing texture size is not so much flexible :( Will figure this out
anyway.

Commited curve mapping to svn now, think dither is easier to be handled
separately.