-
Notifications
You must be signed in to change notification settings - Fork 19
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
Allow colorSpace attributes in getImageData and toDataURL #19
Comments
One use of that would be if rendering has been going to one context, whose image is to be captured and sent to another context. Although, a color managed canvas could take data in any colorspace. A more compelling use case is where an image is being assembled in a canvas, which will then be used in a non-colormanaged, single-colorspace environment such as WebGL or WebGPU. Being able to get the image in that colorspace would be a great convenience, compared to getting it in the original context colorspace and then having the user do per-pixel colorspace conversion and gamut mapping. Which is still possible, but then everyone has to re-implement it while the cancas code already has that functionality. |
I actually think that getImageData might want to be (effectively) colorspace agnostic, since the goal there is generally "let me work with the backbuffer". toDataURL encodes based on a file format always, right? We should be embedding color space info in formats that support it there. I think that it's likely a bug in browsers today if toDataURL doesn't encode colorspace info properly, though since everything is currently srgb, we might be getting that right by-default. :) I'm not sure I want to sign us up for doing colorspace conversions as part of that. There's some motion towards ImageBitmap being the way to request image processing (y-flip, etc), so maybe that's a direction to consider but for color spaces? For example use case #3, we're still TBD on what happens if you e.g. ask for the srgb value for p3 1,0,1. I think the way we're heading is that we may decide to give you float values in the srgb space, which may be outside [0,1]. Choosing to clip implicitly would be trickily lossy. (This will probably mean leaving behind our nice hexcode representations, which don't work for >8bit anyway!) |
Chrome and Firefox generate PNGs without any colorspace metadata. Per the PNG spec, this must be interpreted as sRGB encoding with sRGB gamut, so everything just works (for now). Generated JPEGs (with |
It would be a very useful convenience if users could request image data in a target color space / configuration. This impacts both getImageData and toDataURL.
Example use cases:
rec2020
Canvas for drawing, but we need to generate an sRGB snapshot for social media.color(p3, 1, 0, 1)
declaration and an sRGB#ff00ff
hex code.Currently the workflow would be to use the
drawImage
method to draw the canvas into another canvas in the destination colorspace, but that's rather inelegant.And of course, toDataURL would need to start tagging the destination ICC profile.
The text was updated successfully, but these errors were encountered: