ASWF Google Summer of Code 2022

The Academy Software Foundation (ASWF) is collaboration between the Linux Foundation and the Academy of Motion Picture Arts and Sciences, serving as an umbrella organization that is the home to several key open source software projects used by the film industry (primarily visual effects and animation production). The projects we manage are some of the most high-profile and widely used open source projects originating and used in film production studios. It’s a great opportunity for students to get involved with projects that will be used professionally on films!

The mission of the ASWF is to increase the quality and quantity of contributions to the content creation industry’s open source software base; to provide a neutral forum to coordinate cross-project efforts; to provide a common build and test infrastructure; and to provide individuals and organizations a clear path to participation in advancing our open source ecosystem.

Member projects are focused primarily on visual effects and animation production, and at present include 8 distinct software packages. Summer project applications can be for any of these packages individually, as well as potentially including tasks that bridge between them or provide common infrastructure (they share CI and other resources). The current member projects are:

  • OpenColorIO : A complete color management solution geared towards motion picture production with an emphasis on visual effects and computer animation.

  • OpenCue : A render management / job queueing system you can deploy for visual effects and animation productions.

  • OpenEXR : The specification and reference implementation of the EXR file format, the professional-grade image storage format of the motion picture industry.

  • Open Shading Language : The de facto standard shading and pattern language of physically-based renderers used for film VFX and animation.

  • OpenTimelineIO : API and interchange format for editorial timeline information.

  • OpenVDB : Hierarchical data structure and a suite of tools for the efficient storage and manipulation of sparse volumetric data.

  • MaterialX : An open standard for representing rich material and look-development content in computer graphics, enabling its platform-independent description and exchange across applications and renderers.

  • Rez : Rez is a cross-platform package manager with a difference. Instead of installing to separate environments, all package versions are installed into a central repository, and standalone environments reference these existing packages.

In addition to typical software projects, the ASWF also forms Working Groups to tackle industry-wide or non-traditional projects such as python3 migration, diversity & inclusion, and the creation of Rust bindings for ASWF projects. The Rust Working Group is included in the project ideas list for 2022!

Application Instructions for Students

Please familiarize yourself with the several software projects under our organization. The individual projects are listed below with their home pages, GitHub repositories, and a list of possible projects.

You may choose a summer task from any of our software projects. It is also permissible to propose (a) a task that is common infrastructure shared by the projects, such as with our CI system; (b) a task that crosses project boundaries or involves two projects; (c) a task that is technically in a non-ASWF code base but for which our organization is an appropriate mentor (as an illustrative example: adding comprehensive OpenColorIO support to a widely used open source project).

All of our projects maintain their own CONTRIBUTING guidelines, please read them for the project you are interested in. They each also have separate contributor license agreements (CLAs) which must be signed for them to accept contributions.

Successfully submitting a Pull Request to the ASWF software project you are applying to is a strict requirement prior to submitting an application. This is not negotiable. We will not even read applications from students who have not submitted an acceptable PR to the project they are applying to participate in. It can be a truly minimal change – for example, fixing a typo in an error message. The purpose of this requirement is to prove that you already have the skills to set up a GitHub login, successfully clone the project, build it, make a change, submit a PR, and interact with the community for code review.

In addition to ideas listed below, the GitHub “Issues” page for each project will have issues tagged “GSoC” if they seem like an appropriate size for a GSoC summer project. You will also see many issues tagged “good first issue”, those might be ideal candidates for your small trial PR to qualify for application.

Individual project’s developer mail lists can be found here: https://lists.aswf.io/

You can join the ASWF slack instance here: https://slack.aswf.io/

Application template

Please use this application template. You don’t have to stick precisely to this, feel free to expand or tell us any other relevant details, but this is a good place to start.

The applications will be judged both by the individual leadership teams of the software project you propose to work on, as well as representatives of the ASWF technical advisory council.

Applicant name:

Relevant courses, materials studied, jobs, programming projects, skills,
other open source projects you've contributed to. Go ahead and tell us
anything about your background that you think we will find interesting
for our projects.

ASWF project you are interested in:

Project proposal:

What would you like to do for your summer project?  Please explain in
detail what it is, why it is important, how it fits into the ASWF
project's overall design and goals.  Give specifics on acceptance
criteria -- how we can measure your success, how we can test your code.
Give a week-by-week timeline for expected progress and how it can be
measured.

Tell us about your interest in this project, what you hope to
contribute, and what you hope to get from this experience:

We will not review applications from students who have not contributed a
patch to ASWF by the application deadline.  It doesn't have to be
big -- a short bug fix, a new test case for a unit test, an improved
error message, fixing unclear documentation.  But you must prove that
you can check out the project, build it, find something to improve, make
the change, communicate with the other developers, and survive our
rigorous code review.  Please tell us below which fix you contributed:

Project information and suggested ideas list

OpenColorIO

Home page: https://opencolorio.org/
GitHub: https://github.com/AcademySoftwareFoundation/OpenColorIO
Skills/knowledge relevant to the project: C++11, CMake, color science

Mentor suggestions: Michael Dolan, Mark Boorer

Project Ideas:

  • Add OCIO support to FFmpeg or another FOSS project
    • An important effort for OCIO is expanding the libraries and applications where OCIO is implemented. Users have specifically called out FFmpeg as a library and command-line tool where they would like to see OCIO support, but any other FOSS project leveraged by digital artists or production pipelines could be considered. This could also include upgrading an existing implementation to support the OCIO v2 API and leverage new functionality.
    • Special skills: Familiarity with prospective host library or tool, and knowledge of working with image buffers and authoring plugins.
  • Implement OCIO within webassembly & develop a small proof of concept app in-browser.
    • First ensure working compilation of OCIO into WASM
    • Develop a small prototype app such as: image viewer with input colorspace and output view/display control

Open Shading Language (OSL)

GitHub: https://github.com/AcademySoftwareFoundation/OpenShadingLanguage
Skills/knowledge relevant to the project:

Mentor suggestion: Larry Gritz

Project Ideas:

  • Overhaul/enhancement of osltoy:
    • “osltoy” is a sample application that ships with OSL, a Qt-based GUI app that runs shaders, lets you edit the code or fiddle with the parameters, and see the results interactively an a displayed and continually updated “image.” It’s a bit like https://www.shadertoy.com/ but for OSL, and it’s a local app rather than a web service. It’s a fun way to tinker with shaders, and some studios have used it as the basis for teaching introductory OSL classes. This summer task would be to turn osltoy into a more full-featured, slicker tool that can let people do more of the things that people do with shadertoy – including provisions for saving results from one frame that can be available to the next frame, making keyboard/mouse input available to the shader to respond to, etc.
  • Improved oslc error reporting:
    • One component of osl is “oslc”, which is a relatively straightforward compiler from osl source code to an intermediate code. There are two ways that we could improve the user experience with oslc where error reporting is concerned, and both only require diving into the basic parsing (not the IR code generation or anything farther downstream): (1) Instrument oslc’s parser fully with the code to record column positions (in addition to the lines it currently records) of each syntactic structure, and rig error messages to give those nice modern outputs where it quotes the lines and underscores the particular words or sections containing the error. (2) Make errors involving unknown identifiers print likely suggestions (based on Levenshtein Distance), so instead of errors like “unknown function ‘foo’”, it might also print a specific suggestion for what they probably wanted but had misspelled.

OpenEXR

Home page: https://www.openexr.com/
GitHub: https://github.com/AcademySoftwareFoundation/openexr
Skills/knowledge relevant to the project:

Mentor suggestions: Kimball Thurston, Cary Phillips, Larry Gritz, Nick Porcino

Project Ideas:

  • Explore Other Compression Schemes.
    • OpenEXR currently supports lossless compression through zlib, but other more modern compression schemes exist. We would like to explore adding additional options for compressing with other utilities, such was Zstandard. To do this properly, we also need to assemble a standard set of images to use as benchmarks, and also develop some basic performance metrics in order to compare compression/decompression time across different options.
  • Performance Metric Suite
    • OpenEXR needs a mechanism for quantifying read/write and compress/decompress times.
  • A Fast Header Read
    • Extend the OpenEXR API with a way to read just the header attributes you request, and nothing else, for efficiency when applications need only the header information but no pixel data.
  • Add a Part Type That is Only Metadata
    • An image part that holds only metada with no pixel data could be useful for managing metadata in motion picture pipelines.
  • Add support for bfloat16
    • https://en.wikipedia.org/wiki/Bfloat16_floating-point_format
    • Adding a new pixel type might be tricky, and may present backwards compatibility issues.
  • Add Support for Sorting of Attributes
    • Currently, attributes are written and read in alphabetical order in the file, and stored alphabetically internally. But sometimes it would be convenient to organize and present them in the API, or GUI’s, in a logical, non-alphabetical order. The solution needs some investigation, but it might involve changing the internal attribute storage mechanism, or leaving the internal representation alone and adding an “order” attribute to store the preferred order.
  • Convert boost::python Imath Bindings to pybind11
    • Eliminate Imath’s dependency on boost/boost_python by re-implementing the bindings using pybind11.
  • Add a New Spectral Attribute Type
    • Follow up on Alban Fichet’s spectral image storage presentation by implementing a custom attribute to hold the spectra: https://hal.inria.fr/hal-03252797
  • Switch C++ API to Use the New C Core
    • Retrofit the existing C++ API to use the new thread-safe C API underneath

OpenVDB

Home page: https://www.openvdb.org/
GitHub: https://github.com/AcademySoftwareFoundation/openvdb
Skills/knowledge relevant to the project: C++14, Git, CMake, (Knowledge of Houdini is also useful)

Mentor suggestions: Ken Museth, Dan Bailey, Nick Avramoussis

Project Ideas:

  • Improve our unit-test coverage
    • Run gcov to get a measure of code coverage
    • List the tools and functions that are not covered by the unit tests
    • Write unit-tests for these tools and functions
    • Go through each unit-test file to refactor them (e.g. TestTools.cc)
  • Using Agner Fog’s vector class wrapper library, improve the performance of OpenVDB algorithms with the use of SIMD intrinsics:
    • Introduce VCL to the CMake build system and installation.
    • Identify a few easy algorithms to start with e.g. ::fill() ::clip() and confirm performance on compatible hardware
    • Where it makes sense to do so, re-work algorithms to take advantage of SIMD usage
    • Provide performance metrics with any changes.
  • Implement the Swept Volume Algorithm:
    • Read the paper (https://www.dgp.toronto.edu/projects/swept-volumes/swept-volumes.pdf)
    • Write a pseudo-code
    • Create 2 - 3 examples of inputs (consisting of a pair of a polygon mesh and a trajectory) to the algorithm
    • Implement the swept volume algorithm in the OpenVDB library
    • Write unit-test, possibly using the example inputs created in an early step
      • Implement a Houdini SOP to call the swept-volume algorithm

Rust Working Group

Home page:
Github: https://github.com/vfx-rs
Skills/knowledge relevant to the project: Rust, C++

Mentor Suggestions: Anders Langlands, Luke, Scott Wilson

  • Rewrite/refactor CPPMM
    • CPPMM is our main tool to create the C and unsafe *-sys Rust bindings. It may be worth promoting to a product maintained by the ASWF, and used for other projects (including our own). The current implementation’s design does not make it very easy to extend to C++ projects outside of what’s currently being supported, so some work is needed to make it more extensible and support more valid C++ code.
  • Write bindings for unclaimed projects
    • Currently there are some bindings that are unclaimed (see README.md in the vfx-rs repo) that could use someone to build.
  • Make C++ projects more Rust friendly
    • There are some APIs that are not very Rust friendly, and also are considered difficult to support on the C++ side. The goal would be to work with the parent projects to update the problematic APIs.