sRGB EOTF incorrect value for linear section?

[Myndex]

sRGB EOTF threshold error?

In colour/colour/models/rgb/transfer_functions/srgb.py
in the function "def oetf_reverse_sRGB(V):"
V <= oetf_sRGB(0.0031308),

I was thinking this was an incorrect value till I parsed the code more... Now I see that you're using the oetf_sRGB to create the "inverse"... the specified value per ISO spec is 0.04045 (or the unrounded 0.0404482) ... as a thought the following would reduce overhead wouldn't it? (Or is this solving some other problem? Perhaps a comment indicating the reasons as at first glance it look like the wrong threshold value is in place).

L = np.where( V <= 0.0404482, V / 12.92, spow((V + 0.055) / 1.055, 2.4), )

[KelSolaar]

Hi @Myndex,

The draft of IEC 61966-2-1:1999 which is generally available to the public gives 0.0031308 for the OETF:

Note that it also gives 0.04045:

The former being more precise than the later, it is the one we use in our implementation, and for the reverse, as you noticed it, we compute its exact value for round-tripping reasons:

>>> import colour
>>> colour.models.oetf_sRGB(0.0031308)
0.040449935999999999

[Myndex]

Hi @KelSolaar Thank you for clarifying, that makes sense — sorry I brought it up, just that I have been running into a lot of "wrong values" relating to sRGB elsewhere and trying to be proactive. Cheers.

Though I do have an additional question, I am climbing the learning curve for Python, wouldn't it be more efficient to simply state the constant like this:

        L = np.where(
            V <=  0.040449936,
            V / 12.92, .....

Instead of calling the function each time?

        L = np.where(
            V <= oetf_sRGB(0.0031308),
            V / 12.92, .....

Thank you

Refs:
https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2380-2-2018-PDF-E.pdf

[KelSolaar]

@Myndex : You are welcome!

wouldn't it be more efficient to simply state the constant like this:

Yes but the precision tradeoff is not worth it, especially because the performance hit is meaningless once you start pushing a lot of data through the definition. I don't know if you are familiar with Numpy but if not let me explain:

Assuming you are processing an image, a naive function would loop over each pixel, one by one and painstakingly applying the function onto it. In this case the price for oetf_sRGB(0.0031308)
is indeed high, and the value should be cached. However, because Numpy is about vectorisation and avoiding at all costs expensive Python loops, if the code is written to support it, you can actually pass your entire image at once to the function. Here is some code to illustrate the concept:

def naive():
    import numpy as np
    from colour.models import oetf_reverse_sRGB

    a = np.random.random([512, 384, 3])

    for j in range(a.shape[1]):
        for i in range(a.shape[0]):
            oetf_reverse_sRGB(a[i, j, ...])


def vectorised():
    import numpy as np
    from colour.models import oetf_reverse_sRGB

    a = np.random.random([512, 384, 3])

    oetf_reverse_sRGB(a)


def oetf_once():
    from colour.models import oetf_sRGB

    oetf_sRGB(0.0031308)


if __name__ == '__main__':
    import timeit
    print(
        timeit.timeit("naive()", number=3, setup="from __main__ import naive"))
    print(
        timeit.timeit(
            "vectorised()", number=3, setup="from __main__ import vectorised"))
    print(
        timeit.timeit(
            "oetf_once()", number=3, setup="from __main__ import oetf_once"))

# 30.7470990360016
# 0.13231570900825318
# 0.00013505299284588546

The vectorised version is over 230 times faster, you pay the price of oetf_sRGB(0.0031308) once and it only takes 0.0001351 seconds to run!

[Myndex]

Thank you @KelSolaar — I really appreciate the quick tutorial on numpy !

[KelSolaar]

You are welcome! I will close this one but feel free to ask any more questions!