Which is cool, but let’s swing back to the policy for a bit… 
I think we need to consider the underlying reasons for the policy, other than “AI bad” or “AI good”.
The policy already states in Execution and Privacy Requirements:
All AI models must run entirely locally on the user’s machine. Integration of models that require access to external network services (e.g., cloud-based inference, remote APIs, or online dependencies) is not permitted.
This ensures that image data remains private and under the user’s control at all times, and guarantees that all processing is reproducible, deterministic, and independent of third-party services or connectivity.
The second sentence clearly states why AI models need to run locally on the user’s machine.
I’d like to propose an additional requirement:
Any darktable functionality that makes use of AI must be clearly identified as AI in both the UI and the manual. This can apply to a module as a whole, or to a specific control within a module.
It is important that users be aware of AI usage in their edits. There are situations where AI usage is disallowed, and darktable should make AI usage evident so users in those situations can easily avoid it.
Meanwhile, one of the explicitly unsupported use cases is:
Generative transformations: stylistic or structural changes that reinterpret the image.
- Example: converting a photograph into a painting-like result or changing seasons.
Here is an example of a non-AI edit that converted a photo to a painting-like result. I had it bookmarked because I’d like to try out the technique some time:
This shows how tricky this policy can be. Numerous people here have indicated that they think AI functionality that does something that could be achieved (albeit with more effort) without AI should be OK. The policy lists several types of operations that would be acceptable AI uses. Kudos to @Pascal_Obry for taking this on…it’s not an easy subject.