Author here, Thank you very much for linking! Masaki Kawase is a bit of a graphics programming idol of mine. Living in Japan, I got to interview him on a zoom call about what it was like being a graphics programmer in those adventurous times 1999~2005 of the Japanese video game scene.
This kick-started by desire to write about the Dual-Kawase Blur, a technique I stumbled upon when ricing my linux distro.
The Kawase approach is from 2005, and GPU performance has improved a ton since then. Some of the newer games do use Bokeh blurs with multiple depths of field. The result can look much more natural than the Gaussian stuff. BTW, it's not just a cinematic effect -- the fact that our pupils are round means that like cameras, they act as a disk-shaped filter for things that are out of focus.
Yes, bokeh blur is way more pleasing. In my article the gaussian likes are the focus for their use as a basic building block for other effects, like frosted glass, heat distortions, bloom and the like.
Specifically the 2015 Dual Kawase was created in the context of mobile graphics, with weak memory throughput. But even on my RTX 4090, near the fastest consumer hardware available, those unoptimized unseparable, naive gaussian implementations bring it to a crawl and `samplePosMultiplier` has a non insignificant performance hit, so texture caches still play a role.
At today's high resolutions and especially on mobile, we still need smart and optimized algorithms like the dual kawase.
Has anyone got suggestions for blur algorithms suitable for compute shaders? The usual Kawase blur (described in the article) uses bilinear sampling of textures.
You can, of course, implement the algorithm as is on a compute shader with texture sampling.
But I have a situation where the inputs and outputs should be in shared memory. I'm trying to avoid writing the results out to off-chip DRAM, which would be necessary to be able to use texture sampling.
I spent some time looking into a way of doing an efficient compute shader blur using warp/wave/subgroup intrinsics to downsample the image and then do some kind of gaussian-esque weighted average. The hard part here is that the Kawase blur samples the input at "odd" locations but warp intrinsics are limited to "even" locations if that makes sense.
I would appreciate if anyone knows any prior art in this department.
The part about low-pass filtering using FFT ends with the conclusion that it is fundamentally a different thing from a gaussian blur ("Low Pass Filter ≠ Low Pass Filter"). However: A convolution in image space is just a multiplication in fourier space. If you multiplied with a gaussian in fourier space you should get a gaussian blur. It's just not necessarily the fastest option.
I didn't really understand why every image is slowly moving around. It says:
> Above the box you have an Animate button, which will move the scene around to tease out problems of upcoming algorithms. Movement happens before our blur will be applied, akin to the player character moving.
I don't really understand the explanation - the movement just seemed a bit annoying.
Once Multi-Step Downsampling comes into the mix, the image starts to "boil" as it moves. This is especially bad with very strong lights that are small, as the lights seem to appear and disappear with long downsample chains. Most of the recent blur technique evolution centered on fixing this issue, as shown in "Next Generation Post Processing in Call of Duty: Advanced Warfare" at the end of the article.
This is not the first time [1] I hear this critique of movement by default being annoying. Should I just turn it off by default?
Do you know what aliasing is in a game? When the edges are too sharp? They can look okay in a still image, but they are really noticeable when things are in motion. Another such example is the moire effect. Moire is very noticeable in still images too, but when moving, it's really noticeable.
These blur effects, like any other graphical thing, can have a similar effect when combined with motion. The animate function is to bring these issues out, if there is any.
Justified, in general, looks neater, is more formal, but is a bit more harder to read as well. I personally have no issue with it either way, but to tell you the truth, from a quick check I could not find any website that uses justified text, not even the ones that I think are formal and professional. Reuters, APNews, Wikipedia, Wordpress, Medium, everything I checked is unjustified. So I think it's a conventional default, if nothing else.
If you take a typography class, they will drill it into you that unjustified is the norm (and you will spend some time learning how to make pleasant rags), and that you need a VERY GOOD reason to make text justified.
How much of it is convention vs based in measurable outcomes is up for debate (maybe), but at least that’s where most every formally trained designer/visual artist in the west comes from.
I have not taken a typography class, but norm seems to be context dependent. On the internet, unjustified seems to be the norm, looking at the random high-traffic websites I visited. Printed media is another beast though. I picked up a random book, justified, random newspaper, justified, random marketing material from my mailbox, justified.
So in this current case, since OP's blog is on the internet and not printed, I would suggest unjustified.
After the printing press, but before the Internet, justified text was actually the norm. Every book, newspaper and magazine had justified text. But after hundreds of years, text justification has finally fallen out of favor. We can only speculate about the reason.
I disagree. Fully justified text was the norm for narrow-column media such as newspapers and some magazines. Ragged-right was the norm for wider media such as printed books because, for physiological reasons discovered over centuries, it's easier to keep your place in long paragraphs. Most web media are narrow-column format, so tend to be fully justified. Whether that's good or not tends to be a matter of how one is consuming the matter: a high-pixel-density phone at 15 cm vs. a 1080p monitor at 45 cm call for different presentation for optimal readability.
> Ragged-right was the norm for wider media such as printed books
What? I'm pretty sure that if I pick any book in my shelf, it's going to be justified.
> Most web media are narrow-column format, so tend to be fully justified.
What #2? 99% of web media is ragged-right, the biggest reason being that it's the default, and that browsers have terrible line-wrapping and historically had no support for hyphenation. And justified text gets worse the shorter the lines are, because there are fewer options on where to insert newlines, leading to large spaces between words. Also, good justification requires fine-grained word spacing control, which doesn't work well with traditional low-resolution displays.
My MSc thesis advisor recently told that apparently thesis documents should be submitted with ragged-right lines these days because it makes them easier to read for dyslexics; while it makes sense, it must be a quite new guideline.
ragged right became the web norm because browsers lacked good hyphenation, making justified text look gappy. In print it works fine, but online ragged right tends to be easier to read.
My blog's style has Sakura.css [1] as its base, which keeps the paragraphs narrow on wide displays, limited 684 CSS pixels to aid readability. The justify text-style was a choice by me. Now I really wonder whether that hurt readability.
I looked at random, recent printed media around me, and it's all still justified.
On displays, readability works out differently, and that's why I speculate this has changed. For example, printed media uses serif fonts to aid readability, but on displays, sans-serif works better, especially on lower resolutions.
I for one love justified text. Even on websites. For a book, it almost decides whether I will read it. I can’t with the ragged edges on non-justified text.
Spherical Harmonic Lighting is an alternative or used to supplement the generation of HDR cube maps for the purpose of global illumination. For the very diffuse aspect of this global illumination, Spherical Harmonics are used (Often called light probes), as a very cheap approximation of the environment, that is easy to get in and out of shaders and interpolate between them. They are just a bunch of RGB floats, so you can place a ton of them in the environment to capture a scene's direct or indirect lighting. For specular reflections you still have to use HDR cube maps, as the light probes don't hold enough information for that task.
Blurs are a basic building block of image processing and used in a ton of effects. In a way, there are related topics, as the cube maps generated to cover different roughness factors for PBR rendering are, in-fact blurs! https://threejs.org/docs/#api/en/extras/PMREMGenerator But that's not the topic of the article, but instead of how to do blurs efficiently in real time, in the first place.
This kick-started by desire to write about the Dual-Kawase Blur, a technique I stumbled upon when ricing my linux distro.
Here's a breakdown of how Doom (2016) does it: https://www.adriancourreges.com/blog/2016/09/09/doom-2016-gr...
Yes, bokeh blur is way more pleasing. In my article the gaussian likes are the focus for their use as a basic building block for other effects, like frosted glass, heat distortions, bloom and the like.
Specifically the 2015 Dual Kawase was created in the context of mobile graphics, with weak memory throughput. But even on my RTX 4090, near the fastest consumer hardware available, those unoptimized unseparable, naive gaussian implementations bring it to a crawl and `samplePosMultiplier` has a non insignificant performance hit, so texture caches still play a role.
At today's high resolutions and especially on mobile, we still need smart and optimized algorithms like the dual kawase.
You can, of course, implement the algorithm as is on a compute shader with texture sampling.
But I have a situation where the inputs and outputs should be in shared memory. I'm trying to avoid writing the results out to off-chip DRAM, which would be necessary to be able to use texture sampling.
I spent some time looking into a way of doing an efficient compute shader blur using warp/wave/subgroup intrinsics to downsample the image and then do some kind of gaussian-esque weighted average. The hard part here is that the Kawase blur samples the input at "odd" locations but warp intrinsics are limited to "even" locations if that makes sense.
I would appreciate if anyone knows any prior art in this department.
I use box/gaussian blurs often, but for rendering outlines/highlights of objects.
https://ameye.dev/notes/rendering-outlines/#blurred-buffer
I didn't really understand why every image is slowly moving around. It says:
> Above the box you have an Animate button, which will move the scene around to tease out problems of upcoming algorithms. Movement happens before our blur will be applied, akin to the player character moving.
I don't really understand the explanation - the movement just seemed a bit annoying.
This is not the first time [1] I hear this critique of movement by default being annoying. Should I just turn it off by default?
[1] https://news.ycombinator.com/item?id=42191709
I don't understand its explanation therefore it's annoying
These blur effects, like any other graphical thing, can have a similar effect when combined with motion. The animate function is to bring these issues out, if there is any.
I'm not sure either way, would you say this makes it easier to read and I should make it the default?
How much of it is convention vs based in measurable outcomes is up for debate (maybe), but at least that’s where most every formally trained designer/visual artist in the west comes from.
So in this current case, since OP's blog is on the internet and not printed, I would suggest unjustified.
What? I'm pretty sure that if I pick any book in my shelf, it's going to be justified.
> Most web media are narrow-column format, so tend to be fully justified.
What #2? 99% of web media is ragged-right, the biggest reason being that it's the default, and that browsers have terrible line-wrapping and historically had no support for hyphenation. And justified text gets worse the shorter the lines are, because there are fewer options on where to insert newlines, leading to large spaces between words. Also, good justification requires fine-grained word spacing control, which doesn't work well with traditional low-resolution displays.
My MSc thesis advisor recently told that apparently thesis documents should be submitted with ragged-right lines these days because it makes them easier to read for dyslexics; while it makes sense, it must be a quite new guideline.
[1] https://github.com/oxalorg/sakura
On displays, readability works out differently, and that's why I speculate this has changed. For example, printed media uses serif fonts to aid readability, but on displays, sans-serif works better, especially on lower resolutions.
Spherical Harmonic Lighting is an alternative or used to supplement the generation of HDR cube maps for the purpose of global illumination. For the very diffuse aspect of this global illumination, Spherical Harmonics are used (Often called light probes), as a very cheap approximation of the environment, that is easy to get in and out of shaders and interpolate between them. They are just a bunch of RGB floats, so you can place a ton of them in the environment to capture a scene's direct or indirect lighting. For specular reflections you still have to use HDR cube maps, as the light probes don't hold enough information for that task.
Blurs are a basic building block of image processing and used in a ton of effects. In a way, there are related topics, as the cube maps generated to cover different roughness factors for PBR rendering are, in-fact blurs! https://threejs.org/docs/#api/en/extras/PMREMGenerator But that's not the topic of the article, but instead of how to do blurs efficiently in real time, in the first place.