Subject: Re: [httpwg/http-extensions] Client hints: add support for hinting Display Gamut / Color Profile (#263)

From: HTTP issue updates <[email-masked]>
Date: Fri, 09 Dec 2016 14:21:44 -0800

I have no opinion on the client hint proposal, but I'll comment on the poll.

I expect commerce sites to be the first to care about accurate color. They'll want to make sure they show you a picture of the bright red shoes that matches what will turn up on the doorstep. Then I predict art/photography etc content. And before long, so many people will have extended displays that designers will just want their content to look more awesome.

Also, it's not the kind of thing you care about until you see the improvement in person. It would be interesting to see the poll result in 12-24 months.

(Note that while Apple has done the work to support extended colors in WebKit, we're still missing pieces. Implementing it within other browsers might take more effort. Last time I checked they didn't even color match to sRGB.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/263#issuecomment-266139279

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 13 Dec 2016 13:38:55 -0800

I'm a little fuzzy on some of the implications of `Content-Color-Gamut`. While I definitely see the savings that can be had by being able to specify a pre-understood named colour profile (or some reusable cached ICC profile) instead of embedding the profile in its entirety in each image, I feel a little uncomfortable about the separation of the image asset from instructions that are absolutely necessary for rendering it.

What this means is that information that is necessary for rendering the image will be in HTTP headers instead of the image content itself. If you save that image, it will essentially be incomplete (unless the browser rewrites the data or something).

In a perfect world, I would have common colour profiles be available in some shorthand in the image file itself. Basically just like the sRGB chunk in PNG just generalized for other common colour profiles. I feel that HTTP headers aren't the right place to solve this problem.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/263#issuecomment-266870004

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 14 Dec 2016 07:24:56 -0800

Just to clarify, because there may have been some confusion:

Of the two headers, I am okay with `Color-Gamut` (when the client sends the server the gamut of the client's display). My previous comment is referring to `Content-Color-Gamut` where the server sends the gamut of an image to the client as an HTTP header. I feel like this information is necessary to rendering an image and should be included in image data and not as an HTTP header. Rendering the image without this information is impossible to do correctly.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/263#issuecomment-267062428

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 14 Dec 2016 08:25:00 -0800

This is probably implicit in the discussion, but for posterity I want to enumerate the decision matrix that `Color-Gamut` would help address:
* Maximize the experience: A server has 10bit/channel images and client can display wide gamut (aka serve P3 to P3)
    * If client supports jp2/jpegxr then use; 
    * If bandwidth permits, use png. 
    * Otherwise reduce color space to 8bit/channel and add p3 icc and serve webp/jpg.
* Preserve the experience: A server has 10bit/channel images but client is only sRGB. Sending P3 to sRGB has poor effects and will result in banding and clamping therefore we want to reduce to 8bit/channel, color correcting to sRGB.
* Balance experience and performance: A server wants to reduce bytes by stripping icc metadata. BUT doing this today has inconsistent experiences with different browsers. Notably, browsers that incorrectly assume the attached display is also sRGB and don't color correct (Chrome/FF). The very presence of this CH is a legacy v. modern color-correcting indicator. (this is assuming that [667431](https://bugs.chromium.org/p/chromium/issues/detail?id=667431) ships ahead of CH)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/263#issuecomment-267080002

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 21 Dec 2016 08:20:20 -0800

@colinbendell @njdoyle thanks a lot for the great feedback.

To echo @mnot's suggestion: 
 - formalize above use cases and rough proposal via an ~explainer doc
 - publish explainer on WICG, engage vendors in discussion
 - ... 
 - write down spec once we have implementation's underway

@gunta @colinbendell @njdoyle perhaps something you could drive/own together? 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/263#issuecomment-268564616

---

From: HTTP issue updates <[email-masked]>
Date: Sun, 25 Dec 2016 09:19:08 -0800

Closed #263.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/263#event-904735720

---

From: HTTP issue updates <[email-masked]>
Date: Sun, 25 Dec 2016 09:19:08 -0800

I'm going to close this, as we're going to ship CH without this hint, but please do continue to discuss (here if necessary to coordinate).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/263#issuecomment-269130603