ACES Working Group Proposal OpenEXR Compression Best Practices Working Group
 
Description of the problem or question(s) the Working Group will be investigating:
Many facilities and workflows in the Post and VFX industry use ACES as an intermediate format
when exchanging files but one of the main drawbacks of this currently is the lack of support for the lossless OpenEXR compression options to help keep file sizes and transfer times to a minimum when using the ACES Container file specification.
 
As the resolution and frame rates of our imaging sources, and the subsequent deliverables, increase in size as UHD (and beyond) resolutions become more prevalent, we would like to explore adding support for one or more OpenEXR’s compression methods to the ACES Container specification to help in attaining more manageable file product sizes.
 
In order to be able to deal with these ever growing demands on the storage and compute infrastructure in facilities the following OpenEXR Library Compression schemes were arrived upon as being very successful in managing the needed IO performance and relative file size whilst still being mathematically lossless.
 
Per the various discussions on the topic, the arrived at and suggested OpenEXR compression formats are:

PIZ (lossless) - A wavelet transform is applied to the pixel data, and the result is Huffman encoded. This scheme tends to provide the best compression ratio for the types of images that are typically processed in VFX. Files are compressed and decompressed at roughly the same speed. For photographic images with grain, the files are reduced to between 35 and 55 percent of their uncompressed size. PIZ compression works well for scan-line based files, and also for tiled files with large tiles.
 
ZIP (lossless) - Differences between horizontally adjacent pixels are compressed using the open source zlib library. ZIP decompression is faster than PIZ decompression and in recent OpenEXR versions the performance of ZIP compression has been significantly improved to outperform uncompressed OpenEXR IO[1] [2] [3] [4] . Photographic images tend to shrink to between 45 and 55 percent of their uncompressed size. For our application area, fast read accesses are usually more important than fast writes, or maximum compression.
 
ZIPS (lossless) - Uses the open-source zlib library for compression. Like ZIP compression, but operates on one scan line at a time. Handy and optimally laid out for certain applications to directly benefit from.
 
TAC - July
Optimal MATTE storage as Scope expansion: Come up with some suggested recommendations about part/layer naming and the corresponding storage of them inside the OpenEXR container and use by the DCC vendors.
 
List items that are out of our initial scope for the TAC to consider.

RGB cross-Facility exchange should be ACES 2065-1 

( For reference[5] , here is the OpenEXR Technical introduction documentation: https://www.openexr.com/documentation/TechnicalIntroduction.pdf )
Make this a req that playback is not slower than uncompressed.
also talk about saving
Add in openexr version for speedups.
and mention OpenEXRCore SDK updates.
Add in potential example sequences per @carolp@netflix.com