Development versions (3.5, 3.6) of darktable for Windows

Although I do use dt under Linux Mint regularly, my predominant use of dt is under win 10, simply because that computer is significantly more powerful that the Linux machine. The predominant use of the latter is for browsing videos on how to use dt, which I can then follow on the windows machine.

I have now installed dev. version 3.5 of dt on the linux machine and would like to match it on the windows machine, but the steps to compile from source for windows are beyond me - it is clear from the number of steps described, plus the (probably incomplete) list of dependencies that no attempt of mine to compile dt for Windows would ever succeed.

Is there another way to obtain an executable development version of dt for Windows?

Even the instructions look complicated, it is well documented and easy to execute. Don’t be afraid, and jump at the deep end.

There’s a version here, I think it has the experimental sigmoid tone mapping (alternative module to filmic), but it may not have all the latest changes from the master branch (which will become 3.6):

Thanks for this. However, for personal ethical, moral, intellectual and style reasons I make sure that, to the best of my knowledge, none of my computing resources require me to access that F Book thingy. I closed my account many years ago when FB ‘found’ class mates I apparently had at Birdsville High School in the years 1910 to 1914. For those not familiar with the geography of that corner of Queensland, refer to Google maps street view at co-ordinates -25.89315, 139.35169 to see what a thriving metropolis it is… I am systemically allergic to that level of dishonesty.

You don’t its a dropbox link…I had just written a few more notes about it on FB if anyone was interested…I posted it there a number of days ago. I use FB essentially for 3 photo groups and some family…its a tool…used or misused I guess you have to guage the benefits vs the drawbacks. These days if people use a smartphone to any degree they give away just as much info …

your right as of a day or so it was around 270 commits behind…I think its current as of about May 1…commits after that wont be there…

Here you go…its a zip file so no install needed…just run the batch file in the directory to run DT…

Have to run will update you later if you need more to get it going

EDIT

This one is a bit behind the master but has the sigmoid module for testing…

You can run both…they are working version in zip files…just unzip and go to the directory and right click on the run_dt bat file. It is just set up to use relative paths and its own config directory in that folder so you can run both of these…if you decide you don’t want them just delete the folders…it won’t mess with your current set up…just edit on copies of your files as the xmp files will not be backwardly compatible with your older version…

EDIT 2

Sorry for the quick posts I just wanted you to have access asap. Basically what I do is build the master. Then install it to an empty drive I have for those types of activities. THen I make 2 changes I add a batch file to run DT that uses a relative path command line so that you can unzip the file anywhere and the batch file also uses --configdir pointing to an empty folder I add called config. In this way the install is self contained so then I just create a zip file of the directory. So no building or installing required. As such I have done the same for Jandren’s tone mapper sigmoid fork of DT so you can simply unzip it as well. You need only rightclick and select create a shortcut on that batch file that I have made assuming you want to run it from the desktop as you would other software…So thats it not rocket science…I will try as best I can to update both forks here in a similar fashion if there are any relevant changes. One last thing you can do is copy your current config files to the embedded config directory in the zip file but I think at least at first its better to just use the fresh clean files created by DT on the first run…hope this makes sense to you and no FB…its just that I explained all this in some detail there already…good luck and have fun

3 Likes

@priort Thanks for posting and providing the build.

In my personal setup I use a separate Windows-User to test dt’s development versions. This makes sure that a completely separate database is used. I also copy all test-Raw-files into a certain test-directory to not mingle them with my main dt-version. May sound a bit overly cautious but this way it’s very safe to work with a development version.

Not sure if this is covered with your method. Would be nice if you could comment on this.

as I am using a command line switch to direct DT to use the config dir of my choice…I would say your approach might be over kill. In fact using the command line you can fully control how DT runs. For example you could have one install of DT and use 2 libraries if you chose to do so…one for business and one for personal or in fact many…so IMO there is no need for the second user but you have it set up and working for you so why not…I provided this as a zipped folder so people could essentially run it without any installation necessary. Taking care with test images is certainly not an issue and likely a very prudent precaution…

1 Like

I very much regret the impression I probably appear to have given of being ungrateful for the support you have given. Life happens without permission or prior notification (pun not immediately realised), so I have been able to take advantage of your generosity, and won’t be so enabled for a few more days.

(The dog was unscathed; the tree exhibits no evidence, aside from my dna, the bike frame designers quote a 6 month fulfillment cycle).

1 Like

This is an unconscionably late (to the point of rudeness) reply and thanks for your help in providing this 3.5 Windows version of dt. I offer a feeble excuse of this lateness: brilliant life -savers though they are, oncologists cannot always accurately predict what the combined effects of chemotherapy and radiotherapy will be.

dt 3.5 works fine, now allowing me to interchange images between the Linux and Win versions of 3.5. I did find that installing the ‘DT_DEV_Fixed…’ version requested permission to update my database, which of course I gave, having taken a copy of the 3.4.1.1 version. I have also started to edit new images in a different folder structure (as you recommended), with copies to the old structure. This does mean that if I find a ‘show stopper’ in the 3.5 version later I will have to overwrite the 3.5 database with the 3.4.1.1 version and apply edits to the images in the old structure - but that would always be true with any ‘migration’ to a later version. So, reverting to 3.4.1.1 is not quite as simple as just removing the contents of the zip file you sent me.

Ooops; as I write this I realise that I have taken a copy only of the file ‘data.db’ in ~/appdata/low. Should I also have copied the much large file ‘library.db’ ? Well, too late now.

Anyway, thanks for your gracious help

If you had run DT using the batch file it would not have touched your install…that is the key. It uses command line switches to run DT locally in that folder using a dir in that folder called config
If you don’t do that any install will use your appdata files and yes will update your old version. It does back it up but that is not the point… the point would be to run it locally. Sounds like you made some use of it. You can use the same logic when you run 3.6. Use the batch and s local config file

Yes, I understood this (a legacy from creating .bat files 40 years ago!), and so did a ‘right click’ on the bat file - so I was surprised to see it ‘touch’ my library. Could this be because I don’t have a standard configuration on my Win machine? (I have moved as many libraries and other system files as is safe and sensible off my SDD C-drive to prolong its life and because it is rather small).

About your comment of using the same logic for 3.6: did you also send me that version too? In which case I have been more stupid than usual and missed it entirely.

I most certainly have made use of the 3.5 you sent me: almost constant use over the last few days without any issue at all. I prefer it to the 3.4.1 level, if only because of the enhanced image import functions, never mind the increased functionality within the darkroom.

I’m still at odds to see how it interacted with your install. The batch file points to a config file named exactly that config. So the first time you ran it it should have made a fresh set of config files in that directory. They would be blank so no images in library.db and no user presets or other info in data.db but that is a great starting point to test things. Then you can copy a duplicate of you installed library and data.db files to the config folder and 3.5 would have upgraded them there the first time it ran after you did that. The batch file points DT to the config in the subdirectory of the 3.5 install folder wherever you located it so I am not sure how it ever interacted with your system…only way I could see would be if you inadvertently ran the dt executable without the batch then you might have run in to this…

Thanks for the further clarification. I’m going to assume the most likely explanation: user error resulting from failure to satisfy the minimum requirements of intelligence by the operator… It would only be an issue if, having installed 3.5, it proved to be dis-functional, requiring a fall back to 3.4. Well, it isn’t - far from it - so I can just carry on with those upgraded 3.4.1.1 .db files until an ‘official’ version of 3.5 is made available.

1 Like

A quick update: I installed this level of 3.5 on another Windows computer this evening, alongside 3.4.1.1. I religiously followed your instructions to execute the bat file first (having backed up my *.db files). This time the bat file ran to create valid entries in the ‘config’ directory in the folder from which I ran the bat file. - that is, it built a new data.db and new library.db in the 'folder structure where the bat file was located. DT started OK and I added my first folder. I shutdown DT 3.5, ran the …generate-cache.exe and restarted DT 3.5. It immediately asked permission to upgrade my 3.4 version of data.db and library.db in the LOCAL_APPDATA location - as was my experience with the previous install. It did not touch the newly created dat.db or library.db files in the install folder.

I don’t see what I did wrong.

If you are going to mess with that then you need to also direct that exe to your cache directory if different and maybe even your config directory. The generate-cache.exe would by default go to Appdata likely. I never use this feature. I don’t even use the library database at all. I just use memory as the database option and use DT as a raw editor for a session of editing files…

I think --core --cachedir “path” added as command line would work for the thumbnail generation exe maybe you even have to add --configdir “.\config” bottom line it needs redirection to use the right database etc…

https://darktable-org.github.io/dtdocs/special-topics/program-invocation/darktable-generate-cache/

and

https://darktable-org.github.io/dtdocs/special-topics/program-invocation/darktable/

A simpler approach is to simply copy your 3.4 databases to the config folder in the 3.5 and let it update them. This would be the second step after testing 3.5 dev version with the clean databases it creates. This also helps to determine where any errors might lie ie if they are tied to the database migration.

Finally had a chance to try out a dev-build, although 3.6 seems to be pretty close.

Filmic v5? I missed a lot, apparently :face_with_raised_eyebrow: . Can I read somewhere what and why things have been changed?

What I notice from the dt_dev_fixed for 3dlut, is that well… ‘lut3d’ is missing. Is that what is ‘fixed’, lut3d was causing compilation errors or something and has been stripped out from this build?

Or did lut3d got removed? (It doesn’t appear to be in deprecated filters…)

Yes, the changlog will be published Saturday. Or you can dig thru git

2 Likes