Thanks Dave and Todd for getting these out so quickly! Didn’t even have time to play with the previous one, now there’s a new one.
I have 2 versions of darktable installed (the AgX version in a different directory with a different library).
Ie stable install in /ProgramFiles/darktable
AgX install in c:/darktabletest
When I open the .exe, it asks if I want to uninstall the old version of darktable, and I click no. This seems to work, but am I leaving old files / versions in place by clicking no? What does everyone else click?
Ah thanks, yeah I remember seeing that and have had it running separately successfully.
I wasn’t clear in my question - when I open the .exe nightly build from Todd / Dave to install the new AgX version, a dialog pops up asking if I want to uninstall the old version.
I click no, then point it to c:\darktabletest and all seems to work fine. My question is if others are clicking yes or no.
Edit: I also, from someone’s suggestion at some point, made a batch file with a shortcut icon so I can just double click:
@echo off
REM Change to the Program Files directory if necessary
REM cd /d "%ProgramFiles%"
REM Navigate to the darktable installation directory
cd C:\darktableTest
REM Run darktable with the specified configuration directory
start "" "darktable.exe" --configdir "%APPDATA%\darktableTest"
I have the AgX proof of concept as a separate install with its own name and folder under Program Files and App Data/Local. When I install a new version I will rename the folder under Program Files and my new installation will install the newer program in its place. I leave the folder in App Data/Local alone.
I set up a shortcut with the following properties so my DT AgX version works properly:
Definitely click “no” for dev builds.
I use the same process as outlined by @raublekick and @Dave22152, keeping the dev build and its preferences totally separate.
With each new build from @kofa, I tend to just overwrite the previous dev build, but I still click “no” when it asks whether to overwrite, because that will overwrite my stable build.
Maybe turn off xmp writing just to be safe. I also pointed my cache files to a new directory just to make it easy to clean it all out when I am done…I actually run my main version this way, ie using custom config folders one for the config and one for the cache. I have them that way as I find them easy to locate and specify to back up and if I ever messed up the standard locations during an install the files they are never touched or corrupted by the install…I just run DT pointing to those folders… As for yes no I believe you choose no…as if you say yes then it will uninstall the version that exists in the default install location ie your main DT install and you don’t want that…
Would that be enough to demonstrate the compression/scaling effect of gamma?
So, for vertical (input EV), there should only be 0 EV, and for horizontal (linear light output), a low value like 0.01, 0.18 and 1? Would that really be enough to avoid the same confusion about moving linear Y and curve gamma?
I can do that when I create the next build, and we’ll see; but then you here already understand the difference – would people who don’t read through this whole thread understand with so little guidance?
in my opinion the result is what’s count. The curve might give an indication while learning, how the sliders affects the result. Unless the graph also contains a histogram, no one is able to match the different sections of the curve to the corresponding areas in the image. But age is primarily an tonemapper, not the one tool to rule it all…
I’m considering a checkbox above or below the graph with its value saved in the config: show grid. It would be enabled by default, and once people are comfortable with the sliders, they can uncheck it.
Though “one tool to rule them all” seems to be what some want (see discussions about tone equaliser, sigmoidn, …); or at least some try to use a tool beyond its design limits, and then ask for the tool to be adapted.
So one question is: do you want specialised tools that give you the best possible results within their domain, or fewer more generic tools which give good, but not optimal results?
My take is having one tool that will suffice for 90 percent of the work with other specialized tools for the final finesse. In this Agx seems to be a good fit, which would be supported by tools like exposure, TE, CB-RGB D&S, with extreme finesse with Colorizer etc.
I wonder, what is the ideal placement of the various tonal controls in the pixelpipe? Exposure must come first, to set the middle grey baseline. Tone EQ must come close thereafter, to push/pull otherwise runaway highlights or shadows back into the tonal gamut. Tone mapping clearly is the last step before the display transform, pulling the remaining blacks and whites into the final 0-1 range.
But where should the look and contrast sit? Right at the end, in AgX? Earlier, in color balance or tone curve? What are the tradeoffs between these positions? Does e.g. color EQ benefit from coming before or after the tone curve? What about LUTs or color lookups?
No chart: saves space, but people will be asking questions about toe and shoulder, and telling them to look at debug output and plot it via desmos or a spreadsheet is counter-productive.
Chart, no grid: takes space, people will ask questions about curve gamma and linear Y.
Chart, with grid: too crowded.
Chart, with a grid that can be disabled via a checkbox: takes to much space.
Chart, with a grid that can be disabled by editing darktablerc: not user-friendly at all.
Remove all sliders, controls and visualisation, providing an opinionated maker: people will say they want more flexibility.
Split the module into its elements:
log mapping with controls for exposure; could be used with any curve or LUT, independently of the AgX curve
AgX-style (sigmoidal) mapping curve with curve and matrix controls (still to be added)
look controls (could be used with any tone mapper).
But then you’d have more modules, more module headers taking up space, and potential jumping back and forth between modules.
chart with grid as a collapsible section - after being comfortable with the sliders that can be kept collapsed and just unfolded on demand…
look section as collapsible section - more experienced users will favour having more control so
curvecontrols as standard view (as proposed in the last gui)
collapsible advanced controls
since the latest state of collapsible items is conserved, that might be a minimum denominator for a gui - there won’t be a one size fits it all approach
the darktable guiding principle is: if specialized modules gives better results, then go for specialized modules.
darktable focus on quality not mass market conformity …
