Still struggling with the Windows build, but my friend has made an Arm64 build for Mac…
Filmulator_v0.11.2rc7_arm64.dmg (49.4 MB)
note: may only run on MacOS 12? Not sure.
Still struggling with the Windows build, but my friend has made an Arm64 build for Mac…
Filmulator_v0.11.2rc7_arm64.dmg (49.4 MB)
note: may only run on MacOS 12? Not sure.
Great! But it doesn’t run…
Termination Reason: Namespace DYLD, Code 1 Library missing
Library not loaded: @rpath/libraw_r.22.dylib
Referenced from: /Applications/Filmulator.app/Contents/MacOS/filmulator
Reason: tried: '/usr/local/lib/libraw_r.22.dylib' (no such file), '/usr/local/lib/libraw_r.22.dylib' (no such file), '/usr/local/lib/libraw_r.22.dylib' (no such file), '/usr/lib/libraw_r.22.dylib' (no such file)
(terminated at launch; ignore backtrace)
I will try to reinstall libraw, but perhaps your friend is more capable… I’m on macOS 12.0.1, iMac M1.
Update: Installing libraw fails (I’m not doing it right, I guess). I hope your friend can figure out what goes wrong, @CarVac! I’d really like to try Filmulator.
Another update: perhaps the libraw version is wrong in the Filmulator code? I can install libraw using macPorts in /opt/local/lib/libraw_r.20.dylib but that’s ‘20’, not ‘22’. Also the path is different (but I tried to remedy that with an alias/symbolic link).
Update 3: After tricking the system by adding libraw_r.20.dylib manually to /usr/local/lib and changing the version number to ‘22’, it now crashed saying:
Termination Reason: Namespace DYLD, Code 1 Library missing
Library not loaded: liblensfun.2.dylib
Referenced from: /Applications/Filmulator.app/Contents/MacOS/filmulator
Reason: tried: 'liblensfun.2.dylib' (no such file), '/usr/local/lib/liblensfun.2.dylib' (no such file), '/usr/lib/liblensfun.2.dylib' (no such file), '/Applications/Filmulator.app/Contents/MacOS/liblensfun.2.dylib' (no such file), '/usr/local/lib/liblensfun.2.dylib' (no such file), '/usr/lib/liblensfun.2.dylib' (no such file)
(terminated at launch; ignore backtrace)
So probably more dependencies are broken/missing. Also, it seems that on M1 they should be in different locations than before…
@CarVac If your prefer, I can communicate with your friend directly.
Update 4: Launch now proceeds until librtprocess is loaded; I don’t have it and I don’t know how to install it. The other dependencies may or may not be working now; I fiddled with the filenames. Giving up now… back to my photos. Hoping we will see a working macOS version soon!
Filmulator_v0.11.2rc7_2_arm64.dmg (44.9 MB)
Here’s another attempt; it should include LibRaw in the bundle.
Thanks to you and your friend for not giving up! Still crashes on launch… note that I fiddled with dependencies, adding dylib files to different locations, and so on, so I’m not sure which dependencies are now missing in the bundle, but now launch crashes at librtprocess loading. All the dependencies should be in the bundle (lensfun, libomp, librtprocess, maybe others), because M1 Macs put those in strange new locations, and for non-coders like me, installing librtprocess is already too high a hurdle.
It shouldn’t be doing that but I think it’s an artifact of him testing it on the same machine that he’s building it on.
Is there anything I can do to help? From tomorrow on I’ll be away from my M1 for a few days, but tonight (6PM here) I could test any new builds. Again, I think all the dependencies should be in the bundle, or it won’t run on M1.
He said the dependencies were in the bundle but it was nonetheless looking for the system ones.
He’s working on using a VM to test.
I can do the testing, no problem!
Maybe worth to mention, that msys2 builds of RT using gcc 11.* are not stable. On msys2 I use gcc 10.3 because it’s stable…
Maybe this helps: I noticed that libomp.dylib and libraw_r.dylib inside the application bundle are really aliases (symlinks), pointing nowhere. And while liblensfun.dylib may be the real thing weighing 1.5 MB, librtprocess.0.dylib, though not an alias, seems small at 224 KB.
placing a -20.dylib in your /usr/local/lib under a different name will crash probably.
That -20 is meant to indicate how binary-compatible it is. So you now for sure that between a -20 and a -22 there are binary differences and they are not compatible.
Best to remove that single attempt if you didn’t already.
the previoux build was compiled with a newer version of libraw. If they include the file inside the MacOS package, that will be picked up when running it.
Thanks. I removed the .dylib files I added, and now it crashes at libraw_r.22.dylib not being found. I’m optimistic: once all the dependencies are included in the bundle, it will probably work.
Hi @CarVac, I’ll be available for testing the M1 version a little longer, leaving later tomorrow. Very eager to try any new version that might run.
Using the latest build for linux, the settings for noise reduction are not stored. If I adjust one image, and activate noise reduction, open another image and then return, noise reduction is not active anymore. All other settings are stored though, so I guess noise reduction settings are supposed to be as well?
I haven’t fully decided whether noise reduction’s settings will stay as-is so for now I have made them not save.
Once I decide they’re “stable” I’ll make a database update so they’ll be saved, but you won’t be able to use older versions of Filmulator from before the database break.
Ok, sounds good!
2021-12-15:
Fixed a bug where if the lens was autodetected for LensFun and corrections manually selected, the corrections would not be properly recalled (even though they were saved properly).
Fixed black levels for Panasonic cameras, which have per-channel black level offsets.
The Windows build is still being uncooperative.
2021-12-16
I got the Windows build to work now, at least on my machine. It takes some manual tweaking after CI (swapping in the qsqlite DLL from the old version), which is very irksome, but at least manageable for the time being.
Hopefully it works for others too.
2021-12-29: v0.11.2rc9
I fixed a bug in highlight handling with extended ISOs; low ISOs would have incorrect white saturation points sometimes.
I also realized that recently the Unicode support on Windows stopped working. I shall have to look into that…