Skip to content

Global histogram equalisation is non-deterministic #1416

Closed
Closed
Global histogram equalisation is non-deterministic#1416
Assignees
brianpopow
Labels
bug
Milestone
Future

Description

@nullpainter
nullpainter
opened on Nov 6, 2020

Prerequisites

  • I have written a descriptive issue title
  • I have verified that I am running the latest version of ImageSharp
  • I have verified if the problem exist in both DEBUG and RELEASE mode
  • I have searched open and closed issues to ensure it has not already been reported

Description

As per discussion #1413, applying the default global histogram on an image produces different results on repeated runs of the same image.

Steps to Reproduce

I have created a repro which demonstrates this issue. It loads an image, performs histogram equalisation a number of times and reports on the percentage of pixel differences between repeated runs.

Sample output:

Run #1: 56.93% different pixels to reference
Run #2: 54.81% different pixels to reference
Run #3: 61.85% different pixels to reference
Run #4: 61.83% different pixels to reference

Note that adaptive sliding window and adaptive tile interpolation do not exhibit this behaviour:

Run #1: identical to reference
Run #2: identical to reference
Run #3: identical to reference
Run #4: identical to reference

System Configuration

  • ImageSharp version: 1.0.1
  • Environment (Operating system, version and so on): Windows 10
  • .NET Framework version: .NET Core 5 preview, compiled with .NET Core 3.1

Activity

  1. nullpainter
    added
    needs triage
    on Nov 6, 2020
  2. antonfirsov
    added
    bug
    and removed
    needs triage
    on Nov 6, 2020
  3. antonfirsov
    added this to the Future milestone on Nov 6, 2020

  4. antonfirsov commented on Nov 6, 2020

    @antonfirsov
    antonfirsov
    on Nov 6, 2020
    Member

    Thanks!

    Quoting @tocsoft from an internal discussion:

    just had a quick look at the histogram code looks like we are manipulating a shared buffer in parallel in GrayscaleLevelsRowOperation the increment isn't interlocked so from what i can tell there is a chance that some of the increment operations could be lost...wonder if we have the issue if Parallelism is disabled.

    Any further investigation, or other any form of community help is welcome as always! :)

  5. JimBobSquarePants commented on Nov 7, 2020

    @JimBobSquarePants
    JimBobSquarePants
    on Nov 7, 2020
    Member

    Yep, reviewed the histogram generation code. It shouldn't be parallel.

  6. brianpopow commented on Nov 8, 2020

    @brianpopow
    brianpopow
    on Nov 8, 2020
    Collaborator

    i see the issue now. Its during the histogram calculation. We can use Interlocked.Increment here and still do it in parallel.

  7. brianpopow
    added a commit that references this issue on Nov 8, 2020

    Use Interlocked.Increment during histogram calculation, fixes issue #…

    274cabf
  8. brianpopow
    self-assigned this
    on Nov 8, 2020

  9. brianpopow commented on Nov 8, 2020

    @brianpopow
    brianpopow
    on Nov 8, 2020
    Collaborator

    closed via #1418

    Thanks for reporting this @nullpainter

  10. brianpopow
    closed this as completedon Nov 8, 2020
  11. JimBobSquarePants
    added a commit that references this issue on Mar 13, 2021

    Use Interlocked.Increment during histogram calculation, fixes issue #…

    bc7ea4f
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bug

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions