The people who write the code, ultimately, and our maintainer, Pascal.
Filmic in darktable is exactly the same as it is in Ansel.
No, sorry. Filmic is still the default. Sigmoid is an additional option that people seem to enjoy.
Again, its exactly the same as it is in Ansel. Nothing has changed.
No idea what this means. But this has been discussed to death, and there isn’t really much else to say about it.
I wasn’t encouraged with my initial results from sigmoid, but it is most definitely me not using it properly. Boris Hajdukovic makes good comparison on YT, I just need to spend more time with sigmoid to make my own determination.
Good point on the code Terry, I haven’t thought of that.
I also could not get great results with my .ORF files on Sigmoid and am sticking with filmic. Looking at the Ansel software it does look very easy and simple, but it is only for Windows and Linux and darktable runs so fast on my Mac. CaptureOne has been changing its subscription model and I am happy to have a FOSS alternative that can index tens of thousands of photos quickly without massive RAM and DISK overhead.
Capture One on my 15" MacBook Pro takes a minute and half to start with a catalogue of 65K images. Splitting catalogue into more manageable lots is not a solution that would work for me, for various reasons. Darktable starts in under 10 seconds. Once up and running, C1 is faster than Darktable on my system (real time response to any slider etc), so your comment on DT performance on Apple silicon is very encouraging.
I’m running it on a Mac Studio M2 Max and darktable flies. No lag whatsoever. C1 takes a while to start and it sucks RAM when you do things like AI masking or work with panoramas. The panorama function is old and slow and bogs down with more than 5 frames to stitch. And the catalog feature is cumbersome and duplicative. It makes a copy of your photos rather than generating .xmp files like darktable does. Over time, C1 eats up 2x more disk space.
there are some things darktable can’t do, like make easy mask selections with a mouse or AI. But I use Pixelmator pro and Luminar Neo for those things when I want to go beyond what darktable can do.
I haven’t tried this in C1, but in Luminar and other i wasn’t impressed by the AI masking, it often isn’t precise enough. In darktable you at least have slider which allows even for imperfect mask to easily tune how precise you want the mask to be, in other sw i didn’t saw such feature. Also the ability to export masks in the same output file, so you don’t have to redo them in bitmap editor, is another feature i haven’t seen elsewhere.
Studio M2 Max is a beast, no wonder Dt flies. 
I need portability so my next main system will again be a laptop with all the performance penalties attached But will stay with Apple, there are some apps there that I use for years now (10+) that simply don’t have good enough equivalent on Linux.
I also have a MacBook Air m1 with 16GB RAM and darktable runs almost as fast as the M2 Max. The GPU count is only 7 on the air vs 30 on the Max which probably makes pipeline processing faster, but I would be fine running darktable on any of the apple silicon laptops today.
You are right about masking on Luminar Neo. C1 is better. I haven’t been using darktable in two years for masking and will have to work on those skills again.
The problem with C1 on my Mac mini M1 is that the performance varies a lot. Sometimes a slider adjustment is quick, sometimes there’s a half-second lag. The latter happens when I don’t expect it, so I wiggle a slider and expect to see a result, then don’t, then do, then counter-adjust, then overshoot, until I notice what’s going on. It’s infuriating, and eventually caused me to abandon the program.
Darktable always has a slight lag, but gives obvious feedback on when it’s calculating. If denoising always takes a second, I click, wait, see. That’s five. Sigmoid on the other hand is always fast (being at the end of the pixelpipe). It’s consistent and reliable. No problem there.
Lightroom is always real-time. That’s obviously best, but it also feels limited in some regards, as more heavy-duty algorithms are forgone for faster ones. From what I read, the “real-time” implementation is also incredibly tricky, with various stages of low-latency pre-renders and multiple pipelines at various resolutions, chosen based on current slider interaction activity and performance targets. Fascinating stuff, really, not unlike the dynamic resolution/LOD scaling in video games.
Similar experience here … I go back to LR, when I want to get a decent result in short time. Yesterday, for example, I took a few images of my daughter’s handball team. I downloaded them and edited them in LR because I wanted to share an image online as fast as possible.
In the evening, I sat down and did a “proper” development in Darktable for printing. Funnily I was surprised that with using some presets and module shortcuts, the basic development didn’t take longer in DT. Noise reduction was a bit more difficult since the image was taken at rather high ISO on a Canon EOS 850D, where I find the noise performance a bit disappointing. But finally I got good results.
Maybe I have to try to trust that I can achieve the result just as well with Darktable…
One problem I have with Ansel is that there are some great modules which AP has not included because he doesn’t like them. Some of these modules I really love and feel the alternatives proposed by AP doesn’t always achieve the same look.
I learn something new again. Thanks for pointing this out. It had slipped past me. What file formats allow the masks to be preserved in the export?
I am very happy with my results from my TG6 orf files using sigmoid, but I will investigate if Filmic can achieve eve a better result with them.
From my limited experience with sigmoid, I found I had to adapt the rest of my workflow as well; sigmoid is certainly not a drop-in replacement for filmic. Which works better may also depend on the image.
I’m used to filmic and its quirks, so I can work with it a lot faster and easier than with sigmoid. As filmic works for me, I don’t see any need to invest the time needed to learn sigmoid’s requirements.
But what I don’t understand is why the type of raw file should determine which tonemapper works better…
I agree - it’s not just about swapping tone mappers, the whole approach is different.
I’m not 100% sure that that was really what the OP meant… but I’ve been astonished at the variation, mostly colour but to a slighter extent tonality, between the raw files of different cameras, so - I wouldn’t be that surprised that (to take it to an extreme) someone preferred, say sigmoid for the Sony and filmic for the Olympus.
But I’m no pro, let alone a developer so… 
take it with a grain of salt.
This discussion has helped me understand how challenging it is for darktable developers to manage highlights and shadows and tonal range without increasing saturation. Other tools I have used include C1, Luminar Neo, Pixelmator Pro, Affinity Photo, DXO Photo Lab, and On1 Photo Raw - and all of them change highlights and shadow with changes in saturation. I used to over-saturate my photos and now I can see the beauty in more natural presentations, or with select use of saturation for effects.
Lightroom does basically the same thing with its default settings. there is a video on this, and if you would like to see it, I will Reply with the link.
I have over 120,000 images in my darktable library and they are now searchable with tags and a variety of other values and what amazes me is the speed of access. C1 was never able to hold the 2TB of photos I have with easy of indexing and search speed. That this software is also FOSS and works on Apple Silicon is fantastic.
I remember how zippy ACR on an old 4core/4threads Phenom felt back when I still used that.
Do you have links to read up on this? I’d be curious about the complexity of that cache structure.
IIRC, I heard some comments on a podcast recently.
Possibly it was in “Algorithms + Data Structures = Programs: Episode 160: Rust & Safety at Adobe with Sean Parent”? But it wasn’t much. It was just a few offhand comments by an involved programmer, really.