Open LaurenzV opened 2 months ago
Define "support". Aren't this should be done at the tiny-skia
level? Or what exactly are you trying to implement? Just CSS 4 colors to RGB conversion?
Also, I'm well aware of qcms
, that was never the issue. Adding a proper color spaces support to tiny-skia
is what throw me away. I have no idea how hard it will be. Could be super easy, could be super hard. I simply don't know.
Define "support". Aren't this should be done at the tiny-skia level? Or what exactly are you trying to implement? Just CSS 4 colors to RGB conversion?
For now, it would just be ICC colors, not all CSS 4 colors. You are right, more advanced support would require implementing them on the tiny-skia
level, but in the case of ICC colors, we can simply add color space support inside of usvg
and in resvg
we convert them to srgb. But if we want to later on add things like oklab
, that would probably indeed require changes to tiny-skia
.
But I just realized that we need support for @color-profile
, similarly to embedded WOFF fonts we first need to add @-rules to simplecss
, so I guess this should be tackled first before discussing more.
Yes, the first step would be to parse CSS 4 colors, which a mix simplecss
and svgtypes
tasks. And we can simply convert those colors to sRGB, therefore not changing anything in usvg
.
That would be the easiest first step towards proper color spaces support.
There is this crate which is seemingly basically a port of lcms and allows to convert colors from ICC profiles. Would you accept a PR that implements icc colors with that crate? Although I am somewhat worried about the fact that the crate has a lot of unsafe, perhaps we can put it behind an
icc
feature that is disabled by default and needs to be enabled explicitly? And we should put a warning that it's at one's "own risk", since the crate has a lot of unsafe. Since it's used in Firefox I do assume that they know what they were doing, but still.What do you think?