darktable 3.4.x (osx >= 10.15) including liquify bugfix plus
darktable-3.4.0+53~gd8b57c22b.dmg
(handle with care - backup your stuff first) for productive stuff prefer official dt 3.4 build
Hi,
thank you for providing this binary. One question: is this version any different ā apart from the mentioned changes ā from the official release for what concerns speed/opencl optimization on Big Sur (Intel processor)?
Itās based on Commits Ā· darktable-org/darktable Ā· GitHub - i dont know exactly, whatās the codebase for the official build. It seems that at least the commits from 22. arenāt included in the official build
new build based on Commits Ā· darktable-org/darktable Ā· GitHub (osx >= 10.15)
includes liquify & waveform histogram bugfix
plus
darktable-3.4.0+61~g9e9498259.dmg
(handle with care - backup your stuff first) for productive stuff prefer official dt 3.4 build
Great, and thank you for fixing the waveform histogram !!!
Thanks.
I have written a small program using fswatch and libheif which watches a whole directory tree and when a new jpg or png file is added it will convert it to heic. If some one is interested can share it.
new build current master darktable-3.5.0+543~g54e7e09eb.dmg
theresās a database update included so donāt forget a backup first - thereās no way backā¦
new build current master darktable-3.5.0+693~g5d34b0fa5.dmg
theresās a database update included so donāt forget a backup first - thereās no way backā¦
What is the performance of M1 chip based Macās with dark table?
I havenāt heard that anyone has made a native arm build yet.
When I said I managed to build and run DT on Big Sur/Xcode 12.3, that was on an intel mac, not an M1 mac
being able to build with XCode12.3 and sdk 11.1 is just the prerequisite to build for M1. But the used stack of libraries provided by macports must be supporting M1 or ported first.
Thanks for clarifying, i thought this was a m1 mac.
I was thinking of buying the M1 Mac mini but will wait till DT is ported as it is my most used program.
What are the chances and timeframe for macport library porting for M1?
As far as i know thereās no developer using a M1 Mac - but two users are able to compile on a m1.
But this depends on ported macports packages, so you better look there for a timeline ā¦
Quick question: what are the differences/advantages (if any) between using the standard MacOs dmg package downloadable from the darktable website, and building the package from source according to the instructions on darktable/BUILD.txt at master Ā· darktable-org/darktable Ā· GitHub ?
I am asking this because dt crashes on my MacBook Pro 13 2020 (Intel) when using the filmic/reconstruction tab on Big Sur, and I may try to compile it myself if it solves the problemā¦
thanks for any comments
Compiling yourself means among other things that you might experience fixes that are in master and not yet in official release.
you can ditch the ādeployment target 10.7ā stuff and also some of the patches if you build just for your system. Better use Xcode12 commandline tools with sdk 10.15 even for big sur since there seems to be an issue with sdk 11.1
Thank you for your reply! It seems a bit excessive to me though (maybe Iām wrong) to change macports.conf and use some other (a little obscure) patches and mods if one is also relying heavily macports for other software, just to do a standard build. It would be nice to have a separate, much simpler, instruction page for building dt just for oneās own system, which I guess is what the great majority of users would be interested in. But I do understand that developersā time is limited and they are already doing a tremendous job, which I appreciate very much.
I did not understand whether the standard dmg downloadable from dt website is routinely updated to get the latest fixes or that would be precisely the advantage of building the ports from the sources. Also, do you think that building from source would improve performance, or not really?