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). #4472
- OpenColorIO 2.2, and make it required. #4367
- fmt 8.0 (from 7.0), which has many improvements. CANCELLED: fmt 8.0+ does not work with the old icc compiler.
- GIFlib 5.0 (from 4.0), which adds thread safety. #4349
- libheif 1.11 (from 1.3), which supports many additional features of that format. #4380
- WebP 1.2 (from 0.6) which lets us use their exported CMake configs and retire FindWebP.cmake. #4354
- pybind11 2.6 or 2.7 (from 2.4). #4297
- #4158 Eliminate the last few places where we use Boost and eliminate it as a dependency.
-
#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, andstring_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++).
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.
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.
...