W3C Workshop
on Wide Color Gamut
and High Dynamic Range
for the Web

The path towards richer colors in Chromium

view presentation by Felipe Erias (Igalia)

Chris Lilley Felipe Erias, would you like to talk about what your doing, and what you have done, and what remains to be done.

Felipe Erias Hello. Can you hear me? It is Felipe Erias. I for the past year and a half I have been working on the chromium browser implementing different CSS properties. My talk was about research that I have been working on, planning to see the scope of the work needed to implement support for higher color, richer color basis in the chromium browser.

It is on one hand, it is doable, and on the other, there are some technical challenges, some complex areas that we think need to be studied in the future.

Chris Lilley You mention the back end has the option for higher precision float colors. It wasn't clear from your talk, and I didn't look it up in the documentation: these floats, they can be negative, they may be greater than one or are they restricted to 0-1 I'm wondering?

Felipe Erias As far as I could tell, they are not restricted although Skia only supports a small number of color spaces out of the box. A color space, it is clearly the combination of transfer function or gamma and the matrix relative to the X, Y, Z color space, it only supports a few of those, fewer than half of those out of the box. You could implement your own color spaces I think but I haven't looked at that in detail.

For these color spaces, the definition follows an RGB structure. It wouldn't fit naturally with something like Lab, something like that. It is a new degree, something like that.

There will have to be a step of transforming that color into a higher precision version that have color for it to understand.

Chris Lilley Right. Looking at your slide I see that CIE X, Y, Z is supported which would be one route forward. Also BT.2020 is supported, with linear as a transfer function. It seems like you would have an easy route through there that you could convert through either of those. Basically you could implement them on top of that and convert; it also means though that for interpolation you have to implement it yourself, that's a pain.

Felipe Erias Yeah. You would have to do that yourself. It does the interpolation in sRGB and basically what that means, I think it is similar to how it is going in PDF from the other talk in the section, you define a number of intermediate steps to answer the interpolation and then during those and then you approximate the interpolation in the designed color spaces.

Lea Verou Does it offer any other interpolation options as well or only the gamma encoded sRGB?

Felipe Erias I don't think it does. It is only sRGB. Yeah.

Chris Lilley Any questions for Felipe Erias about this?

Ken Greenebaum I have a random question. I'm from Apple. As you know, we're big fans of the extended range representations and I'm sorry, I'm coming in kind of cold and just dropping in.

It sounds like you're trying to express more gamut and you have floating point and then you have existing color spaces, maybe this is one of them. Have you considered using extended range sRGB, basically you can represent wider colors negative and then use the negative ranges of the color point to mathematically represent those colors? That math falls naturally out of the matrix such as you want to represent the laser red relative to SRGB, one of the red component won't change by very much, but the green and the blue components would be driven slightly negative representing the laser red because then you're subtracting the energy from the green and blue channel, the red would exceed unity by a tiny bit. It may be confusing perhaps. It is a new thing for developers to understand that RGB values can exceed one and go negative.

It evidently shoe horns pretty much any color that you can see and imaginary colors. You had all negative components from red, green, blue. That's imaginary.

That's my kind of modest proposal for how to fit pretty much unlimited gamut in terms of saturation of color and also in terms of brightness because you have very, very bright values represented by going significantly above 1.0.

Chris Lilley If I could respond to you, Ken, firstly, yes, in my experience most developers find this extremely troubling.

The idea of taking red to two is turning up the brightness and that is HDR and they're super fine with that. As soon as you say minus 0.3 green they're like mind blown! But yes, clearly extended range representations can do that.

Secondly, the support in terms of gamut, the Adobe RGB, BT.2020, X, Y, Z, I guess it would work, and the transfer functions has the sRGB one which is used by display-p3 and has the linear Rec 2100 and also supports the PQ and HLG transfer functions so there is room there for HDR as well.

Yes. It is very easy, Windows does this a lot. It takes basically the sRGB, the linear transfer function and then you have any gamut you want from that. People often seem to trip up over this. We had a big discussion in the working group about color-mix(), people said what happens if someone supplies a negative value. We have to trap this and throw an error! No. It is fine. Everyone was like no, no, no, nobody will understand this. The discussion, almost nobody understood it.

The math just works. It is very simple.

Lea Verou I have a question for Ken. I was a little confused if this is a proposal to Felipe Erias about how they could represent wide gamut colors or is this a proposal for CSS when you started speaking, it sounded like it was the former, then it sort of sounded like the latter. I wasn't sure. It is a different response depending on what it is.

Ken Greenebaum Yes. You may have noticed that my thoughts weren't completely formed.

Potentially it could be for both. One thing that's nice (other than potentially confusing folks) is it allows us to use potentially existing interfaces and then in terms of confusing folk, there could be a helper for generating colors if you want to exceed whatever the needed gamut. A nice aspect, if developers and, perhaps I'm one of them, if we think in terms of relative to sRGB colors, those still work, all the constants still work and if they want something special, there could be a helper function that would be used to generate those scary negative values.

Chris Lilley In terms of APIs, I'll drop it right at the end, for the API that Lea is talking about, it has exactly that extended range representation.

I should just point out as well that in CSS Color 4, originally all of the transfer functions were defined from the 0 to 1 range and they're all updated now so that they're defined with the extended range without having anything special. It just say what is you do, it flips the curve and defined exactly what you do.

What we don't have, we have a definition for linear sRGB, which you can link to and it is not exposed as CSS syntax, this is a question, is there value in exposing that to the users, if that's the way you want to think about it, maybe they are doing canvas and CSS at the same time and they want to express it the same way and they want to have the linear sRGB with negative values.

Felipe Erias You have the added value, you would need to qualify that you have the color space information, it is just the sRGB gamut as a base, then you say this clear, it is outside of that, but by this much, which is the exact point.

Chris Lilley Yeah. Yeah.

Felipe Erias I get it. I get it.

I think it is interesting. I hadn't considered it already. I didn't even know that it was something that people do.

I think it could work or be explored for the internal implementation. I don't think it is really intuitive for developers to think this way. I mean, I happen to know more or less where the concept comes from, you know, from color and so on, but maybe it is not intuitive.

If it works, which it should do, I mean, it does, then it is an interesting concept, it doesn't have the internal implementations and we can simplify a lot of the computation and memory requirements if you're able to represent all of the colors in one common way.

Lea Verou What I wanted to say, if this is about implementation in Chrome, I don't have much of an opinion. If this is how the developers specify colors there is existing human factors literature that humans do not actually find RGB that intuitive, it is just that developers have been beaten into it, by having to use RGB repeatedly because this is what is taught and what they're exposed to. Also there is a bunch of other problems with using any RGB color space to define colors, like lack of perceptual uniformity, so there is on that CSS color specifying all of the other color spaces that's two fold, one is to go beyond the sRGB gamut and the other is to provide color spaces that are more intuitive for humans to specify and reason about and create modifications of.

Chris Lilley That's very true. That's why we we lead off the spec with LAB and LCH and we say by the way, you have predefined RGB spaces too if you want.

Dmitry Kazakov People from visual effects area hate negative values.

Chris Lilley There is a comment in chat from Dmitry saying people from the visual effects area hate these negative values and I have heard that also. I also think that apparently there are some implementations that mis-treat negative values, they wrap them around. As soon as you go to the negative, you go to the max value and it would be visually disturbing shall we say?

Dmitry, was that the main point or anything else to add to that? You are muted ... I guess not.

Any more comments before we move on?

Chris Needham I have one.

I'm interested whether you have given thought to what the performance implications may be to using the color representations. You mentioned in the talk that everything is currently handled through 32 bit values, so yeah if there is a potential rendering performance issue, do you think?

Felipe Erias The main impact, it is in terms of memory. At the moment internal only uses the eight bit space color. The colors are in line and then it is moved around.

For a higher precision color, then they create the separate object, only when they need it with a reference count. That's complicated in the implementation.

I think I was talking with somebody the other day that mentioned that there could be some recent changes in the rendering code and that mean this representation of colors would not necessarily have higher impact on that side of the rendering pipeline. At least if they're not used, then they are transformed to a smaller representation.

I think I was talking with somebody the other day that mentioned that there could be some recent changes in the rendering code and that mean this representation of colors would not necessarily have higher impact on that side of the rendering pipeline. At least if they're not used, then they are transformed to a smaller representation.

Yeah

I think memory is the biggest issue, the most immediate one that I'm looking at at the moment, especially when it comes to gradients it spills over with the percentage and so on. It might have a big impact if you just multiply by 4 the size of all colors in the system. There has to be something more elaborate. How they say that, that's pretty much how it works in WebKit and their performance, I don't know if they had any particular issues on that sense, and I don't know if that's even possible.

Simon Fraser I could speak a little bit about WebKit, there are two important distinctions here, there are objects that represents colors in the super class version of the CSS model object, right. Those are the ones that Felipe Erias had mentioned in WebKit, we have the colors in, the wide color spaces, we have the bit set and then we have the side object, it is what contains the float representations of the colors.

We will only allocate that if the authors specified the colors in display P3 (or deeper) color spaces.

Most pages don't do that for all of the colors. Only a few of the objects generally for a lot of pages so that the performance impact is minimal.

The other thing that's important to consider, the rendering and the compositing, that's a whole separate decision on whether that should be 8 bits or floating point, or half float, and currently we have sort of a different situation on Mac and on iOS and we use the 10 bit colors for most of our iOS devices and on Mac we use the 8 bit for the compositing textures. Note that compositing float path is not the point at this stage, although some point in the future we may go there. It has certainly significant memory cost and performance costs.

In general, the performance overhead of using deep colors, it is small right now. At some point in the future if we decide the whole compositing pipeline should be half float texture, you know, that's a decision that we'll make based on the highlight performance and stuff.

Those are the kind of the considerations around performance.

Lea Verou I have a question

Chris Lilley Go ahead.

Lea Verou If I understand this correctly, does that mean that the reason this is in WebKit today is that websites don't use it much; if websites start to specify every single color using LCH, Lab for example, does that mean it will start being slower?

Simon Fraser It is possible, if there are thousands of colors we may go see some performance impact. That's true.

If the content is not specifying the colors but they're in the gamut, we could use that path and we don't currently do that, we don't always go to the float components in that case.

Generally websites don't specify thousands of colors, right. Hundreds may be, but not thousands. I think the overhead of float component colors on the CSS side is really not too large.

Chris Lilley That's the 10bit on the extras, if there is conversion, you have done that to get them to 10 bits?

Simon Fraser Yes. I believe we actually don't follow the spec to the letter. We do the compositing and we don't do that compositing in the way CSS says we should do. Display space is generally close enough and all of the compositing we do, on both platforms, in the color space the display is using, which ends up being the display or something close.

Those 10 bit textures are in display p3.

Chris Lilley It is interesting that you have this, is that related to the frame buffer and that sort of thing, using the hardware? I'm curious as to that decision.

Simon Fraser I believe that's simply what the GPU supports, it may change with that, I'm not sure. It is a historical thing for what the GPUs can support with performance.

Ken Greenebaum Are you using SIF10, is that the 10 bit?

Simon Fraser Yes. That's right. It is, yeah. The two plain format(??).

Ken Greenebaum That's all public information, that's an extended range format incidentally. That's our kind of clever way of getting wide gamut into the iOS‑based hardware in that manner. That's a representation that has 9 bits dedicated for this means 0 to 1.0 range, the half bit, think about it, that's half of the codes, they're asymmetrically allocated to value that's above one. It represent as negative .75 to 1.25 range in the 2.2 gamma and it gets us to 1.6 linear; a half stop of what I call EDR, extended dynamic range.

One small thought about bit precision, I don't know how you all think about it. I like to think about it as setting the noise floor in such a way that, any time you quantitize, you should provide a dither to de-correlate the quantization error that's there regardless in a way that higher precision is really only giving you a lower noise floor.

If you don't require that dither you could get banding.

Chris Lilley Are you quantizing when you go to the texture?

Ken Greenebaum Generally speaking, you are referring to the gamut map, so all of those operations should be performed in a high‑precision space and then before you go back out to whatever your pixel representations are, quantitize that to 8 bit, 10 bit, however many, you should provide dither for the truncation.

Chris Lilley That's standard practice in audio, I hear about it less for visual stuff.

Ken Greenebaum I agree, the audio folk were out ahead in terms of the numerical science.

Chris Lilley I think that was a very useful discussion.

CSS-Color-4 for Print

view presentation by Mike Bremford (BFO)

Chris Lilley Mike, I invite you to start talking about your presentation.

You have a very different implementation because you're not a browser, you're going to PDF and PDF has a certain set of capabilities. On the other hand, the browsers are going on a graphic library. It is maybe not that different. Over to you.

Mike Bremford (No audio)

Lea Verou We can't hear you.

Chris Lilley Not hearing anything from you.

Mike Bremford Is that better?

Lea Verou That works.

Chris Lilley Yeah.

Mike Bremford Technology!

My name is Mike. We, as Chris said, we do PDF output and our recent project has been taking HTML and CSS with the CSS Color 4 and rendering from that.

The different set of problems, really compared to what everybody else has. We have a high gamut color model, we have ICC profiles, we have color and it was very much a question of trying to smash the square Peg that we see as Color 4 into a round hole, the PDF color without breaking too many concepts.

Which we mostly achieve, I think.

In terms of changes for the future for us, I think it is largely trying to play catch up by the sound of it, if Sam and Apple have moved on, we'll update our code to match what they have done I suppose. I have to confess, I haven't followed this in the last six months, I think I have a bit to catch up on by the sound of it.

Chris Lilley Yeah. That's about it.

Mike Bremford Yeah, PDF gets a lot of options with us, we have done crazy things but we happen to sample and split the curve if we have to, which is cheap and universal.

(scribe missed)

(someone) (question on PDF supported color spaces)

Mike Bremford Yes. Interesting. It seems there is fairly limited support for color spaces other than Lab and in various display engines, including Acrobat, things aren't necessarily following that spec. That's a different problem for us.

We generate the documents correctly as far as we're concerned and it is somebody else's problem. When it comes to printing these, it is the same problem again.

It is very interesting and they get us out of a lot of problems with the gradients. Also, of course, mesh gradients, which we would love to see come back to SVG. Someday, one day.

(scribe missed)

Mike Bremford don't think it will serve a huge problem for us, we don't have the activities, it very much causes a fixed value before going to the document and it becomes academic in that point. it is not a real huge issue.

This is without having tried. It should be fine.

Chris Lilley Any comments or questions?

Marc Jeanmougin I'm very much interested in this work.

We have similar problems with, of course, SVG and the PDF. We're delighted to see others are interested in these because up until recently there was only us and recently there is the locateur and review. Feel free to state that.

We are also interested in the discussions because of the gradient problem, where do we interpolation the gradients. We have longstanding work of implementing the CSS color 4 specification because we used to use this with ICC profiles thinking SVG which, I'm not sure, I think was removed, because of the new CSS, but it seems that Color 4 is not yet released and it is a bit of a strange situation because we don't have any equivalent currently.

If you don't know yet how to interpolation the color in color space, obviously the color spaces can be a bit of a problem.

What you're doing basically, that's something interesting. If you want to interact with the community, with me, others, we'll be happy to discuss with you.

Mike Bremford I have been meaning to get in touch on that in particular, mesh gradient, and the other aspect, it never did work out, it was the interpolation movie, at the moment we have hard edges, and we have the two company churrs meeting, and you gees have got a wonderful idea with interpolation bicubic curves I believe and I couldn't figure out the math for that at all and I spend a lot of time on it.

If you get in touch with this, you take that out(??) in terms of the interpolation, I should add that when I did that presentation, we hadn't really looked at the interpolation, it was always an MLB(??), I think it is still sort of being kicked around at that point. it does make our life a bit easier in terms of not doing the interpolation with HLH(??), but the slides, they're now pointless.

I'm doing my best.

We really are tracking what you're doing as well. It is very interesting to watch and see it evolve.

Chris Lilley CSS Color 4 has seen a lot more implementation, a lot more feedback with all of the comments on GitHub and sure, it is not a Candidate Recommendation yet, but is soon going to be.

I would recommend pushing for that in Inkscape, not only does that make SVG and CSS the same, using the same syntax, but it has had a lot more development effort put into it.

I would like to invite Lea Verou to talk about the interpolation, you wrote that portion of the spec about gradients, and color interpolation.

Lea Verou We went through various different designs. Basically one of the issues was that currently CSS gradients and transitions, they interpolate in gamma-encoded sRGB which we all know is terrible.

We can't change how they intepolate in the websites for web compat reasons. How do we define the reasonable interpretation intepolating without specifying what they really want for example, there are reasonable defaults we could have.

I think if I remember it right, what we ended up currently is if both colors are in a legacy format, legacy is basically all of the existing sRGB colors that existed in CSS color three, then they're determined unless the host syntax says otherwise and the host context could be — it is different depending where you're using it, in a gradient, it is a parameter in that and in functions we don't know yet, may be a separate property. Basically everything in CSS needs to be retro fitted to allow for specifying how the interpolation happens and you don't want the same interpolation space for everything. You don't want the general color interpolation property like SVG used to define I think.

Legacy formats interpolate in the default sRGB colorspace, and everything else is in CIE Lab by default I think. Is that correct, Chris, do you remember?

Chris Lilley Yes. That's correct.

Lea Verou Which produces much better results. Much closer to what a designer would create by hand tweaking, which they currently do, a lot of the time.

The host syntax can also specify not just the interpolation space but also sometimes more parameters like if you have a hue-based space, an angular space, you also need to be able to specify how do you interpolate on the hue angle, the shortest arc, the longest arc ...

Chris Lilley To add on to that, compositing is another thing, and you need to upgrade that to allow a linear-light format, that's the obvious choice for the non‑legacy color formats.

Marc, you have a comment on the chat? Saying you're not sure where Cairo allows you to interpolate in the non-sRGB, is that because you don't know or because you have looked and it is difficult?

Marc Jeanmougin I don't know. I don't think it can. I'm pretty sure it cannot. I think it is internal with the 32 bit format.

I'm a bit sad about the state of Cairo, it is very stable but I'm not ready to switch to Skia.

Lea Verou In my experience, you tend to get really good results by just inserting hidden intermediate stops and using the default interpolation, it is not the same but it is pretty acceptable for most cases with not a huge number of intermediate stops.

Chris Lilley You can count deltaE and when it is below acceptability, you add a stop

Mike Bremford We found we needed a lot less stops than I expected.

Chris Lilley Mike, thank you very much for the discussion.

Towards a Color API for the Web Platform

view presentation by Lea Verou (MIT)

Chris Lilley Lea, I invite you to summarize what your talk is about and we'll get the discussion going on there. This is moving on a little bit from CSS exactly, but it is an object model and it is not the CSS Object Model: it is more of a color model for the web as a whole.

Lea Verou Hey, everyone. I'm Lea Verou. I'm a member of the W3C TAG and CSS Working Group member, I edited several of the specs including the Color 5 and Images 3 and 4 which is where the gradients are defined.

Also my day job is human computer interaction research at MIT, influencing my perspective to be focused on usability in the API design.

This work started with a joint work with Chris Lilley on color.js. There are two strong needs for the web platform today, a bunch of web APIs need to be able to represent colors in some way, both as input and output, and right now there is nothing on the web platform for this, what APIs tend to be doing, using strings to take the colors and the developers can't do anything with the strings. Sort of just passing them manually and extracting the components themselves, with disastrous results often.

Also there is no way for the developers to do anything with the colors. There is no way for them to do manipulation or to change the color space, to calculate the difference between them. There was a strong need that we need this color API, especially after reviewing the APIs recently in the TAG like the eye dropper API and we didn't really know what to tell them because it was very obvious to us that such an API is needed on the web platform and there was nothing yet so what feedback do we give people? There were some break I couldn't tell discussions with the working group, we briefly considered using the color value which is a CSS Typed OM object that's defined, not implemented yet. We soon decided a color object to be a good idea and we moved towards designing an entirely new API, a color object that represents a color space agnostic color point, by basically storing a color space reference and the set of coordinates and an alpha.

There are also convenience methods for converting between color spaces, manipulating coordinates in different color spaces, calculating color differences, and so on. There are a bunch of open design issues about the design of the color object, the API, what it should look like, obviously it needs to be as flexible as possible, as extensible as possible.

Even things like the gamut map, when do you do that, how do the authors explicitly opt into that, and that sort of thing, what is the minimum API surface that they need to be able to define their own color spaces and we didn't want to duplicate the JavaScript and others, how do we give them the flexibility to define their own color spaces with decent usability, so on, that was the main thing that my talk was about.

Chris Lilley Any questions for Lea?

No? It seems everybody agrees with every single decision that you made :)

Max Derhak I have a question. A lot has been discussed about CIE LAB and LCH. I'm trying to understand what is the illuminant here and how does LAB with the high dynamic range factor in.

Chris Lilley Lea, do you want to take it?

Lea Verou You should take it. You have a lot of thoughts on it.

Chris Lilley Currently it is a D50 illuminant, which we do primarily because every implementation of Lab use uses that; and if you don't specify it, and if you're not using the chromatically adapted (corresponding) colors, it is going to be terrible. There has been criticism of that, mainly because most of the spaces used on the web have a D65 illuminant and not everyone is convinced the round-trip errors from two chromatic adaptation transform steps are negligible. Having tried this out with code, I think they are.

Another problem, it is that things like in WCAG, the luminance contrast is using D65, if you do that calculation in D50, you have the wrong result.

As we move to HDR, all of the spaces are D65. There has been some work, Fairchild I think did some work extending CIE LAB, they just extended L out to 400 and that was early work.

I don't think it was very convincing, things like HLG looked like a much better bet for relative luminance.

Ken, you have done work, Apple has an interesting Extended DR, it is not really full HDR but it is like SDR extended a bit, maybe you can tell us what's happening there?

Ken Greenebaum I'm not really sure which effort that you're referencing, I'm sorry. I have something called EDR.

Chris Lilley That was the one I was thinking of. Yeah.

Ken Greenebaum That's our attempt to make it very straightforward, backwardly compatible with all of the SDR that developers have done.

If developers have classically used logical 0 to 1 range, now we just allow all of the values to go above 1 and below zero.

We apply it in all kinds of any color spaces, but it is easiest for developers to apply it relative to linear FP16 and then they can set the rest of the color space to any primaries and white point.

Then in terms of white point, we believe pretty strongly that once you get away from the static reference viewing environments where white point was explicitly set we think it is important to have the white point of the display match the white point of the environment and by extension, where the user's eyes are adapted. I don't know if I answered your questions, however.

Chris Lilley That's very true.

Unless you have a massive and extremely bright display (or a dark room), then the primary adaptive stimulus is from the environment and not from the screen that you're looking at.

Ken Greenebaum You can use the CIECAM model to predict that. we try to adapt across all environments, including those where your primarily adapted to the display.

To make devices work out in the real world, there's a lot of adaptation that I believe you have to make the display map into the user adapted visual space.

That's also a key aspect of EDR. Right.

EDR, let's say HDR generally speaking is pretty fragile. You have to be in that dark reference environment for it to work, otherwise once the vision begins to adapt to something brighter in the environment you can't even see the inky blacks that maybe your expensive display can make. So it doesn't make a lot of sense to put the content into them.

We do a lot of adapted correlations.

Chris Lilley There is an open issue currently for color API that needs to expose the X, Y, Z but in what illuminant and in Color 4 it says, D50, and in color.js, the work that Lea and I did, we have multiple of these, we have the relative ones used internally and we have an absolute X, Y, Z, that's used for the HDR stuff and the question is which of these do you actually expose and I'm tending more to — X, Y, Z itself, it should be — I'm sorry, I always say Zed not Zee, deal with it — it should be the D65, that's what you want most of the time so therefore the chromatic adaptation to D50, it only happens as a subset of moving off to LAB.

I particularly think that my talk in another session, (I didn't finish it yet, it is almost done) it is arguing for a new color space called OKLab and they use a cubic transfer function and it doesn't have the hue curvature problem. I'll be talking about that in another session.

That's another push for going more to D65.

Did that answer your question, Max?

Max Derhak I thought it would be a problem with the illuminant but you pretty much identified that, thank you.

Chris Lilley Any more questions for Lea on the object model or any more questions in general to wrap up? (No)

Wrap-up

Chris Lilley In that case, I would like to point out, it is good to have people involved in this discussion, regardless of the fact they do not use this any more and it is described as a flaming pit and it is good to see general use of this resource going and still pushing on.

I feel very bad that there's been so much work done in the SVG implementations, most of which has been wasted or has fallen to the wayside. It is shown that it is perfectly possible, but the browsers have not picked it up.

I fervently hope as we move to a wider gamut world, that the great experience and implementation detail that these teams have got, we can make better use of the implementation work that they have done.

Marc Jeanmougin Do you think there is a chance that the SVG working group can go again or maybe to work in the 2.1 or whatever.

Chris Lilley The problem with that, all of the browsers have dropped off to participate.

Making a spec, reducing the test, pushing that forward One is the learning, the other is the detail, and effectively that's the work that's needing to be done for us in SVG2, it is not just cutting out what's not implemented, it is defining everything in detail so that it is exactly clear and the same with the others, what's happening. That's a lot of work, and it is boring work and nobody really wants to do it. That's the problem.

There so much stuff that's been prototyped out and it has been dropped again. There was vector effects, like filter effects to work on vectors, and you take a shape, you converge on that line and then you morph and you still have vectors. Fantastic stuff, specc'ed out 15 years ago, still not implemented though.

Marc Jeanmougin We could have that in the input, but the outputs ...

Chris Lilley Right. It is certainly possible for a group of people to work on the print or the authoring tool or into the version of SVG, and to some extent, it is an easier thing to do. What is the point if it wouldn't render in browsers, being able to take something between Inkscape and other programs and to keep the semantics, that would be great. In some ways though, that loses the point and that's the issue.

That's not to say it couldn't be done. Maybe there is a need for that community to push SVG.

Marc Jeanmougin There is a push for being more print oriented, like some people, they really want to do printing on the landscape and the lack of color management in CSS or the other, there is a problem for that and that's also one of the reasons why I'm here. CSS color 4 is a good step in terms of going to the color management and that's why I think that Mike's talk was also interesting. People don't print the SVG and the PDFs and people working on the web stuff to print stuff, and basically interactive, they like the interactions between the web world and the print world, it is something that's important to a lot of people.

There is a huge number of users.

Chris Lilley Yeah. I think that's true.

We're wrapping up here.

Okay. Thank you, everyone. Thank you, thank you to the presenters, thank you to Kelly for captioning.

The next session is on Friday. I'll send out details right after this call so people will know how to connect.