Color Correction v2 behaves differently and it is unknown how to mimic old behavior

[schwjm]

Operating System Info

Windows 10

Other OS

No response

OBS Studio Version

27.0.1

OBS Studio Version (Other)

No response

OBS Studio Log URL

https://obsproject.com/logs/EeJ--TrTgLFnAKgN

OBS Studio Crash Log URL

No response

Expected Behavior

I expect the Color Correction feature to behave like it always did given the same/similar parameters, or have a workaround to make it so. The specific blending I used does not seem to be accomplishable via adding the Color Correction filter: (this is the result of "Step 1")

Current Behavior

Adding Color Correction since 27.0 or 27.0.1 creates "color_filter_v2" which subtly changes the accepted parameters. For example, Opacity is a [0,1] coefficient value instead of a [0,100] percentage value. Unfortunately, "25" from the old filter version does not seem to reflect "0.25" under the new version. (this is the result of "Step 2")

Steps to Reproduce

1. Have an image with the legacy color_filter set at -1 Saturation and 25 Opacity

2. Duplicate the image and replace the filter with "Color Correction" (color_filter_v2), using -1 Saturation and 0.25 Opacity

3. Toggle between the two images and observe that the resulting scene is different

The difference may be even more noticeable if the image is overlayed on top of something else that has Opacity filtering, but it is noticeable even without.

Anything else we should know?

No response

[WizardCM]

I believe this change in behaviour is expected as it's now a linear value, which is why there's a v2 in the first place.

[schwjm]

It may be working/expected behavior in a bubble of what it's doing individually, but I think it remains that it's a bit strange that you cannot use the old behavior directly (thankfully, you can still use it at all). In this case I'm expecting a particular look and I cannot accomplish this without a weird workaround of copying existing filters/elements around, I can't add the original filter directly as far as I can tell and this behavior change seems undocumented.

[RytoEX]

It may be working/expected behavior in a bubble of what it's doing individually, but I think it remains that it's a bit strange that you cannot use the old behavior directly (thankfully, you can still use it at all). In this case I'm expecting a particular look and I cannot accomplish this without a weird workaround of copying existing filters/elements around, I can't add the original filter directly as far as I can tell and this behavior change seems undocumented.

What particular look are you expecting? Please provide your source files along with their respective filter settings and screenshots of your expected result and the undesired result from OBS 27.

As I understand it, color (and alpha) blending is now done linearly. You can read more about this on our wiki.

[schwjm]

What particular look are you expecting? Please provide your source files along with their respective filter settings and screenshots of your expected result and the undesired result from OBS 27.

I can dig up the specific images but I don't think they matter (I'm really trying to just have a pattern)--the original post shows an example of what you're asking for (25% opacity, -1 Saturation), where I'm looking for one image to blend into another. The image in the background happens to be also set with 10% opacity under the new filter (though this doesn't seem to make a difference).

With the newer filter, the brighter colors seem to fade out less, leaving more white (e.g. 858a86 in the "E" in "TEEN"), whereas the combination under the original filter leave more color (e.g. 4b624f), which I'd prefer.

Thanks for the information on color blending. The only thing I think I'm really looking for is how to work with the system, or have the legacy option available, where the background color shines through more is transparent (regardless of brightness).

You gave me an idea though. I removed the background image to just leave the black background. Just so I understand it correctly, would you expect f7f7f7 (HSV 0,0,96.9) to blend to 848484 (HSV 0,0,51.8) using "0.25 opacity"? That's what I'm observing and I'm trying to wrap my head around that math, that feels like a strange, unintuitive result.

[jpark37]

I've added some math examples to the bottom of https://github.com/obsproject/obs-studio/wiki/Linear-Color-Blending that should hopefully help you work out the math for your own situation. Let us know if this helps or if there's a specific example you still don't understand.

Behavior differences are expected though. The filter is on v2 because we were trying to avoid breaking everyone's existing v1 filter setup.

[SuslikV]

@jpark37 I looked at the math and it is not good as you think. Alpha is linear. RGB is not. Display devices is not linear. Human eye not linear. Two square images combined together is not 2 light sources (of double square) in the human perspective. It is still 1 source (same area) but may be slightly brighter.

Edit: https://obsproject.com/forum/threads/image-mask-blend-broken-as-of-v27.145973/ Different filter in the link (Image Mask/Blend) but, as soon as math was presented, it is related.

Example. Let's say, I have two perfect monitors (both AMOLED based). There is dark room with this two display devices. I filled first desktop with pure black (0, 0, 0). And seconds with the pure black (0, 0, 0) two. Nothing is seen in the room - it is too dark here. Then I filled second desktop with the (16, 16, 16) and looked at the room walls - I see the light from the both devices (sure one is no light, second is slightly lighter than nothing). Blend of the light on the room's walls happened! Now I shutdown first PC. No blend. Single source of the light. Will my wall will be dimmed now? Now, stick an A4 paper on the wall of this room (to have fixed area for measurements). Will it shine brighter if I turn on the first PC where (0, 0, 0) is on display?

How blend to 0 can get the additional gain? I can understand 2.2->1.0->0.45 but there is going something different. The additional power from nowhere. How?

[MisutaaAsriel]

I believe this change in behaviour is expected as it's now a linear value, which is why there's a v2 in the first place.

This may be true, but shouldn't OBS "upgrade" existing filters in that case? Upgrading by hand one or two filters is one thing, but if you are a "filter heavy" user (like myself), this would entail hours of work, just going through each source, scene, and collection, to "fix" something OBS [syntactically] "broke".

E.G. When using 27.0.1 on my Mac, anything with an adjusted opacity is now fully opaque, which would require me to go through and manually readjust every opacity value, as percentage values are now decimal values, and values over "1.0" are being capped, rather than converted.

OBS also does not warn of this behavior on upgrade, making it opaque to the end user as to why all of their filters are "broken".

---

Unfortunately, for people like myself, changing the behavior of the filter, without offering it as a new filter, or providing an alert on first-launch with the option to "upgrade" old filters (i.e. automatically converting values to fit within the new syntax), means that a large portion of our scenes are critically broken, and the work required to "fix" them exceeds the benefit of using a new version.

[jpark37]

This may be true, but shouldn't OBS "upgrade" existing filters in that case?

Existing scenes should still use the "old" filters. The newly behaved filters are "v2." There's no UI to expose adding the old filters; you can only add them by editing the XML by hand, or using an older version of OBS.

The idea was that users would have their old filters grandfathered in, and they could manually convert to v2 filters at their leisure. We (I) unfortunately underthought the impact that the global blending and alpha changes would have, and so the legacy filters don't quite behave the same in OBS 27 in all cases. Fortunately most users don't use a lot of seni-transparency, but it was a bad experience for others, and I'm personally sorry about that.

We had tough choices to make as far as how to handle color and alpha going forward as we may have to deal with more color spaces in the future (e.g. HDR), so getting rid of color "hacks" was a priority. We tried to make the best tradeoffs we could, and this is a consequence of that. We don't expect to make any more breaking changes to color, so hopefully you can forgive this one-off breakage.

[schwjm]

What is the plan though, are the legacy v1 filters going to be fully dropped at some point? The approach seems to be sitting on the fence between support and not supporting them. If they're grandfathered in, why not also allow adding them via the UI directly rather than requiring copy-paste to use them?

The issue for me is that I have the effect I like, and want to apply it to new scenes or images. Using OBS filters to get this look, rather than manually editing raw images in external programs and exporting several edits for the different color adjustments, is super convenient. This workflow seems to be at risk for me.

Perhaps the answer is not with the current filter (which has been changed for reasons that are probably good but I honestly can't judge), but another filter altogether.

[jpark37]

The old filter will likely not be dropped, but we also don't want to actively support the old-style filter, and we will get less support requests about it going forward if it's not exposed in the UI.

Our expectation is that people will be able to find new values in the new filters to achieve what they want. At some point, you had to make a judgment call about what you wanted the look to be to pick values with the old filter. Just do that process again with the new filter.

We can't make the new filter match blending exactly, but we expect users will be able to get close if they choose to move to the new filter. If not, we can continue to discuss.

[MisutaaAsriel]

This may be true, but shouldn't OBS "upgrade" existing filters in that case?

Existing scenes should still use the "old" filters. The newly behaved filters are "v2." There's no UI to expose adding the old filters; you can only add them by editing the XML by hand, or using an older version of OBS.

That behavior isn't exhibited for me. All my scenes in all my collections are severely broken. I use the color correction filter heavily for both opacity (there's no opacity filter) and for adjusting color due to overlay "effects" altering appearance.

However, I was, and still am due to this change in filters, using 27.0 RC2 due to it fixing a long standing issue with external GPUs not being available for rendering.

Looking in the XML, all my filters are "V2". Is it possible the beta RC version "upgraded" the values of my filters? And how would I go about returning them to V1 via JSON?

[jpark37]

Looking in the XML, all my filters are "V2". Is it possible the beta RC version "upgraded" the values of my filters? And how would I go about returning them to V1 via XML?

I can't say it's impossible, but I haven't seen that bouncing back and forth between OBS versions in testing, and no one else has reported that happening. You can go back by deleting the version part, e.g. color_filter_v2 -> color_filter, but some properties won't work the same, like Opacity was 0-100, and is now is 0.0-1.0.

[Fenrirthviti]

I think there still might be a miscommunication here. Let me clarify to see if this is the case.

V1 and V2 are not going to look the same with the same settings, that was never the intent, and why any existing V1 filters were not automatically upgraded.

V2 filters are using a "more correct" method for everything they do, but it should be possible to get very close to the same end-result using a V2 filter (just with different values in the filter settings). I can understand and sympathize with having a significant amount of filters and the effort required to go back in and fiddle with the settings on each to get back to the same end result that you had before, but we still believe that the updated filters and they way they are processing color and such is a much better end-state in the long run.

tl;dr: We know it will be painful for some users, but we recommend throwing out all existing filters and setting them back up using V2.

Hopefully this helps clarify.

As a side note, I believe jpark37 meant the .json scene collection file, not xml. For example, you want to change the value of "versioned_id":"color_filter_v2" to "versioned_id":"color_filter". I don't expect we'll be pulling v1 out at any point, but typical "unsupported, on your own, ymmv, etc.".

And as a final note, many of the v2 filters in our RC process were bugged, so that is likely an additional reason why you're seeing inconsistent results across the board here.

[MisutaaAsriel]

As a side note, I believe jpark37 meant the .json scene collection file, not xml. For example, you want to change the value of "versioned_id":"color_filter_v2" to "versioned_id":"color_filter". I don't expect we'll be pulling v1 out at any point, but typical "unsupported, on your own, ymmv, etc.".

I understood this. Though I won't lie that XML would be nicer to work with, honestly.

However, my scenes seem to be irreversibly destroyed by using newer versions of OBS.

In particular, even when using mask_filter & color_filter over their _v2 variants, respectively, the opacity value on all objects is still measure in a point value now instead of percentage. So unless I were to hand edit the opacity value for every scene in every collection, which is considerable, as the opacity value is present on nearly everything, I am unable to even restore v1 behavior.

Likewise, V1 behavior is inconsistent between older versions of OBS and 27.0.1. It is closer than _v2 behavior, but it is still different, to a frustrating degree.

And as a final note, many of the v2 filters in our RC process were bugged, so that is likely an additional reason why you're seeing inconsistent results across the board here.

It would appear one of the RC versions "upgraded" the value of my filters from "v1" to _v2, without actually effecting behavior. Behavior was consistent between earlier versions of OBS and 27.0 RC's, but, even with filters reset to v1, inconsistent between 27.0 RC's and 27.0.1.

At this point, newer versions of OBS are practically unusable for myself unless I wish to dedicate tireless hours, which will likely amount to a fair number of days, reconfiguring my entire scenes library to use the new filters and values.

Unless there is a way to restore the old percentage behavior of opacity?

[MisutaaAsriel]

To further give an example of how behavior is changed, here is a background scene I created for one of my streams, using 27.0 RC2, which had the _v2 variables:

And here it is again using the v1 variables in RC2, as well as using v1 variables with 27.0.1 (release):

I was using the color filter to add color to a greyscale masked image. This seems to be broken now.

And there are numerous other examples too, where colors or opacities or other values, whether using v1 or _v2 are significantly changed.

I'm not really sure how I would even be able to remedy it at this point. It would seem one of the release candidate did, in fact, somehow "upgrade" my scenes, but as you said, the behavior of these filters was "bugged" or otherwise incorrect, and now I am stuck with a bunch of broken scenes that are rendered, virtually, incompatible with future versions of OBS.

Edited to paste the correct second image.

[Fenrirthviti]

I've gone through and tested every version of the RC we had for v27, and I'm not able to replicate a state where any filters would have been upgraded without user-interaction (i.e. removing/re-adding). The only state I can think of that might have caused that to happen is if you had exported and imported the scene collection, but I just tested that on a few of the versions and I wasn't able to cause that to happen either.

I don't want to discount that there might have been an issue here, but even if we manage to figure out what happened, the unfortunate reality is that there really isn't anything we can do, so it's a fairly moot point and likely a waste of everyone's time to dwell on.

In either case, the long-term recommendation is still to just redo all the filters, however frustrating that answer might seem to you.

It's also certainly possible that you might have been using what was actually a bug to get a desired effect, which has been otherwise fixed as there was a lot of focus on filters for the v27 release, and a host of various minor bug fixes. Without source files and exact details on what the desired effect is, it would be hard to say for certain.

As this is becoming more and more of a support issue, are you able to join our Discord so we can take a closer look and do some more investigation on how to get back to the desired effects you're looking for with the new filters?

[MisutaaAsriel]

As this is becoming more and more of a support issue, are you able to join our Discord so we can take a closer look and do some more investigation on how to get back to the desired effects you're looking for with the new filters?

I could, yes.