Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Color API direction #1047

Closed
atanassov opened this issue Jul 21, 2021 · 3 comments
Closed

Color API direction #1047

atanassov opened this issue Jul 21, 2021 · 3 comments

Comments

@atanassov
Copy link

atanassov commented Jul 21, 2021

Minutes

Web Platform Color API

  • Discussed the CSSColorValue API and proposed Color API.
  • RESOLVED: Add Color API for representing color points,
    separate from CSSColorValue to represent CSS
    color values
  • RESOLVED: Color API should handle all the color spaces
    currently specced for the web platform.

===== FULL MINUTES BELOW ======

logging to https://www.w3.org/2021/07/21-css-irc
Scribe: fantasai
Present:
Adam Argyle (Google)
Chris Lilley (W3C Team)
Elika J. Etemad (W3C Invited Expert)
Florian Rivoal (W3C Invited Expert)
Lea Verou (W3C Invited Expert)
Miriam Suzanne (W3C Invited Expert)
Pierre-Anthony Lemieux (MovieLabs)
Rossen Atanassov (Microsoft)
Tab Atkins (Google)
Tess O'Connor (Apple)

Web Platform Color API

github: #1047
slides: https://lists.w3.org/Archives/Public/www-archive/2021Jul/att-0004/Towards_a_Color_API_for_the_Web_Platform.pdf

Rossen: Do we have a list of issues to resolve on?
lea: Chris and I prepared some slides
lea: since last time we discussed was confusing
lea: Tab, feel free to interject

Rossen: Do we have something we want to resolve?
lea: I think it's, do we want to have a separate color API, or do we want
to use the CSS color value API for everything in the Web platform
lea: Where should work be done, do we have one or two APIs
The readme has some more overview stuff:
https://github.com/LeaVerou/color-api/blob/main/README.md

Rossen: Motivation kicking off these things was, we had another review
of color-related things with the TAG
Rossen: at the time it was very apparent that we have more and more
color discussion
Rossen: they all seem to circle around whether we use color functionality
vs type of color vs who is responsible for converting things,
who is responsible for caring whether a particular type is safe
to take from HTML to Canvas and still making sense
Rossen: Hey, can we take a step back and define
Rossen: First, there's a lot of science and calculations going into color
and defining the functionality of color
Rossen: having one place where this is made available to platform
would be great
Rossen: Then, if we have this functionality and it is well encapsulated
with good APIs, how do we create a type of this and where does
it go?
Rossen: Is it a CSS value, is it an object, etc.
Rossen: I'm hoping that here we'll at least arrive and all agree that
well, we need all of this stuff
Rossen: and also figure out where it all goes

lea: Current situation in Web platform is basically passing around
strings, so I think we all agree it needs to be improved and
become object-oriented
chris: worse actually, it was originally srgb, and now trying to pass
around wider-gamut colors as srgb strings

Rossen: let's start with functionality first
Rossen: Chris and lea did a bunch of work to define functionality of
color conversion
Rossen: and different color spaces
Rossen: one of the major functional requirements from this effort
Rossen: where is this work currently?
lea: Can i switch to the slides?
florian: Can you send a copy to www-archive?

[slide 2]
lea: Colors need to be used as input and output for various APIs
(canvas, cssom, input type=color, etc.)
lea: also authors themselves want to do things with colors
lea: and do many different kinds of color calculations
lea: ideally color API would cover all this

pal: Who wants to do this? I think most authors don't want to do this.
pal: Likely to be doing wrong, even with API
pal: so want to establish who wants this

lea: some requirements that Chris and I think important for such API
lea: It should be color-space agnostic, not privilege e.g. sRGB
lea: It should be compatible with HDR
lea: It needs to be extensible
lea: a native API is less extensible than a library, but good to add
extensibility
lea: And API should follow layered design
lea: so usable by non-experts
lea: but also useful for experts

chris: This is difference between color library we wrote, and color API
for the platform
chris: our library had everything we could think of that could be useful
chris: tries to do everything out of the box
chris: but for color API, should be core set, that you can extend if needed

lea: Whole debate started a few months ago because there was a proposal
by Canvas to accept and produce CSSColorValue objects
lea: This is an abstract CSSColorValue that inherits from CSSStyleValue
lea: part of typed OM
lea: Multiple subclasses that correspond to specific CSS syntactic
constructs
lea: e.g. CSSRGB that corresponds to rgb()
lea: CSSHSL
lea: CSSColor that's a color() function
lea: each has different API shapes, getters for each argument
lea: also different constructors
lea: e.g. accepting red/green/blue positional arguments for rgb
lea: There's a color space conversion function
lea: it's an early-stage spec, no impls yet

lea: Advantage of using it everywhere is there would be only one object
lea: and good integration with CSS out of the box.
lea: Downsides revolve around the issue that CSS Color Value is designed
to represent syntactic constructs
lea: not actual color points
lea: e.g. there are two variants for rgb
lea: one for rgb() function, one for color() function
lea: you get different objects for these
lea: also it's not a string, but csskeywordvalue
lea: and coordinates are values, so need to do color.r.value to read
the value
lea: because this is all for representing parsed syntax.
lea: These are not issues that can be solved by iterating on the API
design
lea: although it has improved a lot since original design.
lea: Because it is exiting for syntactic purposes,
lea: if we make it easier to use for color points, it will become more
difficult for the uses it was designed for

lea: Stepping back, chris and I designed a library for color
lea: There was CSS meeting where we resolved to learn from this work
and design a color API
lea: We drafted a spec https://projects.verou.me/color-api/
lea: ...
lea: API has improved quite a lot, even this week, since Tab sent us
some very nice feedback
lea: Review the design

CSS Color Value draft:
https://drafts.css-houdini.org/css-typed-om/#colorvalue-objects
Color Object draft: https://projects.verou.me/color-api/
https://projects.verou.me/color-api/
Draft explainer: https://github.com/LeaVerou/color-api

[slide 10]
lea: ...
lea: Color spaces represented by colorspace object
lea: color.alpha is a number
lea: right now all mutable, but that's under discussion

lea: Color spaces are represented by ColorSpace objects
lea: registered in ColorSpace.register()
lea: ability to make anonymous would be nice to make happen
lea: but difficult to design API to not be less usable for common case
lea: Color spaces are represented by ID so don't have to look up objects
lea: Color spaces declare their white point, coords, gamut, and conversion
code to/from existing space
lea: so you declare your base, and provide functions to base and from base
lea: This could create a tree of conversions, but in practice it's one or
two hops
lea: e.g. hsl has base of srgb, but srgb would have a base of xyz
lea: I originally designed to have an ICC profile, but that would make
everything async
lea: so have a separate API that returns a promise to load profile
lea: once registered, cannot unregister color profile

[slide 12]
lea: have getters to get coordinates
lea: and set functions to manipulate in any color space, which can be
relative
lea: can be provided by object literal as well
lea: Gamut mapping is optional. Everything is lossless by default
lea: Should be able to roundtrip without losses
chris: This is needed for non colormanaged APIs e.g. WebGPU
chris: if you set up canvas in P3, things might be out of gamut, but
need to calculate
chris: can always ask to put in gamut if you want
lea: There are functions for toGamut mapping
lea: by default use LCH chroma, but can be any coordinate in any
coordinate space
lea: unsure what to do with nonsensical

[slide 14]
lea: Open questions...
lea: How to declare polar color space?
lea: What is a color space?
lea: Various representations of srgb are all in the same color space, but
treated differently...
lea: should there be some API level distinction between that and different
color spaces?
lea: mutability vs immutability
lea: But there are some benefits to mutability as well
lea: Also how to do HDR tone mapping?
lea: and what would be interaction between Color API and CSS,
lea: would registered color spaces become available to CSS?
lea: do color spaces declared via @color-profile become registered
ColorSpace objects once profile loads?

Rossen: Thanks for clarifying discussion here and providing a lot of
synthesized info
Rossen: There's a lot of density
Rossen: The two primary questions that I took away from the discussion
and overview are
Why/who really needs this?
Is CSSColorValue of Color object the right way for exposure?
Rossen: Challenge by pal, do we really need this?
Rossen: that's one we can cover quickly
Rossen: other one is, if we can walk away from this discussion with
defining if CSS Color Value or Color Object is the right way
to move forward
Rossen: details can be worked through in GH issues

TabAtkins: Earlier I was a pretty big proponent of doing this all in CSS
Typed OM space
TabAtkins: after more thought and seeing this proposal
TabAtkins: I am convinced that, while we have some open issues that I
think those are solvable
TabAtkins: I think this would present a substantially more usable API
TabAtkins: than trying to do it all within TypedOM
TabAtkins: And as Lea said, it means we don't have to contort TypedOM
to fit these other use cases
TabAtkins: I've done a bunch of work with color, would have loved to have
an API like this.

Rossen: One question, does this render CSS Color Value out of the
conversation?
TabAtkins: We still need to represent color values in CSS via TypedOM
TabAtkins: there's just less pressure to do convenience methods in TypedOM
TabAtkins: Some things like converting between functions might still do,
but don't have to worry about extensibility to author color
spaces. Can leave that to Color API

florian: To me the motivation for this makes complete sense
florian: but if have both, will they step on each others toes?
florian: There's other parts of platform also that consume colors, and
we'll need to define what kind of colors they consume. Will it
be one kind, both? Do we need conversion functions?
florian: If every API consumes both and have conversion functions...
should one be a library of the other?
TabAtkins: What is the preferred shape for color-consuming functions is
a key question
TabAtkins: wrt conversions, already define how to create one from the other
TabAtkins: but whether we end up preferring one for APIs like eyedropper
or whatever
TabAtkins: or say that APIs should handle both, is something need to still
answer
TabAtkins: make sure TAG is aware of this question
TabAtkins: If we only do one, I suspect Color API is the one we want to do
TabAtkins: but might want to accept both
chris: Also point out that while we think of CSS as main consumer, there's
also Canvas
chris: which has some color spaces not in CSS
sRGB-linear and rec2020-linear are the two I am thinking of here

lea: Also ....
lea: You can't always derive specific numbers for a CSS color, e.g. can
have a calc() expression
florian: Can it be resolved down to a single value?
lea: What if you have a number that's viewport units divided by pixels?
TabAtkins: and if you use 'em' it's element-specific context
florian: So you'd need to throw if try to convert and it needs a context
but doesn't have one

plinss: Wrt API used in other places in the platform, don't have to solve
here, can take to TAG
plinss: My take is any input probably fine, but output must be Color API
plinss: I'm glad to see both these APIs being developed
plinss: What I really want is one object that really focuses on doing
color right, and one object that does CSS right
plinss: overlap, later
plinss: I'm fine with one set of classes if it would be good fit for
both uses, but I don't think this is the case
plinss: ...
plinss: color object should be underlying object for doing the work
my audio is broken, will type
first comment:
1. Should color objects be immutable?
Much less ambiguity about what happens when live color objects
change.
Maybe design the api initially with immutable colors.
Mutability brings lots of complexity.
TabAtkins: what do you mean?
lea: you get a reference to a color object, use it, and someone else
changes it, what happens
??: might be useful actually
???: does it animate or what?
(lost the link)

pal: meta question, a lot of this stuff sounds cool and fun, but I'd like
to better understand the target applications and users
pal: otherwise black hole
chris: ...
chris: Risk is we get shipping subsets that are useful only for this or
that which is shipping
pal: Question of mutable vs immutable, how can we answer the question
without understanding the use cases?
Rossen: So question is, is this behind the Color API itself or CSS Color
Rossen: I think we have a pretty good answer
Rossen: once this is answered then we can go after your question

smfr: If color objects are long-lived and assign them to different things
[audio cut]

TabAtkins: API that vends a color, or ... hold a reference to that color
TabAtkins: automatically changes the color used
TabAtkins: we very specifically didn't do that for TypedOM
TabAtkins: and I expect we would conclude the same here
[smfr continues to have audio problems]

Rossen: What I'm hearing is the Color object in the way that was proposed
by Lea and Chris in that spec and explainer is the preferred path
forward
Rossen: Anyone objecting to that path forward?
florian: Is the use case question about should we have this at all or
about design?
Rossen: ok let's take that resolution
RESOLVED: Add Color API for representing color points, separate from
CSSColorValue to represent CSS color values

Rossen: Next question is do we actually need this
pal: That's not my question. My question is who are the users? what are
the use cases being targetted?
florian: Do you question that there are any? Or concerned that if we don't
understand the users, we can't do it right?
pal: The latter
pal: There's many color spaces
pal: There's a complete zoo of this stuff, NxN issue
chris: No, it's not
pal: to convert from any space to any other space
TabAtkins: That's what the interconnect space is for
pal: [gives some complicated example]
pal: How can you go through a connecter space?
pal: Like REC709 are defined from camera, so optical to electrical
transfer function
pal: but inverse is not defined, and depends on context,
not just only math
pal: all I'm asking is what are the use cases?
pal: what are we trying to do?
image referred vs scene referred is what Pierre is referring to
here, I think
There are some talks at the Color workshop about this by the way

Rossen: one obvious use case is to have an actual object so we don't pass
strings which are typeless and lose meaning from one object to the
other
Rossen: I hope we all agree that this is needed for user point of view and
for perf
pal: no question there
Rossen: whether or not this object needs to cover all possible color spaces
and their interaction, I think this is more of your line of
questioning
pal: wrt string vs object, definitely want an object
pal: I think that sounds like a great idea

Rossen: so remaining question is, do we have enough use cases that support
having color spaces as an API functionality, what are these color
spaces, where do we star/tend
pal: you define the object
pal: question is, do you define reference transformation
pal: assume this object has a color space and coords
pal: should the web platform define reference transforms between instances
of this class associated with various color spaces, and what are they
pal: until we've answered what use cases we're targetting will be hard to
answer that question
pal: easy to go crazy
chris: that's why we made this library
chris: if just talking about color metric conversion, can have single
transform
chris: as soon as ... e.g. hdr to sgr, then ...
pal: I don't agree, in case of 709 there's not a singe inverse transfer
function used today
pal: so web could decide to just pick one. And actually that might really
help the world.
pal: but not something to do lightly
pal: really need to understand retargetting
lea: it's OK to restrict the scope at first
lea: maybe we decide that some color spaces are out of scope for L1
lea: Some are already out of scope for current design, e.g. index colors
pal: I really like the suggestion

pal: maybe for first pass, just replicate everything in srgb
pal: make sure everything works there
TabAtkins: CSS is already past SRGB, so already need more
pal: ok, then pick that
pal: If we all agree to moving from string to object, then validate that
and grow from there
florian: need object we can do something with

https://www.w3.org/Graphics/Color/Workshop/talks.html
chris: In few seconds remaining, questions pal raised, many will be covered
in the color workshop ^

It sounds like the hard part of Pierre's question is around more
exotic spaces anyway, which are not going to be supported as
built-ins; they could just be added as author-defined ones,
where these choices presumably can be made by the author, right?

Rossen: proposed path forward of scoping what we can do here
Rossen: scoping to CSS is valid path forward, start from there
Rossen: where is this work going to happen?
chris: currently in private repo...
Rossen: ok, open in WICG
pal: I think if the goal is to include video and image applications
pal: WICG isn't the right place, won't get the right people
pal: any color cg or whatever would be good
lea: what about a task force?
[smfr departs]

TabAtkins: Point of WICG is to gather the people you need before you choose
a venue
pal: But WICG is way too high bandwidth
TabAtkins: you don't subscribe to everything, you subscribe to the specific
repo
lea: We don't need all video people, just a few
pal: Happy to point ppl to the repo, but they'll also want to discuss it
pal: some issues best discussed live
color cg had a lot of good discussion on related topics already
florian: Point of WICG is to be a place for "I haven't created a group yet"
chris: ... already has the right people
chris: but can't do spec work
Rossen: so let's pursue WICG and if it doesn't work, can transition out
of there

fantasai: Seems like we wanna start with at least covering all the CSS
and Canvas color spaces
fantasai: So we can resolve on that at least
fantasai: Even without drafting up a more extensive use-cases doc
fantasai: and then maybe chris, lea, pierre can draft up the explanation
of use-cases that pierre is looking for
Rossen: Perfect, TAG loves to see use-cases right at front
fantasai: So take a resolution?
Rossen: objections?
RESOLVED: Color API should handle all the color spaces currently specced
for the web platform.

fantasai: On process, when do you spin out of WICG?
Rossen: when we have impl interest
fantasai: We often have the case that things spin up in WICG and never
spin out
florian: Implementer isn't strictly required, just need a community that
is happy to charter the work, however you manage to get that.
Implementer interest certainly helps with that, but it's not a
formal condition.

Meeting closed.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed Color API discussion, and agreed to the following:

  • RESOLVED: Add Color API for representing color points, separate from CSSColorValue to represent CSS color values
  • RESOLVED: Color API should handle all the color spaces currently specced for the web platform.
The full IRC log of that discussion <Rossen__> Topic: Color API discussion
<Rossen__> github: https://github.com//issues/1047
<fantasai> scribenick: fantasai
<fantasai> Rossen_: Do we have a list of issues to resolve on?
<fantasai> lea: Chris and I prepared some slides
<fantasai> lea: since last time we discussed was confusing
<fantasai> lea: Tab, feel free to interject
<fantasai> Rossen_: Do we have something we want to resolve?
<fantasai> lea: I think it's, do we want to have a separate color API, or do we want to use the CSS color value api for everything in the Web platform
<fantasai> lea: Where should work be done, do we have one or two APIs
<chris> The readme has some more overview stuff: https://github.com/LeaVerou/color-api/blob/main/README.md
<fantasai> Rossen_: Motivation kicking off these things was, we had another review of color-related things with the TAG
<fantasai> Rossen_: at the time it was very apparent that we have more and more color discussion
<fantasai> Rossen_: they all seem to circle around whether we use color functionality vs type of color vs who is responsible for converting things, who is responsible for caring whether a particular type is safe to take from HTML to Canvas and still making sense
<fantasai> Rossen_: Hey, can we take a step back and define
<fantasai> Rossen_: First, there's a lot of science and calculations going into color and defining the functionality of color
<fantasai> Rossen_: having one place where this is made available to platform would be great
<fantasai> Rossen_: Then, if we have this functionality and it is well encapuslated with good APIs, how do we create a type of this and where does it go?
<fantasai> Rossen_: Is it a CSS value, is it an object, etc.
<fantasai> Rossen_: I'm hoping that here we'll at least arrive and all agree that well, we need all of this stuff
<fantasai> Rossen_: and also figure out where it all goes
<fantasai> lea: Current situation in Web platform is basically passing around strings, so I think we all agree it needs to be improved and become object-oriented
<fantasai> chris: worse actually, it was originall srgb, and now trying to pass around wider-gamut colors as srgb strings
<fantasai> Rossen_: let's start with functionality first
<fantasai> Rossen_: Chris and lea did a bunch of work to define functionality of color conversion
<fantasai> Rossen_: and different color spaces
<fantasai> Rossen_: one of the major functional requirements from this effort
<fantasai> Rossen_: where is this work currently?
<fantasai> lea: Can i switch to the slides?
<fantasai> florian: Can you send a copy to www-archive?
<fantasai> [slide 2]
<fantasai> lea: Colors need to be used as input and output for various APIs (canvas, cssom, input type=color, etc.)
<fantasai> lea: also authors themselves want to do things with colors
<fantasai> lea: and do many different kinds of color calculations
<fantasai> lea: ideally color API would cover all this
<fantasai> pierre: Who wants to do this? I think most authors don't want to do this.
<fantasai> pal: Likely to be doing wrong, even with API
<fantasai> pal: so want to establish who wants this
<fantasai> s/pierre/pal/
<fantasai> lea: some requirements that Chris and I think important for such API
<fantasai> lea: It should be color-space agnostic, not privilege e.g. sRGB
<fantasai> lea: It should be compatible with HDR
<fantasai> lea: It needs to be extensible
<fantasai> lea: a native API is less extensible than a library, but good ot add extensibility
<fantasai> lea: And API should follow layered design
<fantasai> lea: so usable by non-experts
<fantasai> lea: but also useful for experts
<fantasai> chris: This is difference between color library we wrote, and color API for the platform
<fantasai> chris: our library had everything we could think of that could be useful
<fantasai> chris: tries to do everything out of the box
<fantasai> chris: but for color API, should be core set, that you can extend if needed
<fantasai> lea: Whole debate started a few months ago because there was a proposal by Canvas to accept and produce CSSColorValue objects
<fantasai> lea: This is an abstract CSSColorValue that inherits from CSSStyleValue
<fantasai> lea: part of typed OM
<fantasai> lea: Multiple subclasses that correspond to specific CSS syntactic constructs
<fantasai> lea: e.g. CSSRGB that corresponds to rgb()
<fantasai> lea: CSSHSL
<fantasai> lea: CSSColor that's a color() function
<fantasai> lea: each has different API shapes, getters for each argument
<fantasai> lea: also different constructors
<fantasai> lea: e.g. accepting red/green/blue positional arguments for rgb
<fantasai> lea: There's a color space conversion function
<fantasai> lea: it's an early-stage spec, no impls yet
<fantasai> lea: Advantage of using it everywhere is there would be only one object
<fantasai> lea: and good integration with CSS out of the box
<fantasai> lea: downsides revolve around the issue that CSS Color Value is designed to represent syntactic constructs
<fantasai> lea: not actual color points
<fantasai> lea: e.g. there are two variants for rgb
<fantasai> lea: one for rgb() fucntion, one for color() function
<fantasai> lea: you get diferent objects for these
<fantasai> lea: also it's not a string, but csskeywordvalue
<fantasai> lea: and coordinates are values, so need to do color.r.value to read the value
<fantasai> lea: because this is all for represnting parsed syntax
<fantasai> lea: these are not issues that can be solved by iterating on the API design
<fantasai> lea: although it has improved a lot since original
<fantasai> lea: because it is exiting for syntactic purpsose
<fantasai> lea: if we make it easier to use for color points, it will become more difficult for the uses it was designed for
<fantasai> lea: Stepping back, chris and I designed a library for color
<fantasai> lea: There was CSS meeting where we resolved to learn from this work and design a color API
<fantasai> lea: We drafted a spec [links here]
<fantasai> lea: ...
<fantasai> lea: API has improved quite a lot, even this week, since Tab sent us some very nice feedback
<fantasai> lea: Review the design
<fantasai> [slide 10]
<Rossen_> https://docs.google.com/presentation/d/1Pkcxwdej2nWqYr0F6dYHpxcMaUMb11w_YmbZmcUV6Gc/edit?usp=sharing
<chris> links are in the slides which will be sent after the call
<fantasai> lea: ...
<fantasai> lea: Color spaces represented by colorspace object
<fantasai> lea: color.alpha is a number
<Rossen_> CSS Color Value draft: https://drafts.css-houdini.org/css-typed-om/#colorvalue-objects
<chris> https://projects.verou.me/color-api/
<fantasai> lea: right now all mutable, but that's under discussion
<fantasai> lea: Color spaces are represented by ColorSpace objects
<chris> Draft explainer: https://github.com/LeaVerou/color-api
<Rossen_> Color Object draft: https://projects.verou.me/color-api/
<fantasai> lea: registried in ColroSpace.register() or can be anonymous
<fantasai> lea: would be nice to make happen
<fantasai> lea: but difficult to design API to not be less usable for common case
<fantasai> lea: color spaces are represnted by ID so don't have to look up objects
<fantasai> lea: color spaces declare their white point, coords, gamut, and conversion code to/from existing space
<fantasai> lea: so you delcare your base, and provide functions to base and from base
<fantasai> lea: this could create a tree of conversions, but in practice it's one or two hops
<fantasai> lea: e.g. hsl has base of srgb, but srgb would have a base of xyz
<fantasai> lea: I originaly designed to have an ICC profile, but that would make everything async
<fantasai> lea: so have a separate API that returns a promise to load profile
<fantasai> lea: once registered, cannot unregister color profile
<fantasai> [slide 12]
<fantasai> lea: have getters to get coordinates
<fantasai> lea: and set functions to maniuplate in any color space, which can be relative
<fantasai> lea: can be provided by object literal as well
<fantasai> lea: Gamut mapping is optional. Every is lossless by default
<fantasai> lea: shoudl be able to roundtrip without losses
<fantasai> chris: This is needed for ??? e.g. WebGPU
<fantasai> chris: if you set up canvas in P3, things might be out of gamut, but need to calculate
<fantasai> chris: can always ask to put in gamut if you want
<fantasai> lea: There are functions for toGamut mapping
<fantasai> lea: by default use LCH chroma, but can be any coordiante in any coordinate space
<fantasai> lea: unsure what to do with nonsensical
<fantasai> [slide 14]
<fantasai> lea: How do declare polar color space?
<fantasai> lea: What is a color space?
<fantasai> lea: various representations of srgb are all in the same color space, but treated differently...
<fantasai> lea: should there be some API level distinction between that and different color spaces?
<fantasai> lea: ...
<fantasai> lea: But there are some benefits to mutability as well
<fantasai> lea: also how to do HDR tone mapping?
<fantasai> lea: and what would be interaction between Color API and CSS
<fantasai> lea: would registered color spaces become available to CSS?
<fantasai> lea: do color spaces declared via @color-profile become registered ColorSpace objects once profile loads?
<fantasai> Rossen_: Thanks for clarifying discussion here and providing a lot of synthesized ifno
<fantasai> Rossen_: There's a lot of density
<florian> q+
<Rossen__> Why/who really needs this? Is CSSColorValue of Color object the right way for exposure?
<fantasai> Rossen_: The two primary questions that I took away from the discussion and overview are
<fantasai> Rossen_: challenge by pal, do we really need this?
<fantasai> Rossen_: that's one we can cover quickly
<fantasai> Rossen_: other one is, if we can walk away from this discussion with defining if CSS Color Value or Color Object is the right way to move forward
<fantasai> Rossen_: details can be worked through in GH issues
<fantasai> TabAtkins: Earlier I was a pretty big proponent of doing this all in CSS Typed OM space
<fantasai> TabAtkins: after more thought and seeing this proposal
<fantasai> TabAtkins: I am convinced that, while we have some open issues that I think those are solvable
<fantasai> TabAtkins: I think this would present a substantially more usable API to people
<fantasai> TabAtkins: than trying to do it all within TypedOM
<fantasai> TabAtkins: And as Lea said, means don't have to contort TypedOM to fit use cases
<fantasai> TabAtkins: I've done a bunch of work with color, would have loved to have an API like this
<fantasai> Rossen_: One question, does this render CSS Color Value out of the conversation?
<chris> Lea's slides: https://lists.w3.org/Archives/Public/www-archive/2021Jul/att-0004/Towards_a_Color_API_for_the_Web_Platform.pdf
<fantasai> TabAtkins: We still need to represent color values in CSS via TypedOM
<fantasai> TabAtkins: there's just less pressure to do convenience methods in TypedOM
<fantasai> TabAtkins: Some things like converting between functions might still do, but don't have to worry about extensibility to author color spaces. Can leave that to Color API
<Rossen__> ack florian
<fantasai> florian: To me the motivation for this makes complete sense
<fantasai> florian: but if have both, will they step on each others toes?
<plinss> q+
<fantasai> florian: There's other parts of platform also that consume colors, and we'll need to define what kind of colors they consume. Will it be one kind, both? Do we need conversion functions?
<fantasai> florian: If every API consumes both and have conversion functiosn.. should one be a library of the other?
<fantasai> TabAtkins: What is the preferred shape for color-consuming functions is a key question
<fantasai> TabAtkins: wrt conversions, already define how to create one from the other
<fantasai> TabAtkins: but whether we end up preferring one for APIs like eydropper or whatever
<fantasai> TabAtkins: or say that APIs should handle both, is something need to still answer
<fantasai> TabAtkins: make sure TAG is aware of this question
<chris> s/for ???/for non colormanaged APIs/
<fantasai> TabAtkins: If we only do one, I suspect color api is the one we want to do
<fantasai> TabAtkins: but might want to accept both
<fantasai> chris: Also point out that while we think of CSS as main consumer, there's also Canvas
<fantasai> chris: which has some color spaces not in CSS
<Rossen__> q?
<fantasai> lea: Also ....
<fantasai> lea: You can't always derive specific numbers for a CSS color, e.g. can have a calc() expression
<fantasai> florian: Can it be resolved down to a single value?
<chris> sRGB-linear and rec2020-linear are the two I am thinking of here
<fantasai> lea: What if you have a number that's viewport units divided by pixels?
<fantasai> TabAtkins: and if you use 'em' it's element-specific context
<fantasai> florian: So you'd need to throw if try to convert and it needs a context but doesn't have one
<chris> q?
<smfr> q+
<hober> q?
<fantasai> plinss: Wrt API used in other places in the platform, don't have to solve here, can take to TAG
<fantasai> plinss: My take is any input probably fine, but output must be Color API
<fantasai> plinss: I'm glad to see both these APIs being developed
<fantasai> plinss: What I really want is one object that really focuses on doing color right, and one object that does CSS right
<fantasai> plinss: overlap, later
<fantasai> plinss: I'm fine with one set of classes if it would be good fit for both uses, but I don't think this is the case
<fantasai> plinss: ...
<fantasai> plinss: color object should be underlying object for doing the work
<Rossen__> ack smfr
<smfr> my audio is broken
<smfr> will type
<smfr> first comment:
<smfr> yes
<smfr> can hear
<smfr> 1. should color objects be immutable?
<smfr> must less ambiguity about what happens when live color obejcts change
<smfr> maybe design the api initially with immutable colors
<smfr> mutability brings lots of complexity
<fantasai> TabAtkins: what do you mean?
<smfr> i will try to call back in
<fantasai> lea: you get a reference to a color object, use it, and someone else changes it, what happens
<fantasai> ??: might be useful actually
<fantasai> ???: does it animate or what?
<smfr> (lost the link)
<fantasai> pal: meta question, a lot of this stuff sounds cool and fun, but I'd like to better undertand the target applications and users
<fantasai> pal: otherwise black hole
<fantasai> chris: ...
<fantasai> chris: Risk is we get shipping subsets that are useful only for this or that which is shipping
<fantasai> pal: Question of mutable vs immutable, how can we answer the question without understanding the use cases?
<fantasai> Rossen__: So question is, is this behind the Color API itself or CSS Color
<fantasai> Rossen__: I think we have a pretty good answer
<fantasai> Rossen__: once this is answered then we can go after your question
<chris> rossen, please suggest a resolution because as you said we are close
<fantasai> smfr: If color objects are long-lived and assign them to different things [cut]
<fantasai> TabAtkins: API that bends a color, or ... hold a reference to that color
<fantasai> TabAtkins: automatically changes the color used
<fantasai> TabAtkins: we very specifically didn't do that for TypedOM
<fantasai> TabAtkins: and I expect we would conclude the same here
<TabAtkins> s/bends/vends/
<fantasai> [smfr continues to have audio problems; fantasai suggests dialing in by phone, possibly using the dial-in code in the video app audio options menu]
<fantasai> Rossen__: What I'm hearing is the Color object in the way that was proposed by Lea and Chris in that spec and explainer is the preferred path forward
<fantasai> Rossen__: Anyone objecting to that path forward?
<fantasai> florian: is the use case question about should we have this at all or about design?
<fantasai> Rossen__: ok let's take that resolution
<fantasai> RESOLVED: Add Color API for representing color points, separate from CSSColorValue to represent CSS color values
<fantasai> Rossen__: Next question is do we actually need this
<fantasai> pal: That's not my question. My question is who are the users? what are the use cases being targetted?
<fantasai> florian: Do you question that there are any? or that if we don't understand the users, we can't do it right?
<fantasai> pal: The latter
<fantasai> pal: There's many color spaces
<fantasai> pal: there's a complete zoo of this stuff
<fantasai> pal: NxN issue
<fantasai> chris: No, it's not
<fantasai> pal: to convert from any space to any other space
<fantasai> TabAtkins: That's what the interconnect space is for
<fantasai> pal: [gives some complicated example]
<fantasai> pal: How can you go through a connecter space?
<smfr> q+
<fantasai> pal: Lke REC709 are defined from camera, so optical to electrical transfer function
<fantasai> pal: but inverse is not defined
<fantasai> pal: depends on context
<fantasai> pal: not just only math
<fantasai> pal: all I'm asking is what are the use cases?
<fantasai> pal: what are we trying to do?
<fantasai> Rossen__: one obvious use case is to ahve an actual object so we don't pass strings which are typeless and lose meaning from one object to the other
<chris> image referred vs scene referred is what Pierre is refering to here, I think
<fantasai> Rossen__: I hope we all agree that this is neede for user point of view and perf
<fantasai> pal: no question there
<chris> There are some taks at the Color workshop about this by the way
<fantasai> Rossen__: whether or not this object needs to cover all possible color spaces and their interaction, I think this is more of your line of questioning
<fantasai> pal: wrt string vs object, definitely want an object
<fantasai> pal: I think that sounds like a great idea
<chris> s/taks/talks/
<fantasai> Rossen__: so remaining question is, do we have enough use cases that support having color spaces as an API functionality, what are these color spaces, where do we star/tend
<fantasai> pal: you define the object
<fantasai> pal: question is, do you define reference transformation
<fantasai> pal: assume this object has a color space and coords
<fantasai> pal: should the web platform define reference transforms between istances of this class associated with various color spaces, and what are they
<fantasai> pal: until we've answered what use cases we're targetting will be hard to answer that question
<fantasai> pal: easy to go crazy
<fantasai> chris: that's why we made this library
<fantasai> chris: if just talking about color metric conversion, can have singel transform
<fantasai> chris: as soon as ... e.g. hdr to sgr, then ...
<fantasai> pal: I don't agree, in case of 709 there's not a singe inverse transfer function used today
<chris> q+
<fantasai> pal: so web could decide to just pick one. And actually that might really help the world.
<fantasai> pal: but not something to do lightly
<fantasai> pal: really need to understand retargetting
<fantasai> lea: it's OK to restrict the scope at first
<fantasai> lea: maybe we decide that some color spaces are out of scope for L1
<fantasai> lea: some are already out of scope for current design, e.g. index colors
<fantasai> pal: I really like the suggestion
<fantasai> pal: maybe for first pass, just replicate everything in srgb
<fantasai> pal: make sure everything works there
<fantasai> TabAtkins: CSS is already past SRGB, so already need more
<fantasai> pal: ok, then pick that
<fantasai> pal: If we all agree to moving from string to object, then validate that and grow from there
<fantasai> florian: need object we can do something with
<chris> https://www.w3.org/Graphics/Color/Workshop/talks.html
<fantasai> chris: In few seconds remaininng, questions pal raised, many were covered in the color workshop ^
<fantasai> Rossen__: proposed path forward of scoping what we can do here
<chris> s/were/will be/
<fantasai> Rossen__: scoping to CSS is valid path forward, start from there
<smfr> q-
<fantasai> Rossen__: where is this work going to happen?
<smfr> out of time
<fantasai> chris: currently in private repo...
<pal> q+
<fantasai> Rossen__: ok, open in WICG
<chris> q-
<Rossen__> ack pal
<TabAtkins> It sounds like the hard part of Pierre's question is around more exotic spaces anyway, which are *not* going to be supported as built-ins; they could just be added as author-defined ones, where these choices presumably can be made by the author, right?
<fantasai> pal: I think if the goal is to include video and image applications
<fantasai> pal: WICG isn't the right place, won't get the right people
<fantasai> pal: any color cg or whatever would be good
<fantasai> lea: what about a task force?
<Rossen__> q?
<fantasai> TabAtkins: Point of WICG is to gather the people you need before you choose a venue
<fantasai> pal: But WICG is way too high bandwidth
<fantasai> TabAtkins: you don't subscribe to everything, you subscribe to the specific repo
<fantasai> lea: We don't need all video people, just a few
<fantasai> pal: Happy to point ppl to the repo, but they'll also want to discuss it
<fantasai> pal: some issues best discussed live
<chris> color cg had a lot of good discussion on related topics already
<fantasai> florian: Point of WICG is to be a place for "I haven't created a group yet"
<Rossen__> q?
<fantasai> chris: ... already has the right people
<fantasai> chris: but can't do spec work
<fantasai> Rossen__: so let's pursue WICG and if it doesn't work, can transition out of there
<TabAtkins> fantasai: Seems like we wanna start with at least covering all the CSS and canvas color spaces
<TabAtkins> fantasai: So we can resolve on that at least
<TabAtkins> fantasai: Even without drafting up a more extensive use-cases doc
<TabAtkins> fantasai: and then maybe chris, lea, pierre can draft up the explanation of use-cases that pierre is looking for
<TabAtkins> Rossen_: Perfect, TAG loves to see use-cases right at front
<TabAtkins> fantasai: So take a resolution?
<TabAtkins> Rossen_: objections?
<TabAtkins> RESOLVED: Color API should handle all the color spaces currently specced for the web platform.
<TabAtkins> fantasai: On process, when do you spin out of WICG?
<TabAtkins> Rossen_: when we have impl interest
<fantasai> fantasai: We often have the case that things spin up in WICG and never spin out
<fantasai> florian: Implementer isn't strictly required, just need a community that is happy to charter the work, however you manage to get that
<florian> s/that/that. Implementer interest certainly helps with that, but it's not a formal condition/

@svgeesus
Copy link
Contributor

slides

@svgeesus
Copy link
Contributor

svgeesus commented Mar 7, 2024

The Color API is now under WICG and implements the two resolutions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants