Equalizer module unevenly applied based on exported image size
I have narrowed this down after seeing a difference in the same image exported to different target sizes.
It appears that the equalizer module is being applied at increasing levels based on the exported image size up to a certain height threshold, but at that height threshold, the cycle starts over again.
So, if I exported the attached checkerboard image (dt_bug.jpg), at a height of 400, it will have less than the desired amount of the equalizer module applied. At an exported height of 977, there appears to be the entire amount of the equalizer module applied. At an exported height of 978, the amount of the equalizer module applied drops to almost zero. The cycle starts again, and I have found another threshold at 1946.
I base my estimates of the equalizer amount appied by looking at the image histograms in linear space versus what I see in the darktable gui before export. I did not try to quantify it but the effect is clearly obvious in the images and the histograms.
I tried the CLI version of darktable, and it seems to be doing the same thing, though the thresholds must be different.
I also tryed to see if the bug was present in the shadows and highlights module, and I saw no evidence that the shadows and highlights module has the same bug.
I'm using linux Mint 18.1, graphics card is NVidia GeForce GTX 960M
I will be more than happy to provide more information or do more exploration of the bug.
#2 Updated by Jeff Welty over 1 year ago
Further investigation with hq export turned off shows that for my image, at an exported height of 977 pixels, the get_scales() function in atrous.c returns 5, and at an exported height of 978, get_scales() returns 6. So there is an nearly instantaneous application of an additional larger scale in the decompose/sythesize steps as you move over that threshold from 977 to 978. Not sure how one would improve the module performance but it seems to be a math problem, not a coding error.
#3 Updated by Roman Lebedev over 1 year ago
- Status changed from New to Closed: won't fix
[16:18:11] <LebedevRI> !bug 11822
[16:18:13] <dtslave> Bug #11822: Equalizer module unevenly applied based on exported image size - darktable - darktable - photography workflow application (https://redmine.darktable.org/issues/11822)
[16:18:19] <LebedevRI> hanatos: ^ closed: wontfix?
[16:44:25] <hanatos> LebedevRI: yeah, not possible to fix. it just depends on size.
[16:44:39] <LebedevRI> yay, i guessed correctly
[16:44:42] <hanatos> we are scaling parameters
[16:44:50] <hanatos> but it's just an approximation to what's happening of course
[16:44:59] <hanatos> wavelet scales are very discrete in nature.
#6 Updated by Jeff Welty over 1 year ago
I'm wondering if Roman's comment that target version was set to 2.4.0 meant the fix I provided for atrous.c ( https://github.com/weltyj/darktable/tree/equalizer_module_improvement ) was supposed to be included in the 2.4.0 release, and just got left out unintentionally?
#8 Updated by Jeff Welty over 1 year ago
- File dt_bug.jpg added
- File dt_bug.jpg.xmp added
- File dt_gui_export_current_0978h.jpg added
- File dt_gui_export_current_0250h.jpg added
- File dt_gui_export_current_0375h.jpg added
- File dt_gui_export_current_0492h.jpg added
- File dt_gui_export_current_0493h.jpg added
- File dt_gui_export_current_0249h.jpg added
- File dt_gui_export_current_0977h.jpg added
- File dt_gui_export_current_0750h.jpg added
I have run a suite of image sizes, with dt 2.4.0 (jpg files named "...current...) and with the "fade in" code that now resides in src/iop/atrous.c at ( https://github.com/weltyj/darktable/tree/equalizer_module_improvement )
wavelet scale thresholds are at exported heights of 249/250 492/493 977/978 1946/1947 and 3885/3886. I also created export heights near the midpoint between the threshold heights.
I have used the clarity settings on 2 instances of the equalizer model on the checkerboard grid to create and exaggerated effect so it's easy to compare differences.
More files coming in another post or two
- If you want to compare results, DO NOT use the dt_bug.jpg.xmp from November 2017, use ths one I just added on Jan 24, 2018 **
#9 Updated by Jeff Welty over 1 year ago
- File dt_gui_export_current_1500h.jpg added
- File dt_gui_export_current_3886h.jpg added
- File dt_gui_export_current_3885h.jpg added
- File dt_gui_export_current_3000h.jpg added
- File dt_gui_export_current_1947h.jpg added
- File dt_gui_export_current_1946h.jpg added
- File dt_gui_export_current_0978h.jpg added
#10 Updated by Jeff Welty over 1 year ago
- File dt_gui_export_fadein_1946h.jpg added
- File dt_gui_export_fadein_0249h.jpg added
- File dt_gui_export_fadein_0250h.jpg added
- File dt_gui_export_fadein_0375h.jpg added
- File dt_gui_export_fadein_0492h.jpg added
- File dt_gui_export_fadein_0493h.jpg added
- File dt_gui_export_fadein_0750h.jpg added
- File dt_gui_export_fadein_0977h.jpg added
- File dt_gui_export_fadein_0978h.jpg added
- File dt_gui_export_fadein_1500h.jpg added