After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 757485 - Several additional blend modes should by default blend using linearized RGB
Several additional blend modes should by default blend using linearized RGB
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: General
git master
Other All
: Normal normal
: 2.10
Assigned To: GIMP Bugs
GIMP Bugs
: 757685 (view as bug list)
Depends on: 735898
Blocks:
 
 
Reported: 2015-11-02 15:10 UTC by Elle Stone
Modified: 2018-01-02 18:25 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Elle Stone 2015-11-02 15:10:57 UTC
A presumed goal for high bit depth GIMP is to make it easy for users to get radiometrically correct editing results. 

A common use case for image editing is blending layers together. Many of GIMP's Layer Blend Modes operate by default on perceptually uniform RGB, when radiometrically correct blending requires operating on linearized RGB.

The following blend modes, and also painting with these blend modes, should operate on linearized RGB by default instead of requiring users to switch from "gamma" to "linear" precision to get radiometrically correct results:

Normal, Dissolve
Lighten only, Darken only
Multiply, Divide, Screen
Addition, Subtract

The LCH blend modes already operate on linearized RGB. The equivalent HSV blend modes probably also should operate on linearized RGB, but that's not so important given that GIMP has the LCH blend modes.

See http://ninedegreesbelow.com/photography/test-for-linear-processing.html for 7 quick tests to check whether an image editor is linearizing RGB values to produce radiometrically correct editing. Currently GIMP, when using the default blend modes and options, fails 4 of the 7 tests.

See http://ninedegreesbelow.com/photography/linear-gamma-blur-normal-blend.html#photographs for photographic examples illustrating why Normal blend mode should operate by default on linearized RGB.

If the above-listed blend modes operated by default on linearized RGB for blending and for painting, GIMP would be much easier to use for digital artists trying to use GIMP to do linear gamma digital painting.

The Burn, Dodge, Overlay, and Soft light blend modes are designed to work on perceptually uniform RGB, as they already do by default, when at gamma precision. However, if users switch to linear precision to get radiometrically correct results from Normal, Addition, etc, blend modes, then they have to switch back to gamma precision to get Burn, Dodge, Overlay and Soft light blend modes to work properly, which is awkward and interupts the creative flow.

If the Normal, Dissolve, Lighten only, Darken only, Multiply, Divide, Screen, Addition, and Subtract defaulted to working on linearized RGB for blending and for painting, the need for users to resort to linear precision to get radiometrically correct results would be greatly reduced.

Regarding Grain extract and Grain merge: To work properly on linearized RGB, the Grain extract and Grain merge blends would require the midpoint to be set to 0.184187 (18% linear gamma gray or 50% LAB Lightness gray). Currently the midpoint is set to 0.5. Using grain merge to emulate film seems to me to be more convincing when using linear RGB with a 0.18 midpoint (produces more grain in the shadows, less and smoother grain in the highlights). But there are other uses, such as emphasizing tonality gradations using wavelets, that also need to be considered.
Comment 1 Elle Stone 2015-11-27 11:46:25 UTC
(In reply to Elle Stone from comment #0)
> 
> The equivalent HSV
> blend modes probably also should operate on linearized RGB, but that's not
> so important given that GIMP has the LCH blend modes.

Actually, the HSV blend modes probably should by default operate on perceptually uniform RGB, as "radiometrically correct" makes no sense in connection with HSV.
Comment 2 Øyvind Kolås (pippin) 2016-12-27 02:15:13 UTC
A branch that is straightening out some non-linear trouble in GIMP pippin/linear-is-the-new black hard codes non-linear vs linearized behavior for paint and layer modes. This branch currently only has one additional layer mode, NORMAL-SRGB in addition to the default NORMAL which in the branch is linear. Old XCF files opened gets NORMAL-SRGB assigned instead of NORMAL so that their rendering does not change.

We might need to add additional legacy layer modes for multiply-srgb, addition-srgb, subtract-srgb etc. that are initially hidden in the UI but selected if an old legacy XCF file is opened.
Comment 3 Øyvind Kolås (pippin) 2016-12-27 02:27:49 UTC
*** Bug 757685 has been marked as a duplicate of this bug. ***
Comment 4 Ell 2017-05-07 18:17:36 UTC
Quite a bit has changed since the original report, so this is a quick roundup of where we're at.

Layer blending is split into two parts: blending and compositing.  Blending is the act of assigning a combined color to overlapping regions of the two inputs, according to the layer mode; e.g., for multiply mode, overlapping regions are assigned the product of the two input colors.  Compositing is the act of taking the three possible input colors that contribute to each pixel (regions belonging exclusively to one of the two inputs, and overlapping regions, whose color is determined by blending), selecting which ones to include in the result (that's the composite mode), and taking their weighted average, according to the relative area of the pixel they occupy.  Alpha values determine how much of a pixel's area is occupied by a certain color, and are used to determine the relative weights for compositing (the specifics of which are not really important here.)  Whew, still with me?

The above is relevant, because now we can choose separate color spaces for blending and for compositing (independently of the image precision).  All the new (i.e., non-legacy) modes use linear RGB space for compositing by default, regardless of the color space used for blending.  This lets us knock some of the mentioned modes right off the bat:  Normal and dissolve don't really do any blending (and dissolve doesn't do alpha compositing either), so they're irrelevant.  Lighten-only and darken-only don't depend on the choice of blend space, so they're irrelevant too; the luma/luminance variants of these modes, however, do.  Merge, split, and erase are also irrelevant.

Other than those, most modes still use a perceptual blend space by default, with the exception of addition, subtract, multiply, and divide, and also color-erase (this mode makes little sense when blend-space != composite-space), and luminance.

Choosing a default blend space is tricky, because it depends on the intended use of the mode.  Multiply, for example, *can* be used for radiometrically correct multiplication, which will place it among the arithmetic modes, *or* it can be used as a darkening effect, which will place it among the other darkening modes, *or* it can be used as a fuzzy-logic AND, which will place it among screen (OR) and exclusion (XOR), *or* ...  No matter which group you put it in, having an inconsistent choice of default blend space among the modes of the group is ugly.
Comment 5 Michael Natterer 2018-01-02 16:32:17 UTC
With all the new blend mode magic, is this fixed now?
Comment 6 Elle Stone 2018-01-02 17:33:10 UTC
"Multiply/Divide/Addition/Subtract/Luminance/LCH blend modes" all blend by default using linear RGB. Soft light uses perceptual by default, and so presumably all the other "50%" also use perceptual by default. These choices seem right to me.

It seems dodge/screen/burn all use linear? I would have thought perceptual by default would be more useful for these blend modes. But maybe it doesn't make much difference in practice. I use these blend modes mostly with a brush to make local tonality corrections, and I think I usually do this using linear precision despite my earlier recommendation to use perceptual - either way there is immediate visual feedback.

I didn't check other blend modes, but I think Difference uses linear, which seems right. 

I was checking with the layer stack at linear precision, on the assumption that the precision doesn't affect any of the blend modes.

It would be nice if it were easier to see whether any given layer is using perceptual or linear RGB for the given blend. But that would be a different bug report.

grain-extract/merge was handled in another bug report.

Is everyone happy with lighten-only/darken-only blending by default using linear RGB? I hardly ever use these blend modes except occasionally to control sharpening artifacts.

I'm OK with closing this bug report, FWIW.
Comment 7 Øyvind Kolås (pippin) 2018-01-02 17:37:49 UTC
lighten-only / darken-only work per component, and the result of the formulas thus are identicaly for linear and non-linear representations.
Comment 8 Michael Natterer 2018-01-02 17:57:07 UTC
That sounds good :) Thanks, closing as FIXED.
Comment 9 Elle Stone 2018-01-02 18:25:31 UTC
(In reply to Øyvind Kolås (pippin) from comment #7)
> lighten-only / darken-only work per component, and the result of the
> formulas thus are identicaly for linear and non-linear representations.

Pippin, thanks! That is not intuitively obvious to me, not at all. But checking an example, it's true.