Do we really need another raw format? intoPIX thinks so, and it could be one of the best ones yet, if it can navigate the many obstacles to mass adoption.
We’re used to evaluating video codecs based on their coding efficiency: how much picture quality we get for every unit filesize. In most situations, though, there’s another factor that weighs quite heavily: how much work the codec takes to encode or decode, which is an issue the JPEG-XS codec was designed to address. A while ago, developer intoPIX implemented JPEG-XS as Tico, for tiny codec, which was intended to be of “low complexity,” and it is; it’s about as good as JPEG-2000 while being considerably easier to implement. Now, the company has developed Tico to handle raw material, too.
OK, sure, once we have a codec capable of handling at least one black and white picture, it’s not that difficult to imagine that same codec storing three such pictures and handling RGB or component colour, or raw data. Making the best of any of these approaches requires some careful preprocessing, particularly gamma encoding, and even some formats which have been called “raw” actually involve quite a lot of in-camera number crunching to prepare the data for compression. That’s presumably part of the work that intoPIX has done to make Tico Raw a reality, although as with so many technologies, the value is often not so much in the specifics of the technology, but the degree to which it can be standardised.
Because, of course, we already have raw formats: entirely too many raw formats, to be honest, where “too many” in terms of multiple conflicting standards is anything more than one. Few of them do substantially more than Cineform did a long time ago, and the barriers to adoption requires at least two entities to adopt the new standard – the camera manufacturer, and the postproduction software distributor, even if we only want to be able to cut the footage from exactly one camera on exactly one NLE. Into this leaps Tico Raw, and while it certainly has some interesting characteristics, it’ll have to scramble up the side of a veritable Olympus Mons of politics before we see the logo on the side of a camera.
To some extent, the company doesn’t seem likely to be bothered by this. There is some talk of Tico Raw being used as a camera codec, but much of the site talks about applying it to situations such as IP video networking. Much as the highest end implementations of this are intent on sending everythin uncompressed, even ten-gigabit ethernet connections start to wither under the demands of sending 4K (or higher) pictures at 60 (or higher) frames per second. Often, IP video networking ends up being more expensive than the systems it was designed to replace. Even if the flexibility and configurability are worth it, that wasn’t really the basis on which the idea of replacing SDI with Ethernet was promoted. Compression to solve that doesn’t have to have the highest coding efficiency ever, but it does have to be fast.
Tico certainly is fast; the delay can be down to thirty-two video lines of latency, something which is fundamentally impossible with many codecs, since they consider larger areas of the image than that all at once. It’s also built with the intention that a realtime implementation in a camera (or IP encoder) shouldn’t consume more than a certain amount of a programmable logic device, and that software encoders and decoders for desktop computers (and phones, presumably) should be able to make best use of modern multi-core CPUs and GPUs with thousands of subprocessors. Multi-core work, again, is something that causes problems with a lot of incumbent codecs, which don’t split out into multiple simultaneous jobs very well, often because things can only be done in a specific order.
In short, it’d probably be great to see Tico Raw in cameras. It’s a wavelet codec, just like Redcode and Cinform. Graphs in the white papers suggest it’s about as good as JPEG-2000 in many situations, which is pretty impressive given how much hard work goes into compressing JPEG-2000. JPEG-2000 has been the basis for camera codecs in the past. There’s a chance Tico might help reduce power consumption somewhat, which is something that some manufacturers have been rather slow to recognise as a legitimate concern. It’s possible that it wouldn’t reduce power consumption much, to be fair, since the codec is not in operation when the camera is not recording, and even in the fastest-paced documentary situations the camera is only recording a minority of the time. Still, with cameras frequently draining batteries dry in much less than an hour, any improvement is welcome.
In the end, as we’ve said, the idea of a third-party raw codec actually achieving much adoption in acquisition seems like a very large leap. It’d be great for that prediction to be wrong; it’d be wonderful to have unified raw, almost regardless of which raw that ends up being, and Tico would be a very realistic contender, but right now a realistic fear is that it will simply muddy some already very muddy waters. About the most positive spin that can be put on something like this is that a disinterested third party, an organisation not involved in cameras or postproduction gear, might stand more of a chance than anyone else. We’ll see.