Anyway, I tried them, and found that, after you master the "a few rough brush strokes + adjust feathering and mask opacity until it snaps" and "overzealous brush + parametric mask" techniques taught in any Darktable course, for wildlife photo editing, AI doesn't bring much. And yes, this does require a course to break the "perfect mask is required" mindset.
Yes, Lightroom courses will brainwash you that AI "select subject, select sky, select object" workflow is the only modern way to do selective editing, but this is the Lightroom workflow. For Lightroom, it is a natural workflow, because it is, in Lightroom, the best strategy that can create a mask that aligns well with the object edges - until it doesn't. Other editors (such as ART and Darktable) have other idiomatic workflows for masking, and they work, because they have other tools than Lightroom for snapping the mask or refining it.
Bird feathers spread out on the tips of their wings are one particularly bad example where AI struggles, but non-AI tools don't.
Yet, LR is industrial standard no matter how enthusiastic developers of free software try. I wish that Adobe have proper competition, working on linux. There isn't.
I have a different problem with Lightroom being an industrial standard. If you avoid Lightroom, you cannot find a photography teacher.
You can find a Darktable teacher, and I did. He is a professional photographer, but I disagree with that particular teacher's style in photography - especially the rejection of strong edits even if they do work as creative reinterpretations of the scene.
You can find a photography teacher with good taste in composition, with recognition that both ultra-constrained and creative edits have their place (and I did find such a teacher), but that teacher will inevitably use Lightroom. That teacher recognizes what needs to be edited, recognizes that Darktable has the right to exist, but will explain the needed changes using Lightroom tool names.
It's now your job to translate - and, importantly, translate the visual effect achieved, not the slider name. This requires seeing the intended effect. This requires doing it in Lightroom first and then trying to make Darktable output look the same.
For example, the teacher asked for a high-key edit and told me to raise the whites. In Lightroom, this keeps contrast high near the top of the tonal range, right until it abruptly becomes zero because of clipping. That "high contrast followed by clipping" behavior is exactly what the requested high-key edit needed.
But your teacher will never describe it in those contrast-related terms. Before translating the instruction into Darktable, you first have to discover the visual pattern yourself that the Lightroom slider is producing.
And the correct translation, if you use the "sigmoid" tonemapper, is the "target white" control, which the official documentation marks as "don’t touch". You need to set it to 130% via right-clicking to override the soft limit of 100%. Very non-obvious, not mentioned in the Darktable course that I went through, but the photography teacher then accepted the edit.
In summary, the requirement to learn Lightroom in advance just to understand the photography teacher is the real trap here.
I think you missed the point. Darktable, effectively, has a parametric curve (implemented by the tone mapper) at the end of its processing chain. And this "curve" will, by default, compress contrast at the bright end in a way undesirable for high-key photos (infinitely smooth rolloff instead of sharp clipping). Adding another curve below that will not help, as the contrast compression factor by the tone mapper is gradually approaching infinity. The fight with this default, which is inappropriate for high-key photos, was the topic of my previous comment.
Curves (in the form of Tone Equalizer and the old display-oriented Curve) do exist in Darktable, as well as parametric, drawn, external, and, since 5.6, AI masks.
I confirm the same experience. I tried to port the Dynamic Range Optimization code in OpenCamera from Java to mathematical formulas (i.e., the spec), with the intention to translate that into Python with NumPy, so that I could run it on my own images not coming from my phone camera sensor. Tool used: just a chat with ChatGPT with the relevant files uploaded, research activated, and questions asked where I did not understand or doubted something in the response.
Result: ChatGPT faithfully and correctly reverse-engineered the initial highlight pre-compression step and then said that the rest (the real thing!) is too complex and not important anyway. I did not pursue it further.
Using multi-level grayscale instead of just two pixel states, on and off, can produce readable text at even smaller font sizes. The catch is that I have to say "text", not "letters", i.e., rely on humans inferring the too-blurry letters from their context. And I do not even need a specially designed font for that.
To give DarkTable credit, neural-network-based denoising will be in the next major release (5.6).
And even without neural networks, DarkTable denoising is better than open-source competitors, due to the database of camera sensor noise shipped with it. For each supported camera and ISO setting, it contains the measured values of Poissonian and Gaussian components of the sensor noise, so proper denoising becomes a one-click operation. That's as opposed to the much more complicated "drag the luminance and chrominance noise sliders until the noise disappears, then drag two more sliders to recover detail" workflow found, e.g., in ART.
The thing is, 127.0.0.53 is a fallback. The real default upstream is nss_resolve, which talks to systemd-resolved via non-DNS protocol on a UNIX-domain socket. Ubuntu disabled this in favor of the less-featured fallback. If you insist on sniffing DNS, you need to add instructions to disable the native nss_resolve module by not including it in /etc/nsswitch.conf.
Thanks for that hint! We still get the lookup if it leaves the machine unencrypted, but if you have both, the Unix domain socket and DNS encryption, we miss lookups.
The article says: "Already, it feels like there’s not much left for a human teacher to contribute, they believed". I also got a question over IM on whether it is possible to learn programming without a live teacher, using AI instead. I answered "no", and I stand by this "no". A live teacher chooses what to teach and in which order. A live teacher can insist on not skipping some boring but important topic and not advancing further until something is mastered, and AI currently can't do that.
On the other hand, avoiding AI completely is counterproductive. I do use AI, including for contributions to projects that allow this, but I do review everything that AI writes. So, in the AI era, the main skill required is code review, and there is indeed a change needed here, as existing programming courses focus mostly on writing code and then on understanding the underlying low-level mechanics.
> Anyone that cannot take 5 minutes to set up commit signing with a $40 usb smartcard to prevent impersonation has absolutely no business writing widely depended upon FOSS software.
No. As a user of your package, I want assurance that the package you publish does what it says it does and does not contain malware. This is different from the package having been published by you. I want protection against you going rogue, not only from you being impersonated. 2FA on your side does not protect me against you going rogue. A comaintainer does.
So the correct quote would be: Anyone that cannot find a comaintainer to review all the code and to prevent deliberate sabotage has absolutely no business writing widely depended upon FOSS software.
And even a mobile app (or, in fact, any single-person 2FA) would be unnecessary if we had a requirement for another live person to approve the release. As a bonus, a two-maintainers-required setup would also improve resilience against one of them going rogue or getting tortured.
reply