Comparing Different ACES Input Device Transforms (Idts) for the RED Scarlet-X Camera
Total Page:16
File Type:pdf, Size:1020Kb
https://doi.org/10.2352/ISSN.2470-1173.2018.06.MOBMU-139 © 2018, Society for Imaging Science and Technology Comparing different ACES Input Device Transforms (IDTs) for the RED Scarlet-X Camera Eberhard Hasche, Oliver Karaschewski, Reiner Creutzburg, Brandenburg University of Applied Sciences; Brandenburg a.d. Havel . Brandenburg/Germany Email: [email protected] , [email protected], [email protected] Abstract One important part of the ACES system is the Input Device The RED film cameras are important for professional film Transform (IDT). productions. Therefore, the Academy of Motion Picture Arts and Science (AMPAS) inserted to their new Input Device Transforms In the first step of the ACES system the IDT converts an (IDTs) in ACES 1.0.3 among others a couple of conversions from image from a certain source, mainly a film camera but also RED color spaces. These transforms are intended to establish a Computer Graphic (CG) renderings to a unified color space. To linear relationship of the recorded pixel color to the original light ensure that all converted images are looking the same, all transfer of the scene. To achieve this goal the IDTs are applied to the functions (gamma, log) and all picture renderings applied by the different RED color spaces, which are provided by the camera manufacture company have to be removed. After applying the IDT manufacturer. This results in a linearization of the recorded image to all input images, they can be combined theoretically without colors. additional color correction – a main goal in modern compositing Following this concept the conversion should render For this reason the built-in functionality of an IDT has to comparable results for each color space with an acceptable ensure that the resulted image maintains a linear relationship to the deviation from the original light of the scene. In color science color light of the scene. To maintain a fixed relationship between scene space conversions need a documentation of the three main colors and encoded RGB values ACES created a Reference Input components of the individual color spaces: primaries, whitepoint Capture Device (RICD) which can distinguish and record all visible and transfer function. For the RED colorspaces in question these colors and an extraordinary luminance range way beyond parameters are only available for the REDWideGamutRGB color “contemporary or anticipated physical cameras” [1]. It makes sure space, whereas the other color spaces are not documented. For this by applying an Input Device Transform (IDT) that the camera reason the behavior of the color conversion can only be tested, but recording a physical scene and a virtual CG camera rendering a not calculated. virtual scene are converting the resulting image data into the ACES RGB color space correctly. That’s why an IDT is not a simple color The goal of this paper is to compare the results of the color space conversion device and an accurate color representation is an conversions of the main RED color spaces: REDWideGamutRGB, important task. REDcolor4 and REDdragoncolor2. Additionally a conversion to the for television usage important color space REC2020 (ITU-R BT.2020) is added. The test setup contains a GretagMacbeth ColorChecker, which is recorded by a RED Scarlet-X camera and a mobile spectrometer (rgbphotonics Qmini). The latter captures the spectral distribution of the individual ColorChecker patches under the same lighting conditions. To compare the results, the recordings of both devices were converted to the CIE xy- chromaticity diagram using The Foundry Nuke11X. Additionally a comparison to reference data provided by the ACES document TB- 2014-004 is included. Finally it is reviewed if the ACES IDT concept is working for the RED Scarlet-X camera. 1. The Input Device Transform (IDT) in an AMPAS-ACES Workflow Shortly after the beginning of the new century the Academy of Motion Picture Arts and Sciences (AMPAS) started development of its own color system, the Academy Color Encoding System (ACES), with the main goal to unify and simplify the process of Figure 1. The ACES Input Device Transform section with the interchanging and archiving digital motion picture images. Reference Input Capture Device Currently version 1.0.3 is in use and contains dozens of color conversion tools mostly to and from their own ACES color spaces. IS&T International Symposium on Electronic Imaging 2018 139-1 Mobile Devices and Multimedia: Enabling Technologies, Algorithms, and Applications 2018 2. RED Color Spaces RedWideGamutRGB colorspace are published [5]. All three primaries of this color space are outside the visible spectrum and for this they cannot be displayed on physical display, which makes In the history of RED cameras (see figure 2) a couple of this colorspace a theoretical space just like ACES2065-1 (see figure colorspaces had been provided to encode the .r3d files. Each color 3). space is part of the metadata and set up during recording. It can be changed losslessly during the postproduction process. The current color spaces are as indicted in The Foundry Nuke11[2]: z x y • DRAGONcolor2 Red 0.780308 0.304253 • REDcolor4 Green 0.121595 1.493994 • REDWideGamutRGB Blue 0.095612 -0.084589 • Rec2020 White Point (D65) 0.3127 0.3290 In the legacy setting of the REDCINE-X PRO 50 application some Table 1. Chromaticity coordinates of REDWideGamutRGB color space in CIE xy-chromaticity diagram [5] legacy color spaces are available: • RedColor • RedColor2 • RedColor3 • DRAGONcolor1 • RedSpace • CameraRGB Additionally the following standard color spaces are accessible as well: • sRGB • REC 709 and • Adobe1998 Figure 2. RED Scarlet-MX camera [3] Figure 3. RED Wide Gamut RGB color space in comparison to other film/video color spaces In the IPP2 color system version of REDCINE-X PRO software package (version 50 used in this test) [4] only the REDWideGamutRGB color space and the transfer function The main problem with the other proprietary RED color Log3G10 are available. Beside the well-documented standard color spaces is the absence of documentations. Mostly the missing spaces like Rec 2020, only the parameters of the primary chromaticity coordinates made it difficult to compare conversion methods. We researched the problem in paper [6]. IS&T International Symposium on Electronic Imaging 2018 139-2 Mobile Devices and Multimedia: Enabling Technologies, Algorithms, and Applications 2018 3. Test setup and methodology The test setup follows a practical approach to mimick the situations on a film set with a film camera and a mobile spectrometer. Both devices were capturing the GretagMacbeth ColorChecker [7] (see figure 4) under the same lighting conditions. All color conversions were taking place inside The Foundry NukeX v.11.2[8] which is the central software in modern film pipelines [9]. The image processing for the RED footage were done using the built-in OpenColor IO [10] system to gain access to the current ACES version 1.0.3, which provided the necessary IDTs. Figure 5. The spectrometer used in this test, the rgb photonics Qmini [11] Following the ACES recommendation we used ACEScg as the host color space in NukeX. The imported RED footage was then converted from the ACEScg color space to CIEXYZ using the following matrix [12] and then to CIEYxy using the built-in Colorspace node: Figure 4. GretagMacbeth ColorChecker (pocket version) and identifiers used in the test (1) The test took place at the campus of the University of Applied Sciences in Brandenburg in early December 2017 at noon. Four different color spaces were compared and provided in Nuke’s Read node reading in the RED RAW footage (.r3d). • DRAGONcolor2 In the input conversion process for the Rec2020 color space • REDcolor4 an error appeared. The scaling of the patch positions within the CIE • REDWideGamutRGB xy-chromaticity diagram using NukeX’s Read node did not work as • Rec2020 expected and rendered a heavily desaturated result. To investigate the conversion from RED Rec2020 to ACEScg color space without We applied no further color correction or white balancing but error we used a different approach. used only ACES IDTs. The RED footage was imported into the proprietary The spectral data were recorded using a mobile spectrometer, REDCINE-X PRO application (version 50) with the import color the rgbphotonics Qmini (see figure 5). It consists of the device itself space set to Rec2020. We set the color space transfer function to with an USB connection to a laptop and an optical fiber cable as the linear, and all other settings derived from the meta data. The input. While ensuring to maintain the same lighting conditions imported image was then exported as a 32bit floating point (clouds) every patch was captured individually and the values were OpenEXR file with no transfer function applied encoded to stored in a spreadsheet (see Appendix A). It has to be pointed out Rec2020 color space. that this process lasted around 5 minutes. This file was then read into Nuke using the OCIO Utility- Once captured, the spectral data recorded by the rgb Linear-Rec2020 as an IDT. This method delivered a sufficient photonics Qmini spectrometer (see figure 5) was converted from result (see section 6), which fell inside the tolerances retrieved from the scene illuminant (around 5700 K) to CIE D65 for better other conversions. This import error should be fixed in one of the comparison. next updates in NukeX. As an additional test to proof the concept we used the chromaticity positions of the ColorChecker patches in ACES RGB provided in the ACES Technical Bulletin TB-2014-004 [1]. We set up a Nuke session in ACES2065-1 color space with CIE illuminant D60 and read in the test footage using all four RED color spaces. With compositing techniques (masking and grading) we separated the primary and secondary patches (red, green, blue, yellow, IS&T International Symposium on Electronic Imaging 2018 139-3 Mobile Devices and Multimedia: Enabling Technologies, Algorithms, and Applications 2018 magenta, and cyan) of the ColorChecker.