Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rework gamut_LUT sampling #17436

Merged
merged 3 commits into from
Sep 20, 2024
Merged

Conversation

jenshannoschwalm
Copy link
Collaborator

Fixes and flexibility for LUT_ELEM

LUT_ELEM is currently meant to be used with a table per 1°, this commit

  1. allows larger tables to be used for higher precision for later linear interpolation
  2. does not use the final averaging any more as it didn't help at all.
  3. Fix color equalizer and colorbalancergb to work correctly with all values of LUT_ELEM

Increase LUT_ELEM to 512

Subtly improved precision for lookup_gamut function due to larger table.
Also, as we use LUT_ELEM to be as 2^n we can redefine lookup_gamut

  • removing the restriction of hue input angle
  • improved performance

@jenshannoschwalm jenshannoschwalm added feature: enhancement current features to improve priority: medium core features are degraded in a way that is still mostly usable, software stutters scope: image processing correcting pixels scope: codebase making darktable source code easier to manage labels Sep 7, 2024
@jenshannoschwalm jenshannoschwalm added this to the 5.0 milestone Sep 7, 2024
@jenshannoschwalm jenshannoschwalm force-pushed the lut_sampling branch 2 times, most recently from 843beed to 829b633 Compare September 7, 2024 11:41
@TurboGit
Copy link
Member

TurboGit commented Sep 7, 2024

This breaks at least test 0093-colorbalancergb-ucs:

Test 0093-colorbalancergb-ucs
      Image mire1.cr2
      CPU & GPU version differ by 230497 pixels
      CPU vs. GPU report :
      ----------------------------------
      Max dE                   : 1.64225
      Avg dE                   : 0.03006
      Std dE                   : 0.11560
      ----------------------------------
      Pixels below avg + 0 std : 91.77 %
      Pixels below avg + 1 std : 92.36 %
      Pixels below avg + 3 std : 96.98 %
      Pixels below avg + 6 std : 99.46 %
      Pixels below avg + 9 std : 99.94 %
      ----------------------------------
      Pixels above tolerance   : 0.00 %
 
      Expected CPU vs. current CPU report :
      ----------------------------------
      Max dE                   : 3.69803
      Avg dE                   : 0.05937
      Std dE                   : 0.24551
      ----------------------------------
      Pixels below avg + 0 std : 89.55 %
      Pixels below avg + 1 std : 93.61 %
      Pixels below avg + 3 std : 98.05 %
      Pixels below avg + 6 std : 99.25 %
      Pixels below avg + 9 std : 99.75 %
      ----------------------------------
      Pixels above tolerance   : 0.24 %
 
  FAILS: image visually changed
         see diff.png for visual difference
         (298060 pixels changed)

The diff output is:

image

Probably expected? Can you confirm @jenshannoschwalm? TIA.

@jenshannoschwalm
Copy link
Collaborator Author

Yes, (unfortunately) expected.

If you think, the difference is too big, i would rethink. Yet - the new way offers clearly improved gamut_luts for UCS mode. The option would be to use different algos ...

Another point, there is also some surpringly large difference in CPU vs GPU code in colorbalancergb. So we might have - i would say hopefully - another round of differences if the reason for this is found. (still on the track)

@TurboGit
Copy link
Member

TurboGit commented Sep 7, 2024

@jenshannoschwalm

Another point, there is also some surpringly large difference in CPU vs GPU code in colorbalancergb.

Yes, I've seen that too.

So we might have - i would say hopefully - another round of differences if the reason for this is found. (still on the track)

Let's wait a bit before merging this then, I'll prefer having a single integration test update if possible.

LUT_ELEM is currently meant to be used with a table per 1°, this commit
1. allows larger tables to be used for higher precision for later linear interpolation
2. does not use the final UCS mode box averaging any more but uses proper average of data inside the lut element.
3. Fix color equalizer and colorbalancergb to work correctly with all values of LUT_ELEM
That code was copy&pasted from the original in colorbalancergb,
has been deduplicated.
Subtly improved precision for lookup_gamut function due to larger table.
Also, as we use LUT_ELEM to be as 2^n we can redefine lookup_gamut
- removing the restriction of hue input angle
- improved performance
@jenshannoschwalm
Copy link
Collaborator Author

@TurboGit would you re-review?

I think the first 2 commits should be merged in any case as simplification, code-bug fix and deduplication.

The third commit improves "things" slightly, marginally better interpolated data plus subtle perf gain.

@TurboGit
Copy link
Member

@jenshannoschwalm : Sure, I'll try to review again later today.

Copy link
Member

@TurboGit TurboGit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, I'll update 0093 test. Thanks!

@TurboGit TurboGit merged commit 3ea7bd4 into darktable-org:master Sep 20, 2024
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature: enhancement current features to improve priority: medium core features are degraded in a way that is still mostly usable, software stutters scope: codebase making darktable source code easier to manage scope: image processing correcting pixels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants