GLSL - 将纹理的特定颜色更改为另一种颜色

Question

My textures consist of 4 different colors. I want to change each color to a different color. I tried it the following way:

precision mediump float;

varying lowp vec4 vColor;
varying highp vec2 vUv;

uniform sampler2D texture;

bool inRange( float c1, float c2 ) {
  return abs( c1 - c2 ) < 0.01;
}

void main() {
  vec4 c = texture2D(texture, vUv);

  if ( inRange( c.r, 238.0/255.0 ) && inRange( c.g, 255.0/255.0 ) && inRange( c.b, 84.0/255.0 ) )
    c = vec4( 254.0/255.0, 254.0/255.0, 247.0/255.0, 1.0 );

  else if ( inRange( c.r, 15.0/255.0 ) && inRange( c.g, 59.0/255.0 ) && inRange( c.b, 5.0/255.0 ) )
    c = vec4( 65.0/255.0, 65.0/255.0, 65.0/255.0, 1.0 );

  else if ( inRange( c.r, 157.0/255.0 ) && inRange( c.g, 184.0/255.0 ) && inRange( c.b, 55.0/255.0 ) )
    c = vec4( 254.0/255.0, 247.0/255.0, 192.0/255.0, 1.0 );

  else if ( inRange( c.r, 107.0/255.0 ) && inRange( c.g, 140.0/255.0 ) && inRange( c.b, 38.0/255.0 ) )
    c = vec4( 226.0/255.0, 148.0/255.0, 148.0/255.0, 1.0 );

  gl_FragColor = c;
}

This works. But it's terribly slow. I'm running this on an iPhone, but the calculations aren't that hard or am I missing something?

Is there a faster way to do this?

Answer 1

Branches are bad for shader performance. Normally, the GPU executes multiple fragment shaders (each for their own fragment) at once. They all run in lockstep -- SIMD processing means that in effect all parallel fragment processors are running the same code but operating on different data. When you have conditionals, it's possible for different fragments to be on different code paths, so you lose SIMD parallelism.

One of the best performance tricks for this sort of application is using a Color Lookup Table . You provide a 3D texture (the lookup table) and use the GLSL texture3D function to look up into it -- the input coordinates are the R, G, and B values of your original color, and the output is the replacement color.

This is very fast, even on mobile hardware -- the fragment shader doesn't have to do any computation, and the texture lookup is usually cached before the fragment shader even runs.

Constructing a lookup table texture is easy. Conceptually, it's cube that encodes every possible RGB value (x axis is R from 0.0 to 1.0, y axis is G, z axis is B). If you organize it as a 2D image, you can then open it in your favorite image editor and apply any color transformation filters you like to it. The filtered image is your conversion lookup table. There's a decent writeup on the technique here and another in GPU Gems 2 . A more general discussion of the technique, applied using Core Image filters, is in Apple's documentation library .

Answer 2

EDIT: It was confirmed by the asker that it is the presence of any branches that causes the incredible slowdown. I will provide an attempt at a branchless solution.

Well, if branches (including using the ternary "?" operator) are unusable, you can only use arithmetic.

A possible solution (which is hideous from a maintenance perspective, but might fit your need) is to map your input color to output color using polynomials that give desired output for the 4 colors you care about. I treated the 3 RGB color channels separately and plugged in the input/output points into wolfram alpha with a cubic fit (example for the red channel here: http://www.wolframalpha.com/input/?i=cubic+fit+%7B238.0%2C+254.0%7D%2C%7B15.0%2C+65.0%7D%2C+%7B157.0%2C+254.0%7D%2C+%7B107.0%2C+226.0%7D ). You could use any polynomial fit program for this purpose.

The code for the red channel is then:

float redResult = 20.6606 + 3.15457 * c.r - 0.0135167 * c.r*c.r + 0.0000184102 c.r*c.r*c.r

Rinse and repeat the process with the green and blue color channels and you have your shader. Note that you may want to specify the very small coefficients in scientific notation to retain accuracy... I don't know how your particular driver handles floating-point literals.

Even then you may (probably) have precision issues, but its worth a shot.

Another possibility is using an approximate Bump Function (I say approximate, since you don't actually care about the smoothness constraints). You just want a value thats 1 at the color you care about and 0 everywhere else far enough away. Say you have a three-component bump function: bump3 that takes a vec3 for the location of the bump and a vec3 for the location to evaluate the function at. Then you can rewrite one of your first conditional from:

  if ( inRange( c.r, 238.0/255.0 ) && inRange( c.g, 255.0/255.0 ) && inRange( c.b, 84.0/255.0 ) )
    c = vec4( 254.0/255.0, 254.0/255.0, 247.0/255.0, 1.0 );

to:

  vec3 colorIn0  = vec3(238.0/255.0, 255.0/255.0, 84.0/255.0);
  vec3 colorOut0 = vec3(254.0/255.0, 254.0/255.0, 247.0/255.0)
  result.rgb = c.rgb + bump3(colorIn0, c.rgb)) * (colorOut0-colorIn0);

If max/min are fast on your hardware (they might be full branches under the hood :( ), a possible quick and dirty bump3() implementation might be:

float bump3(vec3 b, vec3 p) {
   vec3 diff = abs(b-p);
   return max(0.0, 1.0 - 255.0*(diff.x + diff.y + diff.z));
}

Other possibilities for bump3 might be abusing smoothstep (again, if is fast on your hardware) or using the exponential.

The polynomial approach has the added (incidental) benefit of generalizing your map to more than just the four colors, but requires many arithmetic operations, is a maintenance nightmare, and likely suffers from precision issues. The bump function approach, on the other hand, should produce the same results as your current shader, even on input that is not one of those four colors, and is much more readable and maintainable (adding another color pair is trivial, compared to the polynomial approach). However, in the implementation I gave, it uses a max, which might be a branch under the hood (I hope not, geez).

Original answer below

It would be good to know how you are getting timing information so we can be sure its this shader thats slow (you could test this by just making this a pass-through shader as a quick hack... I recommend getting used to using a profiler though). It seem exceedingly odd that such a straightforward shader is slow.

Otherwise, if your texture truly only has those 4 colors (and it is guaranteed), then you can trivially take the number of inRange calls down from 12 to 3 by removing the if from the last branch (just make it an else), and then only testing the r value of c. I don't know how the iPhone's glsl optimizer works, but then you could further try to replace the if statements with ternary operators and see if that makes a difference. Those are the only changes I can think of and unfortunately you can't do the definite optimization if your textures aren't guaranteed to only have those 4 colors.

I would again like to point out that you should make sure this shader is causing the slowdown before trying to optimize.