RGS Blur

What features would you like to see in Pixelmator Pro?
User avatar

2019-07-27 07:43:49

Yeah... I just made up the term RGS Blur. It stands for Root Gaussian Square Blur but, then again, I'm really bad at naming things. Also, there probably already is a name for this, I just don't know what it is. :grin: The algorithm for an RGS Blur is as follows:

1. Take the square of each pixel, i.e. (R², G², B²).
2. Apply a Gaussian blur of the resulting array of values.
3. Take the square root of each resulting pixel value.

Here's why:
https://www.youtube.com/watch?v=LKnqECcg6Gw
(skip to 2'33" and watch to 3'09" if you don't want four minutes of video).

What do you think?

- Stef.
User avatar

2019-07-27 10:01:19

Hi st3f,

Thank you for your question; this topic is really interesting.

Frankly speaking, I don't like the title of the video («Computer color is broken»), and phrases in it like «wrong», «ugly», etc.

When designing Pixelmator Pro architecture, we were carefully considering all the stuff mentioned in the video (and all other stuff also), and came to the conclusion that we should do color processing numerically, as in older software (opposed to perceptually).

The problem is that perceptual color processing should be implemented in «all or nothing» way. We either should make the software completely color-space-agnostic (compute everything perceptually) and consider color spaces only at import and export, or should do all operations numerically.

If we mix perceptual and numerical approaches, we will come to contradictions. For example, you paint red color over green background via smooth brush in single layer. You will have these «ugly» brown edges around brush strokes (between red and green colors). If we implement brush smoothness perceptually, then you will get good-looking yellow edges when painting on single layer. But then layer blending should also be implemented perceptually, otherwise your will still have dark edges if you paint by red brush on separate transparent layer over another green layer. Thus, we need perceptual layer blending in order to not contradict to single-layer painting. This extends to everything, and the software should be completely implemented in perceptual color processing way.

If we did everything perceptually, then minimum required color depth will be 16 bits per channel, and all the results will differ from those in other software, so users will be surprised. Even things like RGB color model are numerical detail of implementation and very remotely related to the way we see colors, but everyone still wants to have tools like RGB Levels and Curves in image editor.

So, we come to the following compromises:
1) All filters, brushes, gradients, blending, etc. are implemented numerically, not perceptually.
2) Color Adjustments are implemented perceptually, except RGB adjustments (to not surprise users).

Numerical color adjustments are following: RGB Levels, RGB Curves, RGB Channel Mixer, Inversion (Luminance Levels and Luminance Curve are perceptual). Grain and sharpness are currently (as of version 1.4) are numerical, but we will redo them in a perceptual way.

The most important thing is that you can get perceptual processing for everything you want. You just need to use linear color space, because in linear color space numerical color processing corresponds to perceptual color processing. Do the following:
1) Image → Color Depth... → 16-bits per channel;
2) Image → Color Profile... → Advanced → ACES CG Linear (Match to Profile).
It is important to do 16 bits first, otherwise you will loose lots of color information at converting to ACES, because ACES requires 16 bit to work properly (we are going to improve this user experience).
User avatar

2019-07-27 16:57:08

Here is comparison of the same 30px Gaussian Blur in two different color spaces:

Image

Image
User avatar

2019-07-27 17:13:44

P.S.: Talking about «RGS Blur» your proposed: in many cases it will look better than «regular» blur, but it is still incomplete solution, since sRGB decoding (gamma) curve is not exactly quadratic curve:

https://www.desmos.com/calculator/swwv6xiui8

so RGS Blur will look worse than «regular» Gaussian Blur in ACES linear color space. Also, sRGB color space is not the only one around there, and different color spaces can have different gamma curves. Also, square-blur-root trick will not help if you blur some layer content on top of other layer (such as blurring layer with red rectangle on top of solid green layer), because numerical layer blending will ruin your square-blur-root stuff.

We can consider adding «Use linear color» checkbox in effects panel (then similar checkbox in blending settings, then similar checkbox in brush settings, then in gradient fill setting...) that will give you desired result without changing document color space to linear.
User avatar

2019-07-28 21:06:02

Hi Anton.

You guys never cease to amaze me. I ask for a new effect to be applied to *one* tool as a variant and you let me know that there's a whole method of working that no only supplies the effect that I want that that one tool but lets me use it with every tool at my disposal. Thank you so much. That is awesome! :grin:

There might be occasions that I want to work in sRGB and still have access to a perceptual Gaussian Blur but those occasions will be few and far between. What's more likely is that when I need to apply a Gaussian Blur, I may also need access to a brush that work in the same way, so it makes sense that I switch to using a linear colour-space up-front when I think I am going to need it. In other words, I'd call my feature request not only met but also exceeded. I'd probably want Color Depth to get its own shortcut key so that I can use it with the Photos extension but that's about it.

A regards the language in the video, I think it says a lot about perspectives and the constraints of technology. A few years back, I showed my then 12-year-old nephew some historic tech that was ahead of its time when it was made, but was now verging on being a museum-piece. His response was that it was rubbish. He couldn't see beyond its current utility. I could see his point of view, that compared against current devices it was sorely lacking in functionality and speed. But I could also see its history, how it made the devices that he was comparing it to possible. How they might not have come into being without it having carved the path first.

I see some of the same language in the video. It's looking at an approach to graphics that ignores the constraints that previous technology has put on us in the past. It ignores the history. I *do* think that the way bright colours blend is much prettier in a linear colour space but I understand that if you're limited on RAM, storage and processor power, that you're going to compromise. That, in the days when 24-bit colour was often aspirational rather than the basic option, that you'd choose to get the most out of that data with a non-linear encoding. And that when you're creating software that manipulates images today you've got to respect that history or you'll create a whole new set of problems. I don't think the words 'lazy' and 'wrong' help with that but am willing to forgive the video a lot as I think it's really informative.

Anyhow... this got a bit rambly. What I really wanted to say was thanks for taking the time to explain how Pixelmator Pro works under the hood and thanks for including features that I wanted but didn't know were there. I just spent ten minutes painting bright colours over the top of each other and grinning like a madman. Fun times.

All the best.

- Stef.