<p>Hey Ton, </p>
<p>On Apr 7, 2012 11:35 AM, "Ton Roosendaal" <<a href="mailto:ton@blender.org" target="_blank">ton@blender.org</a>> wrote:<br>
><br>
> Hi Andrew,<br>
><br>
> Can you elaborate what you mean with "OpenColorIO already supports F65" ?<br>
> You mean to convert from/to this colorspace? Or does it read the raw?</p>
<p>It supports the F65 via ACES, as in the Input Device Transform is published and is a format that OCIO supports.</p><p>The birds eye view of what ACES is:</p><p>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. </p>
<p>The definition of an ideal camera from which to define transforms between different devices (and renderers) and that space.</p><p>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. </p>
<p>An Output Display Transform which accounts for the differences between the ideal projector and the specified output device. </p><p>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.</p>
<p>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. </p>
<p>As for reading F65 Raw, only applications that use the Sony SDK (like Davinci Resolve) will support the raw files natively.</p>
<p>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. </p>
<p>> What software is currently using opencolorIO with f65 support?<br>
> Did you try to read in the data we posted and process it?<br><br>Nuke and the rest of the foundry apps. Beta support for After Effects and Blender :)</p><p>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. </p>
<p><br>
> 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.<br><br>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. <br>
<br>
> 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!<br>
> (There seems to be a F65 SDK too, but I didn't check on that yet)</p><p>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. </p>
<p>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. </p>
<p>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. </p>
<p>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. </p><p>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.</p>
<p>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. </p><p>
Talking to Sony would be wonderful, especially if they engage the larger Blender community openly. </p><p>Sincerely,</p><p><br></p><p>Andrew</p><p><br></p><p>[...]<br>
> On 5 Apr, 2012, at 16:51, Andrew Hunter wrote:<br>
><br>
> > Hey Ton and Sebastian,<br>
> ><br>
> > I read the format woes blog post and wanted to give you my suggestions<br>
> > regarding some of your comments.<br>
> ><br>
> > Firstly, DPX is an inappropriate format for digital originated data.<br>
> > It's was designed by Kodak for digital intermediate work, scanning<br>
> > film and finishing on film. Many implementations differ wildly from<br>
> > each other in how they interpret tags like printing density and other<br>
> > things that really only matter if you are making a round trip on film.<br>
> ><br>
> > DPX remains because many people in motion picture post-production are<br>
> > familiar with it and use it as an interchange format, even though<br>
> > better option exist. Inertia is the problem. As part of the Image<br>
> > Interchange Framework, the Acadmy of Motion Picture Arts and Sciences,<br>
> > such a density based specification was created[1].<br>
> ><br>
> > Secondly, mfx is a container format and not proprietary, in fact it's<br>
> > a SMTPE standard (SMPTE 377M). FFMpeg now has good support for the<br>
> > container format<br>
> > for specific codecs.The image data encoded within however is another<br>
> > matter. There was discussion on the OpenImageIO mailing list about<br>
> > supporting mxf as a series of sub-images but no further headway was<br>
> > made on that front[2].<br>
> ><br>
> > Thirdly, your comment regarding linear vs slog on export illustrates<br>
> > that now more than ever proper colour management is essential for the<br>
> > mango project. In an ideal case, it shouldn't matter wither you export<br>
> > as a linear gamma encoded image or an slog encoded image. As I<br>
> > understand it, S-Log just compresses the linear and overbright vales<br>
> > (ie, >1) into a 0-1 range for integer formats.<br>
> ><br>
> > OpenColorIO already supports the F65 via Academy IIF-ACES (Image<br>
> > Interchange Framework - Academy Color Encoding Space) workflow[3].<br>
> > Included in that are the academy approved transforms for the F65. This<br>
> > is an opportunity for Blender to be at the forefront of supporting the<br>
> > latest advances in digital cinematography. Further information on ACES<br>
> > is available from here[4].<br>
> ><br>
> > This would be however, a potentially major overhaul of how Blender<br>
> > views image data internally. For one, finally defining a colour space<br>
> > that we work in internally!<br>
> ><br>
> > Also of particular interest is the explicit definitions of the<br>
> > interaction with CGI renderers and ACES.<br>
> ><br>
> > Sincerely,<br>
> ><br>
> > Andrew Hunter<br>
> ><br>
> ><br>
> > [1] <a href="https://github.com/ampas/aces-dev/blob/master/docs/APD-ADX_v1.1.pdf" target="_blank">https://github.com/ampas/aces-dev/blob/master/docs/APD-ADX_v1.1.pdf</a><br>
> > [2]<a href="https://github.com/OpenImageIO/oiio/issues/86" target="_blank">https://github.com/OpenImageIO/oiio/issues/86</a><br>
> > [3] <a href="https://github.com/imageworks/OpenColorIO-Configs" target="_blank">https://github.com/imageworks/OpenColorIO-Configs</a><br>
> > [4] <a href="https://github.com/ampas/aces-dev/blob/master/docs/ACES_1.0.1.pdf" target="_blank">https://github.com/ampas/aces-dev/blob/master/docs/ACES_1.0.1.pdf</a><br>
> > _______________________________________________<br>
> > Bf-vfx mailing list<br>
> > <a href="mailto:Bf-vfx@blender.org" target="_blank">Bf-vfx@blender.org</a><br>
> > <a href="http://lists.blender.org/mailman/listinfo/bf-vfx" target="_blank">http://lists.blender.org/mailman/listinfo/bf-vfx</a><br>
><br>
> _______________________________________________<br>
> Bf-vfx mailing list<br>
> <a href="mailto:Bf-vfx@blender.org" target="_blank">Bf-vfx@blender.org</a><br>
> <a href="http://lists.blender.org/mailman/listinfo/bf-vfx" target="_blank">http://lists.blender.org/mailman/listinfo/bf-vfx</a><br>
</p>