rcdrone
New Member
Apologies for inaccuracies. I'm still trying to learn about color theory on-the-fly myself.
1. It looks like YUV 601/709 colors aren't being transformed into sRGB space.
Currently:
601: YUV(601)_gamma(601) -> [YUV_to_RGB(601)] -> RGB(601)_gamma(601) -> [nop?] -> RGB(sRGB)_gamma(sRGB)
709: YUV(709)_gamma(709) -> [YUV_to_RGB(709)] -> RGB(709)_gamma(709) -> [nop?] -> RGB(sRGB)_gamma(sRGB)
What I think should happen:
601
YUV(601)_gamma(601) -> [YUV_to_RGB(601)] -> RGB(601)_gamma(601) -> [gamma_to_linear(601)] -> RGB(601)_linear -> [601_to_XYZ] -> XYZ_linear -> [XYZ_to_sRGB] -> RGB(sRGB)_linear -> [linear_to_gamma(sRGB)] -> RGB(sRGB)_gamma(sRGB)
709
YUV(709)_gamma(709) -> [YUV_to_RGB(709)] -> RGB(709)_gamma(709) -> [gamma_to_linear(709)] -> RGB(709)_linear -> [709_to_XYZ] -> XYZ_linear -> [XYZ_to_sRGB] -> RGB(sRGB)_linear -> [linear_to_gamma(sRGB)] -> RGB(sRGB)_gamma(sRGB)
Note: [709_to_XYZ] & [XYZ_to_sRGB] cancel each other out.
I suppose aliasing the colors as sRGB directly is a form of tonemapping that avoids clipping colors that are out of sRGB range, but the drawback is that colors that would be in range are not displayed accurately.
2. D3D11 SRV and RTV formats aren't tagged as SRGB where appropriate, so texture-sample filtering and alpha blending are going to be performed in gamma space rather than linear space. (I did not look to see if the OpenGL path has the same issue.) NOTE (2018/06/18): Never mind. I've heard linear space is not good for 2D resampling because it makes the images appear brighter than they should. CIELAB space may be better, but gamma is probably close enough.
3. I'd like to have 601 w/D93 white point for an NTSC-J look, but that's not an option.
1. It looks like YUV 601/709 colors aren't being transformed into sRGB space.
Currently:
601: YUV(601)_gamma(601) -> [YUV_to_RGB(601)] -> RGB(601)_gamma(601) -> [nop?] -> RGB(sRGB)_gamma(sRGB)
709: YUV(709)_gamma(709) -> [YUV_to_RGB(709)] -> RGB(709)_gamma(709) -> [nop?] -> RGB(sRGB)_gamma(sRGB)
What I think should happen:
601
YUV(601)_gamma(601) -> [YUV_to_RGB(601)] -> RGB(601)_gamma(601) -> [gamma_to_linear(601)] -> RGB(601)_linear -> [601_to_XYZ] -> XYZ_linear -> [XYZ_to_sRGB] -> RGB(sRGB)_linear -> [linear_to_gamma(sRGB)] -> RGB(sRGB)_gamma(sRGB)
709
YUV(709)_gamma(709) -> [YUV_to_RGB(709)] -> RGB(709)_gamma(709) -> [gamma_to_linear(709)] -> RGB(709)_linear -> [709_to_XYZ] -> XYZ_linear -> [XYZ_to_sRGB] -> RGB(sRGB)_linear -> [linear_to_gamma(sRGB)] -> RGB(sRGB)_gamma(sRGB)
Note: [709_to_XYZ] & [XYZ_to_sRGB] cancel each other out.
I suppose aliasing the colors as sRGB directly is a form of tonemapping that avoids clipping colors that are out of sRGB range, but the drawback is that colors that would be in range are not displayed accurately.
2. D3D11 SRV and RTV formats aren't tagged as SRGB where appropriate, so texture-sample filtering and alpha blending are going to be performed in gamma space rather than linear space. (I did not look to see if the OpenGL path has the same issue.) NOTE (2018/06/18): Never mind. I've heard linear space is not good for 2D resampling because it makes the images appear brighter than they should. CIELAB space may be better, but gamma is probably close enough.
3. I'd like to have 601 w/D93 white point for an NTSC-J look, but that's not an option.
Last edited: