ASWF Google Summer of Code 2020

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 5 distinct software packages. Student 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.

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/

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.

Student name:

School / year / area of study:

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: Patrick Hodoul, Doug Walker, Michael Dolan

Project Ideas:

  • Add Metal, Vulkan, or CUDA language support to GPU renderer
    • The OCIO Processor currently supports rendering color transforms on a GPU with GLSL (OpenGL), HLSL (DirectX), or CG. With Apple deprecating OpenGL support and the availability of several additional high-performance GPU computing platforms, we desire to add shader language support for one or more of these to expand the capability and reach of OCIO. This will also be a critical need for OCIO to maintain full cross-platform support.
    • Special skills: Familiar with C++, shader development, and implementing graphics APIs.
  • Restore Java bindings
    • The OCIO Java language bindings have not yet been updated to support the newly developed OCIO v2 API. Java provides additional Android platform support, but needs some effort to revive. Additionally, adding Java unit test support to OCIO’s CI infrastructure would help maintain the functionality as OCIO continues to evolve.
    • Special skills: Comfortable with Java, with some knowledge of wrapping a C++ library with the JNI.
  • 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.
  • Develop GUI for interactive OCIO config authoring and visualization
    • OCIO is all about color management, but the visual results of a config author’s decisions are not verifiable until the config is generated and loaded into a host application. Learning and using OCIO could be greatky aided with a GUI which provides interactive visual feedback and validation while a config is being authored. This could be a standalone Qt or PySide application, or an expanded plugin within an existing graphics application like Foundry’s Nuke.
    • Special skills: Experience with GUI and graphics programming in C++ or Python, understanding of UX, and interest in data visualization.

OpenCue

Home page: https://www.opencue.io
GitHub: https://github.com/AcademySoftwareFoundation/OpenCue
Skills/knowledge relevant to the project: Python, Java

Mentor suggestion: Brian Cipriano

Getting Started:

Contact Brian Cipriano «cipriano@google.com» and join the opencue-dev list.

Project Ideas:

  • Create a Web GUI
    • Design and begin implementation on a new, web-based GUI to eventually replace OpenCue’s existing PySide2 application GUI. This will consist mostly of front-end work; the new GUI should use the existing OpenCue API on the back-end. Design, including tech stack to be used, will be done in collaboration with the project leads.
    • Special skills: UI/UX design, front-end development
  • Create a REST API
    • Create a REST API to complement OpenCue’s existing gRPC API. Backend should be mostly shared between the two.
    • Special skills: REST API design
  • Create a Cloud Management Plugin
    • Extend the OpenCue GUI to add a plugin for scaling the pool of OpenCue workers running in the cloud. The plugin should use at least one of the major cloud providers (Google Cloud, Microsoft Azure, or Amazon Web Services) but should be designed in way where other cloud providers can be easily added.
    • Special skills: Cloud development and APIs
  • Create Installers/Launchers
    • Create installers (.exe, .msi, .dmg, etc.) and/or click-to-launch wrappers for existing OpenCue components. To goal is to make OpenCue more user friendly by reducing reliance on the command line and providing an intuitive click-to-install/-launch experience.
    • Special skills: Desktop application development

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:

  • New python bindings for Imath using pybind11.
    • Our core C++ library for vector and matrix types, which is widely used by other projects, needs an overhaul of its Python bindings to switch to using pybind11
  • Split Imath into a separate project and modernize
    • The main library is for dealing with OpenEXR image files. But several helper libraries are bundled, including a widely used vector, matrix, and math library known as Imath. We would like to split this off into a separate repository (which will then be a dependency of the image file library). There are several possible sub-tasks:
      • actually splitting the library into separate repo and adjusting all the CMake build scripts
      • make almost all of it exception-free and marked properly as noexcept
      • mark const and constexpr as widely as possible.
  • Explore and benchmark compression methods
    • Design a methodology for assessing compression and decompression speed and file sizes.
    • Benchmark the currently supported set of compression techniques across a variety of represenative images and document the performance and compression ratio tradeoffs among the choices.
    • Speculatively implement additional compression techniques such as zfp or zstd (and possibly others) to find out if they offer advantages over our current set of compression methods.
  • Performance evaluation and regression detection
    • We currently have a test suite to verify correctness, but not performance.
    • Design and implement performance tests as part of our testing framework. This should probably cover a variety of image file scenarios and settings.
    • Extend our build and CI system to automatically detect performance regressions or improvements for submitted code changes and proposed releases.
  • Expand “Simple” API
    • Update the IlmImfRGBAFile interface
    • Expose a pure “C” interface to the DSO
    • Write a sample python binding using this C api
  • Amend test suite to get closer to 100% coverage
    • Current tests cover about 75% of the C++ code base, as reported by SonarCloud.
    • Implement tests that validate the behavior of the uncovered components.

OpenTimelineIO

Home page: http://opentimeline.io
GitHub: https://github.com/PixarAnimationStudios/OpenTimelineIO
Skills/knowledge relevant to the project: C++, Python, CMake, knowledge of how NLEs and DCCs are used, knowledge of EDLs a bonus

Mentor suggestions: Josh Minor, Stephan Steinbach, Nick Porcino, Eric Reinecke

Project Ideas:

  • Progress Callback API
    • Some import and export operations are time consuming, and tool authors would like to provide progress estimations. A progress callback, presumably with a percentage or other measure would enable this.
    • OTIO file format adaptors are written in Python, so this would be a Python-available API
  • Javascript Language binding
    • Use emscripten’s WebIDL or Embind to provide Javascript bindings for OpenTimelineio
    • An open question is whether the adaptors, such as for AAF, would be available under Javascript. The adaptors are implemented in Python.

  • Otioview as a web app

  • Otioview track and timeline metadata viewing
    • Add metadata introspection and navigation on timelines and tracks
  • C Language binding
    • A C foreign function interface (ffi) would enable bindings for languages other than Js and Python.
    • Example applications would be Lua bindings, and remote procedure calls.
  • Reusable timeline display widgets
    • Otioview has a widget for Qt. Having the widget separately available for other apps would be great
    • An ImGui variant
    • A generic widget assuming only the availability of mouse interaction data and simple draw calls
  • C++ and Python operators for time ranges
    • Functions such as “meets”, “overlaps”, and so on.
  • C++ and Python time coordinate system class
    • Coordinate system implementation and operators to enable operations such as local to parent, world to local, and so on.
  • opentime_clock for std::chrono
    • bindings to allow meaningful interoperation with std templates that have time arguments
  • Add OTIO to another ASWF project
    • Identify another ASWF project that might meaningfully interoperate with OTIO and implement it
  • Add OTIO support to an NLE or DCC
    • As an example, the generic widget project could be used to build OTIO support into Blender
    • An OTIO adapter could support time based media, such as Grease Pencil storyboards in Blender

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:

  • Delayed Loading on Windows
    • Introduce support for delayed-loading on Windows by modifying the temporary file implementation in the core OpenVDB library to make use of the Windows- specific std::fopen flags for temporary files (“TD”).
    • Help to improve the Windows-related build, CI and documentation.
    • Background Info: OpenVDB can generate very large files and even with the fastest solid state drives, I/O performance is still a common bottleneck. Delayed-loading (sometimes referred to as lazy-loading) is about reading only the VDB data that is absolutely needed. An example use case is being able to clip or delete voxel data from the VDB before the data has been read from disk resulting in an overall increase in performance when visualizing data.
  • Improved Level Set Rebuilding
    • Modify the rebuilding of VDB level sets to improve the flood-filling operation that can eliminate desirable features.
    • Background Info: Constructive Solid Geometry (CSG) operations include union, difference and intersection compositing of two or more level sets that will result in a new level set. An example could be subtracting some level set spheres from a level set of a cube to generate a “Swiss cheese” level set. If the narrow band or transform of the source level sets does not match the target level set, they must be completely rebuilt before they can be composited which can result in eliminating desirable features of the source level set. In particular, the rebuilding algorithm converts to polygons and back, which will cause holes in the geometry to be filled. The Polygon -> VDB rasterization could be special cased to use the original VDB to determine sign, thus avoiding collapsing holes.
  • Multi-thread Sequential Algorithms
    • Introduce new multi-threaded algorithms that use leaf and tile traversal to replicate existing single-threaded tree algorithms (such as tree::activeVoxelCount).
    • Introduce new extrema and statistics tools (such as tools::extrema) that are multi-threaded using leaf and tile traversal.
    • Background info: Investigations carried out using the existing sequential tree-based algorithms in OpenVDB have demonstrated a large performance improvement by multi-threading across different levels of the tree data structure. In addition, OpenVDB provides general purpose leaf and tile traversal for computing extrema and statistics, however the most intuitive way to use these is by calling them with a tree iterator which is very slow. Both of these performance improvements would use Intel’s TBB and OpenVDB convenience classes such as tree::LeafManager and tree::NodeManager to introduce multi-threading.
  • Improve Filter Operations to Densify Tiles and Optionally Dilate
    • Automatically densify specific VDB tiles required to perform different filtering operations such as gaussian smoothing and handle all edge cases.
    • Provide an option to automatically dilate level set VDBs as required when filtering based on filter and voxel sizes.
    • Background info: OpenVDB tiles are constant-value nodes designed to optimize storage space and improve performance. However not all algorithms, such as gaussian smoothing turn these tiles into dense nodes (often called densifying) when required so as to generate the correct result. In addition, it is left up to the user to specify the correct amount of dilation to perform prior to any filtering based on their filter size and the voxel size. A beneficial feature would be allowing the user to opt-in to dilate automatically up to some threshold.
  • Optimization using SSE/AVX Intrinsics
    • Investigate opportunities to improve VDB performance using vectorization and SSE and AVX intrinsics.
    • Background info: OpenVDB already has optional SSE/AVX build flags, but minimal use of any of these intrinsics. There are lots of potential operations such as bit-counting, finding least significant bit, SSE/AVX operation on floating-point values (e.g. math::Vec3) and integer operations (e.g. math::Coord) that would benefit performance.

Cross-project infrastructure

ASWF-Docker

GitHub: https://github.com/AcademySoftwareFoundation/aswf-docker
Skills/knowledge relevant to the project: Python, Docker, Bash, CMake

Mentor suggestions: Aloys Baillet, JF Panisset

Project Ideas:

  • Better docker image discovery via automatic readme uploads to DockerHub overviews on image push (modern Python 3 development, dockerhub rest API). These readme files would populate the “overview” tab on the docker hub pages such as this one: https://hub.docker.com/r/aswf/ci-openexr.
  • Investigate RPM (yum packages) generation from docker ci-packages such as https://hub.docker.com/r/aswf/ci-package-openexr. These RPMs would potentially be hosted on an artifactory yum repo which would enable any RHEL or CentOS user to very easily install many VFX packages.
  • Create a prototype of a windows docker image equivalent to the linux ci-common and ci-base images to be able to compile VFX packages such as OpenEXR. Many details on the windows version of our CI docker images are still yet to be defined and discovered.

… more ideas go here …