[Bf-vfx] On Format Woes

Sun Apr 8 06:46:25 CEST 2012

Hey Ton,

On Apr 7, 2012 11:35 AM, "Ton Roosendaal" <ton at blender.org> wrote:
>
> Hi Andrew,
>
> Can you elaborate what you mean with "OpenColorIO already supports F65" ?
> You mean to convert from/to this colorspace?  Or does it read the raw?

It supports the F65 via ACES, as in the Input Device Transform is published
and is a format that OCIO supports.

The birds eye view of what ACES is:

A scene-linear (and scene-linear must be HDR) space with a gamut that
exceeds human vision. Intended not as a directly viewable
(display referred) space but rather one where any mathematical operation
can be carried out without fear of clipping. Also, future proof for
different display technologies.

The definition of an ideal camera from which to define transforms between
different devices (and renderers) and that space.

A Reference Rendering Transform that emulates much of the pleasing elements
of film print stock and defines an ideal projector. This is the
non-reservable transform that introduces toe and shoulder and brings the
data into an LDR range.

An Output Display Transform which accounts for the differences between the
ideal projector and the specified output device.

Perhaps the greatest challenge to supporting ACES in Blender is the need to
excise most of the image loading and color related code. Looking at the
comments on the mango blog about how the author of the DPX code didn't know
that there were more than one log curve that could be used shows the folly
of embeding that transform at that level. If something isn't correct, there
is no way for the user to adjust.

With the current incomplete colour management system, blender's dicotomy of
SRGB or srgb primaries with linear gamma concept would need to be removed.
Also, ACES explicitly requires the support for HDR values (the +- 16 bit
floating point range) internally and only clamps to a 0-1 range using the
RRT.

As for reading F65 Raw, only applications that use the Sony SDK (like
Davinci Resolve) will support the raw files natively.

In, Raw is inappropriate for heavy VFX work, I will elaborate on the
reasons why later in the mail. It is however useful for colour grading.

> What software is currently using opencolorIO with f65 support?
> Did you try to read in the data we posted and process it?

Nuke and the rest of the foundry apps. Beta support for After Effects and
Blender :)

I haven't yet had the chance to play with the samples provided. What I can
say is that a standardized, color managed workflow for the format has been
approved by the Academy and is publicly distributed.

> I'm personally a bit concerned about the image quality itself  - the
amount of noise is disturbingly high. I would expect a nicer signal-noise
ratio.

Raw is raw :) That all the secret sauce that camera manufacturers used to
put in hardware to hid as much of that as possible is gone. Your seeing
what the sensor sees and sometimes that means lots of noise. It would be
worth looking into what processing you might have to do prior to the
exporting of the OpenEXR files.

> I also like to figure out how sony stores a frame in 10 Mbyte, and
exports that to 50 MByte files. We probbly have to do more testing. :) And
talk to sony i guess!
> (There seems to be a F65 SDK too, but I didn't check on that yet)

Firstly, a raw frame is monochromatic (in a sense). With any Bayer mask
sensor, each pixel only has one of the RGB triplet values. The demosaicing
process when developing raw files interpolates the missing values and
creates an image that makes sense in and of itself.

One consequence of this is that the measurable resolution of any bayer
sensor is less that the numerical resolution. For example, the Red One can
shoot a 4096 x 2048 frame but the measurable spacial resolution is closer
to 3.5k Both the F65 (8k) and the Arri Alexa (3.5k) supersample relative to
their output resolution to achieve the listed measurable spacial
resolution, 4k and 1080p respectively.

On top of that, many camera manufacturers apply some form of compression to
the raw frame to further reduce the data rate. Red, for example, uses a
form of wavelette compression similar to jpeg2000. I am not certain if Sony
employes their own compression scheme.

Finally, depending on the format, you may be exporting uncompressed
interpolated data. All of these factor into your observation of the 5x
increase in file size after developing.

As to why I think raw isn't suitable for heavy vfx, the advantages derived
from the above features, namely flexibility and parameters that arn't
baked, can be a hinderance.

As for the SDK, there was initially rumors of Sony open sourcing it or
releasing it under a permissive licence. Unfortunately, this was corrected
by Sony to mean that it would be shared with select 3rd parties.

Talking to Sony would be wonderful, especially if they engage the larger
Blender community openly.

Sincerely,

Andrew

[...]
> On 5 Apr, 2012, at 16:51, Andrew Hunter wrote:
>
> > 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
> > _______________________________________________
> > Bf-vfx mailing list
> > Bf-vfx at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-vfx
>
> _______________________________________________
> Bf-vfx mailing list
> Bf-vfx at blender.org
> http://lists.blender.org/mailman/listinfo/bf-vfx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-vfx/attachments/20120408/106a8a0d/attachment.htm 