Verified the issue on Latest Stable# 106 by the navigating to the URL, "http://codepen.io/dom1n1k/pen/Lkyypm?editors=1100".
Observing same behavior in chrome and Firefox.
@dominik -- Could you please provide us the screenshot of the issue which would help us triage further.
Thanks in Advance.

Screenshot

Deleted: chromium624892.png 21.5 KB

	chromium624892.png 21.5 KB View Download

Thank you for providing more feedback. Adding requester "msrchandra@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

@dominik.md -- Verified the issue on Chrome, but I am also seeing the same behavior on Firefox also.
Could you please confirm.
Thanks in Advance.

Yes, Firefox is buggy too :)
Premature rounding (I guess)

However iOS Safari looks better.

Deleted: IMG_0808.PNG 116 KB

	IMG_0808.PNG 116 KB View Download

Thank you for providing more feedback. Adding requester "msrchandra@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Verified the issue on Latest Stable# 51.0.2704.106 and Latest Canary# 54.0.2797.0 on Windows, Mac and Linux and was able to reproduce the issue.
This is a Non-Regression issue seen from M30# 30.0.1599.101 (Official Build 227552) m.

Attaching a screenshot comparing Chrome nad Safari.

Firefox is also showing the same behavior as Chrome.
Changing the status to Untriaged so that the issue would get addressed.
Thank You.

I think this is a Skia issue. But I'll verify.

+senorblanco who is most familiar with filter effects.  Also a repro with no-op filters: http://codepen.io/anon/pen/groZpz

I don't think there's anything wrong with the conversion LUT, but going into 8bit linear and then back to 8bit SRGB reduces the darker tones color resolution (which our eyes are most sensitive to - https://macman860.wordpress.com/2013/02/05/bit-depth-linear-light/).

The solution is more bits per component (I'm assuming that's how Safari works), and there's work going on in Skia to add just that (float32/float16 pipeline w/ color correction).  When that's complete, it should be possible to flip between linear/srgb without noticeable loss of color resolution.

I can definitely see this happening if we do a smooth gradient in one space then convert to another that expands the dark tones, hence increasing the color difference between neighboring pixels. fmalita@ caught me not thinking when I triaged this.

This seems to be a Skia issue at heart, so I'll add that component. Who's doing the Skia work? They should own the bug.

+Brian#2, Mike#2

Sure looks like iOS Safari is just treating "linearRGB" as "sRGB".  Note how dark it is above the teal on the right edge of the iOS screenshot.

Agreed. Note that there really isn't anything that can be done (other than dithering or 10-bit output, which 99% of users don't have) to make this look better. The "good" looking images look good because the bands are uniformly distributed. That makes sense - we're interpolating in sRGB, which is the display space. But for linear, we're interpolating in a non-linear space, so the resulting bands are non-uniformly distributed after conversion back to sRGB (for output).

I claim that the behavior in this case is "correct" (doing what the user asked), even if it's less visually pleasing.

@brianosman not sure I follow this bit: "there really isn't anything that can be done (other than dithering or 10-bit output".

Looking at the simplified http://codepen.io/anon/pen/groZpz, what we're seeing is the effect of running all colors through

  c' = LinearToSRGB(SRGBToLinear(c))

I.e. the filter should be a no-op, but, due to 8bit/component quantization, it isn't.

But if we increase the component resolution for the pipeline and all intermediate buffers (say to F16), then the banding artifacts would go away - or am I missing something?

No, this isn't correct.

What's happening:
input sRGB image -> to linearRGB -> rounding to uint8 -> filter -> rounding to uint8 -> to sRGB -> rounding to uint8

Expectation:
input sRGB image -> to linearRGB -> filter -> to sRGB -> rounding to uint8

Sorry - we were misunderstanding what the filter itself was doing. The results make much more sense now. In particular:

1) Safari is ignoring "linearRGB". Note that even when applying the 50% brightness filter, it produces the same results as sRGB, which it shouldn't.
2) Edge (just to check) appears to ignore the filter entirely, so it's hard to tell how it treats the linearRGB vs sRGB. (The 50% version is still full brightness).
3) We are, in fact, quantizing to 8 bits while we're in linear, leading to the additional banding. The image filter pipeline in Skia does have this behavior (on both CPU and GPU), and fixing that would be a longer-term project, involving some combination of:
  - Using F16 during filtering.
  - Detecting filters that can/will be be applied in a single step, and using sRGB-tagged buffers.

> Safari is ignoring "linearRGB"
Hm, yes. I hadn't noticed it before.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

It's also not working for me on chrome 62 (unstable). 

Also this happens when I use CSS linear-gradient.

That's expected.  To my knowledge no one has done anything to change this.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot