It’s the hardware systems implementation.
Most multi-projector fulldome systems are uniquely configured, customized for the theater in which they’re installed. Like snowflakes, no two are exactly alike. This means the slices of the fisheye frames differ from theater to theater, so a custom encode has to be made for practically every site.
The data for the projector configuration — the lens, the pixel dimensions, how and where they’re pointed, etc. — is stored in an .INI file of some kind. Now if there was one standard “INI” file that everyone used, and a encoder/slicer program everyone used that could read the data and output the channels for each projector… then we could use it and ship our movies pre-sliced to the customer. They would simply copy the movies to the various video channels, and load their play script to run them all.
But there isn’t any standard INI file format, nor is there a generic encoder/slicer program.
Actually, the attitudes expressed to me by the various system vendors I’m talking about (and there are really only about 4 or 5 of them) are remarkably similar. They boil down to: “We’ve developed our own best way of doing things that are optimized for our systems. We only support movies that were encoded using our software. We don’t support anything we didn’t provide.”
Indeed, we had a customer relate how their vendor had warned them if they installed anything else on their system — movies or otherwise — it would invalidate their warranty.
It gets more complex…
Complicating things further — slicing is done differently depending on the vendor. Most systems take the fulldome circle and slice it into various “pie-wedge” shapes, applying the dome curvature correction parameters from the INI file, and output the MPGs for the various projector channels. But one system slices the circle into rectangles first, then feeds those to the projectors, then applies the warping parameters to each of the projectors in hardware.
Each of the hardware vendors has developed their own proprietary slicing methods, and most tend to keep these to themselves, so the encoders are not generally available to anyone else to use. And most prefer to keep it that way, ostensibly for their own quality assurance purposes. I suppose at some technical level, this is understandable. Of course, if their customer is locked into a vendor’s proprietary system, they’ll have to keep returning for movies to the vendor. That’s one way to try to ensure repeat business.
In any event, every hardware vendor’s proprietary encoder requires dome masters and audio files as the source material. Therefore, producers have to provide their originals to the hardware vendor, to make the movies that only they can make.
Naturally, the same quality control and security concerns we have about end-users apply here too. Sure, we have signed distributor agreements with the hardware vendors which say they’re not allowed to send dome masters to customers. Yet we’ve had experiences when vendors have tried to do exactly that — send our dome masters to an overseas location to be sliced at a customer’s site. When confronted, the response wasn’t quite “What, don’t you trust us?” — it was instead, “What, don’t you want the sale?” We were stunned; a disrespect for our intellectual property isn’t part of the agreements we sign with those who represent our content.
And, some vendors don’t want to spend their time making custom encodes for theater sites. They simply pass the job on to their customers. They provide their proprietary encoders, with the site’s configuration hard-coded into the software, and provide instructions on how to use it. Of course, this still requires the dome masters be made available to the customer site, and the same concerns above about quality and security are still extant.
Page 1 – Masters of the Dome Masters
Page 2 – But…
Page 3 – The Reasons for Not Shipping Frames
Page 4 – It’s the hardware
Page 5 – A Sense of Entitlement
Page 6 – Don’t panic!
Subscribe to our blog!