I’ve got a problem with a colorize shader (based on Photoshop Color blending mode) which has to run on sm 2.0 but is to complex (not enough arithmetic instructions). The shader is based on moafi implementation: http://mouaif.wordpress.com/2009/01/05/photoshop-math-with-glsl-shaders/
Basically converting from RGB to HSL and back consumes too much instruction slots. As far as know the solution to this could be to divide the shader to a few passes and use a render target to accumulate the calculations for each pixel. Is this the only way of doing this?
Do you mean that kind of effect where you desaturate the image and turn the grays into a predefined color, but leaving blacks and whites as they are? I doubt you need to convert to HSL and back to do that.
With regards to color, that usually mostly refers to HUE, so I guess converting to hue first is one way to do it. Not sure how the math is different. Depends what final results you want. Dolkar’s example will colorize the grayscale version, if that’s ok.
Thank you Dolkar:). Attached is the shader I am currently using. It is used to colorize 2D textures using the Color parameter. I would like to be able to produce the same effect using only sm2.0.
It works just fine for me. Make sure the balance value is not 0.
And it should actually do the opposite. It keeps the lightness constant, just changes the color.
I was able to make the shader work thanks to Ian Taylor and his RGB<->HSL(HSV) conversion implementation. Attached is a Colorize shader which can be run on sm2.0 devices (one pass).