Darktable Book for beginners

Software darktable
22

There is darktable user manual - process

23

The process doesn’t cover importing, organizing, etc. It is good for what it does, but the whole process is importing, organizing, correcting, editing, saving, making available, and backup.

Dave,

24

Ok, but that is very general.

25

But not all that has to be done with darktable. Keep in mind that darktable is originally developed for Linux; the philosophy there is to have a tool that does one thing well (and not tools that do a multitude of things more or less well). And darktable is (or started as…) an editor for raw files.

As for the link @paperdigits posted: that link jumps into a section of the manual. It might be useful to look at the other parts of that chapter as well, perhaps?

26

It gets you a decent, neutral edit though, doesn’t it?

1 Like
27

The sections around it do: darktable user manual - an introduction to darktable's workflow

28

Tools are always a matter of debate. Some like code editors+debuggers+etc. Others like IDE’s. A good IDE is a good thing, else, individual tools are better. From a learning curve perspective, IDE’s can be easier.

Right now, I’m looking for a jack of all trades, but may be an ace of only one. Latter, I will consider (for example) a dedicated downloader, dedicated organizer, etc. For now, too much.

But maybe I should ask, is DT a jack of all trades, or am I on a fools errand?

Dave

29

dt will do all of this except backup. Also not sure what “making available” means.

30

One thing to note or maybe to say for contest is that there is a new release of DT twice a year. If you go to the github site or the blog posts on the DT website and read the release notes you might get a sense of how things change and in some cases radically such that I think trying to make a book that is both accurate and up to date is a bit of a challenge even if it was an assigned or assumed role in the group…as noted above even keeping up on notes about the new features and additions can be a challenge. So the notion of a book is likely not a reality but there are a couple of youtubers that have done a series of video’s that are module and workflow walk throughs… Bruce Williams and Hal on the Darktable from A-Z channel produce some video’s that are what you might see if you went chapter to chapter in a “book”

31

I meat exporting to social media, or printing, etc. Sorry for the poor wording.

Glad DT can do what I need.

Dave

32

One particular issue is the speed of development of darktable (not issue as in something negative, just not really made for books). There are at least two books by german publishers:

(partially already mentioned before – both by the same author btw.).

As you can see, they are both already outdated, due to the insane :heart: speed of development. Why would I buy a book that covers an old version, if I already know that one of the next versions might bring the AgX tonemapper or insert feature here.

I would buy it for one of three reasons:

  1. I can support the community with it: Even before university started, i was heavily in love with TeX/LaTeX and the entire ecosystem. I bought books of tutorials i had already printed and read several times from start to finish, such as the KOMAScript book by Markus Kohm. I even bought the third edition afterwards in addition. It served me well, but so would have done my home-printed version of the book. But buying it had mutual benefit, as the author of the book and the author of the software were the same person, and the book felt much better in my hands than the printout.
  2. I get information that serves me well for a long time. In a book i would love to read the information that is timeless in its nature. Information that does not change with every release. A book that i will consult in 5 or 10 years because it still has the information i am after.
  3. I get a quick-start into a topic that is new for me.

Unfortunately, i did not see a book that fulfills 1. because i did not see one of the authors showing up e.g. here or on github, but this might be a wrong observation on my side. And i also have the impression, that these books out there would not fulfill 2. very well (i might be wrong here as well). The topic’s nature of image processing does not match well to this kind of books, unless they really cover the maths and algorithms in detail. So the only thing that is left is 3., which was more or less what the OP asked for. For me it’s too late as I am a darktable user for more than 10 years. I can imagine that writing a good tutorial book for beginners is a lot of effort and not easy. It would, however, be interesting to understand which topics are not covered by e.g. the excellent tutorials of @s7habo and others and which glue is missing.

Edit: I missed a third book: https://bildnerverlag.com/produkt/darktable-workflow-fuer-die-perfekte-raw-konvertierung/#. This one is the “practical book for the recent version.” It’s from 2022, so … hm …

33

If we think about :

A. The rate of change of fundamental aspects of dt (like DR → SR) possibly in the nest years won’t be as fast.

B. All the instructive explanations and instructions given in the forum here by a group of people who seem to be OK with not spending all time editing own pictures, but also guide others into dt.

C. Something that is not necessarily “all things darktable” but more an introduction to the basics – approaching dt from a task perspective, (rather than the tools perspective the manual has and shall have) – linking up to forum posts, the manual, selected videos, so as to provide a structure and progress for learning from easy to more advanced. EDIT: Just published as a pdf on darktable.org.

D. Keeping any editorial work outside of github and markdown that for a number of forum members represent a barrier to participation.

– couldn’t then the conclusion possibly be that we could likely manage to establish the Darktable Documentation Team to realize pt. C (and possibly also support @elstoc in work with manual)?

Some other FOSS projects has something like it

34

The first is not that helpful - it’s just transferring lightroom or other image editing software habits to outdated display referred modules in darktable.
The second is quite better since it shows an understanding of the scene referred workflow. Main difference to the manual is the workflow oriented structure - it gives more information on using the gui and groups module descriptions according to a editing workflow.

And the third mentioned book is caught in the legacy display referred way and doesn’t give more darktable relevant information regarding the processing module you can’t get from the official manual.

but to be honest: better spend some time with the videos of Boris https://www.youtube.com/watch?v=vnkphET6pYk&list=PLmZmCIhOC2Frt6Wq3gc0-egOy_P1sXjau
His way of teaching by reasoning about the intended results and derive the proper corrections gives a good overview on “how to do it using darktable”
then maybe read about the used modules in the manual …

1 Like
35

I’ve discussed this in a number of places. In summary: it’s hard enough just keeping the “what darktable does” documentation up to date, without adding to that a big chunk of “how to do things with darktable”. Outside of the introductory sections, we have no interest in the continued maintenance of a “task based” user manual, though there are many other forums in which you could write such a thing, and many people here who’d be happy to read it/comment on it. For example, see a recent post on the darktable blog.

There is no darktable documentation team (and judging by github contributions there isn’t likely to be one). There’s me, @paperdigits and some other occasional contributors. I’m the most frequent contributor and I still don’t really contribute that often.

Edit: Re-reading your post maybe you’re thinking of establishing some new documentation, with a new team, separate from the authors of the manual. That would be fine, but I think step 1 is to get the manual up-to-date.

36

That’s not a bad idea, but it would still have to be managed by someone, or we would likely end up with something like the Emacs wiki (which is a mess).

Git is no doubt a hindrance, but markdown can be learned (and there are editors) and arguably makes the editorial process easier since there won’t be any “cleverly” formatted Word docs or other nonsense to deal with.

1 Like
37

Exactly.
And I do see the need to get necessary resources allocated for maintaining the manual.

But I also do think that the manual necessarily will have higher requirements regarding technical competence (accessing and understanding the coding) for participation, and more strict/stringent way of editing and editorial system, than what some other kind of documentation will need.

So I tend to think that there is potential for tapping into resources that can work on something besides the manual, without it detracting from work with the manual.

38

Not completely true. :wink: At least one author is here (me). Unfortunately due to various time constraints I am not able to participate as much as I can.

And btw, DT is my main tool and actually only tool for „normal“ raw development (for Astro I love Siril). I tried to show workflows in my second book to help people using DT. Well, as can be seen from another thread it might not be so easy.

But it is true, the development is really fast and it is difficult to keep up with that pace in a traditional publishing world.

Yet, I am more a textual person, so I decided to go for a book. But I also love all the great videos of Boris, Bruce, etc. such great work. Thanks to all je them.

Inspired by the other lengthy thread, I was thinking whether it would be worthwhile to set up a „DT cookbook“ with some workflow suggestions compiled (from importing to exporting). Some kind of companion to the manual.

2 Likes
39

I will be in for both. As of April I will have time for this.

1 Like
40

No, not really. We ask that you can (1) make a pull request against the dtdocs repo on github and generally understand that workflow (as your PR will likely be interactive with Chris or myself and (2) that your written English is passable (or I guess write in your native language and translate it).

Really, the bar isn’t that high. The hard part is not the wiritng, but the time it takes to read the existing part of the doc, discern what’s new/changed.

I think Chris/me would be really stoked to be copy editors and release managers for the docs.

To be bluntly honest, we have seen these initives a bunch of times, they don’t take off. We have had many people tell us they’re going to rewrite and restructure the whole manual because they don’t like it. That doesn’t happen either. The workflow stuff ages quickly and is a pain to keep up with.

I obviously agree with Chris, getting the manual up to date and then keeping it up to date should be priority #1.

We have asked for help (a bunch of times) and outlined a very achievible process, and yet the manual is still behind.

Now is the best time to get involved.

2 Likes
41

(whoops, realized how old the original post was just now)

It’s not a book, but I have written a series of text-based tutorials (so like an online “book” of sorts) starting with this introduction on editing with darktable:

2 Likes