Filmulator "Nightly" Builds: Now for Windows and Linux

Since lately the master (and even the dev) branch is way behind, I’d suggest you get this AppImage rather than pulling from master. I’ll try to keep this one updated with a relatively stable recent build.

Updated 2019-06-16

Updated 2019-06-17 - faster librtprocess build
Filmulator-git.f40c8d8-x86_64.AppImage (32.5 MB)

Updated 2019-06-21 - overall speed enhancements thanks to @heckflosse
Filmulator-git.5aa82b4-x86_64.AppImage (32.5 MB)

Updated 2019-08-25 - expanded the range of the tint slider
Filmulator-git.5d2383f-x86_64.AppImage (32.5 MB)
FilmulatorSetup.exe (29.2 MB) (uploaded 2019-09-02)

Updated 2019-10-01 - changed to Qt Quick Controls 2 for a lot of the controls, added a second progress bar for Import in the tabs at the top (only visible while importing), updated base distro to Ubuntu Xenial from Trusty, so the AppImage won’t run on ultra-old distros
Filmulator-git.060321a-x86_64.AppImage (38.7 MB)

Updated 2019-10-07 - finished Qt Quick Controls 2 conversion. Windows build coming later after I figure out how to get a newer LibRaw.
Filmulator-git.f38bc26-x86_64.AppImage (38.7 MB)

Updated 2019-10-22 - added raw histogram
Filmulator-c8d3265-x86_64.AppImage (38.7 MB)
Windows build coming when I figure out msys2 package management in Azure. here 2019-10-23
FilmulatorSetup.exe (33.4 MB)

Updated 2019-11-02: added “enqueue all” button, added sraw and monochrome support
Filmulator-af7d0f0-x86_64.AppImage (38.7 MB)
FilmulatorSetup.exe (33.4 MB)

Even faster enqueuing now:
Filmulator-b2f766f-x86_64.AppImage (38.7 MB)
FilmulatorSetup.exe (33.4 MB)

Updated 2019-11-14: added “forget” from database, added additional processing parameter “shadow rolloff point”. This has a database change so be careful!
Filmulator-b2ac379-x86_64.AppImage (38.7 MB)

Updated 2019-11-17: fix layout issues, fix divide by zero artifacts affecting images containing zero values
Filmulator-5b5b7a7-x86_64.AppImage (38.7 MB)

Updated 2019-12-10: dramatically speed up “forget” operation when the database is large
Filmulator-525440d-x86_64.AppImage (38.5 MB)
FilmulatorSetup.exe (33.5 MB)

5 Likes

@CarVac
Could you change the title of the thread to
Filmulator “Nightly Builds”

Windows 64-bit builds

Filmulator_highlightrecovery_v0.7.0-200-g4e47672_release_Windows64.zip

uploaded

1 Like

I’ve updated the Linux build again, this time with some more speed enhancements.

1 Like

@CarVac

I’m having troubles running these two nightly builds. They both give me a segmentation fault, even though I’m able to run the 0.7.0 AppImage from the GitHub repo.

The only info I can glean is the following from gdb:

Reading symbols from ./Filmulator-git.5aa82b4-x86_64.AppImage...
(No debugging symbols found in ./Filmulator-git.5aa82b4-x86_64.AppImage)
(gdb) run
Starting program: /home/austin/downloads/Filmulator-git.5aa82b4-x86_64.AppImage 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[Detaching after fork from child process 1100]
process 1096 is executing new program: /tmp/.mount_FilmulQJQR7M/usr/bin/filmulator-gui
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7fffefa43700 (LWP 1104)]
[New Thread 0x7fffeedce700 (LWP 1105)]

Thread 1 "AppRun" received signal SIGSEGV, Segmentation fault.
0x00007ffff5c78fb7 in QVariant::QVariant(QVariant const&) () from /tmp/.mount_FilmulQJQR7M   /usr/bin/../lib/libQt5Core.so.5

Thanks!

Edit: Well, they run just fine in an Ubuntu VM. It seems they don’t like my ArchLinux machine, but I have no idea why.

Edit2: It runs fine if I open it with root privileges. Strange.

Are you doing chmod a+x filmulator.appimage?

Try deleting the database ~/.local/share/filmulator/filmulatorDB.

@CarVac That fixed it, thanks!

I updated the Linux build again. This increases the upper limit of the Tint slider from 3 to 10 (now 0.10 to 10), and makes it logarithmic for easier control.

This is because I got an IR photo to play with and it needed to max out the Tint setting.

I’ve just released the first version of Filmulator with a real installer, built on Azure Pipelines CI.

1 Like

I’m in the process of moving from Qt Quick Controls 1, which is deprecated, to Qt Quick Controls 2. It’s done except for the calendar in Organize, which is a little buggy anyway… I’ve gotta figure out how to handle that later tonight/in the future.

Please test and report any unusual behavior you notice. (besides the removal of the Output tab)

Hello @CarVac
I’m trying this version of Filmulator

on a Win10 64 bit system and while it works on raw files coming from Samsung NX300, Samsung NX1, Canon EOS1100D, it doesn’t work very well on raw files coming from Panasonic GX85/GX80.

In particular, while Filmulator does load the Panasonic GX85/GX80 files, they come out having strange colours: from my comparisons with Rawtherapee, Filmulator rendering of the GX85 raw files looks almost identical to Rawtherapee rendering when setted on Input profile = No Profile, hence I suppose Filmulator, for some strange reason, doesn’t apply any input profile color matrix for this camera.

Hence, I’ve tried converting some GX85 raw files to dng files, using adobe dng converter and doing this I obtained the following results:

-Sometimes Filmulator is able to open those dng files, and when it does, the results have the right
colors
-More than often, Filmulator refuse to open those dng files

More precisely, when it refuses to load the files, two cases are possible:

  1. The console output gives the following line: " Error: Failed to read Panasonic IFD Makernote header"
    In this case Filmulator does not crash, and if I enable the “Update file locations” button and then try to import the same file again, SOMETIMES, it gets loaded correctly and the console output the following lines
    “importWorker replace location: C:/MyImagesDirectory/MyWannaBePicture.dng
    importWorker replace STsearchID: 3db3a8010d23def5f556c960ea0b4b920001”
    Other times, even when doing this “procedure”, it continue to output the line " Error: Failed to read Panasonic IFD Makernote header" each time I press the Import button

  2. The console produces lots of lines, it seems Filmulator is doing its behind the scenes job, then Filmulator suddenly crashes; see the output of the console in the image below:

Hope this helps!

P.S. FIlmulator is really a great piece of code!!! I’m observing and waiting it from your first “release” back to 6-7 years ago! Unfortunately at that time it was “a bit unstable” :smiley: , hence I’m patiently waiting from that time that Filmulator grows on its legs :smiley:
If it doesn’t mind you, can I ask you just some questions?
-Does Filmulator apply some kind of “tone curve” in addition to your special “analog tone mapping” ?
-Does Filmulator apply some sort of Sharpening to the image? I know that tone mapping/local contrast does somewhat augment the perceived sharpness of an image, but stil, the Filmulator output seems almost ready for the printing!

1 Like

Could you upload a sample raw file (both original and DNG conversion) for me to try?

If it’s not supported in LibRaw, then it won’t have the necessary color profiles. It should work, but let me see what’s happening.

DNGs sometimes have weird metadata issues. Right now Filmulator does a poor job of actually working with metadata, so this could be an opportunity to improve.

Regarding your questions:

  1. There is a built-in pre-film tone curve to roll off the highlights (adjustable) and a fixed post-film tone curve that brightens the shadows. The latter was based on what I always did to every image in RawTherapee after running the original command-line version.
  2. There is no added sharpening. All that edge crispness comes from the tone mapping. And yes, it really makes for great prints with minimal additional work. In the future we may get early-pipeline capture sharpening in librtprocess which would be good at counteracting soft lenses and diffraction, as well.

Sure, find attached one of the one I was testing: don’t pay attention to the fact that the shot is underexposed, I did shot it that way on purpose, it was one of various exposure shots I was trying to test the dynamic range of Panasonic GX85 :slight_smile:

Just a little update on my previous post:
Initially, the file you’ll find attached, was the one showing always the behavior number 2), while on other files I was testing, sometimes I had behavior 1) (and I were able to open them after applying my “rescue procedure”), sometimes I had the behavior 2) and Filmulator crashed.

Now, instead, after uninstalling Filmulator (and deleting the folder that Filmulator creates in the AppData for putting its database) and then reinstalling it, even when a file shows behavior 1), following my “rescue procedure” doesn’t work, because it always leads to the behavior number 2): in fact, the file seems to load, sometimes also the thumbnail of the loaded image appears in the stripe below, but then Filmulator output on the console all the lines of the screenshot in my previous post, the one that ends with the line “Size of EXIF JPEG segment is larger than 65535 bytes”, and then Filmulator crashes…

P1010239.dng (10.5 MB) P1010239.RW2 (18.5 MB)

I will add capture sharpening to librtprocess in about 3 weeks when I’m back from holidays.

2 Likes

Okay, so on the Linux AppImage we always have the latest version of LibRaw, and the RW2 works just fine. But indeed the DNG doesn’t work. I’ll have to deal with it.

However, the Windows build uses a pre-packaged (from MSYS2) LibRaw and it’s probably not the latest version, so that needs to be compiled from the latest version as well.

Ok, got it.

I have to add, hoping it can be useful, that the older versions available here

https://keybase.pub/gaaned92/Filmulator/

show behavior 1) less frequently than the latest one ( v0.8 if I’m not wrong…) and, up to now, doing a lot of tentatives, never shown behavior 2), hence have never crashed!!

Obviously I’m talking of “.dng” raw files

Those builds are done differently than the CI build I uploaded here, so they may have a newer LibRaw version.

I don’t see why the exif stuff would behave any differently, though.

I added a raw histogram to Filmulator, which now features three mini-histograms plus the final histogram.

The histograms also got some enhancement: they now scan every pixel in the image instead of 1/25 of the pixels (which was why they were noisy and varied a lot between preview and final image before), they’re multithreaded so even with that change they still are imperceptibly brief to compute, the background is now slightly lighter gray for improved readability, the line widths now scale more continuously with UI scale, the lines are less likely to stick out of the frame, and the behavior when the image is clipped on the light side of the histogram is displayed more accurately.

In implementing the raw histogram, I discovered some processing mistakes (white saturation point) and fixed them. This is especially noticeable for Fuji cameras.

Seems the Windows build is unhappy because the CI system is using Qt 5.10 when it should be on 5.13 (and Filmulator currently needs 5.12).

1 Like

WINDOWS 7 64 BIT INTEL ® CORE™2DUO CPU T6500. 3 GB RAM. CRASH OUT PROGRAMM IN IMPORT RAW Filmulator_highlightrecovery_v0.7.0-200-g4e47672_release_Windows64.zip . WHATH DO IS ?