This PR addresses the following issues that occur when using smudging w. spectral blending:
Artifacts caused by low alpha
Assymetric smudging into transparent areas
Smudge never becoming fully transparent
Compatibility with the old smudge
It also cleans up most of the code in prepare_and_draw_dab.
Here are some examples of what the artifacts look like
Severe artifacts caused by only using a white and red smudge brush.
For comparison, when not using the Pigment layer type, the artifacts are barely visible (but the desaturated parts still are).
Smudge never stopping, and the transparency smudge assymetry
Basically, the input requirements for actually using spectral mixing are expanded, and falling back to additive mixing is more liberal. Instead of clamping the opacity, we test against the output opacity and canvas opacity to determine how to proceed. Artifacts are ultimately caused by a lack of precision that leads to loss of color information, and since this happens to a greater degree the darker the blended colors are, additive blending is also used in these cases.
Artifacts that still occur without the inclusion of the last commit in this PR, which adds conditionals to check for dark colors.
A couple of the uses of fastpowhave been replaced with powf to avoid accumulated rounding errors - the uses of the fastpowapproximations in critical loops remain.
The behaviour of the subtractive color sampling is no longer dependent on whether the initial sections have completely transparent alphas - fixing the assymetry problem.
There are still things about the smudging which are very questionable (smudging into areas with low transparency seem to disproportionately use the existing low-alpha color) and these fixes undoubtedly have visual tradeoffs in some other scenarios. I don't think anything is significantly worse than the current state, but I may have missed something.
Additionally, these fixes will not prevent the greying effect of low alphas/dark colors - again, due to lack of precision, that effect is probably unavoidable.
Note: I must have accidentally squashed the code cleanup, assymetry and never-ending smudge commits during a rebase...
Relevant changes for fixing never-ending smudge: mypaint-brush.c - new lines 864-868
_Relevant changes for assymetry: changes to get_color_pixelsaccumulate in brushmode.c
Edit: And the legacy smudge fallback commit got squashed with the "Split out and clean up input debug printing" commit... I haven't messed up a rebase like this in a long time. I'll see if I can recover them. and redo this.
Edit 2: Revisionism complete (could not be arsed fixing out-of-order timestamps).
Edit 3:Don't merge yet, still a color problem to solve (I noticed that the smudge buckets now produce questionable output colors when used with alpha lock).
This PR addresses the following issues that occur when using smudging w. spectral blending:
It also cleans up most of the code in
prepare_and_draw_dab.Here are some examples of what the artifacts look like
Basically, the input requirements for actually using spectral mixing are expanded, and falling back to additive mixing is more liberal. Instead of clamping the opacity, we test against the output opacity and canvas opacity to determine how to proceed. Artifacts are ultimately caused by a lack of precision that leads to loss of color information, and since this happens to a greater degree the darker the blended colors are, additive blending is also used in these cases.
A couple of the uses of
fastpowhave been replaced withpowfto avoid accumulated rounding errors - the uses of thefastpowapproximations in critical loops remain.The behaviour of the subtractive color sampling is no longer dependent on whether the initial sections have completely transparent alphas - fixing the assymetry problem.
There are still things about the smudging which are very questionable (smudging into areas with low transparency seem to disproportionately use the existing low-alpha color) and these fixes undoubtedly have visual tradeoffs in some other scenarios. I don't think anything is significantly worse than the current state, but I may have missed something.
Additionally, these fixes will not prevent the greying effect of low alphas/dark colors - again, due to lack of precision, that effect is probably unavoidable.
Note: I must have accidentally squashed the code cleanup, assymetry and never-ending smudge commits during a rebase...Relevant changes for fixing never-ending smudge: mypaint-brush.c - new lines 864-868_Relevant changes for assymetry: changes to get_color_pixelsaccumulate in brushmode.cEdit: And the legacy smudge fallback commit got squashed with the "Split out and clean up input debug printing" commit... I haven't messed up a rebase like this in a long time. I'll see if I can recover them. and redo this.Edit 2: Revisionism complete
(could not be arsed fixing out-of-order timestamps).Edit 3:
Don't merge yet, still a color problem to solve (I noticed that the smudge buckets now produce questionable output colors when used with alpha lock).Ok, this is now fixed as well.