Sometimes incorrect rendering of source colorspace. (Compositing/transform issue?)

[YellowOnion]

Operating System Info

Other

Other OS

NixOS 26.05.20260507.68a8af9

OBS Studio Version

32.1.2

OBS Studio Version (Other)

No response

OBS Studio Log URL

https://obsproject.com/logs/eChzgWSRB9ah7BI5

OBS Studio Crash Log URL

No response

Expected Behavior

Correct colorspace rendering in all views.

Current Behavior

Program is correct, Preview is not:

multiview doesn't render correctly when scene is not selected:

But does when selected:

filter preview looks fine:

Steps to Reproduce

1. Capture OpenGL game with vkgamecapture
2. Set source transform to Bilinear/Bicubic/Lanczos.

Others are reporting it's due to transform code as well, with croping or other things.

nowrep/obs-vkcapture#285 (comment)

All other settings are default

Anything else we should know?

No response

[YellowOnion]

You can see it here, when I hit transition:

2026-05-27.23-02-28.mp4

[Fenrirthviti]

Can you reproduce this without a third-party capture source?

[YellowOnion]

@Fenrirthviti, I could try, but I'm unsure how to isolate it, I think this is unique to the specific colorspace set by vkcapture.

I'd need to know what colourspace the plugin is using, export it to a file somehow, and load it up with say the static image plugin, if it at all supports OpenEXR or similar.

There is a mention of TODO for F16 pixel format here, but otherwise the code is pretty simple, so not sure how such a specific edge case could slip in.

https://github.com/nowrep/obs-vkcapture/blob/master/src/vkcapture.c#L804-L831

i.e. this PR has a fix for a similar issue,revealed by vkcapture plugin, in non-fade transitions, #13245

[PatTheMav]

Using Studio Mode to present the issue is surprisingly helpful here, because it effectively eliminates transitions as the "source of error": In this mode, the program view is rendered using the video output texture (which includes the transition), but the preview itself is rendered using just the scene source.

So if the preview looks wrong as it does here, it means that the source itself does something wrong, which looks like double-encoding sRGB gamma.

At a glance vkcapture_source_render and vkcapture_get_color_space do things I find unintuitive. Neither VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT nor VK_COLOR_SPACE_HDR10_ST2084_EXT use scRGB, both would need to use plain EDR, so that would lead to OBS converting EDR colour values into EDR again by interpreting them as scRGB. Except if somehow Linux provides those colours as scRGB but "lies" about the format.