Tag Archives: news

ProEXR creator comes up with MOX, new open file format for movie production

Brendan Bolles launched an IndieGoGo campaign to sponsor creating MOX — a new open source movie format for video and film production. But the industry seems split over this idea.

Why another file format?

In Brendan’s opinion, every already existing movie file format falls short for at least one reason, either being not cross-platform, or being patent-encumbered, or not supporting higher bit depths and lossless compression. E.g. both Apple ProRes and QuickTime would work very well as intermediate file formats, but neither are open or cross-platform.

What is MOX, exactly?

The idea with MOX is to take an already existing MXF container and strip it down to standardize codecs and metadata to avoid vendor-specific “dialects”. The next stage would be creating plugins for popular authoring applications to use this file format.

The original proposal includes Dirac, OpenEXR, DPX, PNG, and JPEG, so that both video and VFX target groups of users would be covered. Audio codecs are supposed to be FLAC, Opus, and raw PCM.

The reception of the project

So far we’ve seen both positive and negative responses regarding the idea. At this point, some background information might be helpful.

To begin with, people who started this are not exactly some random folks on the Internet.

Brendan Bolles started out as matchmover in Jeepers Creepers II, then worked as digital artist in Sin City and Sky Captain and the World of Tomorrow, then he did compositing in Grindhouse and Planet Terror.

He also has substantial track record of creating plugins for proprietary software to support open standards: from ProEXR for Adobe Photoshop and After Effects, to AdobeWebM project which brings WebM and WebP support to Premiere and Photoshop respectively, to AdobeOgg which adds Ogg Vorbis and Ogg Theora support to Premiere.

In other words, Brendan has a lot of hands-on experience with various containers and codecs as both user and developer.

His initiative was praised by many people, including Stu Maschwitz, creator of Magic Bullet Looks and, as it happens, Brendan’s former employer at The Orphanage studio:

Imagine of ProRes wasn’t controlled by Apple. Imagine a movie file that played back with the correct gamma on every computer. Imagine multi-channel, high-bit-depth movie files for VFX collaboration. Imagine a camera that shoots both a lightly-compressed, ungraded log digital negative and a compressed edit proxy with the on-set LUT baked in—both in the same file.

Most of the criticism so far boils down to these several points:

1. Completing the spec might take too much time. At this point, MOX is more of an idea at the stage of research. It’s also not the first project of this kind. For instance, MXF Application Specification (AS-07) has not yet been completed after 5 years of work and is currently at the draft review stage. Since there will be public discussion of MOX, drafting and completing the spec might take longer than expected.

2. Getting MOX accepted by the industry. Pretty much every skeptic recalled this undying XKCD classic:

Standards comic at XKCD

On a similar note, one of the users of The Foundry’s forum noted:

We use MXF where I work and then convert to .mov and .mpg for delivery. If it were possible to use MOX from start to finish, that’d be nice, but I don’t see it happening. We are using Leightronix UltraNEXUS-SDI for our system and it’s pretty strict on file format. Getting those systems to use a format will be a huge undertaking. The industry standard for broadcast is mpeg and even though I don’t like mpeg, that’s what it is. This would be good to pass around while working on the project, but not for final delivery.

This part of the skepticism is partially debunked by the fact that, as noted above, Brendan has a lot of experience writing plugins for popular authoring software. For instance, ProEXR has quite a lot of users in the industry, but it’s an implementation of a pre-existing file format. How many users Brendan’s other projects have is another story.

3. Not using Matroska. A lot of critics point out that Matroska is already open, supported by many tools and feature-wise should just fit the bill, hence no need to come up with another standard.

First of all, Brendan specifically says:

I am really trying to avoid creating any new standards here. Technically, MOX will be what is referred to as an “MXF Application Specification”. Just like WebM is simply a re-branding of Matroska + VP8/9 + Opus/Vorbis, MOX will just be MXF + specific codecs + metadata conventions.

Secondly, Brendan has a few technical issues with Matroska:

Matroska has a few limitations that make it unsuitable. A really big one is the way it does timing, using integer timestamps with a fixed timebase. This is totally fine for a playback format, but you can’t seek audio precisely enough for video editing. In my WebM plug-in, I deal with this by scanning all the audio in the file and mapping Matroska’s course timestamps to the actual audio sample numbers.

I asked the creator of Ogg about his container, but he said it wasn’t well-suited either, for different reasons. MXF is the one container (that I know of!) that was created for production purposes, so it seems like a natural choice. It does a whole bunch of things that won’t be part of the MOX spec, but it’s nice to know they could be adopted.

4. The initial choice of codecs makes little sense. Some critics pointed out that Dirac as the only video codec proposed by Brendan is not exactly suitable:

  • not many apps support it and some might have problems supporting lossless encoding/decoding;
  • not good enough performance, compression worse than the one in J2K.

One substitution that was suggested is FFV1 which performs ca. 10 times faster than Dirac and compresses better. Since it’s supported in FFmpeg/LibAV (where it was conceived), it’s widely supported even without some vendors even knowing it.

To this Brendan replies:

I am not completely married to any of the specifics mentioned in the campaign. If it turns out something doesn’t work the way we expect or a better solution is found, then I will switch to that solution and any standard I have written up will have to be re-written.

I am interested in any video codec that is open source, patent-free, and has something to offer that the others don’t. My list of codecs is not set in stone. I certainly intend to try out FFV1, ImageZero, and others.

It is even conceivable that there would be a problem with the MXF container and we would have to use another, which would void any spec we had written beforehand. I don’t anticipate this happening, but that is why I don’t want to devote time to a spec before the project is funded and software is being written.

Some concerns have also been voiced that it takes four file formats — EXR, DPX, PNG, and JPEG — to cover lossless and lossy use cases with all bit depths options.

5. Overdesigned metadata support. Among technical requirements Brendan lists color space metadata in form of ICC profiles, named color spaces like Rec. 709, gamma & chromaticity values, OpenColorIO configuration information, and embedded LUTs.

There is a notion in part of the community that stills should be manipulated in a scene referred model, not display referred. On top of that. some people pointed out that too many types of metadata would likely cause conversion issues, and some of the proposed types might not make sense in movie production context.

Brendan, however, replies:

We’re planning to support ICC profiles, because that’s what Adobe uses. I may agree that it would be better if they didn’t, but if someone renders a movie out of After Effects, it would be good to pass along the same ICC profile that AE spits out, not losing anything.

In the OpenEXR plug-in for After Effects I store the ICC profile but also use it to generate chromaticities, which are the standard EXR way to do color.

My philosophy is to try to embed any metadata that may come along and then do my best to translate it to different programs.

Support in free software

Among deliverables of the project there should be a open source library that could be used to create and open MOX files. There is, however, one single problem with that when it comes to free/libre NLE apps: their interoperability is close to zero anyway.

No free/libre software supports AAF. The only existing free non-linear video editor that appears to read MXF files is Pitivi, and the muxer is yet to be ported, so there is no writing of MXF files in Pitivi yet. Even such a simplistic file format as EDL is only supported in Cinelerra and Blender’s VSE. Feature requests for that have been sitting in respective bug trackers for years with not much to hope for.

So, if you can pardon this strike of alarmism, should MOX fly, it’s going to take an unpredictable amount of time till free/libre video editors become interoperable between each other and commercial apps. Unless, of course, the final spec of MOX will be so amazing that plans and roadmaps all around will be adjusted to make some place for it.

Currently the MOX fundraiser is 70% done, with 20 days to go. Further research by Brendan Bolles and actual design of the MOX specification will go in effect once the project is 100% funded. If you are iinterested in more details about the project, we suggest reading an in-depth interview with Brendan taken by Mark Christiansen for Pro Video Coalition.

Read More

Turn your Android tablet into color fidelity multitool with ArgyllPRO ColorMeter

Graeme Gill has just announced immediate availability of ArgyllPRO ColorMeter, a commercial Android app that allows using colorimeters and spectrophotometers directly via the USB on-the-go port.

What is it good for? Graeme lists a number of possible use cases:

Use your X-Rite Eye-One Display Pro to make accurate measurements of ambient, spot or display light levels and color temperature for Photography or Lighting design. Measure and calibrate Televisions and Projectors using a Klein K10-A. Check print samples using your ColorMunki spectrometer or Eye-One Pro 2 in the field. Obtain accurate sample measurements to incorporate into your documents or web pages, and find the closest matching color swatch instantly. Check movie theater certification using a JETI specbos 1211 — ArgyllPRO ColorMeter has you covered.

If you’ve been wondering, how Graeme is supposed to get compensation for his passionate professional-level work on free/libre color management tools for the past decade, this might just be it: a commercial app for the Android platform where there is virtually no competition between color management related tools.

Ambient lighting measurement

Here’s a quick reality check:

Spectropocket is a lot like ColorMeter (or vice versa), but you are paying for additional hardware ($1,299 for the whole solution), and measurement devices support is limited to i1Pro, i1Pro 2, and ColorMunki Design.

X-Rite ColorTRUE doesn’t connect to the actual device and focuses primarily on adjusting display output for particular tasks at hand (like softproofing) and lighting conditions using desktop/laptop-generated ICC profiles. It’s also limited to ColorMunki Display and i1Display Pro devices.

Datacolor SpyderGALLERY, in return, seems to be an app whose developers were of two minds what they were going to do with it. This is both a calibration/profiling app, hardcoded to use Spyder 4 colorimeters only, and a photo gallery viewer with a CMS on/off switch (the same applies to X-Rite ColorTRUE, really).

As you can see, ColorTRUE/SpyderGALLERY vs. ColorMeter/Spectropcket are a bit like apples and oranges. And between the four of them only ColorMeter is truly omnivore in terms of vendors and models supported.

Spot reflectance measurement

It took Graeme two years to complete and roll out the first public release, given that it was a one-person project, as well as all the work involved with supporting ArgyllCMS and writing new features for it, such as video profiling & 3D LUT creation support. Developing for an entirely new platform wasn’t easy either. Graeme shares:

I had instruments working two weeks after I got my Nexus 7, but the learning curve was fierce — it was 9 months before I felt I knew my way around the UI code to some degree, and I needed to put enough into the app to at least show the potential of it. Inventing pinch-zoom graphs with automatically scaling non-linear axe labels takes time.

The Android API is both good/easy & hard/buggy. Do it in just the right way, and everything is easy. It mostly works as advertised. Stray off that path, and you’re grepping through the Android source code, desperately trying to figure if it’s your misunderstanding or bug, or whether it’s a bug in Android. Stackoverflow is the absolutely vital resource in all that.

Android is missing things you would think should be built in, like gesture sortable lists, or automatic feature scaling with screen size, so I had to invent my own code to do this sort of thing.

It’s important to note that the will be no iOS version for those of us with iPads, because Apple doesn’t make it easy to access USB devices. Over to Graeme again:

I suspect [X-Rite & DataColor] are a bit stumped by iOS not having USB. They can’t bring themselves to give up on 60% of the USA market. X-Rite is big enough to solve the problem with brute force — either fit new instruments with WiFi/Blue tooth, or make a USB host adapter and join Apples HW development program. They may well be working on such a thing, so I was keen to beat them to a release.

At AU$110, the app is not exactly cheap, although the unique combination of features and platform they are available on might just make up for the price to you. And there is a demo version of the app that is “fully functional, except that it shows a sequence of 8 pre-determined readings instead of the true measurement values from your instrument”.

You might have already seen a similar revenue model with e.g. LibRaw which is the base for RawDigger and FastRawViewer — all three projects being made by LibRaw LLC. This keeps the company afloat (although, frankly, both LibRaw LLC developers have other successful businesses), and GPL makes it possible for projects like digiKam to provide reliable support for RAW files.

It’s going to be interesting to see how getting into the mobile development business with ArgyllPRO ColorMeter will work for Graeme who’s among very few people responsible for making color management on Linux just work.

Read More