ebiten: add gamma/degamma option

[hajimehoshi]

Operating System

• Windows
• macOS
• Linux
• FreeBSD
• OpenBSD
• Android
• iOS
• Nintendo Switch
• PlayStation 5
• Xbox
• Web Browsers

What feature would you like to be added?

I propose to add these members:

type NewImageOptions struct {
    // ApplyDegamma indicates whether [NewImageFromImageWithOptions] degammas the input image color values,
    // assuming the input image color values are non-linear sRGB,
    // so that the image color values on GPU will be linear sRGB.
    //
    // ApplyDegamma is useful if you want faithful rendering calculations and results.
    // See also [RunGameOptions.ApplyGamma].
    //
    // The default (zero) value is false, which means the color values are not converted.
    ApplyDegamma bool
}

type RunOptions struct {
    // ApplyGamma indicates whether the shader for the final rendering applies gamma function to the color values,
    // assuming the color values on GPU are linear sRGB and the expected output color values are non-linear sRGB.
    //
    // ApplyGamma is useful if you want faithful rendering calculations and results.
    // See also [NewImageOptions.ApplyDegamma].
    //
    // The default (zero) value is false, which means the color values are not converted.
    ApplyGamma bool
}

See also #3313.

In v3, I might change the default value to do gamma/degamma by default.

Why is this needed?

In order to get correct rendering results.

[hajimehoshi]

We should not assume sRGB as the GPU internal format, since Ebitengine can choose color space. In this case, NewImageFromImage might need to convert non-linear sRGB to linear P3. Hmm

[tinne26]

Does this only affect internal shader color calculations? (e.g., being able to skip a manual linearization step on shaders like https://github.com/erparts/go-shapes/blob/3e574ba7cf801dbc2bb1b994f6e1c1815744160f/shaders/oklab_shift.kage#L25)? Or does it affect rendering results in general? Because I was testing with different images and I couldn't appreciate any difference between multiple image viewers, browsers and Ebitengine.

[hajimehoshi]

e.g., being able to skip a manual linearization step on shaders

Does this assume the input is non-linear RGBs?

Or does it affect rendering results in general?

Yes when alphablending images. Alphablending should work only on linear RGBs.

[hajimehoshi]

So, as your shader assumes that the texture color is in non-linear sRGBs, this seems 'wrong' as the texture format should be linear sRGB (or linear P3, maybe?). The current Ebitengine doesn't distinguish them so non-linear sRGB values are directly passed to a texture without conversion, then your shader accidentally works, but this would technically be wrong, and at the same time, Ebitengine is also wrong for not doing conversion. That's the motivation to introduce gamma/degamma options to make things correct.

[hajimehoshi]

IMO, WritePixels doesn't have to convert the color space. It is possible to give an option for conversion.

Fill specifies a color.Color, but the color space is ambiguous. This also needs an option.

[hajimehoshi]

ReadPixels also requires an option for conversion.

[tinne26]

your shader assumes that the texture color is in non-linear sRGBs, this seems 'wrong'

To be honest, I didn't assume anything, I tested, I saw I had non-linear sRGB, then I applied the conversion. If I thought shaders must receive linear sRGB, I'd have opened an issue for it. Having the option to control it from Ebitengine's side would be nice, but it's not something I have a particular opinion about. I manually apply gamma correction in tons of shaders whenever this is critical to quality. I thought that GLSL also received non-linearized values by default, so I didn't find it strange at all.

[hajimehoshi]

Having the option to control it from Ebitengine's side would be nice, but it's not something I have a particular opinion about.

In the ideal world, all texture data should be linear. The problem is there is no good way to automatically detect whether the input is non-linear or linear, so the developer has to specify the input format explicitly. Also, there is backward compatibility issue. Thus, explicit specifying would not change even in v3.

I manually apply gamma correction in tons of shaders whenever this is critical to quality.

As long as the 'explictly-specifying the input format' way works, your shader still works. The default value might be changed though. However, if the source image is an offscreen image, which is likely a linear RGB value in the future, your shader might not work well.

I thought that GLSL also received non-linearized values by default, so I didn't find it strange at all.

Me neither until recent :-) GLSL and other libs didn't seem to have any assumption for texture data. Go is also problematic since it doesn't distinguish linear and non-linear RGBA. IIUC non-linear premultiplied alpha doesn't make sense.

OpenGL has GL_SRGB8_ALPHA8 which degamma a texture data automatically when picking a color at a shader, so the intention should be that shaders should treat linear data. (By the way,GL_SRGB8_ALPHA8 is not available for Ebitengine as this is only for a 'source' image and not an offscreen image, and Ebitengine delibarately mixes a source image and an offscreen).

[hajimehoshi]

See also golang/go#11420