FR: 2 Mu parameters instead of 1 (enfuse)
Bug #746653 reported by
Joergen Geerds
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Enblend |
Fix Released
|
Wishlist
|
Christoph Spiel |
Bug Description
I hope I have understood the parameters right, but the Mu parameter represents the middle gamma value of the enfusion (defining the middle "grey" basically).
Would it be possible to introduce Mu1 and Mu2, which by default would be 0.33 and 0.66. The two values would basically control the relative brightness of the shadows and highlights, giving the user an opportunity to selectively bring in more highlight details and/or shadow details during the enfusion process... the old Mu would be defined as the center between Mu1 and Mu2.
To post a comment you must log in.
The command-line parameter passed with
"--exposure-mu" does not define the "middle
gamma value", but the luminance Y (of an input
pixel) in the normalized luminance interval [0,
1] that gets the highest weight in fusing.
Probably, you can achieve what you want by
rewriting the definition of w_{\mathrm{exp}}(Y)
in Ch. 5.2 of the Enfuse manual in terms of your
\mu_{1/3} and \mu_{2/3}.
I consider adding your specific
parametrization nothing more than a band-aid
solution of a problem that I have wanted to
attack for a long time:
(a) defining more weighting functions (think of
Lorentzian, Triangle, etc.), and
(b) letting the user define her own weighting
functions.
The options "--exposure-mu" and function= gaussian: 0.5:0.2 function= lorentzian: 0.5:0.5 function= triangle: 0.4:0.99
"--exposure-sigma" would then be obsoleted by a
new option with a new syntax, and the current
defaults could look like this:
--exposure-
with alternatives like
--exposure-
--exposure-
From this point on incorporating (b) is function= '(define (y mu sigma) (exp (* 0.5 (sqr (/ (- y mu) sigma))))):0.5:0.2'
pretty straightforward:
--exposure-
where I have used Scheme as an example and again
have duplicated the current defaults. How to
evaluate an expression like the above in an
efficient way looks like an interesting problem.