Bug 412445 - Adjust Levels : histogram is not the same when Default settings are restored
Summary: Adjust Levels : histogram is not the same when Default settings are restored
Status: RESOLVED DUPLICATE of bug 128377
Alias: None
Product: digikam
Classification: Applications
Component: Plugin-Editor-Levels (show other bugs)
Version: 6.4.0
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-29 11:27 UTC by Alexandre Belz
Modified: 2022-01-07 05:22 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Screen capture of the bug. (1.27 MB, image/png)
2019-09-29 11:27 UTC, Alexandre Belz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandre Belz 2019-09-29 11:27:54 UTC
Created attachment 122934 [details]
Screen capture of the bug.

SUMMARY
Top/Bottom histograms are not the same even if I restore Default settings on this module.

STEPS TO REPRODUCE
1. Open a picture
2. Do some Level Adjustment modification (luminosity mode)
3. click on Defaults

OBSERVED RESULT
The histograms are not the same.

EXPECTED RESULT
Histograms should be the same (no processing done with "Defaults").

SOFTWARE/OS VERSIONS
Windows: 10

ADDITIONAL INFORMATION
Screen capture attached
Comment 1 Maik Qualmann 2019-09-29 12:40:38 UTC
Also this little problem has already been reported, I have to search the bug report first. The difference from the histograms comes from the fact that the preview is a reduced preview for performance reasons. This is not a bug for me. Another problem is that on HiDPI screens, the preview image looks fuzzier. Although I can render the "Before" image sharply, but not the "After" image. Therefore, I'm currently synonymous the "Before" image does not render sharply on HiDPI screens. The preview image in full resolution is not a solution, it is really slow then.

Maik
Comment 2 Maik Qualmann 2019-09-29 12:43:12 UTC

*** This bug has been marked as a duplicate of bug 128377 ***