Artifacts from non-gamma-aware interpolation
 

When images are scaled with bilinear filtering, the resulting image can have artifacts if gamma isn't taken into account. Some patterns appear darker than they should and certain colour transitions can result in a darker border around objects.

You might think a 50:50 blend of two colours is easy to calculate; an equal blend of black (R:G:B 0:0:0) and white (255:255:255) is 128:128:128. However on a normal monitor 128:128:128 is significantly darker than half white brightness. Half-white is roughly 187:187:187 for the commonly-used assumed gamma of 2.2 (sRGB).

To show what I mean, I have uploaded an archive with some images and a config/HDF to The Zone and:
Load the config, boot Test_images.adf. In Filter settings toggle between point and bilinear. Notice darker edges around red-on-green shapes with bilinear filtering. Click left button to move to next image. The third image is a chequerboard pattern. Notice the overall image brightness drops with bilinear filtering.

At least for Direct3D, it could/should be easy to fix this since you can tell Direct3D to do gamma correction when it reads from the texture.

Gamma (Direct3D 9)
"Texture content is often stored in sRGB format. Traditionally, pixel pipelines assumed the colors to be linear so blending operations were performed in linear space. However, since sRGB content is gamma corrected, blending operations in linear space will produce incorrect results. Video cards can now fix this problem by undoing the gamma correction when they read any sRGB content, and convert pixel data back to the sRGB format when writing out pixels. In this case, all operations inside the pixel pipeline are performed in the linear space."

For Direct3D 11, see Converting data for the color space (MSDN):
"To ensure color accuracy in the pipeline
1. If a texture has sRGB content, ensure the ShaderResourceView has the _SRGB format modifier so when you read from the ShaderResourceView into the shader, you convert the texture content from gamma 2.2-corrected color space to linear color space.
2. Ensure the RenderTargetView also has the _SRGB format modifier so the shader output values are gamma converted."


Some more info on issues with interpolating colours incorrectly:
Computer Color is Broken (Computer Color is Broken, YouTube video)
http://www.realtimerendering.com/blo...a-problematic/
http://tavmjong.free.fr/SVG/COLOR_INTERPOLATION/, in particular this image. (The sad faces are blended in sRGB colour space. Notice the darker border around the red-on-green face.)

But does level 10 hardware support DXGI_FORMAT_B8G8R8A8_UNORM_SRGB or should it be only used if 11.0 level? Everyone seems to confuse 11 of Direct3D11 and feature level 11..

winuae.7z updated, image looks more brighter now. EDIT: wait a bit, it wasn't that simple..

(Interestingly enough, I have been playing with my new JVC X7900 projector and testing different custom gamma curves so that UHD HDR look as great as possible but I never thought about PC world gamma and how it is supposed to work)

EDIT2: MSDN article is useless as always. Trying to use SRGB in RenderTargetView() results in very overexposed image. ShaderResourceView fails with:

I think even feature level 9_1 hardware might support it. Hardware Support for Direct3D 10Level9 Formats mentions DXGI_FORMAT_R8G8B8A8_UNORM_SRGB being supported (note the different RGB component order though). And Format Support for Direct3D Feature 10Level9 9.1 Hardware shows hardware support required for B8G8R8A8_UNORM, B8G8R8A8_UNORM_SRGB, B8G8R8X8_UNORM, B8G8R8X8_UNORM_SRGB.

You can create your texture with format DXGI_FORMAT_B8G8R8A8_UNORM then specify the_SRGB format modifier. But do things work better (i.e. no error message) if you instead specify an _SRGB format when you create the texture/buffer?

It sounds like something is correcting/converting one way (e.g. when texture is read) but not the other (when data written to render target)? With point filtering (not bilinear), telling Windows texture data is sRGB should make no difference to the output image.

Did you have more luck with D3D 9 mode (D3DSAMP_SRGBTEXTURE)?

If you end up having to (or wanting to) perform correction manually with a shader, this blog post gives some formulae for very close approximations.

I won't touch D3D9 code anymore, it is frozen, only fixes are allowed.

Would you be able to upload (or create a fork on Github?) the not-properly-working code you used there? I can take a look and see if anything looks obviously wrong.