Does anyone know how to write a mathematical expression for a curve that transitions from linear to logarithmic at a defined cut point? I.E., if I wanted a curve that boosts linear exposure by 4x (2 stops) but rolls off logarithmically to 1.0 with the transition falling at the point where the linear and logarithmic curves blend smoothly.
I’m assuming it will need to be a conditional if/then expression, such as
if ($x<=[cut point], $x4, log2(a$x+b)/2^a - ???)
The tricky part for me is determining the exact point where the linear and log curves meet and understanding how to scale/position the log portion to blend into the linear portion.
I’m not a math person by any stretch, but functionally should be pretty easy to plot a linear slope to a known point in the log function, and conditionally trap the plot to one or the other based on that point.
Edit: Ah, for a moving EC slope, you’ll need to scooch the log function back and forth, a little more complicated. Also complicated by finding a common slope at the connecting point. I think there’s code in either/both dt and RT to do this for their EC tool…
Thinking further, you’ll need to define a function logstart(ec), which takes the ec and returns a log x,y to which to transition. Thinking even further, I don’t think you’d want to use a straight log function, because as you increase ec, the remaining log curve would be flatter… I just looked at dt/RT manuals, none do this directly, but RT seems to have something similar in Highlight Compression…
I started a rolloff branch in rawproc, and I’m playing with your penultimate function. UI-wise, needs preparatory math to allow a simple 1-10 slider to feed it; not sure where I’d start with u and n…
I’ve thought about such a tool intermittently; I really should do it because G’MIC was really the inspiration for rawproc’s toolchain organization. I guess it could be as simple as what I do for groups: just provide a box to type stuff in, and then the marshalling code to put my image array into something G’MIC will digest.
Now, rawproc internal representation is 0.0-1.0; would you be willing to surround your code with conversion ops to translate to 0.0-255.0 and back to 0.0-1.0?
G’MIC doesn’t care about ranges. It is just a math tool with image processing capabilities. You could have options that decide what to do pre and post filter. E.g. normalize range to 0-255 or 0-1 and how much to clip.
Absolutely! In all seriousness, this would be an incredibly useful feature. Prototyping work with raws is not the easiest thing without the required pre-processing. I sometimes work on the bayer side and sometimes after it. It makes perfect sense to test an idea in a high level g’mic script before writing some C.