That is indeed a pity, Christian. I was so much looking forward to having this integrated into master
Have you considered the possibility of shipping a much simpler version of the module as a V1 and then iterate? Like, start with one or two frequency bands. Users could still stack multiple instances.
And then you could take the time to fill in the functionality gap incrementally, with tiny focused PRs.
That’s sad Christian, because you have also trashed all my comments on the two PRs. Those are valid and should be addressed to have the module’s integrated. So please, if someone resurrect the PRs be sure to look at the comments in the two closed PR.
Hi all … I just have a personal wish or " request " to get this lovely module into my darktable build ( as a " side build " ) to make use of the fantastic features .
So here is my question … ,could someone be so kind and create a build from lastest master with Christians latest branch for MacOS ARM ???
I would like to get it done myself … but this is way too much for my understanding !!!
I can only use a given script or command and fire it up in the Terminal … that´s all I can do on that front !
The latest possible DMG created by Christian does not have the LUA and AI options included in the build …
So again … I would greatly appreciate if someone has the time and the fun to create a build with my request !!! Maybe somebody else is interested .
Or … is there somewhere in wide interwebs a complete tutorial how to get this done … for REAL DUMMIES !!! ???
I guess no
@Pascal_Obry if your quality objections are met by other volunteers, would it be feasible for the core developers to merge and support the module, or would it require someone to take ownership of it and understand it as well as Christian does?
Yes for the first part. Most of my comments was about code design and implementation, see:
Now, we also need someone to maintain this and fix possibly issues that will be found before the integration.
I’m still not sure why Christian left the project, the request was quite simple and @Jens-Hanno_Schwalm even proposed to do the OpenCL implementation.
A possible solution is maybe to work with Christian, if you can handle the code and Christian respond and propose changes to the algorithm (the maths being all this).
You have to know your limits! That is the one and only reason I closed both PRs.
Here are the two reasons:
Both of my PR branches on GitHub were corrupted with files that were constantly in conflict. In short, I couldn’t get out of it.
If we want the code to be robust over time and easy to maintain, it needs to be perfectly structured and readable for other contributors who will handle maintenance. This requires rigor and skill in writing and reading code. As I’ve already said, I’m just starting out…
Please, let’s not see problems where there aren’t any.
@Pascal_Obry All your comments have been incorporated into the code. For the basecurve project, the OpenCL bug has also been fixed. And for the “contrast and texture” module, I’ve incorporated all your comments.
I still need to check whether this line is really necessary. (currently line 820)
Unfortunately, I tried to refactor the variables into an array, but without success.
Otherwise, both modules are fully functional and have no known bugs.
And if I can help, I’d be happy to. I’ll compile a new experimental version labeled as such to avoid any confusion
In the case of this module, it sounds like Christian felt he wasn’t yet ready for the admin of completing the PRs. I’m sure many of us are hopeful that the work done on this module by him and also by @Wilecoyote and @jandren on variations based on the core algorithm will result in a module getting merged at some point.
As promised, I’ve compiled an experimental version of Darktable.
This fork will serve as my development lab, where I can explore new approaches to the photographic workflow. It includes the two modules that are not yet part of the official release.
This version can be used alongside the official darktable, it uses its own configuration directory, and sidecars are saved as .lab.xmp files. Existing darktable .xmp files are also read.
Sorry Christian but this does not sound as a good idea.
It is probably better to work with the team and some other volunteers to get the module integrated at some point if you fell them important / useful. A fork is never a good idea in the long run if you ask me. You already got some proposal for help.
One doesn’t preclude the other; my approach is purely experimental. I think I’ve made that clear enough on GitHub, the goal isn’t to create a “competing” fork of Darktable. This allows us to test without the risk of breaking Darktable’s database or the XMP sidecars. This experiment is also teaching me how to work with GitHub. Give me a little time before I resubmit a new “clean” PR.
I understand your reasoning Christian, but I would much prefer to see your wonderful module merged into darktable.
Whilst I would like to monitor its development in the meantime, I am reluctant to install your fork’s Windows .exe file (and the file you have uploaded cannot be unzipped like the nightly build darktable NSIS-deprecated files can).