I sent you some sample images and auxiliary data separately. I hope that helps.
I think I know what is going on:
My image (see below) was edited to be quite bright overall. On purpose. I wanted the subject to be properly exposed and I wanted to blow out the sky - I was not interested in what is behind the window, other than it being very bright. I set the pivot input shift to the subject’s face and increased the pivot target output for the intended effect.
When I clicked on the color picker icon AgX has “fixed” the overall exposure, darkening the whole image to expose it for mid-grey level.
Subsequent changes to the selected image area indeed maintained that mid-grey exposure.
Why even let users change the pivot target output if AgX uses if for automatic exposure control?
What should they use instead? At first glance, the brightness slider in the look section seems to do a similar job but when I compared it side by side to pivot target output the latter produced better results.
The UI is inconsistent. The pivot input shift slider only shifts the pivot input. The color picker next to it shifts the pivot input but also resets the exposure to the mid-grey level. I actually don’t mind both of them maintaining the exposure, as long as it is the last user-set exposure, not just the mid-grey level.
I’ve received your image and XMP, and responded to you, even though it was 11 PM my time:
Thanks, I’ll look into it. The intension of the picker is actually to re-calculate pivot y based on the default mid-grey to mid-grey mapping (I have tried using the ‘current’ one, but that changes all the time as you drag the rectangle, and that quickly drives the image into unpredictable states).
But I’ll check if there’s a problem with the maths. Seems to react strange to dark areas.
Regarding the controls, I’ll try to see if it’s possible to use e.g. click and Shift-click to tell whether to adjust only x or x and y.
Tomorrow, or later.
I’m sorry I previously described the pivot y calculation incorrectly here and in the docs. I’ll update the latter.
Pivot y is not intended for general exposure control. We have exposure for that. It’s OK for adjustments, but has its own limitations.
It’s not for ‘automatic exposure control’.
Here is the original curve (yellow) with two others laid over it, once picking a high pivot, once a low pivot. You can see that, in both cases, the newly picked pivot (x, y) lies on the original curve:
This means that the brightness of the chosen pivot does not change, given that you start from the original 18% → 18% mapping.
When I developed this, I tried taking the ‘current’ pivot into account, instead of using the 18% default. However, as you drag the selection rectangle, the ‘current’ pivot x, y values are immediately updated (I don’t know if there are events to indicate ‘picker activated’ and ‘picker committed’), which meant there was no fixed point of reference, and brightness changed in unpredictable ways. I’ll try to check if such callbacks are available.
The intention of the picker is to move the point of highest contrast without changing its brightness, and it uses the base pivot to determine that brightness.
Exposure, or brightness. Or continue to use pivot y, just understand the limitations of the picker.
See above regarding the callback. Or, better yet, submit a PR…
If you think I’m offended, then you are correct. I don’t like the tone of your feedback (“Why even let users change the pivot target output if AgX uses if for automatic exposure control?” – the only thing missing from that is “That’s just stupid” – it’s not written, but implied by the “why even”). I also don’t like it that here you mention in public that you sent me the files in private, but not that I immediately got back to you, saying I’d have a look.
the module cannot tell if Shift or other modifiers were pressed when the picker was activated
the module is not aware of a picker being activated or deactivated (there’s no ‘start’ and no ‘commit’). It is informed by a callback that a colour was picked, but that callback is invoked whenever the selection changes (many times as you drag the selection rectangle).
So, right now, we’ll have to stick with using the default mid-grey → mid-grey mapping for the calculations. If someone has information about a solution, I can implement it.
The colour picker could be modified to pass the Shift etc. to the module. I can raise that on GitHub. It may come later, or may not come at all. The overall feature freeze of the next release is approaching fast.
As a simple compromise, I can add a separate picker to the pivot y slider:
the pivot x shift picker would only modify pivot x shift
the pivot y picker would modify both (taking over the behaviour of the current picker).
Sincere apologies for the tone, especially the “why even” part. I wanted to be honest about my experience and focus on technical aspects but at least in that sentence I went too far. The last thing I wanted was to sound offensive to you. I didn’t mean to imply you are nor responding quickly enough either - everyone can see you are consistently very responsive. This includes a quick answer to my private message with the test image.
As for the pivot target output slider - it is the best tool for exposure control I found so far. I’ve tested the brightness slider and now also exposure. pivot target output still produces best results overall and I expect many users will like this feature too.
I was not aware of the technical limitations. I understand the currently the callback can only do 18% → 18% mapping or not and there is no fine-grain control over it.
Would 18% → last average output brightness mapping (updated by manually moving pivot target output and defaulting to 18%) work?
The difference was subtle - at first I thought the results were the same but when I compared two pictures side be side I was unable to replicate the pivot target output with exposure. Subjectively I liked the former more. I think (correct me if I am wrong), adjusting exposure is equivalent to moving pivot input shift.
After playing with the picker at 18% brightness I started to like this feature too - it allows me to put contrast/focus on a specific subject without changing the brightness. Ideally this feature would still be available after the user has manually changed the output brightness away from the 18% level.
As I wrote above: we get callbacks all the time the user moves the picker. There is no way to remember settings ‘before the picker’, as the code does not know when ‘picking starts’ or ‘picking ends’ (there is no state; there is only a notification: ‘the currently selected region has this min/max/average value’). Therefore, I cannot store away the current brightness of an area to use as a reference for calculating the updated brightness. That is why the reference is set at the default 18% pivot.
The ‘y’ picker does the same as what the x picker previously did (this adjusts the pivot x and y; there is no point in changing the output brightness of the pivot from a random area, I think, without moving the pivot there).
The one on the x slider does not adjust output anymore. So, to get the previous behaviour, use the picker of the y slider.
I’ve taken the plunge into “master” and am delighted with agx for my editing! One question though: With the default “blender like” preset “master purity boost” is at 0. This leads to the three purity-boost sliders having nil effect when moved. Is this intended? I remember that Master @kofa wrote about the purity boost sliders a while ago but couldn’t find the posts.
I think the rotations are corrected in all presets…I will have to check but if I recall last time I looked all rotations pre were matched by the same post…
EDIT
Ah my error I see in one case the master is 0 and the other 100…I had never even noticed that I though the slider set at 1 in both cases and the differences was on the rotations in the presets sorry…
Thanks for digging this one up. At the time you posted it I couldn’t grasp yet what this meant. With some practice with Agx I now understand your thinking. As a new agx user I found the experience of moving the revese-rotation slider back and forth and nothing happening confusing.
But I guess there is no perfect solution for this if you would like to provide an easy global mode to incrementally unrotate all the rotations.
On the topic of primaries: Would it be possible to display the name of selected primaries-preset on the drop-down menu for the primaries-presets?
Unfortunately, no. What you see there is not retrieved from the list of presets (we used to have that, but it was a very ugly solution, and was rejected by the other developers). What you see is the settings used to initialise those presets. For example, scene-referred default, blender-like|base and blender-like|punchy all use the same primaries, derived from Blender, thus the primaries setting is blender-like, but it’s not derived from the list of module presets: the modules presets are derived from that single, shared configuration of primaries.
I’ve been playing with the source code of the AgX module, mainly to learn about the 18%->18% mapping we discussed earlier. I can see what @kofa meant, it is indeed difficult to make the plugin memorize the current brightness level. Or rather, it looks deceptively easy but the straightforward solutions don’t work. For example, just using the current brightness value:
fails when selecting bright or dark parts of the picture - estimation of the output brightness level becomes then very inaccurate. I’ll try to experiment with other ideas.
But I noticed something else - the target_pivot_x → shift conversion is non-linear (piece-wice linear). That is, shift=-1 and shift=1 are at different distances from the mid-gray exposure.
Does it matter at all? In most cases probably not - I’ve only noticed that when reading the code. But maybe it does when white/black relative exposure settings are very imbalanced?
As far as I understand, it originates from the desire of having the pivot input shift slider with a 0 in the middle and with a [-1:1] range. But is it really required? If either the range or the mid-gray point could be moved we could have a linear conversion between the pivot shift and pivot exposure.
If range [-1:1] is necessary and the mid-point shift has to be at 0, perhaps AgX could use a smooth (quadratic) curve instead of a PWL? For example, this equation smoothly interpolates between coordinates [-1, 0], [0, base_pivot_x], [1, 1]:
