Ask your build questions here. References from the previous thread.
1 Like
I’m glad you got to a useable endpoint…
Pretty pleased.
I was able to compile and build a Windows executable and also create an installer.exe, which installed ok. So I now have an instance of dt, which has the sigmoid module.
At first I gitted (if there is such a word) or rather cloned the entire repository/branch from the author of sigmoid, but compiling and building that did not yield an install which included sigmoid.
Then I found this :
And if synced with the windows build instructions I had succeeded with earlier, it was a relatively painless process.
Next frontier to conquer would be a much more involved one which is “building a filmulator module or might be modules, cos of the architecture of dt’s processing, which may require the various aspects of filmulator to be split up”
It makes sense to start the discussion on this “project”, in its own thread. My initial thoughts are , for compiled apps, this must be such a pain, to have to always compile before they could test anything.
1 Like
Funnily enough I didn’t see this discussion until now.
I built a dt-trunk + sigmoid build under Win10 for the first time yesterday.
To be honest, i was surprised how easy it was. Well done DT devs for the process and documentation!
1 Like
The approach I followed, provided me with a “build” of DT, which includes sigmoid, but the version of DT in this, is not in sync with the latest DT dev version. So I end up having three versons of DT.
-
One with sigmoid, but out of sync (I think) with the current development code on github.
-
One without sigmoid, but is based on the current development version on github.
-
And the stable release 3.4.1.1, which I simply downloaded and installed, and did not build, unlike the two above.
I wish I knew how to, every month, build a version based on the current dev code on github, and combine this with sigmoid. So I can reduce the number of instances/versions I keep on my computer, from 3 to 2. If anyone knows how to do this, kindly share.
I did the steps in the DT windows build doc:
git clone git://github.com/darktable-org/darktable.git
cd darktable
git submodule init
git submodule update
(from darktable/BUILD.md at master · darktable-org/darktable · GitHub)
Then i did:
git remote add jandren https://github.com/jandren/darktable.git
git fetch jandren
git merge jandren/sigmoid_tone_mapping
(from: [WIP] sigmoid tone mapping module by jandren · Pull Request #7820 · darktable-org/darktable · GitHub)
The merge fails for 3 or 4 files.
I then edited those files and fixed the merge issues.
This was very straightforward if you know a little C/C++ coding.
I then built it as per the DT windows build doc.
So the normal way to dealwith that would be to create a local branch containing the sigmoid code, and merge onto it changes from the official darktable master branch. As long as there are no merge conflicts, it is easy. If there are merge conflicts, you may need some coding skills to resolve them. I would suggest just avoiding the sigmoid module altogether though, unless it somehow finds its way into the official master branch.
2 Likes
This will corrupt your database so be prepared as updates don’t recognize the sigmoid module…I would keep a separate version with sigmoid if you want to use it…
This is more complicated than necessary. Just do git fetch https://github.com/darktable-org/darktable pull/7820/head:sigmoid_tone_mapping
This will create a new local branch that you can checkout to: hit checkout sigmoid_tone_mapping.
You can then do git merge master to incorporate newer changes from the main branch. But as Matt said, this could lead to merge conflicts that you need to resolve manually. These are sometimes unavoidable, so this procedure is not recommended to the uninitiated.
Been a while since I studied or wrote/edited any C/C++. It would be interesting.
But - see below, why I’ll hold on this.
Until sigmoid gets included in the official dt roadmap, if periodically Jandren refreshes the sigmoid branch, (one or two months behind the bleeding edge version, is ok for me), then I can build from this revised branch, using the same process I followed earlier, and use this as my “dev” dt edition.
And yes, all warnings noted, installed in its own “dev” directory and own database/config directory, which I already adhere to, as directed by all the kind folks on pixls, with much thanks.
Why would you suggest that? I’m finding it much better to use than filmic.
I really hope it does make its way in.
The PR is flagged as “controversial”, and until that is settled, I think it is premature to be establishing work processes that depend on it.
1 Like
I think its only forthright that I add here, I have eventually figured out filmic, and it now works for me.
Between the base curve(for those who like working the old way - habits may not be easy to let go off for some), and filmic, I have enough options, for tone mapping.
One thing I read about the development process, for darktable, is that anyone with new development ideas, ideally has to collaborate with the rest of the darktable inner caucus, in a very specific way, and also has to be able to demonstrate that they will be around to maintain the code. So its not just a case of - oh here is a new idea, put it into darktable.
There is a lot more work that any new idea in darktable has to live up to, including the contributor demonstrating their commitment to being around to maintain their code. On hindsight, these protocols and controls in the darktable roadmap, are really important, to ensure that darktable remains stable, for a long time to come.
I have enjoyed the new ideas, like sigmoid, but in fairness, maybe what we need is more education about filmic, more marketing of how to use filmic.
Not that an effort has not been made, with the education on filmic, but more information could always help, cos its a bit of a special tool, very different from what most of us have used in the past.
Its easy to use - filmic, when you know how, but it needs some time to learn it, and a bit of practice, to become consistently successful with it.
It has taken me months (over 6 months) to figure it out, but now, I am eventually quite comfortable with it, and it fulfills most of what I need. And any additional tweaks can be done in a few other modules, like the tone-equaliser and the “new” colour-balance rgb.
One major hurdle, with filmic, was learning to always enable the middle-grey-luminance slider, so its always there should I need it. So I have this enabled this slider to be displayed by default, via an auto-apply preset in filmic.
You don’t need middle-grey. Use the exposure module. You can even set up a keyboard shortcut so you can change it while you’re in filmic.