This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Implementation of colorsys.rgb_to_yuv and vice versa
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.11
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: eric.araujo, petr.viktorin, terry.reedy, thomas.stolarski, vstinner
Priority: normal Keywords: patch

Created on 2021-11-10 00:06 by thomas.stolarski, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 29512 closed thomas.stolarski, 2021-11-10 00:21
Messages (12)
msg406067 - (view) Author: Thomas Stolarski (thomas.stolarski) * Date: 2021-11-10 00:06
Since the implementation of `rgb_to_yiq` roughly 30 years ago now, the advent of HDTV has resulted in most broadcasting and video processing having moved towards Rec 709 (or BT.709).

While I know colorsys has been on the chopping block for a while, it seemed a little silly that what is now arguably the most common color space used in video editors isn't available as part of this module, despite being a matrix mapping like much of the others.

YUV is a bit more contentious on its definition than YIQ is, but it is still widely used to refer to Rec 709 and this is the ATSC standardization for HDTV.

I've written a PR for both conversions and will add it to this ticket once it's up.
msg406247 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2021-11-12 22:23
A link to an authoritative reference with the formulas would be necessary to merge this.  I inquired of pydev list whether improvement is allowed.
msg406252 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-11-12 23:04
> A link to an authoritative reference with the formulas would be necessary to merge this.

The PR says: "ATSC BT.709 standard constants".

For exmaple, I found:

"When encoding Y’CBCR video, BT.709 creates gamma-encoded luma (Y’) using matrix coefficients 0.2126, 0.7152, and 0.0722 (together they add to 1)."
msg406263 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2021-11-13 00:50
On pydev, Guido said "There was talk of deprecating colorsys, but PEP 594 now lists it under "modules to keep".  Victor, do you know enough to review?
msg406540 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2021-11-18 15:29
I argued for keeping colorsys: RGB/HLS/HSV are useful in several fields. Colorsys is a nice low-power battery to have around for e.g. picking a color for highlighting any kind of output.

YIQ is the odd one out: it describes actual color, rather than instructions for a monitor. I think that if you need YIQ, YUV, CMYK, sRGB, XYZ or Lab, you should reach for a more specialized library. In other words, I don't see YIQ as an example to be followed.
msg406544 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-11-18 16:01
The GIMP image editor uses which supports tons of formats and supports color spaces, ICC profiles, etc.

I would also prefer to keep colorsys simple and so not support ICC profiles for example.

YUV is a common color encoding system. It's used by the JPEG image format and MPEG video format for example.

In terms of complexity and maintenance burden, supporting YUV (PR 29512) sounds reasonable me.

If colorsys is limited to RGB/HLS/HSV, I'm not sure if it is useful. Nowadays, there are more color formats which are getting popular. If they are not supported, maybe it's better to just remove the module. I don't know.

Well, I don't have a strong opinion on adding YUV support or not.
msg406845 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2021-11-23 15:25
> YUV is a common color encoding system. It's used by the JPEG image format and MPEG video format for example.

As far as I understand it, the YUV/RGB conversion used by JPEG is not the same as the one used by MPEG, and neither of those is the Rec 709 YUV proposed here.

YUV is used in video production and photography. If you need to work with it, you most likely need some kind of precise color matching. If colorsys implements the wrong one *for you* (even if it's the most commonly used one, and what HDTV uses), then the stdlib has failed you.

Meanwhile, RGB/HLS is used by Web designers writing CSS, GUI authors giving you a big green button to click, or color pickers for your avatar's hair. They're designing for uncalibrated monitors. *That* is the target audience for colorsys.
The image libraries these people use to read JPGs invariably convert to RGB and throw away any precise color information, which is meaningless on uncalibrated monitors.

I cannot see a use case for YUV in colorsys that doesn't also require a more complex image processing library. It's that library that should provide the necessary colorspace conversions, depending on if it's dealing with JPEG or MPEG or HDTV.

But please point out my mistakes and clear my doubts!
msg406854 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-11-23 16:46
Ok, let's reject this feature and restrict colorsys to simple color spaces which don't require profiles.
msg406855 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-11-23 16:47
You can write your own module on PyPI with more advanced features if you want to extend colorsys ;-)
msg406864 - (view) Author: Thomas Stolarski (thomas.stolarski) * Date: 2021-11-23 17:07
I figured this would probably be the case, but since YIQ also requires a profile (and the FCC one it implements is pretty weird for digital work), I thought I'd give it a shot anyway.

Would it be worth moving the test/formatting changes over to a different ticket or should we just leave them?
msg406865 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2021-11-23 17:33
I think that there’s no need to change the existing tests.
The CPython project prefers to not do tiny improvements for their own sake.
msg406867 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2021-11-23 17:33
Thank you for suggesting the improvement and working on a PR nonetheless!
Hope the experience can be useful for other tickets in the future.
Date User Action Args
2022-04-11 14:59:52adminsetgithub: 89933
2021-11-23 17:33:56eric.araujosetmessages: + msg406867
2021-11-23 17:33:12eric.araujosetnosy: + eric.araujo
messages: + msg406865
2021-11-23 17:07:15thomas.stolarskisetmessages: + msg406864
2021-11-23 16:47:14vstinnersetmessages: + msg406855
2021-11-23 16:46:20vstinnersetstatus: open -> closed
resolution: rejected
messages: + msg406854

stage: patch review -> resolved
2021-11-23 15:25:20petr.viktorinsetmessages: + msg406845
2021-11-18 16:01:27vstinnersetmessages: + msg406544
2021-11-18 15:29:44petr.viktorinsetnosy: + petr.viktorin
messages: + msg406540
2021-11-13 00:50:27terry.reedysetmessages: + msg406263
2021-11-12 23:04:35vstinnersetnosy: + vstinner
messages: + msg406252
2021-11-12 22:23:01terry.reedysetnosy: + terry.reedy
messages: + msg406247
2021-11-10 00:21:09thomas.stolarskisetkeywords: + patch
stage: patch review
pull_requests: + pull_request27763
2021-11-10 00:06:44thomas.stolarskicreate