Skip to content

Latest commit

 

History

History
102 lines (68 loc) · 5.08 KB

ROADMAP.md

File metadata and controls

102 lines (68 loc) · 5.08 KB
Raw

OpenImageIO Roadmap

This describes the major tasks we hope to accomplish on the road to OpenImageIO 3.0, which should be released circa September 2024. Where there are links to issue, please read the issue for more extensive description and discussion about the modifications required.

OpenImageIO is fairly mature and one could argue that its being used extensively in production for 15 years puts an empirical limit on the criticality of any "missing" feature. So while we welcome new features, those that don't break old APIs can be added in any release, so there are no "must have features" that are required to be completed for this release.

However, 2.x -> 3.0 is one of the rare opportunities for things that might break backward compatibility, i.e., that might require actual source code changes to software that calls OIIO. Since this happens only every 5 years or so, this means that for many such changes (including removing previously deprecated API calls), it is a matter of doing in now or waiting several years.

Dependency modernization (project)

We would like to pull forward a whole lot of other dependencies so that their minimums are somewhere in the "released 3-5 years ago" range. The full list of our dependencies can be found here.

See the Dependency proposal wiki page

  • Big required upgrades with potentially widespread impact on the code base

  • Miscellaneous optional upgrades whose changes will be very localized

    This isn't a complete list, nor do we need to do all of these, but the highest priorities are:

    • CMake 3.18 (from 3.15). Or possibly newer if there's a good reason? (3.19 or 3.20 are also reasonable.)
    • OpenColorIO 2.0, or possibly 2.1 (from 1.1). Open for debate: should it be a required dependency rather than optional?
    • fmt 8.0 (from 7.0), which has many improvements.
    • GIFlib 5.0 (from 4.0), which adds thread safety.
    • libheif 1.11 (from 1.3), which supports many additional features of that format.
    • WebP 1.2 (from 0.6) which lets us use their exported CMake configs and retire FindWebP.cmake.
    • pybind11 2.6 or 2.7 (from 2.4).
  • #4158 Eliminate the last few places where we use Boost and eliminate it as a dependency.

API Modernization

  • #4159 Using span and string_view instead of raw pointers

    Scrub the APIs to find where we have API calls that take a pointer and size (or worse -- just a pointer and an assumption about the size), and instead use span<T> / cspan<T> for things that are like arrays, and string_view for things that are like strings.

  • #4160 Using named keyword/value lists more extensively in imagebufalgo.h

  • Deprecate as much as possible of the old printf-style string formatting we use internally, instead using the fmt/std::format style everywhere. This includes changing Strutil::format to alias to Strutil::fmt::format (currently it aliases to Strutil::old::format, which uses printf style).

  • Remove deprecated API elements

    Hunt for things marked DEPRECATED and try to get rid of them where possible. If we can't remove them, at least make sure they are marked as OIIO_DEPRECATED (or [[deprecated]] in modern C++).

The rest

Other initiatives we hope to have completed by the time of this next major release:

  • #4164 Better color management

    Regardless of OCIO availability, version, or contents of any configs, have universal support for the canonical color spaces that seem to be the common consensus of ACES, MaterialX, and USD.

  • Preliminary Rust bindings for most of the OpenImageIO APIs.

  • Python wheel construction so pip install openimageio will be an easy way for users to install the whole banana.

If there is something you think should be on the roadmap for the next major release but is not, please open an issue or discussion to propose it, or bring it up at a TSC meeting, or on the mail list or Slack channel.

Parking

Here is where we will put things that definitely should be on the roadmap, but that need not be completed in time for the fall 2024 release of OIIO 3.0.

...