Update examples section #56
Conversation
ccameron-chromium
force-pushed
the
wording_and_examples
branch
from
4873420 to
142e440
Compare
|
This adds an examples section so that readers can get a sense of what common use of the API will look like. |
CanvasColorSpaceProposal.md
Outdated
| context.putImageData(srgbImageData, 0, 0); | ||
|
|
||
| // This will draw P3-red to the canvas. | ||
| var p3ImageData = new ImageData(1, 1, {colorSpace:'display-p3'}); |
There was a problem hiding this comment.
Do we expect ImageData with more than 8-bit depth in the future?
There was a problem hiding this comment.
Yes. We removed from this proposal along with >8-bit 2D canvas support. It will be re-introduced in a separate proposal that covers high dynamic range.
| // specified image, but will clip it to the sRGB color gamut. | ||
| var defaultCanvas = document.getElementById('DefaultCanvas'); | ||
| var defaultCtx = defaultCanvas.getContext('2d'); | ||
| defaultCtx.drawImage(myWCGImage, 0, 0, image.width, image.height) |
There was a problem hiding this comment.
Is there any formal spec on clipping behavior? Same question for getImageData.
There was a problem hiding this comment.
CSS Color Module 4 goes over the formal color space conversion math and clamping. If it is ambiguous, it should be made clear. (There is no fancy conversion -- values that don't fit in the target gamut are chopped off).
There was a problem hiding this comment.
CSS Color Module 4 goes over the formal color space conversion math
yes, [here]
and clamping.
Per-component clamping is discouraged because it can produce massive hue shifts. CSS Color 4 talks about gamut mapping but that section has not yet been specce'ed out. open issue It has been incubated though, again the algorithm is fairly simple. For some use cases, simple clamping is still what you want; so there will be both options.
If it is ambiguous, it should be made clear.
Yes, and it will be.
Also I should point out that in CSS Color 4, partly driven by the needs of Canvas for WCG & HDR, the domain and range f the RGB transfer functions are unbounded. This is to avoid any premature clipping, which would preclude round-tripping; and also because HDR will need that.
CanvasColorSpaceProposal.md
Outdated
| gl.pixelStorei(gl.UNPACK_COLORSPACE_CONVERSION_WEBGL, | ||
| gl.BROWSER_DEFAULT_WEBGL); | ||
| gl.colorSpace = 'display-p3'; | ||
| gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA8, image.width, image.height, 0, |
There was a problem hiding this comment.
Maybe use gl.SRGB8_ALPHA8 here so that image is filtered correctly. The extension for WebGL 1.0 should be universal at this point. Same comment for the ImageBitmap upload.
There was a problem hiding this comment.
Done (in both locations).
CanvasColorSpaceProposal.md
Outdated
| fetch(myImageUrl).then(function(response) { | ||
| return response.blob(); | ||
| }).then(function(blob) { | ||
| return createImageBitmap(blob, 0, 0, 1000, 1000, |
There was a problem hiding this comment.
Please consider omitting dimensions here.
There was a problem hiding this comment.
Good work expanding out these examples @ccameron-chromium . A few relatively minor requests.
| This example selects a wide color gamut canvas only if the underlying display has a P3 gamut or larger. | ||
|
|
||
| ```html | ||
| // Note that the gamut is named p3, but the color space is 'display-p3'. |
There was a problem hiding this comment.
Correct - this is unfortunate but deliberate. The three MQ gamut buckets are deliberately approximate, basically "normal" "wide" and "superwide". p3 would match an Adobe RGB screen, for example.
While the color spaces, like display-p3, are much more specific and tightly defined.
Update the examples section to show basic usage of the API.