I fetched and compiled Filmulator the other day,
onto an Oracle VM Virtualbox Ubuntu 15.10 having
just 1 gig swap memory. Would that be the reason
why Filmulator was so s-l-o-w?
Yes, I would say it is RAM-hungry, but it depends very strongly on the image size.
With a 12.8 megapixel image (5D), it peaks at 1.5 gigabytes and drops down to 1.1.
With a 24 megapixel image (a6000), it peaks at 2.2 gigabytes and drops down to 1.8.
With a 42 megapixel image (a7R2), it peaks at 4.4 gigabytes and drops down to 3.3.
With an 80 megapixel image (IQ180), it peaks at 9.1 gigabytes and drops down to 6.3.
It caches the full image size at several points in the pipeline.
I finally cleared enough room to set up a virtual machine with Filmulator. However, when I reach the Filmulator tab and attempt to load an image, I get:
matrix::set_size memory could not be alloc'd
Segmentation fault
What is the application running out of?
How much ram have you allotted your VM? The default of 4 GB is likely too little.
2 Likes
4GB is all I have! That said, I moved the needle up to 2.9 from 2.5 and it worked. However:
VMware: vmw_ioctl_command error Invalid argument.
Aborted
Comment #12 : Bug #1577494 : Bugs : Stellarium helped me resolve this error.
So is it working now?
Yes, thanks for asking 
.
However, working with such low resources makes Filmulator harder to use; e.g. it got Killed just now.
Working in a VM, which takes resources, on a system only 4 GB of ram will likely strain most raw processing programs. For instance, RawTherwpee has a page dedicated to running with 4 GB or less of ram.
I am lucky, my edit machine was recently upgraded to 32 GB ram.
1 Like
I’ll see if I can make a low-RAM setting that doesn’t cache the images. It will be very slow when making any slider changes though, since it will have to recompute from the start every time if it doesn’t cache the images.
Are you really sure that it’s worth the effort?
No, but I’m almost done.
1 Like
@afre: The change is pushed to the dev branch of the filmulator-gui repository.
With a 50 MP GFX file:
Without Low Memory Mode: 6.7 gigabytes consumed at peak.
With Low Memory Mode: 4.7 gigabytes consumed at peak.
With a 12.8MP 5D Classic file:
Without Low Memory Mode: 2550 megabytes consumed at peak.
With Low Memory Mode: 2207 megabytes consumed at peak.
Obviously there’s more overhead with the smaller file.
1 Like
This thread is referring to RAM (temporary working memory), not storage space.
Is this referring to the false positive warning by crappy antiviruses?
In any case, you can remove the thumbnails and database by deleting C:\Users\<USER>\AppData\Local\filmulator\.
No clue what you mean about AMD.
Hello,
No, I got my info from running my backup file, which is necessary to run when you have a 4 TB pc. The backup file for my pc is in D:\ - there should be no other file (besides C:) …but there is currently a file V:\ that’s inundated in with D:. I’ve almost eliminated it, but it’s still there, as you can see. The V:\ file showed up when I downloaded Filmulator.
What do you mean by “inundated in with D”?
In any case, Filmulator wouldn’t create those directories unless you told it to when you import.
Okay, that is probably what I accidently did…do you have any idea how to get it out? What I mean is, when I try to search for the V:\ file to delete it, my pc is telling me there is no such thing…yet obviously there is.
Honestly, I have no idea what the robocopy command is…I am by no means a pc tech, I just noted that the V:\ drive showed up and was really trying to take over the D drive. Is robocopy a bug?
Were you running some sort of backup routine?
I have a Seagate portable 4 TB drive that I use as my backup (the images are screenshots from it running just a few min. ago).
…oh no, please don’t tell me I have a bug in my backup (!)