Hacker News new | past | comments | ask | show | jobs | submit login

For images that actually contain a color profile, the browser should certainly respect that. But for images that don't contain a color profile, assuming sRGB artificially creates a problem where none existed.

WebKit is intentionally squashing rgb(241,0,0) into rgb(255,0,0), whether the display shows them as distinct colors or not. That might improve consistency across displays, in that it'll make every display lower quality, but it doesn't actually improve quality. It might be nice to know that the display you render on has better color fidelity, but why not show all the colors present in the image rather than squashing them together? Then, for instance, if you have a display that has better color reproduction than sRGB but not as good as P3, you'll get the full color reproduction your display can manage.




But the image was presumably shot and colour corrected in P3, which means to squash it down to sRGB will by necessity change the imperceptible colour differences into something perceptible -- and therefore change the image into a new image, one slightly off -- very slightly in some cases. Consider retina displays-- do you prefer the browser messing with your image to produce a 1x image from a 2x? Nope. Do you prefer not having 2x? Nope. Yes a browser can scale it and it will function, but is it as intended? Especially if the browser changes it to be less noticeable or have similar contrast--that would be like a 1x image getting blurred to 2x or shrunk with an algorithm from 2x to 1x. Media queries and other syntax exist so we as creators can decide how we want things to look, down to the Last pixel. You as the content author can export two versions of the image, one colour corrected or edited on a P3 monitor and one corrected/edited on an sRGB and stand a chance that while sRGB will remain the default for now, P3 and beyond should gain as much market share as 2x, "Retina" or 4K displays, in part thanks to UHD Premium displays and content.


After reading a bit more about this here (thanks for all the informative replies) and on colour management in general, I'm pretty sure I prefer my monitor being able to display all 256 different intensities of one colour even if they're not exactly the same as some standard colour, than a scaled and truncated fraction of those (which seems like it'd just cause more visible banding.) The example image shows that clearly. I adjust my monitor's contrast and brightness to my preference, and colour perception is quite subjective anyway (not to mention affected by viewing conditions, hence those hooded monitors and controlled lighting when it is important) so I think colour management is not for me.

In fact, I'd say that if you displayed that example image simultaneously on a non-colour-managed sRGB monitor (logo visible), colour-managed sRGB monitor (logo invisible), and (colour-managed?) P3 monitor (logo visible), no average user is going to want the middle option.


If you ever have a chance to actually calibrate your display with a real hardware calibration tool, I think you'd quickly decide that color management was for you.


And if you ever spend $400 on a wooden volume knob you will quickly decide $1000 power cables are also for you.


> But the image was presumably shot and colour corrected in P3

That's not a reasonable assumption to make about an arbitrary image that doesn't contain a color profile. For instance, consider a pixel-art image drawn entirely on a computer and saved as a PNG with no color profile.

If an image contains a color profile, it's somewhat more reasonable to attempt to interpret that color profile (though it's still odd to not at least attempt to take advantage of higher-gamut-but-not-identified-as-such displays by using the full 8-bit RGB range, on the assumption that the display may or may not render ). And it seems reasonable to support media queries for image color profiles as well. But to quote the article:

> If an image doesn’t have a tagged profile, WebKit assumes that it is sRGB.

That's the behavior I'm arguing is completely wrong: if an image with no color profile contains the colors rgb(241, 0, 0) and rgb(255, 0, 0), the browser should render those as distinct colors, not squash them together.


No offense, but you’re wrong. Full stop.

(It’s okay though. This is something which developers without training in human color perception / color reproduction are commonly wrong about. It comes from lack of training and lack of experience. The proper thing to do is not a priori intuitively obvious to the layman, in the same way optimizing algorithms for CPU cache locality might not be obvious to a color scientist.)

If you take an image which was authored to be sRGB, and show it on a wide-gamut display, stretching all the colors out to fill the gamut, you will supersaturate all the colors and totally distort all of the lightness, hue, and chroma relationships in the image, and it will look terrible.

Likewise, if you take an image which was authored for P3 (or whatever), and squish it down to fit on an sRGB gamut, everything will end up undersaturated, again distorting all the lightness, hue, and chroma relationships. Again, it will look terrible.

There are fancier ways to do gamut mapping than pure clipping, but there is a lot of subtlety involved (Ján Morovič wrote a several-hundred-page monograph about this, if you want more details, https://amzn.com/0470030321), the best one to use varies from image to image, depends a bit on viewing conditions and other context, and the nicer methods are quite computationally expensive.

The HTML/CSS/etc. specs declare that untagged images and other untagged colors are to be treated as sRGB. This is the only reasonable assumption in a world where sRGB has been the primary standard for 20 years.

Any 2016 browser / operating system / image viewer which treats an untagged image as anything other than sRGB is spec-non-compliant and functionally broken. (Sadly, this includes most browsers on most platforms.)


First of all, "terrible" and "amazing" are subjective.

Any 2016 browser / operating system / image viewer which treats an untagged image as anything other than sRGB is spec-non-compliant and functionally broken. (Sadly, this includes most browsers on most platforms.)

Given the blatant loss of information that occurs if you do that, as evidenced by the WebKit logo example, I'd argue the spec is broken. Pixels of different values should be different when displayed, because that's what matters to the majority of users.


> "terrible" and "amazing" are subjective.

Yes, but «distorts the hue, lightness, and chroma relationships between colors as perceived by a large statistical sample of humans with typical color vision» (or perhaps easier, «... as computed using the CIE standard observer and a well-defined color appearance model») is not subjective.

You shouldn’t be “arguing” with the spec here or presuming to speak for “users” until you have studied up on color science, done concrete work with color reproduction, or at least compared both ways for yourself on a few dozen images.

Again, this is the naïve approach which is too often taken, but, contra your intuition, the results are dramatically worse if you do it that way. In an immediately obvious, not subtle way. What most “matters to the majority of users” is that their images look like what they expect. If you totally distort all the color relationships, the images end up looking completely different than intended, and “most users” will be dissatisfied with the output, blaming either the creator of the image or the software for being incompetent but without knowing quite what the problem is.

There are ways to avoid hard clipping, using a more sophisticated gamut mapping algorithm (I recommend you read Morovič’s book), but you can’t just treat one color space as if it were another.

In practice, hard clipping of out-of-gamut colors (assuming you do it along lines of constant hue/lightness in CIELAB space, or similar) ends up working reasonably well. You get some artifacts, but the vast majority of images stay away from the edges of the gamut.

(Photoshop and other Adobe apps have a pretty bad gamut clipping method, which is to map between color spaces without clipping, and then independently hard clip each color component. This sometimes causes severe hue shifts. Alas, even the industry leading software is often implemented by people who aren’t trained in color science, and don’t consider the edge cases. Or wrote their implementation 20 years ago and haven’t bothered to update it to keep up with computing improvements. It’s still much better than just pretending one color space is another though. I’m not sure precisely what Apple’s color management stack does.)


Yes, but «distorts the hue, lightness, and chroma relationships between colors as perceived by a large statistical sample of humans with typical color vision» (or perhaps easier, «... as computed using the CIE standard observer and a well-defined color appearance model») is not subjective.

Most people care whether the colours look good to them, not how close it is to some standard they probably don't know about. Almost everyone buying monitors in a store are going to be strongly basing their decisions on the brightness and vividness of the colours.

What most “matters to the majority of users” is that their images look like what they expect.

...and that is subjective.

Regardless, if 241,0,0 looks identical to 255,0,0 on a monitor with 24-bit colour, that's just not right at all.


Nobody cares about (241, 0, 0) or (255, 0, 0). What they care about is whether the color of the grass, sky, flower, dress, car paint job, sports team jersey, skin tone, ... looks correct.

I feel a bit like a broken record here. There are ways of mapping one color space down to a smaller one without hard clipping to the gamut boundary. But these can be computationally expensive and difficult to design properly.

However, assuming that a better gamut mapping method is unavailable, hard clipping out of gamut colors in practice works much better than just pretending two color spaces are the same. When you do the latter, images end up looking terrible.

The effect is immediately obvious to anyone with standard color vision, and as such is no more “subjective” than anything when we’re dealing with perception. In some sense all perception is subjective if you want to get philosophical. But in a practical sense, not really.

If you have a copy of Photoshop, you can try this for yourself. Collect a number of photographs or other images encoded in a large color space like P3. Then convert these to sRGB in two ways, (a) using the “assign profile” menu option and (b) using the “convert to profile” menu option.

Your proposal is to do the former. In practice, the results are entirely unacceptable. They look bad. That is, if you collect a group of humans with typical color vision and present both options, they will pick option (b) for almost all images, and for most images the right choice will be very obvious to everyone.


The point is the opposite. The logo is not untagged -- it's P3 tagged. When on a P3 display, you see the two colours as barely distinct -- as if you overlaid the logo with an opacity of 2%, I'd expect. It's barely there. The colours were picked close enough together that when properly rendered mapped to sRGB you cannot distinguish the colours without additional transformation. Consider a very high resolution, 3x monitor. Now view a 3x image on a 1x monitor: most browsers transform the image, prioritizing viewing all detail over image size. Safari here, by comparison--and only if the image is tagged with a colour profile--or in our hypothetical example, 3x--is trying to preserve the image as it was intended, losing the details just to show it at approximately the size appropriate on a lower quality display. Obviously the best approach is to provide two images, one for high quality displays and one for low quality displays so you have full control over the transformations applied.


An unintended consequence of that approach is that to get two colours to match visually, they would need to be specified in the same colour profile.

Say there is a background colour in sRGB and an image in P3, and both should display the same colour visually. Changing the visual display of the P3 image just because it could include non-sRGB colours will make them not match.


1. Background colours are generally specified in sRGB today. 2. Media queries can be used to set different background colours on P3 displays.


The image in question:

https://webkit.org/blog-files/color-gamut/Webkit-logo-P3.png

does have a color profile. By the way, it also uses 15-bit color channels.

Here is the same image after pngcrush removed the color profile PNG chunks:

http://dl.dropbox.com/u/1237941/Webkit-logo-profile-removed....

In Safari on my non-high-gamut Mac, the logo is clearly visible. (Edit: To be specific, on the default "Color LCD" profile I get 252,13,27 and 238,12,25 as native equivalents of the sRGB 255,0,0 and 241,0,0. Presumably there is some slight clamping around the edges of the profile, as well as some inherent precision loss if WebKit is performing the conversion on 24-bit colors, but it's not anywhere near as crazy as making 241,0,0 and 255,0,0 look the same.)


> The image in question:

> https://webkit.org/blog-files/color-gamut/Webkit-logo-P3.png

> does have a color profile.

I didn't comment on the handling of that image. My comment related to the bit of the article I quoted, which states that WebKit treats images without a color profile as sRGB.


Then you're conflating two different transformations. Squashing 241,0,0 and 255,0,0 is the transformation from P3, as performed on that image. As I stated in the last bit of my comment, the transformation from sRGB to the display's native color space, as performed on images without a color profile, CSS colors, etc. [edit: and of course images tagged as sRGB!] is far more subtle.


Well I agree that it is wrong simply because it breaks (for example) the PNG standard:

"RGB samples represent calibrated colour information if the colour space is indicated (by gAMA and cHRM, or sRGB, or iCCP) or uncalibrated device-dependent colour if not."

So webkit shouldn't try to transform the colors to sRGB but simply display it according to whatever display is present.

Having said that sRGB designed to be consistent and not high quality. It even has a "black point" defined, but nobody respects that since it would cause a maximum contrast ratio for all images represented in sRGB.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: