Version 1 (modified by Jon Davis, 7 years ago) (diff)


WebKit Contributor’s Meeting


How do web author’s know about wide-gamut displays in their markup?

Code Cleanup

  • deviceRGB vs. sRGB
  • Darin’s Color Reactoring

Designing content or wide-gamut displays

deviceRGB History
deviceRGB is from another era in WebKit, when it was just working on OS X (from KHTML). No colorspace correction.
Direct color going to the system. When added, it got really slow. Ruining the browser. Magic value deviceRGB was used to tell the graphics system to use the old fast code path. It is obsolete today. Saying RGB is essentially sRGB. deviceRGB is a fossil in our code. People didn’t understand it. Used 2 places: used for speed, used for specific purposes.

Our long nightmare is almost over. Most references have been removed.

Beth added attribute to make it look better as opposed to fast. Now we can do both, the attribute isn’t needed.

Darin approached refactoring to address the bad smell of color correction code. 32-bit int to tell what the color is rgba
You could pass 1 for the color which would mean transparent light blue.

Color refactoring: remove RGBa32.
isValid for null pointers. We love our null pointers.

The future of the color class is letting it hold whatever color from CSS. How do we encapsulate this to handle different formats?

Lessons learns:

  • A lot of special-case algorithms
    • Inverting colors
    • 5-6 places for darkening colors, each with different rules
    • canvas and CSS can specify color in HSL, CMYK
  • Special named values for colors
  • Multiple ways to convert NSColors to WebCoreColors; and back again

Any colorspace ops need to go through our new color class.
We currently support only one real different color space SRGB: linearized sRGB for SVG that we call Linear RGB. Filters code is affected by it.

Getting rid of deviceRGB things, replacing RGB int with a struct with rgba, took a few tests and made them test what they say they’re testing. Efficiency code to handle clamping because we didn’t get the data types right.

What are we going to do with the color class now?
What other agenda do we have for color?
Do other ports have color needs?
GTK doesn’t have any color correction support. Go ahead and make your changes.

One way to start is to treat all web color as corrected from sRGB.

How do web authors think about colors and colorspace outside of sRGB? like P3?

For an image tagged with a color profile, webkit does its best to show the most accurate colors for the display it’s on.

On wide-gamut displays WebKit shows sRGB as sRGB. Chrome stretches the colorspace to the wide-gamut making images more vibrant. Webkit has more muted colors.

Bright red Ferrari isn’t bright enough because you can specify a color bright enough in sRGB. One proposal is to specify color with:

rgb(106%, -0.2%, 0)

There would be clamping for these values.

Wide is more range in the colorspace. Deep means more precision on the color (more colors).

A couple ways to specify wide color:

color(“p3”, …, …, …);

Second is a new two-property variant.

color-space: “p3”, “sRGB”;

@media queries:

@media (display-color-depth: depth)
@media (IsupportThisLevelOfColorSpace)

    <source src=”normal.jpg”>
    <source media=“…” src=”wide.jpg”>

WebGL and 2D Canvas color space issues as well:

var c = canvas.getContext(“2d”. { depth: 16, colorspace: &quot;p3&quot;});
c.getImageData(x, y…);

You get data member defined as a byte array or a uint16 array.
Currently you’ll have to do the math here.

getImageData() will get slower… not exposing backing store…
the speed is important… getting as close to the hardware as possible…

Crazy image processing technique, you have to go outside 0-255, use a deep buffer canvas.

For images deeper than 8-bit color is 16-bit color which can use alpha.

Formats need exposed in the “accept:” headers.

Color intents could be used to help identify conversion options for gamut space.

What ColorSync framework can we take advantage of to accelerate the colorspace translation.