Sign in to follow this  
DarkChris

[SOLVED] Mysterious contrast issues

Recommended Posts

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:

[code]
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;
[/code]

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.

[img]http://darkchris.ath.cx/contrast_issues.png[/img]

If you don't see the differences: The blacks aren't as black anymore...

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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 ?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
It's neither the sampler nor the texture coordinates... I've got the first image by using this code:
[code]
float3 color = tex2D(someSampler, texCoord).rgb;
[/code]

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)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this