[Question] How can I use inverse tone mapping (ITM) on the Steam Deck's Gaming Mode gamescope session?

[SaltyBet]

Not an issue, but a question.

From #751, what I'm understanding is that the following ITM-related arguments exist for a nested gamescope session:

• --hdr-itm-enable : enable SDR->HDR inverse tone mapping. only works for SDR input.
• --hdr-itm-sdr-nits : set the luminance of SDR content in nits used as the input for the inverse tone mapping process. Default: 100 nits, Max: 1000 nits.
• --hdr-itm-target-nits : set the target luminace of the inverse tone mapping process. Default: 1000 nits, Max: 10000 nits.

If I understood the information correctly, how can I use ITM on the Steam Deck's Gaming Mode gamescope session?

I was thinking about modifying /usr/bin/gamescope-session, but it's read-only.

Is there a GUI toggle or similar?

[Lawstorant]

You don't need itm settings if you're running steam in gamescope session These are my only gamescope options:

GAMESCOPECMD="gamescope"
GAMESCOPEOPTS=" -e --hdr-enabled --adaptive-sync -w 3440 -h 1440 -r 165"

STEAMCMD="steam-runtime"
STEAMOPTS="-gamepadui -newbigpicture -steamos3"

[SaltyBet]

@Lawstorant: You don't need itm settings if you're running steam in gamescope session

Thanks for replying.

So SDR->HDR ITM should happen automatically?

If so, that's not what I'm seeing while using SDR games on the Steam Deck's Gaming Mode gamescope session (no HDR logo appears).

[Lawstorant]

Do you have all the needed env variables set? And yes, inverse tonemapping is automatic for SDR content

export WINEDLLOVERRIDES=dxgi=n
export STEAM_GAMESCOPE_COLOR_TOYS=1
export GAMESCOPE_VRR_ENABLED=1
export STEAM_GAMESCOPE_HDR_SUPPORTED=1
export STEAM_GAMESCOPE_VRR_SUPPORTED=1
export DXVK_HDR=1
export ENABLE_GAMESCOPE_WSI=1
export STEAM_GAMESCOPE_COLOR_MANAGED=1

[SaltyBet]

Do you have all the needed env variables set?

I'm using SteamOS. Do you mean setting env vars in, say, $HOME/.profile, or something else?

And yes, inverse tonemapping is automatic for SDR content

So SDR->HDR ITM is automatic, but only if I set env vars?

OK, I'll test and report back.

[SaltyBet]

OK, tested and the results are:

Built-In ITM:

• Go to Desktop Mode.
• Set env vars in $HOME/.bash_profile.
• Restart Steam Deck.
• Start SDR-only game in Gaming Mode gamescope session.
• Results:
  • No HDR logo appears.
  • SDR game output.

Special K HDR Retrofit (DLL injection method):

• Go to Desktop Mode.
• Remove env vars from $HOME/.bash_profile.
• Configure Special K HDR Retrofit (DLL injection method).
• Restart Steam Deck.
• Start SDR-only game in Gaming Mode gamescope session.
• Results:
  • HDR logo appears.
  • HDR game output.

I'd prefer not to use Special K HDR Retrofit and instead use the built-in ITM functionality (easier, less external dependencies), but I don't know what else to do here.

[Lawstorant]

I don't quite understand what's your specific issue. What are you trying to achieve? Are you trying to inject HDR ito games akin to Windows' auto-hdr feature?

[SaltyBet]

I don't quite understand what's your specific issue. What are you trying to achieve? Are you trying to inject HDR ito games akin to Windows' auto-hdr feature?

Basically, yes.

When I saw "BT.2446 Method A inverse tone mapping" as an option, what I understood was, this sounds like functionality similar to Auto-HDR and/or SpecialK HDR, so I wanted to test it.

Did I misunderstand what this feature does?

[Lawstorant]

Yes, it's a misunderstanding then. Inverse tone mapping makes sure that SDR content will be displayed correctly when outputting HDR. Basically, it converts the colors and brightness so your games, movies etc won't appear oversaturated and overbright.

Tone mapping -> HDR content looks good on SDR display Inverse tone mapping -> SDR content looks good on HDR display

[isaboll1]

Replying to https://github.com/ValveSoftware/gamescope/issues/1487#issuecomment-2351797731

Steam only shows the HDR logo if the game itself is directly trying to output an HDR swapchain, however Steam automatically converts swapchains into HDR formatted ones if running with HDR enabled as the output swapchain to the display regardless. Gamescope's ITM support supplies the extra tonemapping for SDR content outside of that.

Additionally, Gamescope doesn't automatically use the "-hdr-itm-enable" flag when running with SteamOS. Gamescope always tonemaps SDR content while running in HDR, however the tonemapping isn't to "upscale" the SDR content, but instead to preserve how the SDR content looks as-is while outputting in HDR (while also potentially increasing brightness of the content uniformily using the "-hdr-sdr-content-nits" flag, only for external hdr displays). the "-hdr-itm-enable" flag uses inverse tone-mapping for SDR content, which means it tonemaps SDR content in a way that takes advantage of the expanded range provided in HDR.

[Lawstorant]

@isaboll1 I think you are confusing the terms. Tone mapping always refers to HDR -> SDR conversion and Inverse tone mapping always refers to SDR -> HDR conversion. It doesn't "enhance" anything

[isaboll1]

@isaboll1 I think you are confusing the terms. Tone mapping always refers to HDR -> SDR conversion and Inverse tone mapping always refers to SDR -> HDR conversion. It doesn't "enhance" anything

You're right in the context of the general terms. At any rate, the "-hdr-itm-enabled" flag is used particularly to enhance SDR content displayed through inverse tone-mapping, to take advantage of the expanded range akin to "AutoHDR", since gamescope already does the output to HDR on it's own. Gamescope's default doesn't use that flag for SteamOS.

(I was just using "Tone mapping" in the general sense, to map colors from one set to another)

[Lawstorant]

@isaboll1 You sure? It literally is a switch that just enables ITM. Probably a leftover as it's not needed for ITM to work and can break VRR

[isaboll1]

I'm sure, because the question was asked before https://discord.com/channels/853130811581530142/1049377844935008416/1156267126911418470

[isaboll1]

The HDR ITM stuff was an additional feature that wasn't specifically planned for the HDR support in SteamOS, and isn't used when HDR is enabled by default. Gamescope's default HDR support does use a form of tonemapping (or "inverse tone mapping"), by default, but it's separate from what's done when that switch is enabled, and is only used to make SDR stuff look normal. That process is outlined in the docs for the "Steam Deck Display Pipeline".

The "hdr-itm-enabled" flag on the other hand, is made to replicate what's done with AutoHDR, and "makes SDR apps look like real HDR". It was added by a different developer at the time as an optional thing.

https://github.com/ValveSoftware/gamescope/pull/751#issue-1535653106

[Lawstorant]

Thanks! That's interesting and seems like something that should probably be removed as it's naming is confusing and it doesn't even work properly.

[SaltyBet]

@isaboll1, thanks for the explanation/confirmation of the expected functionality (Discord's opaqueness notwithstanding...).

From what I understand, then:

• HDR ITM is not enable by default in Gamescope, and
• per #1034, HDR ITM does not even seem to work when trying to explicitly enable it.

So, basically, we have the following options for HDR ITM functionality:

• Windows:
  • Auto-HDR
  • ReShade HDR shaders
  • RTX HDR
  • Special K HDR Retrofit (both SKIF and DLL injection methods)
• SteamOS/derivatives:
  • Special K HDR Retrofit (DLL injection method only)

Kind of sad, but at least there is 1 option...

So, maybe, in the meantime, Valve team can work on making built-in HDR ITM usable on Gamescope... 🤞

Anyways, nowhere to go from here right now, so I'll close this Issue/Question.

Cheers.

[isaboll1]

I believe the hdr-itm flag was fixed from the time I made that issue. In my personal use of gamescope with that flag enabled currently, games with native HDR disabled look similar to how they do with in-game HDR enabled (except less accurate, which makes sense. Tested with Ratchet and Clank), and there was this issue created later (now closed) regarding color corruption seen when the feature was enabled, which would mean it is actually working and has an effect on the swapchain (as if it was non functional, the user wouldn't have seen any difference regardless if it was enabled or not). I don't experience color corruption on my end, and their issue was closed. I'm closing my issue due to noticing a similarity between SDR and HDR content with the itm flag enabled, although this is not on a Steam Deck

[isaboll1]

@SaltyBet even though the issue is closed, I can provide an answer to the original question. You can add the itm flag to the "gamescope-session" file in the "bin" folder manually to enable the support, but i think it would only be noticable if you're using the preview version of SteamOS since that has newer versions of Gamescope, and I can notice an effect with that.

I think there may be a way to define this stuff without risk like that in the future due to the new Lua config stuff being added. Currently, any update will wipe that change

[SaltyBet]

@isaboll1, thanks for the feedback.

The /usr/bin/gamescope-session script seems to be read-only on SteamOS; that's why I originally posted this Issue/Question, to confirm if there was another way.

I'll try testing SteamOS after it comes out of preview; ideally, it should include some kind of per-game toggle, to select what kind of ITM to use: SDR-like (default) or HDR-like (expanded range).

Coincidentally, the only other way to "inject" HDR that was working on SteamOS, is now broken on latest Proton stable.

[sjohal21]

Replying to https://github.com/ValveSoftware/gamescope/issues/1487#issuecomment-2380393562

I think there might be an issue with your setup then. Running latest release of Gamescope on Fedora 41 on an AW3423DWF connected to an AMD 7900 XTX GPU (so not a Steam Deck too) and there is a strong difference between ITM enabled and disabled, as the monitor goes all the way to ~1000 nits peak brightness.

[Lawstorant]

I might try it now. Maybe it no longer destroys VRR? Between ITM and VRR I strongly prefer to have the latter