Worked all day, Never Complained

Spark Series
1

Hi everyone,

I thought I’d share a little write-up from this week’s shoot at Six Flags Over Texas, where we were filming Tormenta, the world’s tallest dive coaster.

My Spark, now officially named Quick Silver, performed flawlessly in the blazing Texas summer. The outside temperature was around 100°F, with a real feel of 113°F, and there wasn’t much shade to be found. The camera stayed powered on and shooting from roughly 8:00 a.m. until 4:00 p.m., with only brief interruptions for battery changes and normal production pauses.

I switched the fan from Low to Medium as a precaution, but the internal temperature remained remarkably stable all day, hovering between 50°C and 53°C.

Zero failures. Zero missed captures.

Once again, the camera simply did its job—and did it well.

I was shooting alongside an ARRI Alexa Mini, and interestingly, the Mini actually became much hotter sitting in direct sunlight. That may have been partly due to its dark carbon finish versus my shiny silver Spark body. (One of the many reasons I chose the silver version.)

The Mutiny Power I/O also worked flawlessly, converting my V-Mount setup to Gold Mount while providing run/stop control through the 3-pin port for my Tilta motors. I started the day using Core SWX Nano 98Wh batteries before switching to IndiPRO 250Wh Gold Mounts, simply to reduce battery swaps throughout the day.

Swapping between the EF and PL mounts is incredibly simple and only requires a T8 Torx driver. I brought along a Wiha Micro Bit set, which had everything needed.

One thing I’d still like to see from Pixboom is guidance on default shim configurations for each mount type. I couldn’t find any mention of this in the manual. It wasn’t an issue for me since the Canon CN7 has built-in back-focus adjustment, but it would be helpful to know the factory shim stack and recommended starting point for each mount.

For example, DZOFilm provides a chart for the Vespid lenses that specifies how much shim adjustment is typically required when changing from EF to PL. Having a similar reference from Pixboom would help establish a good baseline before fine-tuning flange depth.

Our schedule was compressed this time, so we weren’t able to mount the Spark directly on the coaster as originally planned, but I was still happy to put it to work on the ground.

The very first comment from our director after seeing the first playback was:

“WOW… the color looks amazing.”

Keep in mind, he’s a die-hard ARRI fan. So yes, Pixboom—you should be proud.

I absolutely think there’s still room to grow in areas like color science and the overall image pipeline, but the camera’s starting point is already incredibly impressive.

My current on-set DIT workflow

  • Connect the Pro Card to Pixboom Cine.
  • Open each clip individually.
  • Set your In point using the #1 flag.
  • Set your Out point using the #2 flag.
  • Export only the usable section.
  • Pixboom Cine remembers these in/out points even after ejecting the Pro-card from your computer

Pre-trimming clips before delivery not only reduces export time, but also saves a tremendous amount of storage. It’s also a perfect opportunity to remove false starts and unusable takes before your client ever receives the footage.

For delivery, I typically export:

  • CinemaDNG for clients who want the original image quality.
  • ProRes if specifically requested.
  • H.265 versions for my own archive.

I then back up the original Pro Card media together with the H.265 proxies. Having lightweight proxies alongside the untouched originals makes revisiting projects much faster later.

One thing I discovered recently is just how much storage speed matters during export.

I’ve had excellent results exporting directly to my Oyen Digital U34 Bolt and U35 SSDs. During another shoot last week, I compared them against older Samsung T7 and even T9 drives, and the Samsung drives took roughly five times longerto complete exports from Pixboom Cine once their DRAM cache filled during sustained writes.

I haven’t experienced that slowdown with any of my Oyen Bolt drives.

If anyone is interested in the Oyen drives, feel free to send me a message. I can help you get a nice discount through B&H.

This isn’t an advertisement—just sharing what has genuinely worked well for me.

I’ll check with production to see if I’m allowed to upload a few CinemaDNG sample files for everyone to explore.

Until then, I’m simply happy to report that the Spark handled an entire production day in the Texas sun without missing a beat.

A continuing challenge on set with the released firmware where there is a complete lack of drive and clip naming. We’re still currently stuck with A001 & C001 with unique hex identifiers to tell clips apart, this is a serious issue for any serious production workflow. I do hope this is resolved very soon. 

Image
Image1390×1850 961 KB

Image
Image2494×1862 1.11 MB

3 Likes
2

So you don’t drop the files onto an ssd before you import them into the pixboom software? You work directly from the pixboom drive and you export to your ssd? 

3

I ended up using all 3x 0.05mm shims and 1x 0.02mm shim on my PL mount to get accurate marks. Of course, results may vary since the shims are designed to fix manufacturing variances, so a different PL mount on my body or my mount on a different body may require different thicknesses.

I haven’t yet tested out the EF or E mounts for accuracy. Maybe I’ll do that this weekend.

4

This is my question as well, does transcoding the footage in Pixboom directly off the drive affect its long term health and use?

5

Yes, while… It would likely be best practice to clone the Pro-Card to a SSD before conversion, I am finding that it just takes too long to do all of that round tripping on-set. 

I have been finding most of my jobs are using between 1 & 1.5TB of each Pro-card … Here is a rough estimate of transfer times I am seeing on my Mac M1 Max 

24 files 1.53 TB - None of them trimmed. Using Pixboom’s included USB-C and Oyens Cable for the U34

  • Offshoot with checksum from Pro-card to U34 4TB - 50 mins 939/MB sec

  • Finder Drag and drop from Pro-card to U34 - 23 Mins 

Exporting within Pixboom Cine from the Pro-Card

  • PXBC to PXBC - 25 Mins 

  • PXBC to CDNG - 55mins 

  • PXBC to Prores HQ - 38 Mins 

  • PXBC to H265 - 55 mins

As you can see the less round tripping you can do on set will speed up your off loads, however take all this with a grain of your own risk on data transfer. I typically follow the 3.2.1 rule pretty closely on my data. :-) 

1 Like
6

Yes, it will effectly put cycles on the drive. However no more than just cloning one time anyway. I find my time on set and the appearance of finishing quickly to be worth way more then a few extra cycles on my media.

On a previous shoot the DIT did not comprehend data transfers and checksums on the Samsung T9 drives and this forced me to wait an extra 2 and half hours around set while he cloned my drives. Some people just never listen…  

2 Likes
7

I would say no. SSD lifecycles are WRITE dependant. You can read an SSD infinitely (ignoring bit-rot), it’s writing to an SSD that is considered a ‘cycle’ because thats when each transistor changes its position within the NAND.

Setting in and out points in Pixboom Cine directly from the SSD will not effect its lifecycle. Constantly using cache recording on the spark will however significantly reduce it’s life as you’re constantly writing to the SSD.

I dumped the first SSD to my mac then used Pixboom Cine to set in/out points but it was way too much data and time for real world on-set use.

So I bought 2 x SSD, use Pixboom Cine to set in/out from the SSD and only export my select clips to my working drives.

Hope that helps

1 Like
8

Yes, you are correct in that a ssd write cycle is that, only a write cycle… I was referring to just usage of the pro-card and the little bit of writing it would do when making the in/out points and the H265 proxy that I want with the original media. It stores this In & out inside the PXBC file structure. 

A few things I would love @Young to consider for future updates. 

  1. Can the camera do proxy recording in-camera so we no longer have to export H265 it will just give us a proxy files along side the PBXC files… this is already done in camera same as Red, Arri, even My ZR Nikon does it..

  2. Can the Pixboom Cine software be setup to export too two output locations simultaneously, so that we could export one time to a Main SSD & to a Backup SSD onset. 

  

2 Likes
9

I tested the EF mount (what my camera shipped with) and the single 0.05mm shim that was already on it when I received it was the proper shim.

Unfortunately, all my E mount lenses lack any focus marks, so I’m unable to test the proper shimming of that mount at this time.

1 Like
10

Hi sir, two quick questions:

  1. Your export times (PXBC→ProRes HQ 38 min, →CDNG/H265 55 min): was Cine reading straight off the Pro-card, or from already-offloaded footage on the U34?
  2. If Spark could record ProRes HQ or CDNG in camera, skipping the transcode step entirely — would that actually make your downstream workflow faster? And are there drawbacks or problems we might not be seeing from the bench?

Thank you!

11

For this random export test, I exported 1.53 TB of footage directly from the Pro Card through Pixboom Cine to the U34 SSD.

Ideally, the camera would record a codec that is natively supported by editing software while still preserving all of the RAW sensor data. A format that can be dropped directly into Resolve or other NLEs without conversion would be the gold standard. Until applications like Resolve support PXBC natively, though, we’re working within the current workflow.

One feature I really appreciate in Pixboom Cine is the ability to quickly set In and Out points before exporting. Being able to trim these massive files without first exporting the entire clip is a huge advantage.

That said, I would never turn down the option to have the camera internally record CinemaDNG or ProRes if the hardware is capable of it.

My original request, however, was actually for something different: built-in proxy recording.

The camera would continue recording the primary PXBC RAW file as it does today, but at the same time it would generate a second, low-bitrate H.265 proxy for every clip.

This would provide several benefits:

  • Instant playback on set without needing to open Pixboom Cine.
  • faster browsing when reviewing footage on slower drives.
  • Better long-term archiving. I archive my original PXBC files, but having matching H.265 proxies would let me quickly identify clips without having to download or export the massive RAW files just to see what’s inside.

The PXBC files would remain the high-quality masters, while the H.265 files would simply act as lightweight companions for viewing, organizing, and editing. It’s a workflow that’s become standard on many professional cinema cameras, and I think it would make the Spark much more efficient to use without compromising image quality.

1 Like
12

thanks for confirming the test details — and for the well-thought-out proposal.

I agree with the direction on proxy dual-recording, and it’s now under evaluation. Beyond the three benefits you listed, our internal discussion surfaced one more reason it matters even more for Spark than for a conventional cinema camera:

The ideal rhythm for high-speed work is to keep shooting until you’ve got the moment (or filled the card) before offloading — mid-day offloads are slow and introduce DIT variables, as earlier replies in this thread pointed out. Supporting that rhythm requires instant, scrubbable review on set without pulling the card. RAW is too heavy for smooth in-camera scrubbing, but with a proxy, the playback engine only has to decode a lightweight H.265 — instant scrubbing, out to a big monitor via SDI with UI overlay, or streamed to a phone/iPad over Wi-Fi. And the same proxy files cut the wait at offload time.

On native PXBC support in NLEs: we’re in contact with Blackmagic and Adobe, and we’ll share updates as they come.

We’re currently confirming hardware feasibility for dual-recording with our engineering team — no version commitments yet, but this request is firmly on the table.

2 Likes
13

My guess is that recording proxies at the same time might be a pretty big ask for Spark, given the kind of high-frame-rate data it’s already pushing.

An “after recording” proxy option feels more realistic to me — hit a button, let the camera chew through the files while it’s idle. The catch is that you probably couldn’t shoot during that process, but I could still see that being useful for certain workflows.

2 Likes