I am doing post processing by drawing to an FBO and then applying a certain fragment shader when drawing the FBO's texture to the screen. I want to use a look-up table texture to apply color grading. Since I am targeting OpenGL ES 2.0 and possibly older PCs, I cannot use 3D textures. Instead I can use a 2D texture as an atlas of the layers of my 3D look-up table.
What I'm concerned about is correctness and performance when the texture lookup is performed. My look-up texture needs to have linear filtering so I don't have to have a full 256^3 sized look-up table to cover all hues.
My fragment shader would look something like this: Round B up and down to get the two regions of the texture to sample from, add offsets accordingly to R/G and sample the texture twice with the two offset .rg values. And finally linearly interpolate based on B.
But I as I understand it, the when the GPU encounters a
texture2D call on a texture with linear filtering, it will be calculating the input coordinates for those calls for neighboring pixels in parallel to get a derivative. This derivative is used to determine how to sample the texture pixels.
Since this is a post process, I don't want two neighboring pixels to influence each other. It could be a black pixel from the edge of a sprite next to a bright blue sky pixel. In the look-up table, these two would need to sample distant points. So is the GPU going to decide the derivative is huge (minification) and try to linearly sample and involve all the random in-between texels on my look-up table?
Is there a way to get my linear filter to ignore neighboring pixels and only interpolate from the 4 nearest texels? Sort of like treating everything as magnification?
The problem is similar to this question that was asked in regards to HLSL, but I'm targeting OpenGL 3.0 and OpenGL ES 2.0: Color grading, shaders and 3d textures