Hot Tube – 2014 MacPro Timelapse Processing Review

This post is also available in: German

The new MacPro in a Timelapse processing: A number-chrunching comparison off the mainstream on larger scale time-lapse processing with the new Mac Powerhouse 6-core 2014 Mac Pro vs iMac 27″ vs MacBook Pro 15″ vs Retina MacBook Pro 13″

TIME IS MONEY

This is especially true with large quantity, large volume time-lapse image processing. Rarely do clients pay well for the days and nights at the office, rendering and feeding the machines with render-jobs. Returning back from a week assignment with two or even more terabytes of RAW data and between 50000 to 100000 images is standard with 20+ MP DLSRs. In the face of such landslides or mountains of data, every possibility to reduce render times is more than welcome.

Reading the probably best MacPro test ever I was scratching my head – that shiny piece of US metal is a must-have for sure, but with how many cores?

It was when my trusted Apple Pro Dealer Steiger Electronics in Innsbruck, received a shipment of MacPro’s two weeks ago, that I took the chance to take one of these beasts out for a weekend of number-crunching nerdness.

At the office I couldn’t resist posting an image of the MacPro tube on my desk.

Mac Pro at the Headquarters, or Death Star talking to Apollo 13

Mac Pro at the Headquarters, or Death Star talking to Apollo 13

People commented. Justin, a astronomer friend over in Linz called and said: “I don’t get the hype on the new MacPro. I’ve just bought a new Windows Workstation, half the price, same speed.” I love that guy, he’s as nerdy as me. “Naa”, I said – and the discussion was rolling from there. For me it is simply amazing to see so much workstation power in such a small enclosure. Apple doesn’t care about conventions, they just do it, and it has been a long road to this design. Workstations are often loud, huge, ugly – not the MacPro.

But talking to a die-hard Windows nerd about Mac’s, you could also talk to a Wall. I know that, I’ve been one myself (W-nerd, not the Wall).

WHEN I WENT MAC

To understand why I am so excited about the new MacPro you need to know my IT history. Because fun thing is, Windows and MS-DOS is basically where I come from. But today I use all Macs, and I am more than happy with this decision taken back in 2009 for many reasons.

THE NEW MAC PRO POWERHOUSE AND TIMELAPSE PROCESSING, MORE CORES THE BETTER?

Houston, we need more cores, more cores, more cores. In the case of the MacPro it's 6 cores on one die.

Houston, we need more cores, more cores, more cores. In the case of the MacPro it’s 6 cores on one die.

It requires some very special workflows to mass-process images for quality output timelapse footage, that satisfies even the most demanding client.

Furthermore there is the constant “overwhelming-data-volume” (ODV) factor, as I call it. From the multiple DSLR cameras on set, to the storage cards, to the card readers, to the RAIDS the sequences are stored on, to the rendering software … in time-lapse processing, you immediately realize that all your shiny hardware will forever look slow when it comes to render many hundred or even thousands of images into film sequences.

With time-lapse processing all hardware is constantly pushed to the limit by the overwhelming constant flow of never ending terabytes of time-lapse sequences. At some point in TL processing I usually feel like Bill Murray in Groundhog Day. One sequence finished, next. Sequence finished, next. And so on.

But finally the gray anodized shimmering MacPro tube landed on my desk for testing. I now could clear a question I always wanted to know for time-lapse processing (nobody could tell me up to now):

With time-lapse processing, do more CPU cores shorten rendering times, or do higher clocked GPU’s?

Would the new MacPro be the ultimate solution for time-lapse processing?

One should note, that since the time-lapse movement has gained incredible momentum worldwide over the past years, it seems that editors even at the biggest consumer/prosumer IT Magazines still have no idea of the processing challenges of us time-lapse folks. Probably not even the slightest idea. Process, categorize, level, color grade over 100000 RAW DSLR images over a couple of days? Welcome to my world.

So that’s why there are a gazillion of funky “benchmark” tests out there which are all nice and cool, but in reality have nothing to do with the workflows and processing common to the time-lapse community.

DEFINING AND CREATING A FIRST TIMELAPSE WORKFLOW TEST SET

Testing, testing, testing at one half of my office. Obviously, both the Display of the rMBP and the MacPro were not color calibrated during the test.

Testing, testing, testing at one half of my office. Obviously, both the Display of the rMBP and the MacPro were not color calibrated during the test.

That’s why I did my own test set: Based on carefully selected archive RAW, JPG and TIFF Image sequences of Nikon’s D4, D7000, D600, D800 and Canon’s 6D, I created a set of folders to benchmark the MacPro with 18 tasks against some of my current Hardware – Tasks out of my usual Timelapse real life, proven workflows.

For the test however, I allowed me the luxury to limit all but two folders to 100 images each, simply to keep the test manageable in time (although it took two nights and two days to do this, holy crap).

The two special folders exceeding 100 images were: a time-lapse folder containing 500 Nikon D800 RAW images, and a massive folder of 2982 Canon 6D RAW images – the result of a typical long winter nights’ night-to-day transition in the Dolomites. I have many of these transitions with 3000 or more images, both processed or in my ever long backlog.

The test folder (ca 64 GB total incl. subdirectories) was mirrored to each machine locally. No external drives involved, so that the machines had to rely entirely on their built in drives.

DIFFERENCES IN TIME: SENSOR SIZED DO AFFECT RENDERING TIMES

There is a noticeable difference between processing D4, 6D, D600 files or D800 files. And remember: we talk about 100 images only per folder. Multiply the resulting times in the master table by 10, 20 or 30, then you see why time-lapse cinematographers could use a Cray Titan or the ALMA correlator to speed up things. A friend once even suggested using Amazon’s EC2 Service, but how do I get TB of data there…

Because of the huge files Nikons D800 produces, this DSLR camera (still legendary with it’s high ISO performance) is a true time-lapse processing nightmare. Large sequence-folders with hundreds of D800 images slow down all current hardware during processing.

Even the MacPro, while still fast, sweats a bit here.. But of course D800 images provide for immense reserves when it comes to special projects like the world’s first Nationalpark Hohe Tauern 360° Cinema Project, where in Mid 2013 I had to provide special 138000 x 8000 px D800 imagery (860 GB Data for an Intro and Outro transition sequence). Which drove my by-then hardware at the edges.

Remember the legendary Nikon D3s? In my rare free time I love to process NASA ISS Footage which is all D3s, and 12 MP D3s files are just a blast to render. So much faster!

TRIED AND PROVEN – THE CHRISTOPH MALIN TIMELAPSE PROCESSING WORKFLOW

My time-lapse Workflow has evolved over time and consists of classic Apps for Import, Deflickering, time-lapse Key-framing, Ramping & Leveling, Rendering and Export tasks, mainly

This workflow has proved with many of my clients which demand premium highest quality time-lapse footage. I export in various Apple ProRes formats, which is also 98% of what my clients demand.

Note: For this test, all Sequences were exported as 4K Apple ProRes 4444 Quicktime mov Files. AfterEffects was set to Multiprocessing on all Machines.

TASK FORCE ONE

So I developed various standard tasks for benchmarking the MacPro, and all future systems I get my hands on:

A) Lightroom
Lightroom Import01 Create 1:1 Previews – import hundred D800 RAW images, a common task when importing images to do LRT holy grail processing, creating one-to-ones avoids the annoying Lightroom bug which causes standard sized previews of a imported sequence to only be rendered within the visible grid view and not for the images outside of that view 
02 Export JPG – export hundred D800 RAW images from Lightroom as 100% quality, 300dpi, full size JPGs
B) LRTimelapse
Gunther Wegner's LRTimelapse - the screen time lapsers watch many hours per day.03 Create Exposure Line – when you work your way trough many time-lapse sequences that have been shot with the LRTimelapse holy grail procedure, this is the blue exposure line you are staring at most of the time – here a transition with 500 Nikon D800 RAW images is imported into LRTimelapse the first time. LRT is reading the EXIF data and creates the blue exposure line. From there it goes on with the LRT Workflow initializing and key framing the sequence, switching back and forth with LRT and Lightroom.
C) After Effects
GBDeflicker - get rid of that nasty Aperture or Transition flicker04 RAW Deflicker with GBDeflicker 3.0 – a deflicker run within Adobe After Effects over 100 D600 images
05 Render TIFFs – render 100 Canon 6D tiffs
06 Render JPGs – render 100 Nikon D7000 jpgs
07 Render RAW files – from the AE timeline, render the GBdeflickered sequence created in Task 04
08 Render RAW files – render 100 Nikon D4 RAW images
09 Render RAW files – render 100 Nikon D800 RAW images
10 Render RAW files – render a not yet LRT processed D800 transition consisting of 500 RAW images
11 Render RAW files – render a huge GBTimelapse transition with 2982 Canon 6D RAW files accompanied by XMP files that include some color grading and other information from Lightroom
D) Motion
Motion rendering some JPGs.12 Render TIFFs – same as 05
13 Render JPGs – same as 06
14 Render RAW files – same as 09
15 Render RAW files – same as 08
16 Render RAW files – same as 10
17 Render RAW files – same as 11
E) Bridge
Screenshot of a Retina Macbook 13" on the "Relax your Eyes" screen setting.18 Create Index – create an index of 500 Nikon D800 raw images. I also use these indexes for other operations in Photoshop CC (Frame by frame retouching Satellites, Airplanes etc). The indexes can be exported and do not need to be recreated each time the folder is being looked at, or transferred to a different drive.

ITERATION AND SOME GREAT HARDWARE

Note that for example during LRTimelapse processing one repeatedly iterates task 01, 03 (then with additional key framing and auto ramping) as well as 11 to get to a nice transition time-lapse. So one can multiply the times of the test results.

That said, some words about the benchmark Machines:

MacProMacPro: MY2013 (late), 16GB 1867MHz DDR3 RAM, 256GB PCIe Flash SSD, 3.5 GHz SixCore Intel Xeon E5, AMD FirePro D500 3072 MB, OSX 10.9.1 – the Testmachine.
iMaciMac 27″: MY2012 (late), 32GB 1600MHz DDR3 RAM, 1 TB Fusion Drive, 3.4 GHz Intel Core i7 QuadCore, Nvidia GeForce GTX 680MX 2048 MB, OSX 10.9.1 – a tried and proven workhorse with lots of thermal reserves
Retina MBPrMBP 13″: MY2013 (late), 16GB 1600 MHz DDR3 RAM, 512 GB PCIe Flash SSD, 2.6 GHz Intel Core i5 DualCore, Intel IRIS 1024 MB, OSX 10.9.1 – excellent Retina screen, lightweight, and actually a excellent performer for a dual core Core i5 system, super responsive due to the new PCIe flash SSD
MacBook Pro 15"MBP 15″: MY2012 (mid), 16GB 1600MHz DD3 RAM, OCVertex 256 GB and Samsung 512 GB SSD (Sata6), 2.6 GHz Intel Core i7 QuadCore, Nvidia GeForce GT650M 1024 MB, OSX 10.9.1  - production workhorse (also for hotel rooms). Sped up with a OCVertex SSD (Bootdisk) and a 2nd internal Samsung SSD for processing.

I also do have a 11″ MacBook Air dual boot (Win7, OSX) to control a special GBTimelapse rig, but it would be true masochism to run these benchmarks on that little machine. So I skipped this one.

NUMBER CRUNCHING IN SECONDS AND MINUTES: THE RESULTS

The results are quite interesting, are based on averaged multiple tests and they confirm a couple of things, but also crunch some and there are some surprises. Here’s the monster master table… Do a screenshot and print it out if you like.

Green = better (less time), Red = worse (more time).

2014 MacPro Timelapse Processing Test

2014 MacPro Timelapse Processing Test

Here’s my personal, far from perfect review of some of the findings. I’d be happy about feedback and will answer as possible for given time:

a) Lightroom

Task 01 – Create 1:1 Previews.

Sure, 100 Nikon D800 RW images, that does not sound like much. But even the SixCore MacPro takes over 4 (!) Minutes to get the create 1:1 previews job done. Which is the reason why most Timelapsers love and hate Lightroom. It is such a slow-ass software, when it comes to process large amounts of images. As well as images ALWAYS take around a second to load in full size view if you cycle back and forth during LRtimelapse leveling, no matter if you are on a MacPro or whatnot and regardless if you have rendered 1:1 previews before.

I don’t know at what instance of programming Adobe fails to get this straight, probably at the level of reading out XMP info for each image.

Just check out the processor load of this indexing. Looks like the MacPro is just falling asleep most of the time. Indexing like this should be done in 30 seconds or less, not 4 Minutes+!

Lightroom: SlowAss Software when it comes to importing and preview building

Lightroom: SlowAss Software when it comes to importing and preview building

There is also no option in Lightroom to adjust any multicore or GPU settings. By the way, exporting images is also very slow, as you can see in the table. Maybe Adobe will improve this in one of the next releases – never give up hope.

b) LRTimelapse

Task 03 – Create an exposure line out of EXIF data of a given folder.

Gunther Wegner has done the incredible job of enabling the timelapse community to do day-to-night-to-day transitions (if they get the holy-grail method right on site and in processing. You can learn that here).

Before LRTimelapse, it was a painful task for a handful men on the planet to frame-by-frame deflicker transitions, including amongst others Gunther, me, my TWAN colleague Bernd Pröschold, considered to be  the inventor of the Holy Grail Timelapse method since 2002.

So, while working with LRTimelapse, unsurprisingly the MacPro again needs the least time to read the Exif data, and display it in a blue exposure line thanks to it’s powerful PCIe SSD. Here is how it looks like with the Retina MacBook Pro.

LRTimelapse initial XMP readout with a rMBP 13"

LRTimelapse initial XMP readout with a rMBP 13″

LRTimelapse initial XMP readout with a 6-Core MacPro

LRTimelapse initial XMP readout with a 6-Core MacPro

This EXIF readout and later initializing can never be fast enough. It’s best to have a PCIe RAID for this, or at least a decent PCIe SSD – it speeds up the process especially when you work your way trough many sequences during a production week.

Worth to note: Once the iMac had loaded a to-be-processed folder into the SSD part of it’s fusion drive, the machine also got much faster at processing EXIF (for example from 00:01:20 down to 30 secs). Note that in the near future, I will expand the test for LRTimelapse’s new Video export functions (see below).

c) After Effects

Task 04 to 10 – simply just render as fast as possible.

The Tube is getting red hot ;) MacPro on all six cores, hyper threading...

The Tube is getting red hot ;) MacPro on all six cores, hyper threading…

Probably many hours are spent with Timelapse creation worldwide on AfterEffects, although Gunther is working hard and successful on changing this (since v3.2 you can also use LRTimelapse to render even ProRes vids directly. I will test this exciting feature during the coming up AstroMaster 2014 event). According to Gunther this is currently also the only way to convince LR5 to really use multicore processing. Aha.

However, it was interesting to explore which machine did well with this proven Adobe sequencer.

No, it's not a waste bin. It is the next step in workstation - and a no frills "we can do it" design attitude.

No, it’s not a waste bin. It is the next step in workstation – and a no frills “we can do it” design attitude.

Interestingly the iMac rendered JPGs and the ultra large 6D folder with 2982 images faster than the MacPro, repeatedly. Seems like for this, the maximum turbo clock speed is better than more cores. I have no explanation other than Anandtechs Turbo Behavior explanation of his outstanding MacPro Review, which shows nicely when a current 4, 6, 8 or 12 Core tops out with TurboBoost according to the cores used.

As for the “older” iMac with Fusion Drive, it is however again critical, that the sequence is within the SSD part of the drive. If not, the iMac has to work on the HDD part of the drive, and then performance goes down quite a bit. You can then hear the machine messing around with the Harddisk.

While rendering, all these machines usually get quite hot, and in case of the 15″ MacBook Pro, even quite loud. Rendering at Hotel rooms over night always gives for a bad sleep with the 15″ MBP fans roaring.

Outstanding in this regards is the super thin, super silent iMac as well as the MacPro.

The tested iMac has large thermal reserves, while the 15″ MacBook Pro is cooking eggs.

I was curious about the MacPro. How hot is the air coming out of the top hole when all CPU cores and GPU is glowing red hot?

Holding a hand above the MacPro tube then feels like holding a hand into a slow hair dryer airflow (without the dryer sound of cours), but it never gets too hot (no knowledge yet how this is with a 12core on full load). Conclusion: For winter when my office gets colder, while rendering I’d place the Mac Pro below my feet as a nice feet warmer :) Probably not the intended design use, but it’s good at that, too.

15" MacBook Pro rendering D4 RAW footage into 4K.

15″ MacBook Pro rendering D4 RAW footage into 4K.

iMac rendering D800 footage, still lot's of thermal headroom.

iMac rendering D800 footage, still lot’s of thermal headroom.

d) Apple Motion

Task 12 to 17 – render even faster as possible

Motion shares the same great render engine with Final Cut Pro X and Compressor. Says Anandtech here:

“Final Cut Pro’s [Ad. - true for Motion too] division of labor between CPU and GPUs exemplifies what you’ll need to see happen across the board if you want big performance gains going forward. If you’re not bound by storage performance and want more than double digit increases in performance, your applications will have to take advantage of GPU computing to get significant speedups. There are some exceptions [...], but for the most part this heterogeneous approach is what needs to happen. What we’ve seen from FCP shows us that the solution won’t come in the form of CPU performance no longer mattering and GPU performance being all we care about. A huge portion of my workflow in Final Cut Pro is still CPU bound, the GPU is used to accelerate certain components within the application. You need the best of both to build good, high performance systems going forward.”

And high performance rendering is exactly what Motion delivers. One thing is clear after this test: if you need to render

  • TIFFs
  • JPGs
  • RAW

out for quick previews during a project, look no further. Motion is super fast, almost twice as AE, and distributes the workload best between GPU and CPU. And it doesn’t cost the world: With EUR 44,99 this Apple Pro App is really well priced.

Motion rendering a large 6D RAW sequence of nearly 3000 images in 16 minutes on a MacPro vs 01:42 on AE by ignoring the XMPs.

Motion rendering a large 6D RAW sequence of nearly 3000 images in 16 minutes on a MacPro vs 01:42 on AE by ignoring the XMPs.

But be warned. Speed in this case comes with some drawbacks with timelapse processing, that come from Motion’s history as a 3D render tool:

  1. Motion ignores XMPs, it unfortunately can’t read them since many moons
  2. It also can’t map (single pixel size) over-saturated pixels of your DSLR footage, which in turn AfterEffects does map.

This means: For example on RAW rendered Motion footage of the above Dolomites set seen in the screenshot, red, blue, green and white Hot Pixels of the 6D pop up like little flashes during playback. This is when you realize how much Hot-pixels our DSLRs still create during a long imaging night at High ISO. Again, no prob for a review, but in no way suitable for client footage.

Oh, and before I forget it: Maybe Apple finally get’s the annoying “Adjust to Composition mess” fixed in a future release.

e) Adobe Bridge

Task 18 – Create Index for fast preview of images in folder.

Interestingly, the iMac was a bit fighting with Bridge. Contrary to the MBP 15″, it doesn’t like the indexing task well. Fastest of course again the MacPro. But over one and a half Minutes of indexing for 500 Images is still too slow, even on the top machine. Adobe needs to get bridge way faster on this topic. SSD’s help, of course.

screenshots_rmbp001

FINAL VERDICT

You guess it. Of course I am impressed with the SixCore Mac Pro on Time-lapse processing. Who wouldn’t.

But I need to get my hands on a 8-core MacPro to test as well as a 12-core. For the time being, the medium price 6-core tested, with it’s outstanding performance (not overpriced, too) is the choice for time-lapse rendering if you already own Macs or plan to do so to expand rendering capabilities.

BTW, I wouldn’t be surprised to see some cool MacPro Bags popping up soon (I would however order a Pelicase for that). Why? In fact the MacPro is very portable due to it’s small size and sturdy Aluminum Housing. Provided that there is a display at the location to plug it into, I would not mind taking a MacPro to a production week in Europe or the Canary Islands for rendering at the Hotel if the project demands it.

Apple, here’s an Idea: what about enabling future Macbook Pro’s to receive the MacPro’s output video signal. Via a screen switcher, the user could then use both the MacPro and the MacBook Pro for rendering on the job.

Creating all the sequences (here with a Nexus 7 and DSLRDashboard controlling a D800) that feed a MacPro.

Creating all the sequences (here with a Nexus 7 and DSLRDashboard controlling a D800) that feed a MacPro.

As for the hardware of the tested MacPro here are some recommendations:

First: Do NOT order it with 256 GB SSD, take the 512 GB instead, unless you have Thunderbolt SSD storage lurking around your desk.

On the test machine there was never enough space, only around 110 GB left (and I threw off some unnecessary apps of that Demo). Which was filled up pretty soon with just one 64 GB sequence as well as AfterEffects render cache.

Second: order the MacPro with the minimum amount of RAM ex factory and exchange this minimum RAM for at least 32 GB of certified apple RAM with your Apple Pro Dealer. It is much cheaper to do so, and the MacPro as well as AfterEffects and all other Apps certainly benefit from RAM to breathe.

Third: Although buying via the Apple Store is always a great experience, buy the MacPro at your local Apple Pro Dealer. They can always do a better price than the Apple Store including all CTO options.

Milky Way sinks into the Atlantic. The faint light of Venus is reflected on the Ocean. Timeless Moments that were enjoyed during the AstroMaster.

That’s why we do time-lapse: Milky Way sinks into the Atlantic. The faint light of Venus is reflected on the Ocean. Timeless Moments that were enjoyed during the AstroMaster.

Regarding my other Test machinery: Interestingly a current maxed out iMac will beat the cheapest 4-core MacPro on certain aspects and it comes with a excellent 27″ screen, but on rendering it will not beat the 6-core on most tasks.

Worth to note is, that the current MY2013/14 iMacs gain a lot of speed due to their new PCIe SSD flash storage. It really pushes iMac’s again to be excellent all-in-one render machines.

Last but not least: Some may think after reading the table, that the Retina Macbook Pro 13″ tested is slow. It is actually NOT. It is a very fast machine. The PCIe SSD speed can be felt so much all the time while working with it.

My MacBook Pro 15″ retrofitted with SATA6 SSD’s is by far not slow at all, but the rMBP really feels amazingly faster just by how Apps open up or finder operations are executed. I didn’t expect this to be so noticeable.

However, with “only” two cores this 13″ rMBP is of course a bit “underpowered” against Quad Core i7′s when it comes to true rendering force. But that is not the point: The 13″ MacBook Pro is lightweight, super silent, has a super crisp display that makes photo editing a new experience, and rarely (as with the 15″ MacbookPro) you can hear it’s fan going on even while rendering. Very Hotel, Inflight or Train friendly machine.

If you want to use a 13″ rMBP to render, feed it a huge job and let it crunch over night. It will do that job perfectly, like every Mac.

What a pity I had to return the MacPro. It is an outstanding, silent and powerful machine in the currently smallest possible form factor – the next, major step in Workstations. And a welcome turbo boost for Time-lapse processing.

Now I need to call Justin to discuss this test ;)

Cheers
Christoph Malin

PS: Here’s a nice blog post about the test over at Matthias Uhlig’s Kids-of-all-ages Blog

6 thoughts on “Hot Tube – 2014 MacPro Timelapse Processing Review

  1. Pingback: Test MacPro 2014: Motion’s “Adjust to Composition mess” | Christophmalin.com

  2. I will love to hear what the superpowered Justin machine is capable of. With 2 12 cores xeons and 64 gb of ram…

  3. Pingback: Apple und Birnen - Mac Pro Vergleichstest von Christoph Malin | Kids Of All Ages Blog

  4. “Apple, here’s an Idea: what about enabling future Macbook Pro’s to receive the MacPro’s output video signal. Via a screen switcher, the user could then use both the MacPro and the MacBook Pro for rendering on the job.”

    As far as I know that’s already supported through target display mode. Read this: http://support.apple.com/kb/PH14264?viewlocale=en_US&locale=en_US

    Or does it only work with an iMac?
    Kind regards,

    Jules

      • That’s a bummer. But then it should be a relatively easy to add to future generations of MacBooks or perhaps even unlock support for it on the current generation by means of a firmware update. (Although I don’t see that happening unless the public demand would be very strong for this feature).

Leave a Reply