Talk:sRGB

The image with the squares

Its caption says: ‘On an sRGB display, each solid bar should look as bright as the surrounding striped dither. (Note: must be viewed at original, 100% size)’

The thing is, for the average reader 100% is when the browser says the zoom level is 100%. At this zoom level, the image will display at 104 × 36 ‘CSS pixels’ because that's what the width and height attributes are set to. Since this is the pixel size of the image, that means it will be displayed at 96 DPI. Which means that on a high DPI device, even though the reader has followed the instructions, the image's pixels are interpolated, usually in a way that makes the striped bars appear too dark.

Even if the user thinks to right-click and open the image in a new tab, that won't help. You see, at offset 33 there's a pHYs chunk (00 00 00 09 70 48 59 73 00 00 0e c4 00 00 0e c4 01 95 2b 0e 1b) that says the image resolution is 3780 pixels per metre. This means that a conforming viewer will still end up interpolating the pixels in the same way. And if this chunk is absent, I wouldn't be at all surprised if viewers end up substituting a default DPI of 96 anyway.

I've tested Firefox, Chrome and Edge, all with similar results. Now high DPI displays are becoming increasingly popular, and with the lack of support for the use of device pixels in the wiki software, I think we can no longer display calibration images like this on Wikipedia. The risk of misleading our viewers is already too big, and will only continue to grow in the future. — Preceding unsigned comment added by 92.67.227.181 (talk) 12:29, 26 June 2022 (UTC)

I also think it's sus that the file doesn't contain an sRGB chunk. I'm not sure anyone would notice, but still. — Preceding unsigned comment added by 92.67.227.181 (talk) 13:14, 26 June 2022 (UTC)

Disagree. At default settings retina screens are fine, as they are usually 2:1 or 3:1. And it's useful to have gamma targets on screens, just ideally should be set aside (not in the main table) and with a sentence that indicates how to properly view. It's not sus if the image does not have the sRGB, especially a small image. sRGB is not needed as sRGB is the default for the web, and sRGB is therefore assumed.

What IS needed is for such targets to have the image property set to img{image-rendering: crisp-edges;} and I suspect that is actually the problem you are having in viewing.  Myndex talk   09:47, 27 June 2022 (UTC)

>Disagree.

This is a matter of fact and not an opinion about which you can just ‘disagree’. Using a retina screens is no guarantee of the image rendering correctly, it all depends on how the image ends up being upscaled; most software that is in common use today does it wrong, almost always interpolating pixels in such a way that the striped bars appear too dark. It is not useful to have gamma targets on screen if they are wrong, such as is the case here, in fact it's counterproductive. And the image not having an sRGB chuck is sus, because this article is about sRGB so the image should explicitly contain sRGB values and be clearly tagged as such; not doing so indicates a lack of care and understanding. (Also, note that if a PNG file contains a gAMA chunk but no sRGB chunk, a conforming implementation doesn't assume sRGB but instead uses a plain gamma as specified by the gAMA chunk.)

Setting ‘image-rendering: crisp-edges;’ doesn't always help. For example, one of the more popular DPI settings for desktops and laptops is 144. In that case crisp-edges will result in either the light or dark lines being duplicated compared to the other, resulting in an overall brightness that is way too light or dark. I've checked four different calibrated displays and it only shows up correctly on the oldest one (which is 96 DPI so that was to be expected). — Preceding unsigned comment added by 92.67.227.181 (talk) 17:07, 1 July 2022 (UTC)

No, you are pulling opinion from thin air, you are not reciting facts. Just because YOU can't figure it out does not meat it has no utility or is not useful to others. At most it might require some additional discussion.  Myndex talk   16:25, 2 July 2022 (UTC)

pHYs is seldom applied.

"wouldn't be at all surprised if viewers end up substituting a default DPI of 96 anyway."

I would think it will just use native pixels. Your gAMA comments are correct, Chrome and Firefox both use it instead of sRGB if sRGB chunk is absent. 2A00:1370:8184:6AD9:D044:40FD:8073:258E (talk) 06:41, 11 September 2022 (UTC)

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)