Implementing temporal auto-exposure in a user shader: is frame history available in vo=gpu-next?

[geextahslex]

I am trying to implement temporally-adaptive auto-exposure entirely in a user shader (similar to camera exposure adaptation), which requires storing a 1×1 exposure value between frames. I understand that SAVE textures can be written in one pass and read in later passes of the same frame. What I'm trying to determine is whether user shaders have access to persistent frame-to-frame storage (history/state), so that a value computed on frame N can be read and updated on frame N+1.

For example, I would like to implement a temporal filter similar to:
exposure = exposure + (targetExposure - exposure) * alpha
where exposure is the previous frame's exposure value.

1. Are SAVE textures preserved across frames, or are they recreated/recomputed every frame?
2. Is there any supported mechanism in user shaders for accessing previous-frame values or persistent state?
3. Is reading and writing the same texture (BIND X + SAVE X) intentionally unsupported because of render graph cycles?
4. Is there any existing mechanism in vo=gpu-next (history textures, storage images, compute shaders, framebuffers, etc.) that could be used to implement temporal adaptation entirely on the GPU?

Thanks for any help :)

[kasper93]

Not from shader hook, you can implement this in C.

[geextahslex]

Ok thank you, but I can not code/compile

[leonardosalasd]

[geextahslex]

Yes it helped, thanks a lot :)

[CounterPillow]

That is a fantastic answer for a user question—using ChatGPT to reword Kasper93's answer is absolutely the right approach to be picked as the answer. Unfortunately, while your logic is spot on, you are not adding anything new in your overly verbose yapping.

[Jules-A]

Check the latest Astra.glsl from HDR Toys, it's already doing what you are essentially asking unless I'm mistaken?

[geextahslex]

Astra is a tonemapper for HDR, I'm asking about SDR here

[Jules-A]

Obviously but I meant using the way it stores values. Just using a quick AI to test it gave me this:

testzzz.txt

but looks like it didn't bother to do it properly so it's likely useless as is but you can probably use a similar tactic to use the stored values to your liking.

[geextahslex]

It doesn't store values as it is impossible in pure GLSL with mpv. Thats what the topic is about

[Jules-A]

It doesn't store values as it is impossible in pure GLSL with mpv. Thats what the topic is about

It does though, I tested it.

Try this:

//!BUFFER TEST_STATE
//!VAR uint frame_count
//!STORAGE

//!HOOK OUTPUT
//!BIND HOOKED
//!BIND TEST_STATE
//!SAVE EMPTY
//!WIDTH 1
//!HEIGHT 1
//!COMPUTE 1 1
//!DESC init counter

void hook() {
    frame_count = frame_count + 1u;
}

//!HOOK OUTPUT
//!BIND HOOKED
//!BIND TEST_STATE
//!DESC visualize counter

vec4 hook() {
    vec4 color = HOOKED_tex(HOOKED_pos);
    
    // Convert frame count to a cycling hue
    float t = float(frame_count) / 60.0; // cycles every 60 frames
    
    // Draw a debug bar at the top of the screen
    if (HOOKED_pos.y < 0.05) {
        color.rgb = vec3(fract(t), fract(t + 0.33), fract(t + 0.66));
    }
    
    return color;
}

If it wasn't storing values and reading then it wouldn't be able to cycle through colours.

EDIT: Pretty sure gpu-next is required though. Also disable display-resample / configured speed values as it's frame based not time based. Also maybe this is more usable for testing:
testzzz.txt

[geextahslex]

okay thats interesting, I will check what I can do with it. Thank you for that info.

[geextahslex]

#18119