05:49:07 RRSAgent has joined #colorweb 05:49:07 logging to https://www.w3.org/2019/09/17-colorweb-irc 06:23:44 rrsagent, make logs public 06:33:37 tidoust has joined #colorweb 06:33:37 cyril has joined #colorweb 06:33:40 markw has joined #colorweb 06:33:58 cpn has joined #colorweb 06:35:09 chris has joined #colorweb 06:35:14 GregFreedman has joined #colorweb 06:35:32 jer has joined #colorweb 06:36:39 scribe: Cyril 06:36:53 Chair: Chris Lilley 06:37:20 Introductions 06:37:30 Chris, vice-chair of the ICC working group 06:37:37 ICC secretary 06:37:44 Francois Daoust, W3C staff 06:37:55 Chris Needham, BBC 06:38:01 Mark Watson, Netflix 06:38:08 Cyril Concolato, Netflix 06:38:15 Greg Freedman, Netflix 06:38:20 Chris Lilley, W3C 06:38:28 JEan-Yves Avenard, Mozilla 06:38:33 Jer Noble, Apple 06:38:45 Chris Cunningham, Google 06:38:59 Simon Fraser, Apple 06:39:07 smfr has joined #colorweb 06:39:22 chris: 3 topics for discussion 06:39:32 ... HDR on the web 06:39:35 chcunningham has joined #colorweb 06:39:35 ... Image format 06:39:47 ... Working color space and CSS 06:39:57 simon: prefer to start with CSS 06:40:18 Topic: Working Color Space 06:40:20 chris has changed the topic to: Working Colorspace in CSS Color 4 06:40:43 chris: in CSS, sRGB was used from the beginning 06:40:53 ... nobody cared about that for a while 06:41:10 ... then we added transparency with compatibility for Photoshop 06:41:24 ... then in CSS Color 4 we added more color spaces 06:41:41 ... but when you have 2 color spaces, there is a need to describe what happens 06:42:00 ... and for compatibility we still used sRGB, which has problems 06:42:26 ... to my mind, we need at least XYZ and Lab 06:42:35 but Apple uses linearized sRGB 06:42:46 ... with negative vlues 06:42:55 markw: I think Microsoft also uses that 06:43:05 chris: I looked at scRGB 06:43:12 ... but it seemed scene-refered 06:43:37 ... linearized seems a reasonable option 06:43:46 Riju has joined #Colorweb 06:43:49 ... but currently browsers store a triplet of RGB in 8 bits 06:43:58 ... there's going to be an increase in space 06:44:05 ... storage space 06:44:23 ... maybe some parts of the page could still use sRGB and other the linearized space 06:44:39 simon: it seems that linear srGB is an option? 06:44:41 chris: yes 06:45:11 simon: having a compositing color space as a CSS property would be problematic 06:45:17 ... with impact on the stacking context 06:45:34 ... implementations often pop out elements into GPU textures 06:45:48 ... on Apple platform, the architecture that we use does not allow the control of the color space 06:45:56 ... we would only have control on a per page basis 06:46:08 chris: I can see advantages of that 06:46:22 ... but we you switch it on, it changes the whole page 06:46:36 markw: the obvious question that bleeds into the next topic 06:46:46 ... true sRGB are going to map to 0,1 06:47:05 ... how do I specify luminance values that are outside the sRGB range 06:47:21 chris: sRGB says the luminance is 80nits, but it's not true 06:48:12 markw: [scribe lost] 06:48:33 how do we get HDR colors into this sRGB linear space ? 06:49:25 leonardr has joined #colorweb 06:49:37 ITU-R BT.2408-2 states "Graphics White is defined within the scope of this Report as the equivalent in the graphics domain of a 100% reflectance white card: the signal level of a flat, white element without any specular highlights within a graphic element. It therefore has the same signal level as HDR Reference White, and graphics should be inserted based on this level." 06:49:45 markw: there are a number of specs here and there that indicate what the peak value is 06:49:50 For PQ this is defined as 58% and for HLG 75%. If you display those signals on a PQ monitor or a 1000cd/m^2 HLG monitor it comes out at 203 cd/m^2. On different brightness HLG monitors, the HLG adaptive system gamma implemented in the screen will maintain the perceptual contrast without any requirement of metadata. 06:49:59 ... in windows you have 2 settings to control that 06:50:25 ... the peak white of sRGB is whatever the user has selected what the paper white is 06:50:57 ... the relation between SDR and HDR is not fixed and depends on the user settings 06:51:12 if we have e.g. a PQ coded pixel what do we map that to ? There is no canonical way to match together SDR and HDR 06:51:12 ... is there some reason why some of these have to be exposed to the web user? 06:51:31 chris: some people may prefer things brighter 06:51:45 jeanyves: can you have a generic SDR to HDR conversion? 06:51:57 chris: no you can have 2 for HLG and PQ 06:52:38 jeanyves: is there a point in defining a default that will never work> 06:52:47 chris: I'm optimistic that it can work 06:53:39 chris: sometimes the UI of some service on some TVs is really blinding 06:54:07 markw: it depends on how the TV does the SDR/HDR compositing 06:54:14 ... we don't have the control 06:54:34 chris: the best we can do is define a mapping, that is the default mapping 06:54:51 ... and then say that the user may adjust it for preferences, and the system also may adjust 06:55:03 markw: how can we specify that a color is in an HDR color 06:55:10 chris: CSS Color 4 has support 06:55:20 markw: for the gamut not the luminance 06:55:38 ... how do I tell CSS that I want an HDR color not an SDR color 06:56:22 ... we could use a boolean to indicate if a color is an HDR one 06:56:30 ... and leave the relationship unspecified 06:56:32 so it would be rec2020(r, g, b, bool) 06:56:49 markw: metadata is a different thing 06:57:00 chris: It could say SDR, PQ or HLG 06:57:19 markw: if it is a coded value yes 06:57:54 chrisbao: so y are looking at this from media pov not display pov 06:58:12 ... one of the ways we could define our objective is to say that I have an HDR video frame rendered in a video element and rendered side by side using CSS and they look the same 06:58:26 ... not sure it's feasible 06:59:00 markw: you could also use capability detection to know that the browser does not support that 06:59:20 ... but having the same rendering for the video pipeline and the graphics pipeline 07:00:51 cyril: in TTML, there is a way to specify a gain to apply to the subtitle compared to 80nits 07:01:21 chris: we moved from color space to HDR, and it's good, it should not work on SDR only 07:01:29 ... but the question is control at element level or page level 07:01:49 simon: it's hard from an implementation perspective to have element control 07:02:21 chris: Google? 07:02:43 chris_c: I'll defer to the experts in the room 07:03:15 markw: for each video that is on the screen, we need the metadata to apply to each video 07:03:35 ... so if we want the graphics to match the video, we need to adjust each graphics to the matchign video 07:03:59 ... I don't know if this needs multiple working color spaces 07:04:11 chris: in PiP on TVs are they in separate planes? 07:04:19 chrisbao: not every vendor can do that 07:04:32 ... some do separately, different color gamuts, tone mapping 07:04:48 markw: the metadata drive tone mapping is an optimization 07:05:15 chris: if much of the web content to be composited is going to be SDR, we should signal 07:05:26 markw: there is no tone mapping issue for SDR, you don't care 07:05:35 ... the peak is 80nits or 100nits 07:05:44 chris: Adobe RGB is 160nits 07:05:54 ... and proPhoto is even more 07:06:00 markw: I scoped my comment to video 07:06:21 chris: but we have photographers who want to display their photos 07:06:53 cyril: where would the control at page or element level be specified? 07:06:55 Re: "but the question is control at element level or page level" - I'll source an opinion from compositing / color folks in Chromium 07:07:01 chris: it would be in the CSS Color 4 spec 07:07:32 ... the problem is that you would have to opt-in for a slower path for the whole page? 07:07:53 markw: how does the current renderer deal with luminance differences between sRGB spaces? 07:08:03 chris: it is ignored 07:08:13 ... some browsers will convert ICC profiles 07:08:47 chris: at this point, we will capture that as an issue with drawbacks 07:09:00 ... I don't get a sense that there is a solution 07:09:17 ... but it seems that people care about designing for HDR from the beginning 07:09:43 s/we need the metadata to apply to each video/we need the metadata to apply the correct tone mapping to each video/ 07:09:50 []: I created an experiment using OpenCV.js, and Canvas is 8 bit so I have to tone map 07:09:59 ... are we proposing to increase canvas bit depth? 07:10:07 chris: there is discussion going on 07:10:13 simon: I think it's generally accepted 07:10:20 s/adjust each graphics to the matchign video/apply tone mapping to each graphics area to the match the video 07:10:46 chris: I think they used half floats 07:11:08 []: what is the percentage of displays capable of doing HDR? 07:11:12 s/the peak is 80nits or 100nits/the peak is 80nits or 100nits which is less than the display capability 07:12:05 chris: not known, but we can assume it is going to increase 07:12:24 ... people consume even ordinary content in bright sunlight 07:12:34 ... displays are having that capability 07:13:19 ... PQ assumes a dark room, HLG too to some extent 07:13:58 riju: we are shipping some ambient light system for that 07:14:11 markw: ambient light system is going to happen 07:14:19 ... there is no need for APIs to do that 07:14:32 chris has changed the topic to: HDR color in CSS 07:14:46 Topic: HDR Color in CSS 07:14:47 simon: there is a desire for people to specify color in HDR 07:14:56 .. this is going to have an impact on the user experience 07:15:00 ... like power usage 07:15:11 ... we may want to limit the use of these colors 07:15:30 markw: the outer page could specify limits on the inner page 07:16:05 sushraja: feature policy may be a good way to restrict 07:16:08 chris: good point 07:16:26 ... anything more on this topic? 07:16:45 phil: bgsRGB is another flavor of sRGB 07:16:55 ... it's part of the IEC specification that includes sRGB 07:17:17 markw: are we in agreement in what is needed and what is the process? 07:17:34 ... the question of tone mapping and metadata, is it part of the problem? 07:17:56 ... what is the next steps to gather the requirements and develop them further 07:18:05 chris: in this case, we need a requirements document 07:18:18 ... because we don't collectively understand the same issues 07:18:30 phil: there are different views in the ICC org 07:18:43 ... ICC is not going to be the answer for dynamic content 07:19:12 ... we need to be realistic in where ICC can contribute 07:19:37 ... we have practical implementations in 2 areas: 07:19:56 ... Adobe have main profile for HLG and PQ display 07:20:42 s/HLG and PQ display/HLG scene and HLG display and PQ display 07:21:03 ... it is LUT-based 07:21:28 ... those are used in Adobe products 07:21:53 ... in ICC version 4, we have a single white point 07:22:01 ... that's worked very well, until HDR 07:22:11 ... diffuse white/graphics white and display 07:22:17 chris: you have 3 07:22:45 phil: you map peak white to peak white using a variety of transforms 07:22:45 diffuse white, ful screen peak white, small hilight peak white 07:23:36 ... the Adobe implementation is based on mapping the diffuse whites 07:23:52 ... and that's been quite successful 07:24:20 ... we haven't decided which way we ant to go and we'd like to get feedback from this group 07:24:33 markw: it'd be good to have a document to send to our experts 07:25:47 s/[]/riju/ 07:26:20 scribe: markw 07:26:31 scribenick: markw 07:27:00 phil: v4 based ion mapping white point to white point - media white to media white 07:27:18 s/v4/ICC v4/ 07:27:22 ... however, with HDR need to decide on white point - media peak white can't be mapped to sdr peak 07:27:48 .. as that would compress. One soln is to map graphics white to sdr peak white. 07:28:13 ... PCS white point is based on illuminant D50 - 100cd/m2 07:29:17 chris: ICC working on better write up of the problem statement - how to deal with HDR in ICC profiles 07:29:50 pal: not convinced that the solution based on ICC is necessary for HDR color on the web 07:30:01 chris: what info do we need ? 07:30:15 pal: enumerated color spaces - not that many 07:30:59 ... for entertainment media ITU-T etc. have enumerated the color spaces that are used 07:31:42 phil: ICC is just a way of packaging those things 07:32:00 pal: but it is very general. We should start with the ones people use 07:32:24 phil: ICCmax has a reference encoding profile feature - instead of specifying a transform you point to it - e.g. with a URL 07:32:47 chris: ICCmax also has calculator and floating point 07:32:57 pal: what's the problem starting with something simple 07:33:17 -> CSS Color Level 4: https://www.w3.org/TR/css-color-4/ 07:33:33 chris: CSS Color 4 has enumerated set of color spaces. There is a proposal to have an Annex which maps those enumerated spaces to full ICC profile 07:34:00 chris: also have @profile way to fetch a full ICC profile. At least Google don't want to fetch arbitrary profiles 07:34:08 ... publishing people want full profile support 07:34:23 CSS color space enumeration: https://www.w3.org/TR/css-color-4/#predefined 07:34:31 ... print formatting a rather different space 07:34:56 pal: so why not expand that enumerated list with HDR > 07:35:09 chris: which ones ? 07:35:22 pal: basically there are two: HLG and PQ 07:35:36 pal: typically used with 2020 07:35:46 markw: not just typically, universally 07:36:59 chris: so we could have those two - mark had suggested a boolean 07:37:33 markw: that was for color specified in linear space: need to say which linear space. Agree with enumeration for PQ and HLG when the data is coded with the TF 07:37:54 cyril: TTML has a way to specify the gain applied for PQ and there is a default way to do that for HLG 07:38:06 ... so why not do the same here ? 07:38:31 pal: you need to specify whether the =pixels are coded u HLG or PQ. Is there any downside to that path ? 07:38:37 smfr has joined #colorweb 07:38:51 s/=pixels/pixels 07:39:08 ... suppose I am creating a professional authoring application for images - just can't do that in canvas today 07:39:15 chris: why not 07:39:26 pal: no way to specify HDR text / colors in CSS 07:40:46 markw: new enumeration vbalues for 2020pg and 2020hlg would be great, as long as it is understood that what you get after converting to linear is in a different scale than sRGB 07:40:59 chris: great, but will anyone implement it ? 07:41:22 jer: for Apple have to check with Dean Jackson and Simon Fasier 07:43:13 chris(c): problem has been lack on consensus to date 07:43:42 jean-yves: interest in HDR so far has been for video 07:43:43 topic: HDR image format 07:44:08 chris: w3c would like there to be an image format that everyone can use 07:44:19 ... don't want fragmentation, like we have today 07:44:36 ... SVG requires PNG and JPEG 07:44:47 ... W3C does not want to develop a new image format from scratc 07:45:04 ... if there is something that exists that is open and RF we would prefer that 07:45:32 pal: not just format, but full image codec ? target > 07:46:04 cyril: at least one candidate: AVIF 07:46:07 chris: HEIF ? 07:46:21 cyril: HEIF is the file structure, but you can put any codec in it: HEVC, AV-1 etc. 07:46:39 pal: HT J2K 07:46:57 ... It's J2K with lower computational complexity 07:47:26 s/HEVC, AV-1 etc./HEVC, AV-1 etc. (AVIF is the name for AV-1 in the same codec) 07:48:12 markw: many people unhappy about the licensing uncertainty associated with HEVC 07:48:46 pal: HT J2K format is called JPH 07:50:01 markw: HEIF is a container, when used with AV-1 it's called AVIF 07:50:29 cyril: HEIF is a container specification, MIAF is a restriction that provides context for different codecs 07:50:49 ... AVIF further restricts MIAF for AV-1 codec 07:50:57 pal has joined #colorweb 07:51:27 -> ISO/IEC 23008-12: https://www.iso.org/standard/66067.html 07:51:29 jer: HEIF on Apple platforms is usually HEVC. Also supports live photos (short video) 07:52:24 -> ISO/IEC 23000-22: https://www.iso.org/standard/74417.html 07:52:38 chris: are the libraries that can be picke dup and used, that are widely deployed ? 07:52:43 -> AV1 Image Format: https://aomediacodec.github.io/av1-avif/ 07:53:08 markw: AV-1 has open source RF library - not yet widely deployed because it is new 07:53:13 pal: same for HT J2K 07:53:32 cyril: is it lossless or lossy ? compression ratio 07:53:35 ... ? 07:53:55 pal: either lossless or lossy, range of compression ratios as you would expect 07:54:30 ... just a lot more computationally efficient as it changes the arithmetic codec 07:54:42 s/arithmetic codec/arithmetic coder/ 07:55:20 chris: how should we proceed ? got some candidates. Should we put together a doc with pros & cons etc. with an object of defining one winner ? 07:55:37 ... could have more than one but one would be ideal 07:56:05 chris: I assume there are test images ? 07:56:35 cyril: colorist tool (made by a Netflix engineer) can generate synthetic images and do ICC conversions 07:56:36 pal: HTJ2K is defined in ISO/IEC 15444-15 | ITU T.814 ("Information technology - JPEG 2000 image coding system: High-throughput JPEG 2000") https://www.itu.int/rec/T-REC-T.814-201906-I 07:57:01 -> Colorist: https://github.com/joedrago/colorist 07:58:24 markw: there are evaluations of AVIF on JPEG test set from their last CfC 07:58:49 chris: sounds like a document on this would a good idea. I'll start something. 07:59:10 chris(n): I had started a document already that was for internal use but could be a basis for a CG report 07:59:24 chris: can we put that in the W3C giuthub ? 07:59:36 chris(n): sure - I already converted it to Respec 07:59:50 -> HEIF, freely available spec : https://standards.iso.org/ittf/PubliclyAvailableStandards/c066067_ISO_IEC_23008-12_2017.zip 07:59:54 pal: who was asking for image format ? 08:00:02 chris: came up last year 08:00:11 sushrajaMSFT has joined #colorWeb 08:00:29 chris: content creators would probably like some guidance 08:00:48 ... and if there is consensus that browsers more likely to support 08:00:56 https://bugs.chromium.org/p/chromium/issues/detail?id=960620#c1 08:01:06 ... do browsers already support these things ? 08:01:08 ^^ chrome 08:01:32 jer: we disabled a few because we didn't want to expose them to the web due to security 08:01:41 chris(c): we have a bug for AVIF support in Chrome 08:01:53 jean-yves: pushing WebP 08:02:18 Zakim has left #colorweb 08:02:37 chris: anything else on image formats ? sounds like formats exist and we need to choose 08:03:09 markw: next steps ? 08:03:38 chris: I will take on chris n's document and get it into the GitHub and then we can work in the GitHub repo 08:04:01 s/get it into/get it or something based on it/ 08:05:43 cyril: 08:06:22 ... breakout session tomorrow at 5.30 on images on the web, not specifically HDR. Question of MIME types, use of video vs image for sequences 08:06:58 ... AVIF has an Annex defining two media types, one for still images and one for sequences, but Mozilla ask why have two if everyone supports both 08:07:17 -> Proposed break out on images tomorrow: https://www.w3.org/wiki/TPAC/2019/SessionIdeas#Images_on_the_Web 08:07:31 chris: similar discussions on PNG, but it still doesn't have a media type ... ideological video vs image debate has derailed things in the past 08:07:53 markw: shall we have a call in a couple of months ? 08:09:04 chfris: suggest early december or january 08:09:40 ... consensus for december ... 08:09:46 chris: I'll do a doodle 08:09:57 chris(n): where's the mailing list / 08:10:04 public-colorweb@w3.org 08:10:51 https://lists.w3.org/Archives/Public/public-colorweb/ 08:10:59 RRSAgent, make minutes 08:10:59 I have made the request to generate https://www.w3.org/2019/09/17-colorweb-minutes.html cyril 08:11:14 https://github.com/w3c/ColorWeb-CG 08:11:21 RSSAgent, make minutess 08:40:34 smfr has joined #colorweb 08:43:33 tidoust has joined #colorweb 08:48:15 smfr has left #colorweb 12:56:37 pal has joined #colorweb 13:13:31 pal has joined #colorweb 13:59:17 tidoust has joined #colorweb 14:56:46 pal has joined #colorweb