Larry Gritz
2018-11-10 21:43:59 UTC
Although I intend to have semi-annual major releases, here we are again a full year after OIIO 1.8 was released. Sorry.
But at long last, I have branched RB-2.0 and tagged Release-2.0.0-beta1.
This could have been "1.9" but I decided to call it 2.0 because we made much more extensive non-back-compatible API changes than usual, and also since this past year marked OIIO's 10th anniversary. It seems an appropriate time for a first-digit flip.
Currently, this is identical to master, but they will diverge as soon as something needs to go in master (future 2.1) that shouldn't also go in the 2.0 release.
Because this code has been used so extensively in production (at SPI, we build our renderer and many other production tools straight from the master OIIO branch), I intend for the "beta" period to be fast, then a release candidate or two, and hope to mark a final (non-beta, non-RC) release on Dec 1.
Because this is "beta", there may yet still be a few changes that break compatibility, by the time we are calling in release candidates, it should be a 100% stable API (except for dire emergencies), and of course once it's released, compatibility-breaking changes will only to in master/2.1 and never in the 2.0 release branch.
Please see the CHANGES.md for the extensive list of changes versus 1.8, but here are just a few of the top highlights:
The ImageBufAlgo API has had a big revision (both C++ and Python), and now supports a much more Pythonic/algebraic notation of being able to return an ImageBuf result directly instead of needing to pass a result reference.
The Python bindings are now all based on pybind11 (no more Boost.Python) and have had a number of cleanups, one of which is that all API calls that take or return pixel data now do so with Numpy multidimensional arrays, rather than the old style Python array.array flattened to 1D.
ImageInput and ImageOutput creation now returns unique_ptr<> rather than raw pointers, making resource cleanup a lot more foolproof and ownership a lot more clear.
ImageInput read calls now take subimage & miplevel as parameters (seek_subimage is no longer required), so no "state" is presumed preserved between calls, and thus the interface is reentrant and thread-safe, no app-side locks necessary to have multiple threads reading from the same file (if you stick to the new safe calls).
TIFF I/O has been vastly sped up when threading is enabled (10x or more speedup reading/writing TIFF files for many modes).
New ability to write certain image file formats to and from memory buffers (no files required).
Support for reading OpenVDB volume files (for texture3d, among other things).
The 2.0 release (and its subsequent minor releases) does not impose any new, or raised-minimum, dependency requirements. However, after the branch is complete, we are expecting to raise some of the dependency minimums for future (next year's) major releases, TBD.
Explore, enjoy, get your software ported to the new interfaces, and let us know any problems before it's fully set in stone at the end of this month.
--
Larry Gritz
***@larrygritz.com
But at long last, I have branched RB-2.0 and tagged Release-2.0.0-beta1.
This could have been "1.9" but I decided to call it 2.0 because we made much more extensive non-back-compatible API changes than usual, and also since this past year marked OIIO's 10th anniversary. It seems an appropriate time for a first-digit flip.
Currently, this is identical to master, but they will diverge as soon as something needs to go in master (future 2.1) that shouldn't also go in the 2.0 release.
Because this code has been used so extensively in production (at SPI, we build our renderer and many other production tools straight from the master OIIO branch), I intend for the "beta" period to be fast, then a release candidate or two, and hope to mark a final (non-beta, non-RC) release on Dec 1.
Because this is "beta", there may yet still be a few changes that break compatibility, by the time we are calling in release candidates, it should be a 100% stable API (except for dire emergencies), and of course once it's released, compatibility-breaking changes will only to in master/2.1 and never in the 2.0 release branch.
Please see the CHANGES.md for the extensive list of changes versus 1.8, but here are just a few of the top highlights:
The ImageBufAlgo API has had a big revision (both C++ and Python), and now supports a much more Pythonic/algebraic notation of being able to return an ImageBuf result directly instead of needing to pass a result reference.
The Python bindings are now all based on pybind11 (no more Boost.Python) and have had a number of cleanups, one of which is that all API calls that take or return pixel data now do so with Numpy multidimensional arrays, rather than the old style Python array.array flattened to 1D.
ImageInput and ImageOutput creation now returns unique_ptr<> rather than raw pointers, making resource cleanup a lot more foolproof and ownership a lot more clear.
ImageInput read calls now take subimage & miplevel as parameters (seek_subimage is no longer required), so no "state" is presumed preserved between calls, and thus the interface is reentrant and thread-safe, no app-side locks necessary to have multiple threads reading from the same file (if you stick to the new safe calls).
TIFF I/O has been vastly sped up when threading is enabled (10x or more speedup reading/writing TIFF files for many modes).
New ability to write certain image file formats to and from memory buffers (no files required).
Support for reading OpenVDB volume files (for texture3d, among other things).
The 2.0 release (and its subsequent minor releases) does not impose any new, or raised-minimum, dependency requirements. However, after the branch is complete, we are expecting to raise some of the dependency minimums for future (next year's) major releases, TBD.
Explore, enjoy, get your software ported to the new interfaces, and let us know any problems before it's fully set in stone at the end of this month.
--
Larry Gritz
***@larrygritz.com