-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Summary of the wide gamut support on Canvas #4167
Comments
cc @whatwg/canvas |
Some clarification notes, that came up while talking to @annevk:
|
I haven't really followed all of the previous discussion about this kind of extension. Can you explain how this fits into the context of w3ctag/design-reviews#315, #299 and https://github.com/WICG/canvas-color-space/blob/master/CanvasColorSpaceProposal.md? |
This is a summary of the IDL changes proposed by w3ctag/design-reviews#315. This is also a subset of the original proposal, that included color spaces specification and that was discussed on #299. So those two are a superset of what's being proposed here. |
Can you provide the use cases that this solves along with the rationale for the decisions made relative to other options? |
The high level goal is to allow canvases to take advantage of full color gamut available on display devices.
A fully formed color space spec would include this (wide gamut) plus color spaces support (P3, rec2020, etc... and maybe a SRGB mode that doesn't do linear blending of non-linear values). That said, it is our understanding that even that fully formed spec would need a wide-gamut mode that is backward compatible with the current SRGB support. This spec is this minimal color space support (extended SRGB) and wide gamut support on canvas and canvas export API. |
Do you envision the entire canvas pipeline running at float16 when CanvasPixelFormat is set to "float16"? What is the functionality that those applications need from canvas? Naively, I can't think of much overlap between the canvas api and the needs of a photo editor. |
I'm not 100% sure what you mean by "the entire canvas pipeline", but if you mean the backing storage for both 2D and WebGL and the drawing commands for 2D, then yes. The main 2D commands that are impacted by this, as it stands now, are drawImage of wide gamut content (video, images, etc) and rendering of gradients. In general, for any type of drawing (and some game) application color fidelity (and representing colors outside of sRGB) is a big issue. Granted, the case strictly for 2D is a bit reduced, although we do have cases of people doing WebGL -> 2D canvas for interface, in which we would like to preserve the quality of the rendered image. |
CoreGraphics doesn't seem to support a 16bit float pixel format. Do you know what Apple's feedback on this proposal is? |
There was general consensus about this being the way forward at 1-year-ago's TPAC. There is definitely support in macOS for half-float IOSurfaces through the whole pipeline (I haven't locally tried in CoreGraphics myself) |
(cc @smfr, I think) |
CG does support half-float pixel formats on both its GPU-accelerated and non-accelerated code paths, so we support this proposal. |
But what kind of backing store would you use that can be exposed to JavaScript? JavaScript doesn't have |
@annevk per the IDL above, Float32Array will be used to represent the pixels during getImageData and putImageData operations when the backing store is float16. These aren't the fastest way to use the canvas APIs anyway, so a conversion is fine. WebGL already uses Float32Array for uploading to float16 format textures and reading back float16 format framebuffers. |
@fserb wrote:
Where is the extended sRGB space defined? What is the transfer function? What is the range of the function? In other words, what do values less than 0 or greater than 1.0 (255/255, in 8bits) mean? |
@kenrussell what is the fastest way? And why don't we add Float16Array if we have several use cases? |
By the way, related to @svgeesus's question, are we ensuring consistency with CSS and SVG somehow? |
@annevk the fastest Canvas 2D APIs are the drawing operations (drawImage, rectangle/line/text drawing), not per-pixel manipulation (getImageData/putImageData). Adding Float16Array to JS would require a large amount of hand-tuned assembly language to be added to every JS engine in existence. float16 is a native data type on GPUs but not on today's CPUs, and is handled with a library in every other language. I think it should be handled with a library in JS, too, and such libraries have already been written: https://github.com/petamoriken/float16 . |
@kenrussell thanks, could you perhaps also address #4167 (comment)? And how would out-of-range values be handled, e.g., when going from float32 to float16? @svgeesus that's great to hear. CSS Color 4 also seems like the ideal place to describe the WCG/HDR abstract model (the mapping of float16 values to colors, if you will). |
@fserb is the best person to describe the extended sRGB color space; that's outside my domain. float32 values can be defined in the spec as being converted to float16 internally with similar rules to how double (float64) is converted to float (float32) in C/C++: https://stackoverflow.com/questions/16737615/how-is-floating-point-conversion-actually-done-in-cdouble-to-float-or-float . |
Let's close this in favor of #8708. |
This is an IDL summary of the new proposed interface to support wide gamut on Canvas (half-float + extended SRGB)
2D Context
ImageData
ImageBitmap
convertToBlob
The text was updated successfully, but these errors were encountered: