Hmm, how many languages are descended from Algol?
(I donāt know what those arrows really are meant to symbolize.
As e.g. Simula introduced the fundamental concept of Object Oriented Programming (with a basic notation that also is adapted by several other programs), there likely could have been more arrows there. But it doesnāt detract from your main point. E.g. Simula was simply Algol with OOP on top. )
Itās most likely true that this conversation should not be in a thread titled āImprovement Suggestions.ā Iām not the only one who expressed the sentiment below. Perhaps just seeking solace in the company of others who shared a common experience.
Now Iām going to go into that thread about the new UI and ask the OP when the presets are coming that will make my RAW files look just like my OOC jpegs. ![]()
Just for grins and good humor and to honor the OP, I will mention one specific thing that was really annoying for a while, with a simple solution that at least one new guy is not going to recognize quickly, even with the manual, even though itās in there. I think itās specifically mentioned once in a video, but things get overlooked in many hours. Contrast in the highlights and contrast in the shadows in the Filmic options tab default to āhard,ā which makes the module nearly inflexible. This took a while to realize, because most of the demonstrations of this module do not involve the options tab.
5.0 already has styles that mimic ooc jpegs for each camera.
Thatās actually laugh out loud kind of funny. My camera jpegs are cool-toned monochrome with the contrast turned all the way up and an orange filter. There probably isnāt one like that. Itās no matter; itās only for the EVF.
that might happen if Canon, Nikon, Sony publishes their in camera image processing algorithms with a free use license
I was not serious. Hence the suggestion to mention it in the UI thread.
Old brain, I actually meant APL.
So just to be clear, nobody is going to mention anything specific that we could actually do to improve things and weāre just going to roll with unactionable generalizations?
Iāll try to be helpfulā¦. ![]()
One thing that might help new users is a video that lays out from import to export, a basic Darktable workflow. It could be done in two or three episodes that explain how to import, navigate and rate/tag in the Lightable and then move on to a minimal edit that covers exposure, tone mapping, local contrast, etc, and completing with export options
After that itās up to the user to learn from the extensive tutorials made by Bruce Williams, Boris and many others
If done generally enough then it wouldnāt get stale for quite a while. It might very well exist out there already, or be found in pieces, but itās hard to find in the volume of work thatās been done. So put it in a brief article in PIXLS with a link - and maybe some of the images used in the videos so people can play along - and then itās readily available for anyone.
That might help people get a grasp on the workflow so they can learn on their own without recycling the same issues.
Just a thought
So more or less a video of this: darktable user manual - an introduction to darktable's workflow ?
Yeah, lay out those same steps in a video, link the same images used in the demonstration and then pin or bookmark them some way so theyāre easy to find.
I donāt want to volunteer anyone, but this seems like itās something that @Bruce_Williams or @s7habo could easily produce
I agree, I generally hate āour unique patented special sauce thatās totally not the same as what everyone else is doingā attempt to differentiate. āDeepPrimeā means absolutely nothing, and then people come over to Darktable and complain about the word āSigmoidā. All I needed was to know that itās a tone mapper and I was happy.
However, with the recent AgX tone mapper experiment, which adds a Sigmoid section, I must admit that use of the word Sigmoid has become a bit confusing, so a rename of the Sigmoid module might make sense at some point.
Hasnāt Bruce already done this? Iām fairly sure he has a recent series of videos for beginners showing the overall workflow.
Perhaps ā{Filmic|Sigmoid|Base|AgX} Tonemapperā would be more descriptive names. Possibly with a de-emphasized āTonemapperā.
I think making the purpose of the module clear in the name makes sense, yes, so adding ātone mapperā for those modules.
Maybe the moduleās function can be incorporated into the names of all modules, e.g. āx denoiseā, āx sharpeningā. But it could get cumbersome, and some modules have multiple functionsā¦
He might have done that, but the problem is that heās produced such an impressive number of videos that I have trouble locating one or a series that lays out the entire end to end process.
But Iām no suggesting to reinvent the wheel. If that exists then it could be pinned or book marked so itās easy to relocate
Iām going to be blunt and honest here, and I promise my intention is not to piss anyone off or create any issues. And it certainly isnāt meant to diminish the efforts of anyone involved in documentation, tutorials, or anything else. Iāve brought up two specific pieces of documentation that I thought could be improved and was met with what I felt was, essentially, āwe canāt / wonāt do thatā.
My first observation was that the diffuse and sharpen documentation starts off overly technical, with a long description of technical matters about what diffusion is, the physics of light diffusion, allusions to mathematical things like the Orton effect. I suggested specific ways this moduleās documentation could be structured, as well as the suggestion that a similar template could be followed for all modules and other documentation pages as appropriate. The response was essentially āwe try to be consistent but sometimes we arenāt.ā
I shared above my thoughts on the sigmoid module documentation and things I specifically think are unclear, or could be helpful. Part of this included provided some more technical information, at the very least pointing out that the module is named after a specific thing. The response is āthose things arenāt useful.ā
What Iāve gathered following this thread is that there are rules and design decisions for the documentation, and that is a good thing. But I can also look through the documentation and find all sorts of ways that these rules and design decisions arenāt followed. The two documentation pages Iāve provided feedback on contradict each other in terms of these rules, and I donāt know where the lines are drawn so all I can do is offer suggestions on what could help me.
This thread is full of people sharing points of friction that theyāve experienced, and the responses feel generally dismissive. I doubt that is the intention, but itās how I have interpreted these interactions. It is often easy for people to point out things that frustrate them, but that doesnāt mean they know how to fix them. It is an opportunity for a collaborative conversation with the goal of finding some solution.
Again, my intention is not point fingers or create drama. I think we all recognize that managing documentation and knowledge for a program this complex is a massive undertaking. The efforts are greatly appreciated, itās just become somewhat frustrating trying to commiserate about shared frustrations.
I just had a quick look and Episode 140 is āA noobies guide to processing RAWs in Darktableā. I havenāt watched it actually, but it might fit the bill.