Re: [csswg-drafts] [css-color] [filter-effects] Should no-op filters produce different output from no filter? (#7100)

The CSS Working Group just discussed `[css-color] [filter-effects] Should no-op filters produce different output from no filter?`.

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-color] [filter-effects] Should no-op filters produce different output from no filter?<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/7100<br>
&lt;dael> smfr: This is the problem where filter like blur-0 flattens p3 colors to srgb per spec but impl, chrome always and some webkit will propegate p3 colors through filters<br>
&lt;Rossen_> q?<br>
&lt;dael> smfr: chris suggested new value for color interpolation, but doesn't solve problem i'd like. Spec doesn't match impl and I'd like them not to flatten P3 colors<br>
&lt;dael> chris: suggestion seemed to be copositing is in device color space. All filter operations or just compositing?<br>
&lt;dael> smfr: I believe impl are running filter operations in display color space which is P3 and close to srgb<br>
&lt;dael> chris: Looks okay but is wrong. What I suggested would fix that but doesn't fix existing issue<br>
&lt;dael> chris: Slightly concerned about making it do what you want b/c makes it hard to test if it's behaving correct. not completely opposed but want ot get it right<br>
&lt;dael> smfr: svg filters are spec in srgb color space and all constants work in srgb. One approach would be how to spec those in lab color space so impl can filter in that<br>
&lt;dael> chris: lab not good choice. svg are linear srgb not gamma encoded. I suggested an extended linear srgb. outside P3 clor would be fine. if want to upgrade whole thing to another color space then xyz would be a better choice then lab.<br>
&lt;dael> chris: doing in extended linear srgb would give you same result if not clipping<br>
&lt;dael> smfr: Might be possible<br>
&lt;dael> chris: You and I are attaching different bits of problema nd maybe can do both<br>
&lt;dael> smfr: You mean add new color interopolation and change default?<br>
&lt;dael> chris: yeah<br>
&lt;dael> Rossen_: Possible in current impl or compat issue?<br>
&lt;dael> smfr: Won't match what impl do. Would be signifinct work in one webkit codepath<br>
&lt;dael> Rossen_: Academically good, but would be avoided by impl<br>
&lt;dael> smfr: Our slow path, CPU based which is 8-bit unsigned. We'd have to change that to floating point or non-8bit<br>
&lt;dael> smfr: Our codepath with GPU is assuming srgb so applying that to values in P3 which happens to work most of the time. Probably what Chrome does too<br>
&lt;dael> Rossen_: chrishtr do you know if that's what youre doing?<br>
&lt;dael> smfr: For GPU accelerated you're feeding through P3 color values when using srgb matrix?<br>
&lt;dael> chrishtr: not sure, need to talk to Chris Cameron (?)<br>
&lt;dael> smfr: Would be good to see if willing to change to chris suggestion<br>
&lt;dael> chrishtr: Is that in the issue?<br>
&lt;dael> smfr: Yes, thing so<br>
&lt;dael> chrishtr: I'll re-read and ask Chris<br>
&lt;dael> chris: Please also get back to me in issue if something not clear. linear srgb extended should be GPU friendly<br>
&lt;dael> smfr: This should come up with canvas filters too so someone should think about that case too<br>
&lt;dael> Rossen_: Sounds to me like we need to have more eyes on the problem<br>
&lt;dael> chris: Agree<br>
&lt;dael> Rossen_: Want to capture proposed combined solution<br>
&lt;chrishtr> +1 to issue<br>
&lt;dael> chris: I'd rather write it on the issue instead of try and word on the fly<br>
&lt;dael> Rossen_: Alright, please add to issue<br>
&lt;dael> Rossen_: Anything else on this?<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7100#issuecomment-1118031530 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 4 May 2022 23:47:01 UTC