Colorequal decouple brightness #16218
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jenshannoschwalm
added
scope: image processing
|
@TurboGit not sure if we want the third commit merged into master, it certainly helps to understand "what goes wrong" with current code. |
jenshannoschwalm
force-pushed
the
colorequal_decouple_brightness
branch
from
ffc2331 to
e9e71a6
Compare
Reading this do I understand correctly that this PR is 100% equivalent to current master (expect for fast expf)? I'm asking because even if using expf I see big differences in the output, but maybe that's due to the bilinear interpolation being done in 2 steps. |
We likely require blurring the brightness correction to be independent of the chroma corrections.
Improves performance a lot. Due to definition of `dt_fast_expf()` there is a significant error but that is not significant for what we do here. (Might change this later to some lookup table for performance)
At least while we work on the brightness corrections in the guided filter we would like some visualizing of "what happens". Introduced a mask button after the effect radius slider. If active it shows the "saturations" data plus false-color representation of brightness correction. Shifts to red show increased brightness, to blue decreased brightness.
We should use the "size_allocate" signal to enforce a refresh of the background colors.
jenshannoschwalm
force-pushed
the
colorequal_decouple_brightness
branch
from
ea267be to
d5466cc
Compare
|
There was a blurring sigma change. Fixed. Should be ok now... |
TurboGit
approved these changes
Jan 31, 2024
There was a problem hiding this comment.
All good now, thanks.
With fast_expf:
Expected CPU vs. current CPU report :
----------------------------------
Max dE : 1.42615
Avg dE : 0.03530
Std dE : 0.13232
----------------------------------
Pixels below avg + 0 std : 92.53 %
Pixels below avg + 1 std : 92.75 %
Pixels below avg + 3 std : 95.14 %
Pixels below avg + 6 std : 99.60 %
Pixels below avg + 9 std : 99.99 %
----------------------------------
Pixels above tolerance : 0.00 %
With expf:
Expected CPU vs. current CPU report :
----------------------------------
Max dE : 0.00000
Avg dE : 0.00000
Std dE : 0.00000
----------------------------------
Pixels below avg + 0 std : 100.00 %
Pixels below avg + 1 std : 100.00 %
Pixels below avg + 3 std : 100.00 %
Pixels below avg + 6 std : 100.00 %
Pixels below avg + 9 std : 100.00 %
----------------------------------
Pixels above tolerance : 0.00 %
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently we process all three correction parameters with the same gaussian blur in one 4-channel group.
We might want to process the brightness correction in a different way so that has been split and we have to blur twice for each group of correction.
Using the fast "expf" variant gives a huge performance gain without significant differences.