Advanced Lift Gain Gamma... could use help please.

LuciferHawk wrote: Lets keep it simple

... snip ...

LuciferHawk wrote: ...If above cannot be done, any brute force approach will have no different result than the AL implementation, only different accuracy and performance.
Reducing samples is basically that and you would not need random samples for an already random source/image.

LuciferHawk wrote: By the way, source should mainly be C++.

DrakePhoenix wrote: What language are the ReShade binaries written in anyway?

DrakePhoenix wrote: If it is C++ or C# I wouldn't mind seeing the source code and poking around, just to try and learn a little more about graphics programing in general by looking through some actual code. But I understand completely, crosire, if you aren't comfortable with giving the source out.

DrakePhoenix wrote: Also, back to the subject more at hand... I tried using crosire's code for full sampling of the entire frame buffer. I received an error when it tried to run (actually, repeated errors) that the loop had attempted too many iterations.

[loop] for (int x; x < BUFFER_WIDTH; x++) ...

DrakePhoenix wrote: On the subject of getting the frame buffer as a texture and storing it to another texture... how do games normally present the frame buffer in the first place? We obviously can access it and the information there, because we can sample from it. This suggests to me that it is already stored as a texture in its own right, isn't it? So wouldn't we really only need a way copy the texture en total without having to sample through it? Something along the lines of (psuedo code) manipTexture = frameBufferTexture?

DrakePhoenix wrote: Also I had another thought. Probably not a very good one, because my brain doesn't seem to be working very well today (I think I'm getting sick). But for trying to determine an approximate average of the scene's colors and/or brightness, what about taking and averaging a number of random samples, instead of ordered samples or sampling the entire set? So when calling tex2D, instead of passing it 0.5 or texcoord, pass it float2(noise(xVector), noise(yVector)). Run that multiple times through an iterated for-loop.

LuciferHawk wrote: Is a copy (in source) of a renderTarget/texture to a texture with custom size internally the same as sampling it in HLSL?

DrakePhoenix wrote: the possible ability to simply copy the frame buffer over as a usable texture

crosire wrote:

DrakePhoenix wrote:

LuciferHawk wrote: Is a copy (in source) of a renderTarget/texture to a texture with custom size internally the same as sampling it in HLSL?

In OpenGL it is, the API runs a pixelshader internally when copying between FBOs. Direct3D10+ has an API member for direct memory copying between texture, which could sometimes be a little faster. But the difference should be negligible if you sample the source texture using point sampling and thus disabling interpolation.

crosire wrote: ... snip …
Plus it's closed source currently for reasons that were mentioned already (a search in the forum should bring those up).

crosire wrote: Try to put a "[loop]" in front of the "for" keyword.

[loop] for (int x; x < BUFFER_WIDTH; x++) ...

crosire wrote: … snip …
… redirect to another section of post...
It already is. Everything attached to shaders in ReShade is either a texture or a constant buffer (separate uniforms in D3D9 and a uniform buffer in OpenGL).

crosire wrote: … snip ...
This sounds like a good idea actually. … snip ...

DrakePhoenix wrote: I'll try that. Thanks. But that reminds me... In some cases I've seen “[flatten]” in front of if/else flow control segments. What is that for? I've noticed that sometimes the compiler doesn't seem to like simple if/else, and prefers instead #if/#elif/#else/#endif, but in other places it handles basic if/else just fine. Does [flatten] allow one to use basic if/else where the compiler might otherwise want to see #if/etc.? Or is it for some other purpose?

DrakePhoenix wrote: So if we set up something like “texture MyTex : COLOR;”, then what we would get is a texture that contains what was in the backbuffer at the time the definition/assignment is processed, right? And obviously, MyTex would then be something that could be manipulated or otherwise processed, or passed on to other textures as well.

DrakePhoenix wrote: Which then brings the next question to LuciferHawk: Can we then simply take such a texture and use abstraction to reduce it down quickly and efficiently so that brute sampling can be limited to only a handful of samples? Something along the lines of defining a texture (say MySmallTex) with 5x5 dimensions, set that as the render target for one of the passes, and subsequently pass the MyTex texture to it.

texture MyTex : COLOR;
sampler MyTexSampler { Texture = MyTex; };
texture MySmallTex { Width = 5; Height = 5; };

float4 SampleFromMyTex(float4 p : SV_Position, float2 c : TEXCOORD) : SV_Target {
    return tex2D(MyTexSampler, c);
}

technique Test {
    pass {
        // Samples 5x5 points of MyTex and writes them into MySmallTex
        VertexShader = ...;
        PixelShader = SampleFromMyTex;
        RenderTarget = MySmallTex;
    }
    pass {
        // Do something with MySmallTex
    }
}

DrakePhoenix wrote: What I had in mind was the possibility that perhaps a random sampling might be more efficient (better accuracy at the same performance level, or better performance at the same accuracy level, or whatever). But I think that LuciferHawk is correct (now that I better understand what he was saying), that the pixels from any given frame are effectively random (at the least when taken as relative to any other given frame from the same game output). That being the case, I'm now not convinced that a random sampling would actually result in any increase to efficiency, as the number of samples necessary for accuracy would likely have to be just as high as with a structured or evenly distributed sampling method. Additionally, the accuracy of the result would not be static. In fact, a gaussian structured sampling might be superior to random sampling because of these issues (and I imagine LuciferHawk does something like that in AL).

DrakePhoenix wrote: One last thing: I'd like to apologize for my long posts.

crosire wrote:  Just use a pseudo-random input that stays the same over frames. A simple noise texture will do.

Ganossa wrote: Just letting you know that I reduced the resolution on my bright detection algorithm and it works to a certain extent (being still almost as accurate - down from 98% to about 90%) and gives a huge performance increase (also for compilation). I think this was a very fruitful discussion mate

Update: Tailored it more to be useful for calculating average and corrected it up to have a little less performance (still high increase of performance compared to original) but even higher accuracy than my original algorithm, at least for average.

I will try to make the resulting values accessible in the Framework so it only has to be calculated once.