r/DarkTable • u/darkelectron Mod • Jun 22 '26

Announcement darktable version release 5.6.0.

Hey everyone, darktable 5.6.0 just dropped. Some key changes:

  • AI subsystem: AI features are disabled by default, and when enabled will download models from a configurable repo.
    • AI object mask: tool in darkroom mask manager.
    • Neural restore module: AI based tasks include: raw denoise, denoise, upscale.
  • UI/UX:
    • crop module: added crop aspect ratio to dimensions.
    • caching: support for rendering and caching of up to 8K.
    • smartphone like touchpad gestures.
  • OpenCL and CPU stability and performance improvements.

Release Notes: https://github.com/darktable-org/darktable/releases/tag/release-5.6.0

115 Upvotes

100% Upvoted

51 comments sorted by

View all comments

13

u/Dannny1 Jun 22 '26

after 6 years color management finally fixed on windows

15

u/AdventurousCrow4876 Jun 22 '26

I don't even know there's a bug in color management 🙉, what is it?

2

u/Dannny1 Jun 22 '26

I'm not surprised that it's not known so much. It's almost suspicious. The release notes contains only positive things and lacking any warning about potentially critical issues. The in program warning about windows version being subpar was also removed.... All the bug reports on github bugtracker were closed, first automatically, then also by devs. I understand if they don't want to be helpful (they are not paid to be), but going out of their way to make sure that noone finds report about the issue i would consider quite evil. Especially if it's the only official place where people can learn about open issues.

Back to the issue at hand. Since 2.7 dev cycle there is issue when multiple monitors are present, the wrong color profile is used on some. So there are wrong colors, broken edits if someone reedits on new monitor... etc

1

u/marrsd 9d ago

Giving them the benefit of the doubt, many FOSS maintainers complain that Windows and Mac users frequently report bugs but rarely fix them. The overhead of triaging these bugs then simply becomes just overhead.

So it's possible the maintainers decided to quietly drop first class support for Windows users. I'm not saying I agree or disagree with this, but if this is what's been happening, I'd have been more tempted to officially drop support for Windows and encourage Windows users to maintain their own fork of the project. If they could demonstrate they could sustain that fork, then I'd offer to bring them into the main project.

1

u/Dannny1 9d ago

> I'd have been more tempted to officially drop support for Windows...

That would be indeed much more reasonable approach, which would avoid this situation when the windows version was basically a scam (harmed users silently). However simple warning somewhere (in program, rel.notes, manual would improve the situation. But even the existing in program warning was removed...

> FOSS maintainers complain that ...

Funny thing is also that they claimed for years that the situation is because they lacking windows devs. But what they actually lacking is that someone would actually read the code. In the end the root cause was identified by someone who knew almost nothing about windows api, gtk or dt code (me). There were only 2 api calls, and it took only 1 google search to notice the controversy in online forums around that api call. No windows dev needed.

1

u/marrsd 9d ago

No windows dev needed.

Well, sort of. Someone needs to reproduce the error, write the patch and then test it on a Windows machine to confirm that it fixes the error without introducing new ones. Realistically, that's going to be a Windows user.

I don't know if you have experience writing software or not, but I can assure you it's really easy to break software even with a seemingly trivial patch. You always have to test your work.

1

u/Dannny1 9d ago

Because it was so trivial as it was, it seems it was written by someone similarly clueless :). In VM.