Talk:sRGB

The amendment also recommends a higher-precision XYZ to sRGB matrix using seven decimal points

That is not what the cited reference actually says. It says that you should use the inverted matrix from (F.7) to sufficient precision. (Actual text: ‘enough accuracy decimal points’ – Points? Seriously? This is an official standard, but it reads like a YouTube comment.) It then goes on to say that for 16 bits per channel 7 decimal places should be enough. (Which seems fair given that 16 bits is enough for just under five digits, although at first glance (F.7) itself seems to be rounded to insufficient precision for 16 bits...) Why don't people read the references they cite? 92.67.227.181 (talk) 17:45, 1 July 2022 (UTC)

"seems to be rounded to insufficient precision for 16 bits.."

Seems? Well, check it out with a brute force. Name for decimal point and numbers after it are defined by its insane ammount of its own ISO standards. Valery Zapolodov (talk) 02:02, 29 September 2022 (UTC)

You are saying it as if I am lying. This is from the standard, https://imgur.com/a/1FMB3sO 2A00:1370:8184:6AD9:F9BC:A3B4:30C7:B031 (talk) 04:20, 29 September 2022 (UTC)

Lighten up. We can discuss different interpretations of sources with anyone being interpreted as making accusations of lying. Dicklyon (talk) 04:36, 29 September 2022 (UTC)

"Computing the transfer function"

I don't think the re-written version is helpful, the previous version seemed more clear to me at least, though this may be it was what I was more used to reading. The new version, and the use of uppercase seems less clear to me. Myndex talk   04:23, 3 July 2022 (UTC)

This whole thing is quite not verifiable since the source is not available in public or on libgen. I mean it sounds logical and BT.2020 says the same thing about this, solving a pair of equestions... I mean "Colour Engineering: Achieving Device Independent Colour" Valery Zapolodov (talk) 01:59, 29 September 2022 (UTC)

Meanwhile these authors already wrote a new book! And I still do not know where to find the book Colour Engineering. https://www.wiley.com/en-ie/Fundamentals+and+Applications+of+Colour+Engineering-p-9781119827184 Valery Zapolodov (talk) 15:01, 9 August 2023 (UTC)

Contradictory formulas?

The formulas for the $\gamma (u)$ in the section Transfer function ("gamma") do not agree with those in the From CIE XYZ to sRGB section below. It seems that part of the problem is that the formulas in the DRAFT of the standard (public) differ the OFFICIAL standard (paywalled). Would please someone with access to the latter put the correct formulas, with every parameter rounded (or not) exactly as in that document, and get rid of the incorrect ones? In name of the world wide world, thanks... Jorge Stolfi (talk) 21:02, 17 December 2024 (UTC)

Can you explain more clearly which part seems contradictory? The section § Transformation should be correct here. I don't see any contradiction between that and the earlier section § Transfer function ("gamma"). –jacobolus (t) 21:24, 17 December 2024 (UTC)

The contradictions were actually confusion between the historical and current specs of the standard. I revised the whole page, separating the two. Please have a look and let me know if I made any mistakes. --Jorge Stolfi (talk) 10:12, 18 December 2024 (UTC)

I don't have time to check the details right now, but if I remember I'll take a look when I get the chance. Why are we removing the sentence "sRGB essentially codifies the display specifications for the computer monitors in use at that time, which greatly aided its acceptance" from the lead section? It seems like useful basic context for readers. –jacobolus (t) 17:27, 18 December 2024 (UTC)

This looks incorrect to me: "Part of the confusion is due to the value of $\Gamma$ having changed from 2.2 in the initial draft (which is widely available) to 2.4 in the final document (which is paywalled)". If this is referring to Anderson & al. 1996, you can read it directly here at imaging.org. Compare to color.org/sRGB.pdf which should be an accurate summary of the final spec. –jacobolus (t) 17:27, 19 December 2024 (UTC)

If that is the correct paper, it definately says 2.4 in the formula. I agree this is claim is certainly wrong. There was and is confusion between the 2.4 used in the formula and the fact that the closest match pure exponential curve has a gamma of 2.2, but this was never misprinted in any papers imho.Spitzak (talk) 17:13, 20 December 2024 (UTC)

No, 2.2 was never EVER USED IN sRGB. sRGB was originally called NIF RGB. And even back then it was using 0.42 ~~ 1/2.4 gamma (see page 55): http://www.graphcomp.com/info/specs/livepicture/fpx.pdf Valery Zapolodov (talk) 01:42, 25 December 2024 (UTC)

Why "sRGB is assumed"

The artcle said

"If the color space of an image is unknown and the R, G, and B samples are encoded with 8 bits each, the sRGB encoding usually the assumed default, in part because color spaces with a larger gamut need a higher bit depth to maintain a low color error rate (∆E)"

I removed the sentence after "in part" since it is confusing, unsourced, and probably incorrect. First, the sentence is incomprehensible except by readers who already know what it is supposed to say. (What is ∆E?) Maybe it is even conflating "gamut" with "gamma", which are two unrelated concepts. The sRGB encoding is usually assumed by default, when not specified, solely because it is the standard for images intended to be embedded in HTML pages; not for being optimal in some technical sense. (It should be noted, by the way, that the specification of the venerable PNM (PBM/PGM/PPM) image file format specifies BT.709 as the encoding, not sRGB.) Jorge Stolfi (talk) 19:20, 25 December 2024 (UTC)

I would skip the "in part" section of this sentence, and just say that sRGB is the assumed default color space for untagged images, especially on the web. "not for being optimal in some technical sense" – sRGB was designed to be relatively close to existing computer displays when it was first published, and then there was a whole generation of computer displays which were themselves designed to more or less match sRGB (for example iPhones from ~2010–2020 did no color management in software but had displays which were extremely close to matching sRGB). I don't think there's such a thing as a "technically optimal" color space, but sRGB is quite well adapted for its intended purpose. –jacobolus (t) 19:44, 25 December 2024 (UTC)

It does not conflate gamma with gamut. Of course if we have much more complex gamma (well, transfer function, not pure gamma) like PQ we ideally need 10 bit at least to stay at good quality in SDR portion. But of course no one will assume HDR image unless explicitly tagged. WCG images in theory need higher bitdepth to stay at the same spacings between 8 bit codepoints. Yes, since iPhone 7 photos use P3, so it is kinda "did not age well" point. Valery Zapolodov (talk) 01:08, 29 December 2024 (UTC)

Either way, unsourced and handwavy speculation about this point is not really appropriate for Wikipedia. –jacobolus (t) 01:26, 29 December 2024 (UTC)

Why were all of the useful formulas removed?

Before December 2024, this article contained useful formulas to convert from electric sRGB to XYZ and back again. Instead now there are only abstract equations using seemingly non-standard symbols (D of EOTF and E for OETF) not used in other color-space articles. All of the constants are also hidden behind symbols that the reader has no manually resolve.

I don't see what the point of this is. The old article was much more useful to anyone trying to actually implement conversions from and to sRGB. Peter163 (talk) 15:04, 1 February 2025 (UTC)

For reference, the old article was on point: https://files.catbox.moe/sixtvp.png Peter163 (talk) 15:16, 1 February 2025 (UTC)