If you’re talking browsers it’s poor. But HDR on displays is very much figured out and none of the randomness that you get with SDR with user varied gamma, colorspace, and brightness. (That doesn’t stop manufacturers still borking things with Vivid Mode though).

You can pack HDR in JPG/PNG/WebP or anything that supports a ICC and Chrome will display it. The actual formats that support HDR directly are PNG (with cICP) and AVIF and JpegXL.

Your best bet is use avifenc and translate your HDR file. But note that servers may take your image and break it when rescaling.

Best single source for this info is probably: gregbenzphotography.com/hdr/

DuckDNS has long enough latency (over 2000ms) where Google Assistant can’t connect. I moved to FreeDDNS and my Home Assistant issues went away.

Reference: community.home-assistant.io/t/…/140?page=7

Silksong might be one of the “easiest” ones if I ever did a RenoVK. Basically, you check the swapchain size, and any 8bit texture that the game tries to build that matches that resolution gets upgraded to 16bit. And done. That alone will get the SDR layers to stop banding. (We actually do 16bit float because we want, but 16uint would be a perfect, less problematic banding fix).

I might look at vkBesalt. That’s basically how ReShade ended up building an addon system. You have to be able to inject shaders, create textures, and monitor backbuffer to do postprocess. Instead of just doing it at the end, it allows us to listen for render events and act accordingly. That’s the basis for most out mods. Every game will use DX/GL/VK commands so it’s much easier to tap into that instead of compiled CPU code.

I wrote the RenoDX mod if you’re talking about that. I don’t think there’s anything like Reshade’s addon system for Linux games. We’ve done OpenGL and Vulkan mods but that still relies on intercepting the Windows implementation. Silksong primarily needs a 16bit float render to solve most of its banding, but not sure how you can do the same on Linux.

We avoid per-game executable patching intentionally, but sounds like that would be the best choice here. Getting the render to 16bit would solve most banding, but you’d still need to replace shaders if your goal were HDR (or fake it as a postprocess with something like vkBasalt).

We would have also accepted a bluer yellow.

The point is to show it’s uncapped, since SDR is just up to 200 not. It’s not tonemapped in the image.

But, please, continue to argue in bad faith and complete ignorance.

From understanding my old GameBoy that had 4 AA batteries in alternating rotation, that had 6V (1.5V each battery). Chaining positive and negative together increased the voltage.

Since this has them pointing both up, it’s just 1.5V but it’s as if you put a half sized battery.

Basically, the same, just less amperage because of a smaller battery (if compared to 2 of the same).

tl;dr: same, but half capacity.

He should take that kangaroo to court!

This is a trash take.

I just wrote the ability to take a DX9 game, stealthy convert it to DX9Ex, remap all the incompatibility commands so it works, proxy the swapchain texture, setup a shared handle for that proxy texture, create a DX11 swapchain, read that proxy into DX11, and output it in true, native HDR.

All with the assistance of CoPilot chat to help make sense of the documentation and CoPilot generation and autocomplete to help setup the code.

All in one day.

(something something) incredibly proud of yourself.