[Bf-committers] On Format Woes

[Andrew Hunter]

Hey Ton and Sebastian,

I read the format woes blog post and wanted to give you my suggestions
regarding some of your comments.

Firstly, DPX is an inappropriate format for digital originated data.
It's was designed by Kodak for digital intermediate work, scanning
film and finishing on film. Many implementations differ wildly from
each other in how they interpret tags like printing density and other
things that really only matter if you are making a round trip on film.

DPX remains because many people in motion picture post-production are
familiar with it and use it as an interchange format, even though
better option exist. Inertia is the problem. As part of the Image
Interchange Framework, the Acadmy of Motion Picture Arts and Sciences,
such a density based specification was created[1].

Secondly, mfx is a container format and not proprietary, in fact it's
a SMTPE standard (SMPTE 377M). FFMpeg now has good support for the
container format
for specific codecs.The image data encoded within however is another
matter. There was discussion on the OpenImageIO mailing list about
supporting mxf as a series of sub-images but no further headway was
made on that front[2].

Thirdly, your comment regarding linear vs slog on export illustrates
that now more than ever proper colour management is essential for the
mango project. In an ideal case, it shouldn't matter wither you export
as a linear gamma encoded image or an slog encoded image. As I
understand it, S-Log just compresses the linear and overbright vales
(ie, >1) into a 0-1 range for integer formats.

OpenColorIO already supports the F65 via Academy IIF-ACES (Image
Interchange Framework - Academy Color Encoding Space) workflow[3].
Included in that are the academy approved transforms for the F65. This
is an opportunity for Blender to be at the forefront of supporting the
latest advances in digital cinematography. Further information on ACES
is available from here[4].

This would be however, a potentially major overhaul of how Blender
views image data internally. For one, finally defining a colour space
that we work in internally!

Also of particular interest is the explicit definitions of the
interaction with CGI renderers and ACES.

Sincerely,

Andrew Hunter


[1] https://github.com/ampas/aces-dev/blob/master/docs/APD-ADX_v1.1.pdf
[2]https://github.com/OpenImageIO/oiio/issues/86
[3] https://github.com/imageworks/OpenColorIO-Configs
[4] https://github.com/ampas/aces-dev/blob/master/docs/ACES_1.0.1.pdf