> My suggestion on the user interface side would be : > * in the "keep one-shot auto result" case, uncheck the "auto" checkbox. > * in the "re-apply auto" case, keep the "auto" checkbox checked > (This refers to the auto-exposure UI.)
Re-reading this message, I see possibility of reading it wrong, like "when/where to keep checkbox checked ?". To make it very clear, here's a step-by-step concrete example, in the auto-exposure case: * You have a series of pictures and want a quick first-pass rendering (possibly before refining). * Open a picture from the series. * Enable auto exposure by checking the checkbox. * Depending on your intent, keep the box checked or not: ** Use case 1: the pictures have been consistently underexposed (to avoid digital clipping in highlights, while only a few pictures actually had a high contrast scene that would need it). You apply "auto" on the selected one, this gives a satisfying result (like +2.3EV) and you want to apply it unchanged to other pictures in the batch. ** Use case 2: the pictures have wildly different exposures (e.g. they were shot with approximate exposure, under changing sky conditions). Uniform EV change would be no good, but batch-applying auto on all of them will be definitely an improvement. * Depending on your intent/use case, keep the box checked or not. * Go back to lighttable, keeping that photo selected. * Copy the development settings or create a style (both scenario would ideally support that). * The copied development settings or style would keep the intent (that you showed by keeping the auto checkbox checked or not in the first picture). * Pasting parameters to other pictures or applying the style will, depending on your showed intent, either : ** Use case 1: apply the recorded parameters to destination image and keep the box *unchecked* there. ** Use case 2: apply the "auto" algorithm on destination image and make the box *checked* there. So far darktable does what you want in use case 1, whether or not the checkbox is kept checked in first photo. The new behavior would satisfy use case 2. Are the use cases clear ? Thank you for your attention. ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ Darktable-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/darktable-users
