MSI B4501 Motherboard
AMD Ryzen 5 2600 Processor
Nvidia GTX 1660 GPU (6 GB RAM)
HP EX950 NVMe PCIe M.2 512GB SSD System Drive
Crucial MX500 500GB SATA SSD Data Drive
32 GB Corsair Vengeance LPX DDR4 2666 C16 RAM (2x16 GB)
ThermalTake ToughPower Grand RGB650W PSU
Runs GoPro Fusion Studio (as well as everything else I’ve asked it to do) flawlessly.
This was while rendering about 100 GB of 360 time-lapse images using Fusion Studio:
Barely breaking a sweat. 
Rendering is also very fast, and Fusion Studio has never crashed on this machine. So I’m happy.
Just being picky… If it’s not using 100% CPU and isn’t disk I/O bound (per your post) then there maybe latitude to run the process faster…?
It is a bit odd that it doesn’t pin the processor utilization at 100 percent while exporting time-lapse photos because it does when exporting actual video (from Fusion Studio or any other video-rendering software I’ve used). I noticed the same thing on my other computer, which has an i7-6700 CPU, 32GB of system RAM, and an Nvidia GTX 1650 GPU with 4GB of video RAM. Video rendering fully utilized the processor, but time-lapse rendering did not.
My guess is that rendering the time-lapse pictures, being a sequence of stitching tasks without the additional video encoding stage, provides enough “rest” between individual frames that it never fully utilizes a reasonably-powerful CPU or GPU. But the additional encoding step of a video export does.
That’s just a guess, mind you. But it seems as likely as any other I can come up with.
It may be an SMP/affinity thing. ffmpeg creates multiple threads and utilizes all CPUs, but the python code only runs on 1 CPU when running (linux) mapillary_tools. I solved that and about halved my elapsed processing time by starting two instances roughly 30 seconds apart. Perhaps Fusion Studio is a mix of multi/single threads?
That makes sense. I really haven’t looked at the software that closely other than from a stability point of view. Just getting it not to crash mid-render was a triumph. I also haven’t tried the Linux tools because I’m trying to get Linux, Nvidia, and Wayland to play nicely on Linux before actually asking it to do anything useful. It seems to work on Fedora, so maybe that will be my next project.
I’ve found that most of the instability of Fusion Studio results from it not always interpreting the files from the SD cards properly. Most of these problems can be solved by manually copying the files to the computer rather than importing from the camera.
One problem is that if the camera momentarily loses GPS, it tends to start a new folder; and then starts yet another new folder when it gets GPS back. But Fusion Studio invariably crashes on the first image of every new folder if it named the sequence after the image set in the previous folder. The workaround in that case is to import the folders manually and process them individually rather than letting Fusion Studio import them from the camera itself.
Another problem is that if one of the image files is corrupt or doesn’t exactly match its companion (in other words, the front and back images don’t match in some regard), Fusion Studio simply crashes. It doesn’t merely skip that file and move on. It goes down in a blaze of glory. The workaround is to delete that file from both sets, split the folder into two at that point, and process them individually in two separate sessions, clearing the “Sources” directory in between the two runs.
In short, Fusion Studio is buggy enough that just getting it to run in a stable manner has been a noble fight. I haven’t really looked at optimization yet. I’ve found that the most important step in getting it to run without crashing is to copy the files from the SD cards to the computer and process each folder individually. That prevents about 99 percent of the problems.
Judging by what you posted it seems that the camera - SD card interface or coding is buggy. Unlike PC OS’s the camera will probably be buffer/timing constrained and may even be running out of time to write files and GPS data. It is weird that it fails on USB/importing though. That sounds far more major than just a write race/fail. What I am getting at here is this may be the root cause of the Fusion Studio failure.
The first step IMO is to review the SD card and maybe replace with a faster one. Also format it in camera if the facility exists. Some filesystems also have parameters that can slow access, so check that as well. vfat is probably faster than ntfs in single file write for example.
Time lapse mode (multi jpg) is also far more I/O intensive than creating an mp4. If the SD card review doesnt help, perhaps lowering the resolution or increasing the frame delay will be a good experiment/test. A camera firmware update may also address fixes in this area.
The BlackView cameras have multiple warnings about using alternate SD cards. I dont even remove it from the camera, WiFi transferring instead.
If doing lots of rendering/GPU/Nvidia stuff on Linux I’d suggest the proprietary driver. It is an install option on Debian. (I dont know others) Too many things seem to fail when using the open source (nouveau) one.
I’m sorry. I didn’t make myself quite clear.
It’s not that the USB import fails, per se. It’s that when the camera decides to split an uninterrupted sequence into two folders, Fusion Studio treats the two folders as one Multishot sequence, and invariably crashes on the first image in the second folder. The USB interface works just fine. It’s Fusion Studio that vomits.
The reason manually importing works around this is because you can process the folders individually by only placing one set (front and back) at a time in a folder on the computer, and navigating Fusion Studio to that folder.
In other words, either folder pair will render fine on its own. But when Fusion Studio automatically imports them to itself from the camera, it treats the two sequential pairs of folders as one multishot set (presumably because of the EXIF timestamps) and tries to process them sequentially – and crashes on the first image in the second folder. Manually importing the files and processing them individually prevents that from happening because Fusion Studio can’t see the other par of folders in the sequence.
The one thing I am almost certain will cause the camera to split a sequence into multiple folders is a momentary loss (or re-acquisition) of the GPS signal. There may be other reasons, as well. Whatever the case, every time I’ve had Fusion Studio crash at the same image on two consecutive render attempts, the problem was that the camera had split the sequence into two (or more) folders; and every time I processed those folders individually without letting Fusion Studio know that the other folders existed, they processed successfully.
So in summary, the USB interface works just fine. The problem is in the software not being able to handle a sequence that was split into two folders by the camera. If you present the two sets of folders separately, the render will succeed.
