5 ms·

Blur Radius Comparison

123 points by zdw 3y ago

mwkaufma 3y ago
Are there differences between implementations doing optical vs srgb blur?
- phaker 3y ago
  SVG filters default to linear color (but svg gradients etc default to srgb) so the 'SVG fe' are all linear. Color space used changes where the midpoint is so nothing else here uses linear color (unless they've decided to fudge that to match user expectations).
burnedtoast 3y ago
Another really annoying fact about drop shadows, is that Android choose to implement the light source pretty much where your nose is. So when a view with drop shadow moves closer to the bottom of the screen, its drop shadow increase visibility at the bottom of the view and decrease visibility at the top. This makes it's impossible to match specs given by designers on Android.
- chrismorgan 3y ago
  Can you show pictures or something of what you mean? I can’t find any mention of what you describe, and it would surprise me greatly to encounter a point light source rather than a distant light source, partly because of how fiendishly complicated it makes implementation (including just being impossible on the web), and partly just because we’re mostly used to distant light sources for illumination.
  - vesinisa 3y ago
    I think they're referring to this: https://m2.material.io/design/environment/light-shadows.html https://m2.material.io/design/environment/light-shadows.html Notice how there are actually two shadows that must be combined. The point light source shadow rendering depends on the object position on screen.
    - ghusbands 3y ago
      A point light source can be at infinity. I don't think that design document implies that shadows need to change based on screen position. Note that "elevation" is about how far 'off' the background the element is pretending to be.
    - chrismorgan 3y ago
      They’re two shadows, but nothing calls them point sources; I claim that any reasonable implementer would from such descriptions absolutely presume them to be distant (as in, never have it even occur to them it might be otherwise). The only detail that seems confusing and could support otherwise is the sentence “On the web, shadows are depicted by manipulating the y-axis only.” (I’m using roughly SVG’s terminology: fePointLight has x, y and z, which can be approximately infinitely far away but it’ll only be approximately so, and feDistantLight, which has azimuth and elevation, and projects from infinity.)
  - burnedtoast 3y ago
    https://pasteboard.co/AUrdZZe5KxoO.png https://pasteboard.co/AUrdZZe5KxoO.png In this screenshot all the views have the exact same spec: 8dp elevation.
    - ghusbands 3y ago
      Do you see this in all apps or just custom/particular ones? Can you control where the key light is at all? It would be surprising for the key light to be so close to the screen (rather than nearer infinity), given that the design document linked elsewhere seems to expect consistency at particular elevations.
      - burnedtoast 3y ago
        It's the behavior for all apps and I don't think it can be customized. There are some APIs to affect the spot shadow color and ambient shadow color (from API 28), but no way to affect this offset / light source position AFAIK.
    - chrismorgan 3y ago
      OK, now I’m interested in whether there’s any x-axis cast (which would indicate a nearby point light source) or not (which would be simulating the physical impossibility of a light source both nearby and infinitely far away), and whether it’s rendering with actual perspective (without which it’s a cheap hack and physically impossible, but the difference is probably humanly indistinguishable, and honestly the whole thing is just a bit weird anyway given the orthographic top-down projection of the content, so maybe I shouldn’t even talk about the physical impossibility above).
      - burnedtoast 3y ago
        Yes the same goes for X-axis as well. Here's a screenshot showing that: https://pasteboard.co/O5H4djIUMoG6.png https://pasteboard.co/O5H4djIUMoG6.png
        chrismorgan 3y ago
- grishka 3y ago
  That's why you ask your designer to give you an elevation value instead of a blur radius and offset. If you really want a shadow with arbitrary color/radius/offset like CSS box-shadow, you have to use paint.setShadowLayer() in a software-rendered canvas (a bitmap or a software layer). Exception is that such shadows for text can be rendered with hardware acceleration.
  - burnedtoast 3y ago
    Yeah, that's normal practice and usually works OK. But then sometimes it happens that the given elevation value give a shadow much weaker than in the design tool. Especially for things like a bottom toolbar where the top of the shadow is close to the bottom of the screen and supposed to visually separate the toolbar from content. Another toolbar using the same elevation in another place on the screen may look fine. So when QA say that the shadow is too weak, you have to tell your designer this and they have to come up with something different, or you have to increase elevation to compensate, or fall back to a pre-rendered 9-patch, or something else... As i said, annoying :\
blauditore 3y ago
Interesting, because at early CSS3 times, I always had the impression that Firefox had much nicer renderingof shadows etc. than Chrome, which looked rather cheap and fast. Same for font-faces. They're probably aligned better now.
- jansan 3y ago
  box-shadow on Chrome used an incorrect blur radius until about five years ago. Then they finally fixed it.
  - blauditore 3y ago
    I wonder if that was on purpose - larger blur radii are generally more expensive to render.
codeflo 3y ago
The point about gamma correction is important. Many effects like scaling and blurring should occur in what's called linear color space, otherwise you add or remove energy, which can look very wrong. Normal RGB isn't linear. GPUs and most game engines get this correct, maybe because in animated 3D graphics, you'd notice this immediately. But browsers are ridiculously bad at understanding this -- there was an article a while back that demonstrated some pathological cases.
- jiggawatts 3y ago
  Browsers, chat apps, social media apps, Outlook and all other email clients, Teams, Zoom, Adobe Photoshop (really!), DaVinci Resolve (a colorist tool ffs)[2], and on, and on... Developers assuming that RGB is a triplet of 8-bit numbers and that maths can be naively done to those numbers is one of my favourite examples of the Dunning Kruger effect.[1] It's such a rarity to see a tool correctly implement color management or linear light for transforms by default that it always jumps out as far out of the norm. > animated 3D graphics You'd think so... but no. It's a persistent error in 3D games as well, as well as 3D renderers like Blender. A common question posted in game-dev forums is "textures look brighter/lighter/faded in game compared to Photoshop". This is because most image editors use the sRGB non-linear gamma, but the game engine uses linear light because it's essentially a physical optics simulator. Beginner game developers load the sRGB 8-bit pixel values and then use them as-is without first undoing the gamma to bring them into the linear light space. This results in over-bright textures. The Quake engine and its derivatives were notorious for this kind of thing, made even worse by OpenGL accelerators like the 3dfs Voodoo card doing more incorrect things on top of that. Similarly, "Cinematic" mode in Blender should be renamed to "not broken" or simply "correct" color management mode. [1] I'm guilty of making all of the mistakes I've listed here, in a 3D engine, a ray tracer, and several other graphics utilities. We're all beginners at some point! [2] The "best" video colorist tool on the planet is not color managed on Windows or Linux. It outputs "whatever" to the screen and ha-ha... good luck. On a HDR screen, with HDR on, if you enable HDR in Resolve you get a washed-out incorrect mess. That just blows my mind.
  - codeflo 3y ago
jansan 3y ago
It is quite bad, but not that long ago the blur of css box-shadow was different between browsers, too. I wrote a little workaround that rendered a blurred rectangle on a canvas and then picked the alpha value at a certain point to calculate a correction factor. In that case, Chrome was the culprit, and since I had mentioned that we were working around the problem, the Chrome devs originally refused to fix the issue, but eventually they did the only right thing and fixed it. Lots of insights in the comments for this issue: https://bugs.chromium.org/p/chromium/issues/detail?id=179006 https://bugs.chromium.org/p/chromium/issues/detail?id=179006
dahart 3y ago
> Figma’s blurs have added noise, and the noise is biased to make the result one 8-bit value darker. The noise repeats every 256×256px. I’m not sure why their background blur never reaches black, given the others do. Photoshop will also add noise when you convert from 16 bit to 8 bit. The reason for doing this is to prevent visible banding when blurring things, or just working with gradients (like blue skies). This is really important when printing things, because sometimes banding that wasn’t visible on your screen will show up clearly in your prints. Also really important if you scale the colors of a gradient or blurred region later… small steps between colors become larger and there’s no way to get back to smooth. I only became sensitive to whether software does blur math in higher precision, and whether it dithers, after working with prints and wasting $100 a pop on a large format print that came out with ugly unexpected banding. Last time I checked, Image Magick’s blur and 16->8 conversion was terrible, and has for a long time been one reason stuck in my head why I avoid Image Magick for serious work. I don’t know how effective adding noise in 8 bits is. It’s better to work in a higher bit-rate colorspace, and only dither at the last second when converting the final to 8 bits. Well, it’s better to never use 8 bits if you can, but that’s not always possible. Hopefully Figma’s noise is at least added during the higher-precision blur operation before storing the results in 8-bit colors. Figma’s noise bias might be a simple mistake, and it might also be the reason they chose to clamp the blacks, if a developer was seeing -1s (which depending on the implementation, might underflow and suddenly show up as a saturated bright color).
- marcedwards 3y ago
  >I don’t know how effective adding noise in 8 bits is. It’s better to work in a higher bit-rate colorspace, and only dither at the last second when converting the final to 8 bits. Yes, I completely agree. Injecting white noise is a pretty terrible way to avoid banding, given there’s better dithering options available. The blur should be a shader, and the dithering could be done within the shader as long as it’s not error diffusion dithering. I don’t really see why there would be a big perf difference. I think even pattern dithering with a small kernel would give better results than white noise.
coldcode 3y ago
A designer complained to me that her Photoshop blur requirements did not match my iOS implementation. I had to manually adjust my code until it met precisely, which was a pain. A few years later, she became a developer and admitted she was wrong to complain about exact matching between platforms.
- marcedwards 3y ago
  And now you have some scaling factor values to match things easily.
esafak 3y ago
Too bad there is no support for lens blur.

123 points by zdw 3y ago

mwkaufma 3y ago

Are there differences between implementations doing optical vs srgb blur?

phaker 3y ago
SVG filters default to linear color (but svg gradients etc default to srgb) so the 'SVG fe' are all linear. Color space used changes where the midpoint is so nothing else here uses linear color (unless they've decided to fudge that to match user expectations).

burnedtoast 3y ago

Another really annoying fact about drop shadows, is that Android choose to implement the light source pretty much where your nose is. So when a view with drop shadow moves closer to the bottom of the screen, its drop shadow increase visibility at the bottom of the view and decrease visibility at the top. This makes it's impossible to match specs given by designers on Android.

chrismorgan 3y ago
Can you show pictures or something of what you mean? I can’t find any mention of what you describe, and it would surprise me greatly to encounter a point light source rather than a distant light source, partly because of how fiendishly complicated it makes implementation (including just being impossible on the web), and partly just because we’re mostly used to distant light sources for illumination.
- vesinisa 3y ago
  I think they're referring to this: https://m2.material.io/design/environment/light-shadows.html https://m2.material.io/design/environment/light-shadows.html Notice how there are actually two shadows that must be combined. The point light source shadow rendering depends on the object position on screen.
  - ghusbands 3y ago
    A point light source can be at infinity. I don't think that design document implies that shadows need to change based on screen position. Note that "elevation" is about how far 'off' the background the element is pretending to be.
  - chrismorgan 3y ago
    They’re two shadows, but nothing calls them point sources; I claim that any reasonable implementer would from such descriptions absolutely presume them to be distant (as in, never have it even occur to them it might be otherwise). The only detail that seems confusing and could support otherwise is the sentence “On the web, shadows are depicted by manipulating the y-axis only.” (I’m using roughly SVG’s terminology: fePointLight has x, y and z, which can be approximately infinitely far away but it’ll only be approximately so, and feDistantLight, which has azimuth and elevation, and projects from infinity.)
- burnedtoast 3y ago
  https://pasteboard.co/AUrdZZe5KxoO.png https://pasteboard.co/AUrdZZe5KxoO.png In this screenshot all the views have the exact same spec: 8dp elevation.
  - ghusbands 3y ago
    Do you see this in all apps or just custom/particular ones? Can you control where the key light is at all? It would be surprising for the key light to be so close to the screen (rather than nearer infinity), given that the design document linked elsewhere seems to expect consistency at particular elevations.
    - burnedtoast 3y ago
      It's the behavior for all apps and I don't think it can be customized. There are some APIs to affect the spot shadow color and ambient shadow color (from API 28), but no way to affect this offset / light source position AFAIK.
  - chrismorgan 3y ago
    OK, now I’m interested in whether there’s any x-axis cast (which would indicate a nearby point light source) or not (which would be simulating the physical impossibility of a light source both nearby and infinitely far away), and whether it’s rendering with actual perspective (without which it’s a cheap hack and physically impossible, but the difference is probably humanly indistinguishable, and honestly the whole thing is just a bit weird anyway given the orthographic top-down projection of the content, so maybe I shouldn’t even talk about the physical impossibility above).
    - burnedtoast 3y ago
      Yes the same goes for X-axis as well. Here's a screenshot showing that: https://pasteboard.co/O5H4djIUMoG6.png https://pasteboard.co/O5H4djIUMoG6.png
      - chrismorgan 3y ago
grishka 3y ago
That's why you ask your designer to give you an elevation value instead of a blur radius and offset. If you really want a shadow with arbitrary color/radius/offset like CSS box-shadow, you have to use paint.setShadowLayer() in a software-rendered canvas (a bitmap or a software layer). Exception is that such shadows for text can be rendered with hardware acceleration.
- burnedtoast 3y ago
  Yeah, that's normal practice and usually works OK. But then sometimes it happens that the given elevation value give a shadow much weaker than in the design tool. Especially for things like a bottom toolbar where the top of the shadow is close to the bottom of the screen and supposed to visually separate the toolbar from content. Another toolbar using the same elevation in another place on the screen may look fine. So when QA say that the shadow is too weak, you have to tell your designer this and they have to come up with something different, or you have to increase elevation to compensate, or fall back to a pre-rendered 9-patch, or something else... As i said, annoying :\

blauditore 3y ago

Interesting, because at early CSS3 times, I always had the impression that Firefox had much nicer renderingof shadows etc. than Chrome, which looked rather cheap and fast. Same for font-faces. They're probably aligned better now.

jansan 3y ago
box-shadow on Chrome used an incorrect blur radius until about five years ago. Then they finally fixed it.
- blauditore 3y ago
  I wonder if that was on purpose - larger blur radii are generally more expensive to render.

codeflo 3y ago

The point about gamma correction is important. Many effects like scaling and blurring should occur in what's called linear color space, otherwise you add or remove energy, which can look very wrong. Normal RGB isn't linear. GPUs and most game engines get this correct, maybe because in animated 3D graphics, you'd notice this immediately. But browsers are ridiculously bad at understanding this -- there was an article a while back that demonstrated some pathological cases.

jiggawatts 3y ago
Browsers, chat apps, social media apps, Outlook and all other email clients, Teams, Zoom, Adobe Photoshop (really!), DaVinci Resolve (a colorist tool ffs)[2], and on, and on... Developers assuming that RGB is a triplet of 8-bit numbers and that maths can be naively done to those numbers is one of my favourite examples of the Dunning Kruger effect.[1] It's such a rarity to see a tool correctly implement color management or linear light for transforms by default that it always jumps out as far out of the norm. > animated 3D graphics You'd think so... but no. It's a persistent error in 3D games as well, as well as 3D renderers like Blender. A common question posted in game-dev forums is "textures look brighter/lighter/faded in game compared to Photoshop". This is because most image editors use the sRGB non-linear gamma, but the game engine uses linear light because it's essentially a physical optics simulator. Beginner game developers load the sRGB 8-bit pixel values and then use them as-is without first undoing the gamma to bring them into the linear light space. This results in over-bright textures. The Quake engine and its derivatives were notorious for this kind of thing, made even worse by OpenGL accelerators like the 3dfs Voodoo card doing more incorrect things on top of that. Similarly, "Cinematic" mode in Blender should be renamed to "not broken" or simply "correct" color management mode. [1] I'm guilty of making all of the mistakes I've listed here, in a 3D engine, a ray tracer, and several other graphics utilities. We're all beginners at some point! [2] The "best" video colorist tool on the planet is not color managed on Windows or Linux. It outputs "whatever" to the screen and ha-ha... good luck. On a HDR screen, with HDR on, if you enable HDR in Resolve you get a washed-out incorrect mess. That just blows my mind.
- codeflo 3y ago

jansan 3y ago

It is quite bad, but not that long ago the blur of css box-shadow was different between browsers, too. I wrote a little workaround that rendered a blurred rectangle on a canvas and then picked the alpha value at a certain point to calculate a correction factor. In that case, Chrome was the culprit, and since I had mentioned that we were working around the problem, the Chrome devs originally refused to fix the issue, but eventually they did the only right thing and fixed it. Lots of insights in the comments for this issue: https://bugs.chromium.org/p/chromium/issues/detail?id=179006 https://bugs.chromium.org/p/chromium/issues/detail?id=179006

dahart 3y ago

> Figma’s blurs have added noise, and the noise is biased to make the result one 8-bit value darker. The noise repeats every 256×256px. I’m not sure why their background blur never reaches black, given the others do. Photoshop will also add noise when you convert from 16 bit to 8 bit. The reason for doing this is to prevent visible banding when blurring things, or just working with gradients (like blue skies). This is really important when printing things, because sometimes banding that wasn’t visible on your screen will show up clearly in your prints. Also really important if you scale the colors of a gradient or blurred region later… small steps between colors become larger and there’s no way to get back to smooth. I only became sensitive to whether software does blur math in higher precision, and whether it dithers, after working with prints and wasting $100 a pop on a large format print that came out with ugly unexpected banding. Last time I checked, Image Magick’s blur and 16->8 conversion was terrible, and has for a long time been one reason stuck in my head why I avoid Image Magick for serious work. I don’t know how effective adding noise in 8 bits is. It’s better to work in a higher bit-rate colorspace, and only dither at the last second when converting the final to 8 bits. Well, it’s better to never use 8 bits if you can, but that’s not always possible. Hopefully Figma’s noise is at least added during the higher-precision blur operation before storing the results in 8-bit colors. Figma’s noise bias might be a simple mistake, and it might also be the reason they chose to clamp the blacks, if a developer was seeing -1s (which depending on the implementation, might underflow and suddenly show up as a saturated bright color).

marcedwards 3y ago
>I don’t know how effective adding noise in 8 bits is. It’s better to work in a higher bit-rate colorspace, and only dither at the last second when converting the final to 8 bits. Yes, I completely agree. Injecting white noise is a pretty terrible way to avoid banding, given there’s better dithering options available. The blur should be a shader, and the dithering could be done within the shader as long as it’s not error diffusion dithering. I don’t really see why there would be a big perf difference. I think even pattern dithering with a small kernel would give better results than white noise.

coldcode 3y ago

A designer complained to me that her Photoshop blur requirements did not match my iOS implementation. I had to manually adjust my code until it met precisely, which was a pain. A few years later, she became a developer and admitted she was wrong to complain about exact matching between platforms.

marcedwards 3y ago
And now you have some scaling factor values to match things easily.

esafak 3y ago

Too bad there is no support for lens blur.