I might be in the minority here, but I think updating a traditional manual is not the best approach. Manuals are static, difficult to update, do not encourage collective ideas and thoughts. I’d love to see a darktable based discussion board - not too different from this one - but with set topics (menu down side) where each one would include both a pinned opening description and instruction, then opportunity for users to add, recommend, advise as needed. Topics could be: Theory (moving from Lab to linear RGB); Basic workflow; one for each major workspace (i.e. Lighttable; darkroom etc. - these would be more general); then each module have their own topic - pinned to top is what the module does and what each adjustment does, basics of when to use it. Discussion under that allows contributors to share ideas about the module.
This is both best and worst idea.
Manuals sure are static and are supposed to be that way IMO. And should contain enough info to get you going. Quite frankly the best manuals I’ve seen are either Canon cameras ones divided into 2 sections+ sections (basic, in-depth, rarelly-used stuff) and there’s plethora of other options available.
If I’ve seen any “manual” being something like a discussion board I’d be VERY skeptical.
What you’re proposing although isn’t a discussion board but rather weird multi-page manual with comments 
What would work best - I don’t know, but I do know that properly organized manual is always positive thing. And that manual having additional references, in-depth stuff etc - that’s even better.
Another thing are “wikis” but that’s another hornet’s nest and I don’t think I’ve ever seen a manual done well in form of wiki (RawTherapee’s rawpedia included)
A manual that’s easier to edit is the way to go - I think @paperdigits has the right idea. Happy to help with the move to markdown if I can and I’ll be much more likely to contribute changes after it’s done. In the meantime I’m trawling the forums/youtube and building my own local wiki with tips/tricks.
There are some good nuggets in this thread regarding documentation for dt 3.
One of my roles in the working world for many years has been software support. That experience has taught me that you can never get every user to approach a software product the same way. You can have the perfect manual with a sublimely written Getting Started section, and some people will still just install the product and blindly bash away at it. And then of course come running to the help desk, forum, or whatever support medium is provided, with questions that were already easily answered by Getting Started.
An additional thing to remember is that many people will download apps and give them a quick try to see how they feel, with minimal investment of time and effort; in that scenario, there’s a good chance that none of the resources (manual, videos, etc.) will have been consulted.
IMHO this is the best approach. A link and a friendly suggestion to RTFM is an appropriate way to answer a question if the FM provides a suitable and understandable answer.
At a minimum, it must be an accurate reference. That needs to exist before anything else is added.
Agreed. Task-oriented guides, and tool-oriented reference.
There sure aren’t many!
Agreed. Markdown is simple enough that non-technical contributors should have no trouble. I think this is an excellent way to broaden the base of contributors.
@obe Some information has been updated…I posted it on the FB page files section it is now likely from a few weeks ago but certainly the new filmic was in there as was a discussion of the linear workflow…couple that with the last couple of documents put out by Aurelien and a lot of the new stuff is explained…
@priort I assume that FB means facebook. I’m not a frequent user of FB. After having keyed “darktable” in the search field of FB what do I do next to get access to the documentation you mention?
I think that video is a wonderful tool to get a general understanding of how darktable or a specific dt-tool works and the internet is a fast way of communicating and releasing the latest information. However, if I want to look up a specific option in a dt-tool I need a structured way of accessing this information: the reference manual.
I’m simply not going to search for and watch videos lasting may be more than 30 minutes just to learn that the option in question is not covered in the video…
I think @priort meant FB group “Darktable (unofficial)” where the docs for 3.0 were shared. If you’re not a big fan of FB (not that anybody should be - it’s a horrible platform tbh) you could try instead https://github.com/jade-nl/dt.miscellaneous/tree/master/Usermanuals - this should be of some help 
You can have info in any way and form imaginable and there still are going to be users that refuse to read 
I know - I worked with those. Worst people are the ones that “learn” from the simplest recipe and apply it everywhere, even more than a gospell or whatever religious stuff and if anything is not up to recipe then it’s the code fault and not the recipe 
I think initial DT screen is rather nice in this regard as it points to general places of interest. It isn’t the most welcoming but I remember my first interaction with it was positive enough that I stayed. Maybe “first runs” mode would be good for people that don’t skip tutorial levels in games? 
@johnny-bit Thanks Hubert indeed that is where I was referring too…thanks for clarification to @obe
Hi’ @johnny-bit and @priort thanks a lot.
I have applied for membership of the facebook group and downloaded the draft version of the 3.0 manual. It’s impressive that the manual is available in so many different languages. I always use dt in the English version which makes it simple to communicate screen shots etc.
The draft manual contains a fine description on how to use filmic rgb 
! Some tools are still missing but apparently in progress…….!
Actually in the tone eq video Aurélien presents a really simple flow that minimizes use of all the sliders and gives good results…
So it’s a long video but near the end where he runs through some examples he basically does this…
Take you image in to DT and with exposure with no regard to the histogram add or remove exposure to achieve a good look for your midtones. Now activate filmic with defaults and set middle gray to 18.45…now just adjust
black and white to bring the histogram in line. This is pretty quick use of filmic. You can move and tweak latitude and contrast or dynamic range if you need to but generally you likely won’t . Then he opens the tone equalizer to defaults and applies the opposite
EV that was added by exposure module at the start. Then maybe small change to contrast compensation and then make your tone edits finally if the tone edits move the histogram too much he goes back to filmic to tweak the black and white points again……so it’s
a pretty quick formula and he repeats it I have tried it and it works pretty well…in addition as mentioned earlier he will often add local contrast and or contrast and saturation via the color balance module. I have had pretty good success with this approach….before
I would try to go through all the settings in filmic to get the best curve and it would take some considerable time esp when modifying the gray level in there ……AP seems to use exposure to set middle gray and then uses 18.45 in filimic as a general rule……check
it out in the video it will likely be more clear that what I can explain…
Let me get down from the docs discussion (which is very important, though) to the original topic. Last weekend I walked through my old photos practicing in redoing the development using the “new” RGB approach. In spite that mostly I feel this approach brings better results, especially color-wise and less artifacts of any kind I notices one unpleasant flaw, which I can see in the Result section of @anon41087856’s first post in this thread as well.
The issue is the sky color. My development using linear RGB modules makes sky lighter and with subtle green tint (compare the sky on OOC JPEG vs dt 3.0 in the original post. That’s what I’m talking about). This color shift is pronounced the most on highland shots. When I tried to edit shots made in Tibet, where sky is dark and has slight magenta tint, I got it greenish andmuch lighter , so I had to apply Color Zones to every shot to darken the sky and shift the color to restore the original tone. On the contrary the Base Curve-based LAB approach makes sky darker than needed and shifted the color in the opposite direction, so neither of them gives right sky tone without a special correction.
Or maybe the color shift is in the OOC JPEG and you got used to it ?
Be careful with shifts, they are only defined by comparison with a reference. Mixing in metamerism errors of sensors loosely respecting Luther-Ives conditions + sub-optimal 3×3 input color profiles (assuming sensor are linear when they are not really), it’s impossible to characterize a shift without a spectral ground-truth.
All you can do is enabling/disabling filmic and see if the colour looks the same at a different exposure. But comparing OOC rendering to software output makes no sense.
Also, remember input colour profiles are approximations optimized to give better colour rendition for (caucasian…) skin tones. Blue is at the other end of the chroma wheel.
So to get “good” sky colour… One would have to do different correction or what? And TBH in your (@anon41087856) example according to my wife (waaay better photographer) OOC JPEG is “worse” than edit, mainly because colour is actually better and more “real” + there’s no halo effect near mountains + the sky and sea in righthand side do not fade to gray.
Wow. That sentence takes some unpacking.
What I did so far when the sky stats to look not the way as I want it:
look → preserve chrominance → luminance Y
Which I would describe as: It “darkens” the blues. It gives better colors in pictures with a dominant blue sky.
But darkening is not a colour shift.
Sure. Just saw the same difference on images you provided.
Okay. Will do this and let you know. But the results look really unnatural without correction. I may post it here for evaluation. Also I may provide a RAW to play with. Altitudes were up to 5000m, so the sky in reality is very dark and has violet/magenta shift. And I expect to see it after development.
…is always a challenge because the color of sky is always different. I saw sky to be yellow, orange, green… I’d agree with @anon41087856 that it’s a matter of taste and natural look instead of “right” color representation. However, there are always cases that we may say for sure that color is wrong. I’m talking about such a case.
Well I’m gonna play with this, too.
Regarding the non-Luther-Ives property of sensors, this might interest you: Perceptual Color Characterization of Cameras - PMC
Especially this graph:
Left is the spectral sensitivity of the CIE 2° observer, right is the spectral sensitivity of the typical camera. That huge overlapping of sensitivity means your “green” camera channel is pretty much a full-spectrum/panchromatic channel instead. Hoping you can match this RGB to XYZ by only a 3×3 matrice is delusional, you clearly see that it’s not a linearly independent (orthogonal) vector base, so your dot product means bogus. Ain’t no linear algebra in non-orthogonal vector bases, unless you extract eigenvector and make them orthogonal.
Solving this pack of knots properly will need @hanatos magic (https://jo.dreggn.org/home/2019_moment_spectra.pdf) with a database of spectral sensors calibration (What is the Space of Spectral Sensitivity Functions for Digital Color Cameras).
Please let us keep all things dt away from the commercial sites such as FB.