I still don't really understand this gamma business. Say I wanted to make a program that displays the full range of colours in a gradient. The intuitive way to do this would be to use some constant delta between subsequent colours - this would give you Linear RGB, right?blargg wrote:After an informal test of displaying a gray ramp, it looks as though the SNES encodes the video signal linearly, thus resulting in a gamma applied to the raw RGB values by the display. So SNES images in an emulator should look more or less correct on a PC without the emulator doing any gamma correction. In retrospect, this is the only approach that makes sense. Like with the PC, you want the RGB values in the framebuffer to have gamma applied by the display device.blargg wrote:The question for the SNES is what gamma it applies when encoding composite and s-video outputs (and perhaps RGB). If it uses none, then proper conversion to the linear RGB values of the light leaving the display's surface requires applying a 2.5 gamma. If the SNES uses 0.5, then conversion requires applying a 1.25 gamma.
This one.3. SNES applies no gamma when encoding video. So we need to apply a 2.5*0.45 = 1.125 gamma.
Now say I wanted to display this using Direct3D, would I need to use the D3DPRESENT_LINEAR_CONTENT flag in the presentation parameters to get it to display correctly? (as opposed to the case of say, displaying a picture taken with a digital camera)
Now say I was to make a sprite in MS paint. My monitor is calibrated to use a gamma of 2.2, which would then be applied to the linear RGB values used in my image and influence my choice of colours. I save the image as a BMP and display it in my game, which uses Direct3D. Would I need to use the D3DPRESENT_LINEAR_CONTENT flag to get it to display the same way it did in paint? After all, the colour values I used were linear. Or am I misunderstanding this flag altogether?
Edit: information on the flag can be found here.