# Should JPEG encoding take into account gamma?

When an image is encoded using JPEG, the RGB pixels are first encoded into YUV, and then the UV channels are downsampled. Before actually doing the DCT and encoding the coefficients, JPEG doesn't gamma correct the Y channel. Is this correct? Shouldn't we determine the DCT coefficients that will most affect our viewed result?

• I dont know but it certainly does make sense not to gamma correct. – joojaa Aug 22 '15 at 12:27
• I'm not posting this as an answer since I'm not confident in it, but human vision's perception of brightness is not linear. In fact, sRGB does a quite good job of compensating for that and giving the most precision in the areas that matter. So you might find that gamma correcting before compressing luma may actually yield worse results. – yuriks Aug 22 '15 at 19:55
• AFAIK, video standards assume R'G'B', ie. a non-linear colour space, when applying the 3x3 colour transforms to/from YCbCr. In an application such as video where one wants to maximise quality per bit, it doesn't make sense to use linear. I think sections 27 and 29 of Charles Poyton's Color FAQ express it more clearly: poynton.com/notes/colour_and_gamma/ColorFAQ.html#RTFToC27 – Simon F Aug 24 '15 at 7:54
• "Video demystified" also says: "YCbCr is the color space originally defined by BT.601, and now used for all digital component video formats. .... The technically correct notation is Y'Cb'Cr' since all three components are derived from R'G'B'." – Simon F Aug 24 '15 at 8:07
• The gamma exponent is stored in JPEG exif data. most software totally ignore it. but you can assume than after decoding a jpeg its already in gamma space so there is no conversion to do before sending the rgb value on the display buffer. – v.oddou Sep 15 '15 at 2:23

According to Wikipedia (insert standard disclaimer RE accuracy):

JPEG does not define which color encoding is to be used for images. JFIF defines the color model to be used: either Y for greyscale, or YCbCr as defined by CCIR 601.

YCbCr is a non-linear format. As I mentioned earlier, "Video Demystified" states:

"YCbCr is the color space originally defined by BT.601, and now used for all digital component video formats. .... The technically correct notation is Y'Cb'Cr' since all three components are derived from R'G'B'."

and Charles' Poynton's Colour FAQ states

Video systems approximate the lightness response of vision using R'G'B' signals that are each subject to a 0.45 power function.

With compression we are after the best visual representation per bit and, as the eye is non-linear in approximately this way, it makes sense to use non-linear representations.

• From these details, as I understand it, JPEG expects the input RGB values to be encoded in a way that the display will apply a power function upon display. In order to recreate those specific RGB values, they should not be corrected prior to encoding. – Mokosha Sep 14 '15 at 23:06
• The trouble with stating it like that is that it's a bit ambiguous. We should probably state that, if your "RGB" data is, in fact, R'G'B' (and let's assume sRGB falls into that category) then you shouldn't modify the values before applying the R'G'B'=>YCbCr matrix. If, however, the data has, say, been computed with a renderer (so possibly linear), been processed using downscaling (which should be done in linear space) or, say, captured (and cleaned up) with a CCD (which I think is linear), then it has to be remapped prior to JPEG compression. – Simon F Sep 15 '15 at 8:24

The short answer is "no", for reasons covered in Alvy Ray Smith's memo, Gamma Correction. Gamma is not about nonlinearity in human perception, it's about nonlinearity in display devices (and, I suppose, acquisition devices too).