[SOLVED] Mysterious contrast issues

Started by
6 comments, last by DarkChris 13 years ago
Can you explain me why I keep losing the contrast when I sample a texture like this? I know that that the code doesn't make sense, but it's a simplified version of my actual code that still produces the same errors:


float3 color = 0;
float weights = 0;

for (float sampleX = -1; sampleX <= 1; sampleX += 2 / 25)
{
for (float sampleY = -1; sampleY <= 1; sampleY += 2 / 25)
{
float weight = 1;
weights += weight;
color.rgb += weight * tex2D(someSampler, texCoord).rgb;
}
}

color.rgb /= weights;


I don't think that the contrast errors are related to gamma as I'm not really calculating anything with the colors. It think they are somehow related to floating point precision errors. Is there any solution to my problem? Note that the weights may vary.

contrast_issues.png

If you don't see the differences: The blacks aren't as black anymore...
Advertisement
Try to add this line in the final of the pixel shader.

return pow(color, 1/2.2);
I've already configured the rasterizer and the samplers to be in linear space... But that's not the problem... 5*x/5 should always be x, independent of whether I'm in gamma space or not.
I don't see you init color.rgb to zero which you probably want for a filtering calculation. Does that variable come down from the vertex or vertex shader ? Might be white, so the 1/weights will add a slight gray always. Just a guess.
The color.rgb is set to 0 right before this code gets executed. The thing is that the contrast error is not as apparent on this image as on other images. The error seems to be 17/255, which is quite huge...

The thing is that I'm sampling the texture at the same texture coordinates n times, sum the samples together and divide the result by n.

n * sample / n ? sample
Really strange. What API are you using ? How do you provide the tex-coords ? What filter is the sampler set to ?

I don't see any precision problem so far, the calculation in the shader is supposed to work with floats after all. Could still be a driver or hardware issue though. You might try other formats (higher precision), but I doubt it's the issue.

Silly as it sounds: Have you tried a full black source image already ? And could you do a diff of the source and dest image and show it, maybe that rings some bells for anyone ?
You should try to narrow down the source of the problem. Precision could be an issue, since you are accumulating 625 values, and as the accumulated value grows, there will be more and more errors introduced when additional terms are accumulated.

Is the problem there by just sampling once? Then the problem is likely not with the code, but with the fact that the image you sample is wrong to begin with. Does the error go away when you sample just once, and increases the more times you sample it? Then the problem is likely with floating point precision errors. You need to experiment, for example change the code, and analyze the result to try to see where the error is coming from.
It's neither the sampler nor the texture coordinates... I've got the first image by using this code:

float3 color = tex2D(someSampler, texCoord).rgb;


And yes I've tried a whole black image and the error is huge. The API is basic DirectX and the shader code is basic HLSL.

... And now it gets weird. I've tried less samples. And it gets even worse. :(

EDIT: Oh my god... I'm so dumb... The color wasn't actually set to 0. I've initialized it with 1. Ok, the thread can be closed +rep to everyone ;) (EDIT, if I only knew how)

This topic is closed to new replies.

Advertisement