color balance: slope, offset, power: optimize luma finds right values but initally uses wrong ones

[trougnouf]

When using color balance: "slope, offset, power", optimize luma will produce very light results that appear completely off.

Scrolling back and forth on "factor" (which restores the values shown initially) produces the desired results.

Using Arch Linux, version 2.7.0+95~gf85f182e6 and files from an X-T1 (X-Trans)

[aurelienpierre]

Hmm I should write the doc about that. The thing is the luma optimization tries to remap the max RGB to 100 % luminance, the min RGB to 0 % and the average RGB to 50 %, over the selected area. So, if you select a dark area to do the auto-optimization, what happens is normal.

But, I have found that there is a ×100 error in the UI when the auto-optimizer is run (the value displayed is a ratio between [0; 1] but it should be a %). So that explain why, when you scroll after the optmization, the values are actually remapped closer to 0. I must correct that.

[trougnouf]

That does fix the scrolling behavior, thank you :)
The image still ends up very light, and I don't seem to be able to select a particular area when I click on optimize luma, is that normal behavior and I should wait for the documentation and close this or it's a potential bug?

[aurelienpierre]

is that normal behavior and I should wait for the documentation and close this or it's a potential bug?

It really depends which area you sample for the auto-tuning. Also, I see you are using it with filmic, so what you see is a double up : both filmic and color balance are raising the mid-tones. Just stick with filmic to fix the lightness. Your first image is quite good, add a bit of contrast in colorbalance and you are good to go.

If you want to ensure the auto-tuner is working properly, disable filmic, spot an area with the color-picker, trigger the optimization, and ensure, with the global color picker that the average luminance over the zone is 45 - 50 % (it should be 50 %, but the measure is done in the display RGB, so it measures what you see after the output RGB conversion, and not the actual data).

[trougnouf]

Thank you, I got it to work well :) There still seems to be an interface bug, clicking on "optimize luma from patches" optimizes over the whole image, with seemingly no way to select a patch (though it often appears to work when I click on it and select an area before it's done "working..." the first time after a reset). The individual selectors (s.a. "factor") on the other hand remain in selection mode after performing their computation, allowing the user to select a different patch.

Thank you! That picture is my first experience with the filmic module and it's performing great! It's taking some used to and the help of your very helpful documentation and I don't think I could have gotten such results with my previous workflow.
Its "black relative exposure" optimizer doesn't work on some of my (X-Trans) photos (such as this one), it selects the minimum value, getting it to work usually involves deactivating the lens correction, rotating by 0.25degrees, or a slight crop, I will file a separate bug report once I have a few different sample raws (not doing a lot of photo editing atm because I have an upcoming exam).

[aurelienpierre]

here still seems to be an interface bug, clicking on "optimize luma from patches" optimizes over the whole image, with seemingly no way to select a patch

To select the patches, you have to use each of the 3 slope/offset/power factors color-pickers in this order. Then hit the optimization button.

it selects the minimum value, getting it to work usually involves deactivating the lens correction, rotating by 0.25degrees, or a slight crop

There is not much I can do here. All of your fixes involve interpolation so that means you have bad noise that gets blured this way. The thing is the optimizer works assuming the min RGB is black, but has no way to ensure it's not actually noise or demosaicing artifacts.

Or maybe I could blur the picture slightly before measuring the minimum, but I have to check how to do that from the UI.

Good luck for your exam !

[trougnouf]

Thank you!

I've uploaded the RAWs I already found to be affected on https://drive.google.com/open?id=12tB8HNLdznfKqd5Ip8SUwnw3BTs82yFZ , I noticed that clipping the input gammut to sRGB and demosaicing in frequency domain chroma could also work, but no workaround works consistently (and so far denoising / hot pixels / defringe hasn't been a fix)