Compare commits

..
304 Commits
Author SHA1 Message Date
Larry Gritz fbce7d59f4 fix(ustring): fix Cuda warnings (#3978)
To my eyes, these two constructors look like they should be treated as
doing exactly the same thing:

    MyType()
        : mymember(...)
    { }

and

    MyType()
    {
       mymember = ...;
    }

But nvcc in Cuda mode says no, if the constructor is constexpr, the
former is okey dokey, but latter gives a warning. Fine, Cuda, whatver
you say.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-09-08 13:41:19 -07:00
Larry Gritz 616bf69fef build: Fixes to work properly with fmt 10.1 (partial port of #3973)
Rig CI to properly test "latest" and "bleeding edge" fmt. It turns out
we had not yet been testing 10.1 or keeping up with their master.

In the process, I discovered that the combo of fmt >= 10.1 and gcc >= 11
results in a mangled AVX math heisenbug, symptomatic in our simd_test. I
struggled with this on and off for many days, having great difficulty
reproducing (though it does fail every time and deterministically, I
just can't seem to narrow it to a smaller example). It only happens with
gcc, only gcc >= 11, only when we use FMT_EXCEPTIONS=0 to disable true
exceptions in fmt. The change happens specifically at fmt commit 9a034b0
(midway between 10.0 and 10.1), which changes the definition of
FMT_THROW when exceptions are disabled. Why this should affect SIMD math
is a total mystery, and currently I am suspecting either a gcc compiler
error or that it's exposing undefined behavior. I found that redefining
FMT_THROW on our side to something innocuous is a good workaround. If I
no longer disable fmt exceptions, that also makes it work, but I don't
know what that might break for us or downstream.

My report of this to the fmt project is
[here](https://github.com/fmtlib/fmt/issues/3620), maybe they'll uncover
the true cause.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-09-05 10:59:44 -07:00
Larry Gritz be3c19a978 Bump version after release
Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-09-01 14:29:12 -07:00
Larry Gritz 9984e93000 Stage release v2.4.15.0
Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-09-01 09:48:29 -07:00
Larry Gritz 1738e0a6a5 ci: Bump 'latest release' test to OpenEXR/Imath 3.2 and OCIO 2.3 (#3971)
Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-09-01 09:48:29 -07:00
Larry Gritz 904e8dfc37 build: Fix broken libheif < 1.13 (#3970)
Typo introduced in #3894 broke our ability to build against libheif <
1.13. A conditional compilation that should have kicked in for >=1.16
was mistakenly written as 1.6.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-08-31 17:11:33 -07:00
Larry Gritz f58124dd60 admin: Relicense code under Apache 2.0 (#3966)
This is Update 4, the original PR is ongoing and we will continue to
update as additional people relicense.

Per PR #3905 (https://github.com/OpenImageIO/oiio/pull/3905), update the
RELICENSING document with the names of people and companies who have
signed on to the relicensing thus far, and update the SPDX license
notices on source files whose extant authorship (per 'git blame')
comprises only authors who have relicensed.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-08-29 21:56:27 -07:00
Larry Gritz 21e10fb2c0 Admin: Add Jesse Yurkovich to the TSC (#3937)
Proposal from Thiago to add Jesse Yurkovich, representing Blender, to
the TSC.

Vote passed by majority of TSC members voting yes on the PR itself.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-08-27 22:01:42 -07:00
Jesse Yurkovich 4836a21950 fix(dds): Fix div by 0 during DXT4 DDS load (#3959)
Fixes #3950

Fix the div-by-0 when handling unassociated alpha during a DXT4 DDS
load. The code mirrors what other formats do by first checking to see if
the alpha value is not 0 before continuing.

Added the 218-byte file from the bug to the local test suite.

---------

Signed-off-by: Jesse Yurkovich <jesse.y@gmail.com>
2023-08-25 11:43:09 -07:00
Mikael Sundell 84cd074604 build: Added check for Boost_NO_BOOST_CMAKE, ignore if already set (#3961)
Enable set of Boost_NO_BOOST_CMAKE through make using
MY_CMAKE_FLAGS=-DBoost_NO_BOOST_CMAKE:BOOL=OFF.

Signed-off-by: Mikael Sundell <mikael.sundell@gmail.com>
2023-08-25 11:43:02 -07:00
Jesse Yurkovich 1f05697cbd Fix(rla): Invalid read from an empty vector during RLA load (#3960)
The incoming length of the RLE data could be 0. In this case we would
attempt to take the address of the 1st element of an empty vector.

Added a new 1004-byte file to the local test suite.

Fixes #3951

---------

Signed-off-by: Jesse Yurkovich <jesse.y@gmail.com>
2023-08-25 09:03:39 -07:00
Jesse Yurkovich 2031172953 cleanup: Fix typo in debug output (#3956)
Fixes a typo in the debug output triggered during the image plugin
search sequence.


Signed-off-by: Jesse Yurkovich <jesse.y@gmail.com>
2023-08-25 09:02:00 -07:00
Larry Gritz 88249cf59a fix: various protections against corrupted files (#3954)
Fixes #3952

Several interrelated fixes to guard against corrupted files:

* Extend the `limits:imagesize_MB` sanity check to Targa files to
address #3952 specifically, and check in that failing example file into
the testsuite. (N.B.: Only a couple readers use this, TIFF and now
Targa. it should be extended to the others. Mackerel!)

* Improve the error message used for the above, both for Targa and TIFF.

* For low-memory situations, perhaps the default of 32GB is too large.
Make the default be the minimum of 32GB and 1/2 the size of physical
memory on the machine. (An app that legit expects humongous files is
expected to raise the limit appropriately.)

* The generic "Read error: hit end of file" we sometimes issued from
`ImageInput::ioread()` was hard to discern which reader it came from, in
cases where the file extension was absent or misleading and a succession
of files were tried. By changing this error message to say which format
reader triggered the error, it might make these errors easier to track
down in the future. This also changed the reference output of a few test
involving truncated or corrupted files.

---------

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-08-24 22:31:51 -07:00
Larry Gritz cd1ffe5abf ci: Make more robust timer_test (#3953)
On overloaded VMs, the timer_test is ureliable and fails spuriously too
often.

Two strategies in this patch, hope some combination does the trick:

1. Increase the absolute error allowed for the timing tests when doing
CI runs.

2. Add just a bit more relative error (via a new unit test macro,
OIIO_CHECK_EQUAL_THRESH_REL).

Hopefully this will cut down on CI failures for unit_timer test case.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-08-24 18:09:36 -07:00
ShootfastandLarry Gritz 6cbd1e8fa2 build: Silence gcc new/delete warnings for texturesys (#3944)
Disable GCC warnings around mismatched new/delete for shared_texturesys
creation


Signed-off-by: Shootfast <markboo99@gmail.com>
Signed-off-by: Larry Gritz <lg@larrygritz.com>
Co-authored-by: Larry Gritz <lg@larrygritz.com>
2023-08-24 18:09:20 -07:00
Larry Gritz e015ae4293 dev(ustring.h): string literal operator for ustring and ustringhash (#3939)
* Add string literal operators for ustring and ustringhash so you can
write: ``` "foo"_us "bar"_ush ``` Note that on Cuda (but not on the
host), this ustringhash construction is constexpr.

* Add a new `ustringhash(const char*, size_t)` constructor, which is
also constexpr on the device side.

* Mark the existing `ustringhash(string_view)` constructor as constexpr
on the device side.

We can mark those things as constexpr on the device side because on the
Cuda side, the implementation only takes the hash (which is constexpr),
and does not actually add a ustring to the table (which cannot be
constexpr). To make such declarations easy, add a new macro to
platform.h, `OIIO_DEVICE_CONSTEXPR` which is constexpr for the device,
merely inline for the host.

---------

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-08-24 18:09:11 -07:00
xiaoxiaoafeifei 672ed4c445 fix(bmp): fix signed integer overflow when computing total number of pixels (#3948)
fix #3947: runtime error: signed integer overflow in file
src/bmp.imageio/bmpinput.cpp:302
2023-08-20 11:21:34 -07:00
Larry Gritz c90efcf167 admin: Update pull request and issue templates (#3946)
The most important fix is to remove links to the old CLAs and update
references to the mail list to the new one.

Also spruced up some language while I was there, hopefully to coax out
improved PRs and Issues.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-08-20 11:21:14 -07:00
Anton Dukhovnikov 65e3838985 build: suppress Xcode warnings (#3940)
When building the code with Xcode ("cmake -G Xcode"), there are 1000+
warnings about implicit 64 to 32 bit conversion.
This change adds a compile option to suppress such warnings when
generating an Xcode project.

Signed-off-by: Anton Dukhovnikov <antond@wetafx.co.nz>
2023-08-12 08:51:08 -07:00
Larry Gritz 6d2b4194e7 admin: Relicense code under Apache 2.0 (#3938)
This is Update 3, the original PR is ongoing and we will continue to
update as additional people relicense.

Per PR #3905 (https://github.com/OpenImageIO/oiio/pull/3905), update the
RELICENSING document with the names of people and companies who have
signed on to the relicensing thus far, and update the SPDX license
notices on source files whose extant authorship (per 'git blame')
comprises only authors who have relicensed.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-08-03 21:06:20 -07:00
NicolasandLarry Gritz 99e4bc86ac fix: utf-8 text rendering (#3935)
Text rendering doesn't work with utf-8... 

I can't render chinese, arabic... or special chars as éèûîà...

It seems that the string function to convert utf-8 to unicode is quiet
simple.

Fixes #3933 

[Note]: OpenImageIO is used in the [gpx2video
project](https://github.com/progweb/gpx2video).

---------

Signed-off-by: Nicolas VIVIEN <nicolas@vivien.fr>
Signed-off-by: Larry Gritz <lg@larrygritz.com>
Co-authored-by: Larry Gritz <lg@larrygritz.com>
2023-08-03 20:55:56 -07:00
Larry Gritz 59953474b2 Bump version after release
Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-08-01 17:05:44 -07:00
Larry Gritz 40cff8d4a5 Docs: Make sure README has links for slack and meetings (#3936)
Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-08-01 13:15:24 -07:00
Larry Gritz 4d7fed6984 Stage for v2.4.14.0
Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-07-30 17:06:27 -07:00
Jesse Yurkovich 9757e20694 fix(python): Fix arithmetic overflow in oiio_bufinfo (Python interop) (#3931)
When an incoming 1-dimensional, buffer-like, object was used in Python,
the corresponding check inside OIIO would overflow if its length
exceeded a signed 32bit value.

An error similar to `Pixel data array error: Python array shape is
[2304000000] but expecting h=24000, w=24000, ch=4` would be raised.

I modified a few similar calculations and tried to follow the
predominant pattern already used.

Tested using the following snippet which would previously fail:
```
import OpenImageIO as oiio
import numpy as np

filename = "t:/foo.png"
xres = 24000
yres = 24000
channels = 4  # RGB
pixels = np.zeros(xres * yres * channels, dtype=np.uint8)

spec = oiio.ImageSpec(xres, yres, channels, "uint8")
image = oiio.ImageOutput.create(filename)
image.open(filename, spec)
if not image.write_image(pixels):
    print("error = ", image.geterror())
image.close()
```

---------

Signed-off-by: Jesse Yurkovich <jesse.y@gmail.com>
2023-07-29 11:06:19 -07:00
Larry Gritz 0881ebdedb build: bump build_openexr and build_opencolorio defaults to latest versions (#3920)
Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-07-29 11:06:03 -07:00
Larry Gritz 20756dad13 admin: Relicense code under Apache 2.0 (#3926)
Per PR #3905 (https://github.com/OpenImageIO/oiio/pull/3905), update the
RELICENSING document with the names of people and companies who have
signed on to the relicensing thus far, and update the SPDX license
notices on source files whose extant authorship (per 'git blame')
comprises only authors who have relicensed.

This is part 2, the original PR is ongoing and we will continue to
update as additional people relicense.

Signed-off-by: Larry Gritz <lg@larrygritz.com>

---------

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-07-29 11:05:46 -07:00
Larry Gritz 39f2022aca docs: Put logo on the main readme (#3927)
Add some logo images in ASWF/logos for handy use.

---------

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-07-29 11:05:24 -07:00
Larry Gritz ec4ead0cbb ci: Lock down icx version (#3929)
Intel's servers have again updated the default icx that you get when you
install from their yum repository, and the new one seems incompatible
with our libstdc++ toolchain. So lock down on 2023.1.0 for now so that
our CI can pass.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-07-29 11:05:12 -07:00
jasonbaumeister 77c2a8b217 feat(ico): Add IOProxy support to ICOInput (#3919)
This updates ICOInput to use the IOProxy model so it can read from files
or the IOMemReader

Signed-off-by: Jason Baumeister <jason@jasonbaumeister.com>
2023-07-29 11:03:17 -07:00
jasonbaumeister c9d75870c6 fix(psd): CMYK PSD files should copy alpha (#3918)
During the CMYK to RGB conversion in PSDInput, the alpha channel was
never copied to the RGBA output. Converting a PSD to JPEG worked because
it ignored all the 0 alpha values, but converting to WebP would result
in a fully transparent image.

I added a cmyk-with-alpha.psd test to the psd-colormodes test to check
this

Signed-off-by: Jason Baumeister <jason@jasonbaumeister.com>
2023-07-29 11:02:53 -07:00
Larry Gritz b32e546d16 ci: Test against pybind11 v2.11 (#3912)
Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-07-29 11:02:39 -07:00
D-Spirits c1f43ae796 Admin: Add DevilishSpirits to RELICENSING.md (#3922)
For the relicensing request in #3905 and signed with my personal PGP
key.
2023-07-29 11:02:05 -07:00
Larry Gritz f8f342f08a build: Fix broken OIIO_NO_NEON definition (#3911)
Clean up the `#if` tests that disable Intel SIMD when not on Intel
architectures, which incorrectly disabled ARM NEON when on ARM.

Fixes #3909

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-07-16 21:48:49 -07:00
Jesse Y 5ca4b06516 docs: Update ImageInput docs to not use deprecated APIs (#3907)
Update the ImageInput documentation to not use the deprecated
`read_image` APIs.

Based on the discussion in #3902

---------

Signed-off-by: Jesse Yurkovich <jesse.y@gmail.com>
2023-07-15 16:46:20 -07:00
Larry Gritz 23751c1bf1 admin: Relicense code under Apache 2.0 (#3914)
Per PR #3905 (https://github.com/OpenImageIO/oiio/pull/3905), update the
RELICENSING document with the names of people and companies who have
signed on to the relicensing thus far, and update the SPDX license
notices on source files whose extant authorship (per 'git blame')
comprises only authors who have relicensed.

This is part 1, the original PR is ongoing and we will continue to
update as additional people relicense.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-07-15 16:46:15 -07:00
Benjamin Buch 110ed69660 build: Find OpenEXR equally well with our FindOpenEXR and exr's exported config file (#3862)
If OpenEXR is found by cmake config file, OpenEXR_VERSION is set instead of OPENEXR_VERSION

Signed-off-by: Benjamin Buch <benjamin.buch@technoteam.de>
2023-07-15 16:45:52 -07:00
Benjamin Buch 3ab3231304 build: Fix WebP linking if CMAKE_FIND_PACKAGE_PREFER_CONFIG is ON (#3863)
Our own FindWebP.cmake was setting up targets that didn't
match the capitalization of the cmake configs that come with WebP itself.

Signed-off-by: Benjamin Buch <benjamin.buch@technoteam.de>
2023-07-15 16:45:43 -07:00
Larry Gritz 99542f910d admin: Mark more files that LG has contributed to as 'and Apache-2.0' (#3906)
This batch is for files that LG (relicensed!) has contributed, in
addition to >2 other authors. Also add appropriate license notices to
some that had no posted license before due to oversight.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-07-13 18:19:29 -07:00
Larry Gritz a21aa460ff admin: Copyright and license notice updates (#3904)
* Add copyright/license notices to some mixed-authorship files that
lacked them before (all related to tests)
* Get rid of the pointless year in many copyright notices (change to the
current LF recommended wording)

---------

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-07-08 20:38:16 -04:00
Larry Gritz 95177f11a6 admin: update licensing (#3903)
Since LG has re-licensed all his old code under Apache-2.0, we can
change the license notice from BSD to Apache-2.0 for all files in which
LG is the only extant author. Also change all files that LG co-authored
with other people to specify "BSD-3-Clause and Apache-2.0".

Some files (mostly test scripts) had no license notice, so in those
cases, we added one.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-07-08 20:37:06 -04:00
Larry Gritz ab08205f6a admin: Change open source license to Apache 2.0 (#3899)
By majority vote of the TSC, we are changing OpenImageIO's main
incoming/outgoing open source license from BSD-3-Clause to Apache-2.0.
New code submitted from July 1, 2023 will be contributed under the
Apache 2.0 license.

Old code submitted prior to July 1 2023 is under the original BSD
3-clause license, unless relicensed per the process described in the new
RELICENSING.md file. We hope to get the vast majority of the code base
relicensed quickly and we will document which set of files contain a
mixture of licenses.

Instructions to everybody reading this:

* If you are contributing code under the authorization of an employer,
please let them know we are changing to Apache 2.0 and make sure that
you are authorized to make all future contributions to under that
license.

* If you made prior contributions to OpenImageIO over the years and are
willing to relicense your code under the Apache 2.0 license, please
submit a PR adding your name to the list in RELICENSING.md. If you were
working for a company that might own your IP output at the time you made
those contributions, please also ask somebody there (who has the
authority to do so) to submit a PR adding the company name as well,
indicating that they are re-submitting all of the old contributions
under the new license.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-07-08 20:33:56 -04:00
Larry Gritz d6c151efba docs: Document CVE
Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-07-08 20:33:22 -04:00
Larry Gritz 50d51f58d7 admin: Remove old CLAs that are no longer in effect
Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-07-05 21:34:11 -04:00
Larry Gritz 91341990f6 admin: Add charter and other ASWF documents to the repo (#3850)
By unanimous vote of the OpenImageIO TSC, as of July 1, 2023, we
adopt the technical charter, Code of Conduct, new CLAs, and GOVERNANCE
document.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-07-05 21:33:51 -04:00
Larry Gritz 7b3d368a87 Bump version after release
Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-07-01 11:54:02 -07:00
Larry Gritz d308780e12 Stage v2.4.13.0
Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-07-01 09:38:58 -07:00
Larry Gritz 8e8dab1215 fix(strutil.h): ensure proper constexpr of string hashing (#3901)
The underlying farmhash algorithm (which is the basis for
Strutil::strhash, and thus ustring's hash representation) turned out to
not be properly constexpr under certain circumstances and needed to be
expressed a different way to be fully constexpr on all platforms and for
all strings.

New implementation suggested by Alex Wells.

Also, make sure string_view ctr from char* can be constexpr, even for
C++14. This is related for the sake of the strhash calls that, when
taking string literals, actually choose the variety that accepts a
string_view.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-07-01 01:29:47 -07:00
Larry Gritz dfa76c7a5e testing: Fix missing simd test due to copy paste typo (#3896)
Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-07-01 00:08:38 -07:00
Larry Gritz b86d8ad011 docs: Document use of the DCO which is now required for all PRs (#3897)
Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-07-01 00:08:20 -07:00
Larry Gritz 9bcd4e7a1f ci: Simplify build_llvm.bash script (#3892)
* Remove leftover logic from when we used TravisCI.
* Pick a default for LLVM_DISTRO_NAME so it works when the script is run
standalone when not on GitHub Actions CI. (But it's still really only
meant to run on x86 Ubuntu, and not designed for anything useful outside
of our CI.)
* Eliminate all the complexity with old LLVM versions -- in practice,
our CI only uses this to download fairly modern clang versions.

Fixes #3891

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-07-01 00:07:51 -07:00
Larry Gritz f11dbfc40d ci: Fix broken heif dependency and test (#3894)
The strukturag repo for libheif recently upgraded the version it was
serving from 1.14 to 1.16, and that caused our tests to fail because (a)
some of the codec support has been moved to plugins that are loaded at
runtime and those are now distributed in packages we need to install
separately; (b) you must call heif_init() or it won't know about the
optional plugins.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-07-01 00:07:19 -07:00
Larry Gritz 84f8acdc56 docs(raw): Fix explanation of raw:Exposure config hint (#3889)
Fixes #3888

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-06-17 16:35:16 -07:00
Larry Gritz c79e11bfcf fix(IBA): Improve error message for IBA::ocio functions (#3887)
If colorconvert, ociolook, ociodisplay, ociofiletransform fail
because OCIO support is not enabled, make sure the error message
makes that clear.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-06-16 18:56:36 -07:00
Fabien Servant @ TCS 44ab7f4192 fix(exif): Convert paramvalue string to integer when needed (#3886)
Make sure we can input exif tags as strings containing numbers when
number are required.

E.G. if my input is "Orientation"=>"8", i would like the jpeg output to
contains the value 8 for the exif tag orientation.
2023-06-16 18:56:30 -07:00
Larry Gritz 55f97a43b7 fix(exr): correction to dwa vs zip logic when outputting OpenEXR (#3884)
PR #2147, addressing issue #1844, is related to an apparent OpenEXR bug
wherein single channel tiled images where the tile dimensions were not a
power of 2 and >= 16 would not work properly with dwa compression. We
work around the problem by automatically substituting zip compression in
those cases. But it was implemented with a subtle bug, forgetting that
tile_size == 0 for untiled images, and thus we were silently switching
from dwa to zip compression for all *untiled* single channel images of
any size (which presumably were never problematic). This patch fixes the
test so we are not changing the compression for the untiled files.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-06-14 13:30:32 -07:00
Larry Gritz 5b2d2066e6 fix(jpeg2000): better pixel type promotion logic (#3878)
J2K output was defaulting to UINT8 when asked to output an unsupported
type. It should have been UINT16 to try to minimize the amount of
precision loss.

Fixes #3876

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-06-14 13:30:32 -07:00
Larry Gritz bd588e5ca8 admin: Update mail list URL (#3880)
Everybody please go to https://lists.aswf.io/g/oiio-dev and sign up for
the new mail list as soon as possible. The old list is on its last legs
and having trouble, let's get this done.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-06-14 13:30:32 -07:00
Larry Gritz c7ff69ff59 ci: Add test with new aswf containers for VFX Platform 2023 (#3875)
Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-06-12 16:40:24 -07:00
Larry Gritz e97403c7ba build: Fix fmt vs gcc warning that had version typo (#3874)
The comment was right, but the test seems to have had a typo we didn't
catch in review.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-06-12 10:21:23 -07:00
Larry Gritz 8add832fa8 fix(psd): Prevent simultaneous psd thumbnail reads from clashing (#3877)
When reading a PSD file, if it contains a thumbnail, we read it from the
in-memory blob with a combination of an IOMemReader and an ImageBuf.
But... we always named it "thumbnail.jpg" without considering that
multiple simultaneous PSD files reading identically named images (but
which are in fact different) could cause a weird kind of clashing in any
underlying use of ImageCache!

The simple fix is to use ordinary ImageInput approach to reading the
thumbnail from the IOMemReader, but just store it in the ImageBuf.

Fixes #3824

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-06-12 10:21:14 -07:00
xiaoxiaoafeifei 749a557b5e fix(ico): heap-buffer-overflow (#3872)
heap-buffer-overflow in function ICOInput::readimg 

fixes #3871
2023-06-10 11:04:50 -07:00
Larry Gritz c095abae93 build: Fix use of OIIO_LOCAL_DEPS_PATH (#3865)
We set it, but we didn't use it where it was intended.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-06-10 11:04:43 -07:00
Jesse Y e43cbe830c docs: Many fixes to python code examples (#3869)
A variety of minor documentation fixups:
- Use Python 3 style 'print' statements consistently everywhere (some
snippets had a mix of both)
- Correct the usage of `ImageSpec::channels` that should be
`ImageSpec::nchannels`
- Template syntax errors in two C++ snippets
- Document the new default for `max_memory_MB`
2023-06-10 11:02:46 -07:00
Ziggy Cross 98ff1e57ae ImageInput and ImageOutput docs updated to Python 3. (#3866)
## Description

Fixes #3846 by updating Python examples.

Current code examples for
[ImageInput](https://openimageio.readthedocs.io/en/latest/imageinput.html)
and
[ImageOutput](https://openimageio.readthedocs.io/en/latest/imageoutput.html)
raise a SyntaxError in Python 3:
```python
File "<cwd>\main.py", line 13
    return
    ^^^^^^
SyntaxError: 'return' outside function
```

It seems these code examples might be for Python 2.7. Perhaps it would
be worth creating an extra tab instead of replacing the old code?

## Tests

Tested on Python 3.11, no issues.

## Checklist:

- [x] I have read the [contribution
guidelines](https://github.com/OpenImageIO/oiio/blob/master/CONTRIBUTING.md).
- [ ] If this is more extensive than a small change to existing code, I
  have previously submitted a Contributor License Agreement

([individual](https://github.com/OpenImageIO/oiio/blob/master/src/doc/CLA-INDIVIDUAL),
and if there is any way my
  employers might think my programming belongs to them, then also

[corporate](https://github.com/OpenImageIO/oiio/blob/master/src/doc/CLA-CORPORATE)).
- [x] I have updated the documentation, if applicable.
- [ ] I have ensured that the change is tested somewhere in the
testsuite
  (adding new test cases if necessary).
- [x] My code follows the prevailing code style of this project.
2023-06-07 16:04:17 -07:00
Larry Gritz 503fb7a511 feat(OpenCV): Improve OpenCV support -- errors, version, half (#3853)
Various improvements to OpenCV support:

* IBA::from_OpenCV and to_OpenCV now set error messages for every type
of failure they encounter, instead of returning false with no
explanation. For from_OpenCV, the error message can be retrieved from
the ImageBuf returned; for to_OpenCV, the error message can be retrieved
from the global OIIO::geterror(). Several assertions were removed,
instead relying on error return codes and messages.

* Add global OIIO attribute "opencv_version" which allows you to find
out what version of OpenCV OIIO was built against, which was previously
impossible to know without seeing the build-time status messages. This
can be retrieved via

      OIIO::get_int_attribute("opencv_version")

  and also you can find out from the command line with

      oiiotool --echo "{getattribute(opencv_version)}"

The return value is an integer encoded as `10000*major + 100*minor +
patch`, and it will return 0 if no OpenCV support was enabled when
OpenImageIO was built.

* For OpenCV >= 4.0, to_OpenCV can now correctly construct a 'half'
matrix. For OpenCV 3.x, we turn it into a float matrix as before, since
CV_16F was only supported starting in 4.0.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-06-02 11:38:35 -07:00
Larry Gritz a7ff737902 docs: Update CONTRIBUTING and SECURITY (#3852)
Just a routine update of these files as I proofread them in light of the
move to ASWF. This patch is addressing the "old" project, there will be
further ASWF-specific edits for changes that will take effect after the
project is fully moved.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-06-02 09:49:13 -07:00
Loïc Vital 1cd944338c fix(jpeg): fix density calculation for jpeg output (#3861)
In `jpegoutput.cpp` when computing the density fields the relationship
between `XRes`, `YRes` and `aspect` is `aspect = XRes / YRes`.

However this relationship was not respected in one specific case, when
`aspect >= 1.0` and `XRes` and `YRes` are not set.

This PR solves this problem by enforcing the correct relationship.

Related to: https://github.com/OpenImageIO/oiio/issues/2822
2023-06-02 09:49:03 -07:00
Larry Gritz 5cb94101ba Bump version after release
Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-06-01 13:02:37 -07:00
Larry Gritz e7fe406481 CHANGES
Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-06-01 10:26:37 -07:00
Larry Gritz 73fdd4281a Stage for v2.4.12.0
Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-06-01 10:11:09 -07:00
Larry Gritz 0c48ae1ae3 ci: Fix package name for icc (#3860)
The Intel yum repo renamed this package a couple weeks ago, and it broke
our CI. Update to the new name.

Adjust fmt use to solve icc warning.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-06-01 07:33:26 -07:00
Loïc Vital 0e9406e17a fix(raw): raw input fix user_flip usage (#3858)
When reading a raw image, setting the `user_flip` to 1 meant ignoring
the `flip` value (to avoid buffer rotation from LibRaw).

However the value 1 for the `user_flip` is **not neutral**: values lie
between 0 and 7 (see
https://www.libraw.org/docs/API-datastruct-eng.html#libraw_image_sizes_t),
and 1 corresponds to a horizontal mirror (in my understanding of the
source code).

The proposed fix is to use 0 as `user_flip` value for ignoring the
`flip` value.

This modification invalidates the changes made in this PR:
https://github.com/OpenImageIO/oiio/pull/3847.
Therefore, flip to orientation conversion has been adapted to match
exactly LibRaw's documentation, which handles only rotations (+90, +180,
-90 degrees).

The previous PR was only tested on images of landscape and human faces,
hence the mirroring issue remained unnoticed.
When reading images containing text however the problem is clearly
visible.
This PR fixes this mirroring issue on the following 4 orientations: 0,
+90, +180 and -90 degrees rotation.
Other orientations could not be tested as they don't seem to ever appear
on raw images datasets.
2023-06-01 07:33:19 -07:00
Larry Gritz 73d99b9733 build(Mac): Fixes for latest xcode on MacOS 13.3 Ventura (#3854)
I found that this was needed after weekend OS update of my laptop.

Also added MacOS-13 CI test.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
2023-05-29 09:52:07 -07:00
Loïc Vital e28cffbf2a fix(raw): fix LibRaw flip to Exif orientation conversion (#3847)
When reading a raw image while having a `user_flip` set to 1, we set the
orientation Exif tag to LibRaw's flip value (so that LibRaw doesn't
rotate and/or mirror the buffer but the image still gets displayed
correctly).

However LibRaw's convention for flip values differ from Exif orientation
values: https://www.libraw.org/comment/5176#comment-5176.

In this PR we fix this issue by converting LibRaw flip values to Exif
orientation values. This conversion is based on:
- https://www.libraw.org/comment/5178#comment-5178 (conversion proposed
by LibRaw's maintainer)
-
https://github.com/LibRaw/LibRaw/blob/6fffd414bfda63dfef2276ae07f7ca36660b8888/src/write/file_write.cpp#L22
(LibRaw's function for applying the flip).

Tested on:
- CR2 images with flip values 1, 5 and 6
- ARW images with flip values 1 and 5
(unfortunately I could not find any image covering other flip values).

Since the conversion is `[1, 2, 3, 4, 5, 6, 7, 8] -> [1, 2, 4, 3, 5, 8,
6, 7]`, the only test that came out with different results before and
after the change is the one with flip value 6:
in that case, the image orientation got corrected by the fix.
2023-05-19 18:56:00 -07:00
xiaoxiaoafeifei 5ff2c56dd2 fix: prevent heap-buffer-overflow in file src/gif.imageio/gifinput.cpp, line 368 (#3841)
Fixes #3840
2023-05-19 18:55:49 -07:00
Larry Gritz 2d0e89bdab fix(int): prevent possible deadlock when reaading files with wrong extensions (#3845)
Make pvt::imageio_mutex be a recursive_mutex

Fixes #3842
2023-05-17 09:24:11 -07:00
Larry Gritz 1ebe68ca90 fix(oiiotool): don't propagate unsupported channels (#3838)
Fixes #3837

oiiotool already attempted to trim extra channels when outputting to a
format that can't support it. It correctly handled the two common cases:

* More than 4 channels for formats that don't have
`supports("nchannels")` will drop after the first 4 channels.
* More than 3 channels for formats that don't have `supports("alpha")`
will drop after the first 3 channels.

But this omits an interesting (but rare) corner case: a 4 channel file
where the last channel is NOT alpha, and the output file supports an
alpha channel but not arbitrary channels. A concrete example might be an
input file that is exr with channels R, G, B, Z, writing to a PNG file
(which can support RGB or RGBA). We wouldn't want to write what appears
to be an RGBA file if that last channel isn't really alpha.

Also, noticed that oiiotool --chnames didn't properly clear the
alpha_channel and z_channel flags, which is important if the new channel
lists drop one of those channels.
2023-05-15 14:49:27 -07:00
Larry Gritz 405909bf70 Improve make_texture for very large images (#3829)
`make_texture()` already took a configuration option "maketx:forcefloat"
(defaults to 1), which if set to 0 disables the conversion to a float
buffer for intermediate computation.

For `oiiotool -otex`, there was no way to specify this. This patch
allows it to be disabled with the new optional modifier
`-otex:forcefloat=0`.

Also, in make_texture, this option only controlled the initial
conversion of the whole buffer to float, but the downsized levels all
were float either way. This patch now uses the forcefloat config option
to also control the buffers used for downsizing.

Disabling forcefloat like this has a speed penalty (the downsizing math
on float buffers is faster than going in and out of float for every
indvidual value) and loses some precision in the process of repeatedly
downsizing to generate the MIP levels. But it can sure save a lot of
memory if you have a ginormous uint8 image and want to avod the 4x
balooning of memory. I don't recommend disabling forcefloat except for
images that can't fit into memory for the texture creation without it.
But when this is the right hammer to use, it can be the difference
between being able to create the texture, or not.

Some other improvements:

* `oiiotool -otex` wasn't outputting ANY status output during texture
output as maketx does, and for that matter, -v and -debug were not being
influencing the behavior of make_texture at all despite it having such
support. So fix to pass down the right flags. Now there are proper
verbose status and debug messages when requested.

* Eliminate useless call to is_monochrome by calling it only when the
previously-computed pixel stats indicate that the average value of all
the channels is the same (if they don't have the same average, there's
no way the pixel-by-pixel values will be the same in all channels for
all pixels). This saves an extra traversal of all the pixel memory
during texture creation.

* Use synchronized/flushed status messages so users can see them as they
are issued for very long maketx tasks. This also included some
conversion from old iostream stuff to fmt-based print.

* For verbose/debug, more fine-grained timing for make_texture, in
particular, print the time spent downsizing and writing each MIP level.
2023-05-15 12:00:45 -07:00
Larry Gritz aead17571b ci: Fix warnings (#3833)
I'm honestly not sure why some GHA CI jobs suddenly started warning
about this in the past day or so. Something must have updated on their
end. But switching to the safer Strutil equivalents fixes it.
2023-05-15 11:59:35 -07:00
Ray Molenkamp 61d234347c Fix: Build error with MSVC (#3832)
`ssize_t` is a posix type, msvc seemingly doesn't know about leading to
a build error with MSVC 2019

usage elsewhere in this files used the `py::ssize_t` type, which seems
to fix this
2023-05-15 11:59:19 -07:00
Larry Gritz adf95f683a build(deps): fmt 10.0 support (#3836)
fmt 10.0 was recently released, and it breaks a lot for us because they
have fully removed legacy support for automatically being able to format
anything that has an iostream `<<` operator. This facility was deprecatd
in 8.1 but could be re-enabled with FMT_DEPRECATED_OSTREAM, but even
that was removed in 10.0.

So this means that we had to write several explicit format handlers for
some types for use with format() and print().

Also, they are even more strict with sprintf/printf which don't honor
the custom formatters as far as I can tell, so in several cases I also
switched those to the std::format/print style.

Fixes #3835
2023-05-15 11:12:34 -07:00
Larry Gritz 5b59ff65e3 One more revision to synchronized Strutil::print (#3828)
This is a continuation/fix for #3825
2023-05-15 11:12:31 -07:00
Larry Gritz e29c89b136 cleanup(strutil): use forward properly for sync::print(). (#3825) 2023-05-15 11:12:26 -07:00
Larry Gritz fa5dd1b222 fix(psd): Improve memory efficiency of PSD read (#3807)
The PSD reader was written 12 years ago by a GSOC student and has
changed little since. The following is not a knock on that student, who
clearly did a good job if his code has survived mostly unomdified for
over a decade. In chasing down problems with handling extremely large
psd files, I've noticed some oddities and inefficiencies that need
fixing. It's not an emergency, so I'll handle it in pieces.

The item addressed by this patch is memory usage and thread concurrency.
It turns out that the reader allocates memory for the scanline reads as
it goes... and basically keeps it in the ImageInput until it's
destroyed, even though it will never actually be used again. I guess
it's just trying to save the next allocation if it reads the same
scanline again or on the next subimage? But this means that if you read
a really big psd image, it's basically doubling the memory use -- it
reads one copy into the user's buffer, but also holds on to this extra
copy for no reason. Also, a bunch of the decoding helper functions
implicitly use this memory, which means we lock a mutex for the duration
of read_native_scanline (which in theory should not be necessary since
all I/O is happening through thread-safe IOProxy calls).

So this patch does the following:

1. Remove both this retained scanline memory as well as some other
scratch memory from the ImageInput, and make it allocated and freed
local to read_native_scanline.

2. Change all the helper methods that used it implicitly so that they
are passed buffers to use. In many cases these have been changed to
`const` methods and in a few cases to `static`, making it much easier to
assure ourselves that they don't modify (or sometimes use at all)
anything in the PSDInput to do their task.

3. The result of these changes means that read_native_scanline doen't
need to modify any of the data methods of the class (though it does use,
without modifcation, some things set up in the course of open). Because
it's now non-mutable, we can also remove the mutex, now allowing
multiple threads to read scanlines from the same file simultaneously
without blocking each other.

4. Some other miscellaneous cleanup, including that some scratch memory
was allocated as std::string (!), whereas it should really be a
`vector<unsigned char>` or `unique_ptr<unsigned char>`, and also
changing some computations from double to float.

There is still some more work to do after this is merged. In particular,
I think now that scanline read is stateless / non-mutable with respect
to the PSDInput object, this is a candidate for adding a multi-scanline
read_native_scanlines method (replacing the default implementation of
looping and calling read_native_scanline serially for each scanline),
which should also be able to read multiple scanlines with some overhead
and allocations done once per block, and with blocks of scanlines
running in parallel using the thread pool. This should be a huge
efficiency gain when reading psd files. But it will wait until the next
patch.
2023-05-05 16:48:22 -07:00
Larry Gritz c903169614 Bump version after release 2023-04-30 22:51:32 -07:00
Larry Gritz 56449a9d72 Stage for v2.4.11.0 2023-04-30 22:50:12 -07:00
Larry Gritz d84fef0922 feat(oiiotool): expression eval NIMAGES gives current stack depth (#3822)
Based on a suggestion Matt Chaput on the oiio-dev mail list.
2023-04-30 11:09:31 -07:00
Edoardo DominiciandEdoardo Dominici 41ced5bf5b Fix float128 compilation of NVPTX backend for LLVM (#3823)
The latest version of libfmt began using the `__float128` type but this
is [not supported in the NVPTX backend for
LLVM](https://discourse.llvm.org/t/compiling-cuda-code-fails/61240/13).
A way to detect this particular platform seems to be to check both
`__CUDA_ARCH__` and `__clang__`.
I am not disabling it entirely on any CUDA target because NVCC 10+
understands `_float128` and generates instructions for it when tested on
godbolt.

Following up from https://github.com/OpenImageIO/oiio/issues/3809.

Co-authored-by: Edoardo Dominici <edoardod@sy1wse0003.al.com.au>
2023-04-30 10:44:18 -07:00
Larry Gritz c7e37e5c5c test: Change the few symbolic links to copies to help Windows (#3818)
Windows isn't smart about symbolic links. There were a few places in the
testsuite where we used symlinks to essentially de-duplicate test
reference images that were expected to be identical. But then the
resulting archive you get when you ask GitHub for a zip file of the
whole repo (which some people download to get OIIO source rather than
git clone) can't be unzipped correctly on Windows (at least not by
cmake's unzip command).

OK, so just change those links to full copies.

Fixes #3811
2023-04-25 17:04:46 -07:00
Jesse Y 561b1ed0f9 build: Fix incorrect branch name when cloning openexr-images for the tests (#3814)
The `openexr-images` repo was never updated after the default branch was
renamed to `main`. This will fix the following silent errors in CI:
```
Cloning into '/__w/oiio/oiio/build/testsuite/openexr-images'...
warning: Could not find remote branch master to clone.
fatal: Remote branch master not found in upstream origin
```

Additionally, the cmake attempted to symbolically link local repos like
`oiio-images` if they were found. Unfortunately this type of link will
fail unless running as admin on Windows (which is rare) and the
COPY_ON_ERROR directive did _not_ work here (cmake 3.24; weird;
sigh...). The output will now look something like the following:
```
-- Linking oiio-images from C:/Users/jesse/source/oiio-images
-- Link result failed to create symbolic link 'C:/Users/jesse/source/oiio/build/testsuite/oiio-images': A required privilege is not held by the client.
-- Copying oiio-images from C:/Users/jesse/source/oiio-images
```
2023-04-25 14:36:01 -07:00
AdamMainsTL 3c8ce0ed00 Support HIF extension (#3813)
I've come across some unsupported files from Canon cameras that have a
.hif extension. These are HEIC/HEIF files with a slightly changed
extension. I have no idea why Canon decided to do this. Without any
changes I am able to open the images, probably because it checks the
header, but I am unable to write to paths with a hif extension.

Some random articles/forum posts mentioning the HIF format in relation
to Canon cameras:
https://www.cameralabs.com/jpeg-vs-heif-canon-hif-comparison/
https://www.dpreview.com/forums/thread/4558661

https://www.reddit.com/r/canon/comments/kjc6xl/new_eos_r6_owner_here_photo_files_show_up_as_hif/
2023-04-24 22:03:20 -07:00
Larry Gritz 2e835bacdf build: ffmpeg 6.0 support (#3812)
It seems to work fine with the new 6.0 with no code modifications, other
than our cmake build misidentifying the version.
2023-04-22 23:15:37 -07:00
Larry Gritz 4646313d35 Refactor simd.h to disable Intel inrinsics when not on Intel (#3810)
Especially when compiling for Cuda.

Fixes #3809
2023-04-19 09:40:19 -07:00
Brad Smith 31bc1e6432 Fix building on OpenBSD (#3808) 2023-04-18 23:51:58 -07:00
Larry Gritz 534e47eef2 fix(psd): Handle very wide images (#3806)
When decoding RLE data, some arguments to decompress_packbits() were
inexplicably declared uint16_t (they were passed uint32_t arguments, and
I honestly don't know why we didn't get a warning all along). This
prevented us from correctly reading PSD images whose width was more than
64k, which I suppose are rare enough that it's not hard to understand
why this went unreported for so long.

But anyway, just changing those parameters to uint32_t does the trick.
2023-04-17 08:54:24 -07:00
Eric Mehl 8ec4a8dca3 Fix fast_exp2 with MSVC and sse4.2 (#3804)
I ran into the problem described in #2929 and did a little digging to
see if I could find the source of the bad color conversions. I tracked
it down to `fast_exp2()`
https://github.com/OpenImageIO/oiio/blob/a77e36250fadfb4c391688eb1df4b3dd88d5e367/src/include/OpenImageIO/fmath.h#L2050-L2080

and in particular the return statement on L2071. In the process of
trying to figure out what part of that return statement was going awry,
I found that separating the bitcasts to separate variables as in this
PR, the problem went away. All testing was done with the `color_test`
added in #3023.

It also succeeded when adding various `std::cout` lines to check what
the values of each computation were, so it does sound like a compiler
optimization that does or does not get triggered is the problem.

Unfortunately I don't know why it's not failing on the CI builds, I
double checked to make sure I'm using the same settings and flags. I
also tested on two different machines and get the same failures, and
success with this patch, on both.

One strange wrinkle is that even without this patch, color conversions
worked fine when using AVX2 for the SIMD mode.

Summary :
Previous results (without this patch)

- USE_SIMD=0 - PASS
- USE_SIMD=SSE4.2 - FAIL
- USE_SIMD=AVX - FAIL
- USE_SIMD=AVX2 - PASS

With this patch
- USE_SIMD=0 - PASS
- USE_SIMD=SSE4.2 - PASS
- USE_SIMD=AVX - PASS
- USE_SIMD=AVX2 - PASS

Visual Studio 2019 versions 16.11.32228.343, 16.11.33328.57 and
16.11.33423.256(same as current Github build runners) in RelWithDebInfo
mode.
2023-04-15 09:43:38 -07:00
Larry Gritz 5187a52dab fix(python): improve error messages of bad python array sizes (#3801)
For cases of calls like `ImageOutput.write_image(array)`, this improves
the error messages when the array dimensions don't match the size of the
image we're writing, in two ways:

1. For the case of 2D images where the dims don't match, print what the
array shape actually is and what was expected. That's more helpful than
just saying "can't figure out array shape" and printing the number of
dimensions (but not the shape).

2. A mistake caused a number of error messages to be substituted by a
cryptic "can't handle numpy array with noncontiguous channels", but that
was only supposed to be for one particular case; fix that.
2023-04-13 11:26:31 -07:00
Larry Gritz 65806259dd fix(raw): handle raw 1-channel raw images (#3798)
Fixes #3797
2023-04-13 11:26:18 -07:00
Larry Gritz f660d2d7fe Bump version after release 2023-04-02 08:43:29 -07:00
Larry Gritz 0b131b231b Stage for v2.4.10.0 2023-04-01 16:34:53 -07:00
Tom Knowles 448d05d51f fix(maketx): Add support for CDFs of bumpslopes channels (#3793)
Currently, if you run oiiotool with --bumpslopes and --cdf at the same time (or -obump:cdf=1), the CDF is only produced for the first four (of six) channels. The techniques described in Burley (2019) actually do apply reasonably to the squared derivative channels, so it's useful to allow all six channels to have CDFs here.

maketx and oiiotool-maketx tests updated with new relevant tests.
2023-04-01 12:42:02 -07:00
Larry Gritz c8559ea177 Testing: improve testing of maketx (#3748)
* Tests for maketx -u, --attrib, --sattrib, --cdf

* maketx was documeted to take --cdf as a simple flag, but was
  incorrectly implemented as requiring a (pointless) nonzero argument.
  Fix it and hope nobody was depending on the undocumented behavior.

* maketx -v arg never had any effect. Add it back.
2023-04-01 11:50:59 -07:00
Larry Gritz 5e386bc330 Document that OIIO builds fine with clang 16 2023-03-31 19:10:05 -07:00
Larry Gritz 9d933a75d1 CI: bump 'latest versions' test to the newest openexr release (#3796) 2023-03-30 23:41:42 -07:00
johnfeaandTuomas Tonteri d3c6fd2e4d Make project compile with clang 11.0.1-2 in Mac (#3795)
Co-authored-by: Tuomas Tonteri <e90@tuomastonteri.fi>
2023-03-30 23:41:38 -07:00
Larry Gritz 12931a4891 fix: unique_ptr type mismatch caught by sanitizer (#3790) 2023-03-12 00:53:21 -08:00
Larry Gritz 2f92fcb894 fix(gif): gif.h array overrun (#3789) 2023-03-12 00:09:41 -08:00
Larry Gritz 7fa327a634 docs: edit INSTALL to correctly reflect changed dependencies lately
There were still some bolded (indicating newly changed) dependency
minimums that actually were bumped in 2.3 and should have been
unbolded long ago.
2023-03-11 15:36:53 -08:00
Larry Gritz 9934ab38a9 ci: updates to runners, dependencies (#3786)
* Don't use deprecated ubuntu-18.04 runner. Switch to running on
  ubuntu-20.04, but use docker containers that supply ubundu-18.04.

* Bump 'latest' version of openexr, webp, pugixml.
2023-03-11 15:08:09 -08:00
Larry Gritz 3a0d7d068f fix(IC/TS): Avoid deadlock situations with file handle cache (#3784)
There turns out to be a way to get wedged into a mutual deadlock on
the file handle cache, with how get_texture_info on a udim pattern
checks to see if the attribute requested is present and equally valued
in all constituent files of the udim set. This hits the handle set
pretty hard, and if multiple threads are hammering the same sets and
rapidly cycling textures out of the cache, there can be trouble, it
seems.

Remedies in this patch:

* When it's trying to close files because the number of handles is too
  high, we already had it so that if we only exceeded the max_files
  limit by a little bit, we would simply try to get the lock, and
  abandon the attempt if somebody else is holding it, but if we are
  quite a bit over, then stay and wait for the lock to be released.

  In this patch, we make the that default behavior -- if we are over
  the limit and need to free some handles, simply try to get the lock,
  and if somebody else is holding it, leave it all up to them and
  return immediately. The pros of this are (a) snappier response by
  never waiting at this point, and (b) removing the possibility of a
  deadlock, because if you can't acquire the lock, you just move
  on. But the con is that lots of threads adding new files may run
  faster than the one thread who has the file and is trying to release
  files, so it's possible that the number of handles will exceed the
  limit by a wider margin now, but hopefully only momentarily.  (But
  note that this can be overridden with a new ImageCache attribute
  "max_open_files_strict", which if set to nonzero revert to the old
  behavior. At least for now, in case I am neglecting to understand
  some bad consequence of this change.)

* The recursive_mutex controlling access to the ImageInput in each
  tile cache record is changed to a recursive_timed_mutex, and when
  closing a handle by calling release(), instead of an unconditional
  lock, try acquiring a lock for 100ms. If it fails to do so, it may
  be in a possible deadlock, so just give up and move on. The only
  consequence is that maybe that handle isn't freed after all. It will
  then move on to the next one, not the end of the world, but at least
  it can't get stuck there.

* In find_file, eliminate the call to check_max_files -- it's not
  needed here, since it's also called by open(), which is the only
  time that new file handles might be opened. We just don't also need
  it again simply because we're adding a file to the cache.
2023-03-10 23:01:51 -08:00
Fabien Castan 8a0ac72b0f rawinput: fix typo on CameraElevationAngle (#3783) 2023-03-07 18:16:08 -08:00
Larry Gritz bc75a81fcf Bump version after release 2023-03-01 09:57:57 -08:00
Larry Gritz 246ee42759 CHANGES and stage for v2.4.9.0 2023-03-01 09:52:37 -08:00
Larry Gritz 7abc4faf89 Qt6 compatibility (#3779) 2023-03-01 09:11:42 -08:00
Larry Gritz 3954b098b4 api(ustringhash): make a public explicit ustringhash ctr from hash value (#3778) 2023-03-01 09:10:27 -08:00
jreichel-nvidia e191d3b9eb Add cmake option to disable the stacktrace functionality. (#3777)
Setting the cmake option OIIO_DISABLE_BOOST_STACKTRACE to ON disables the use of
Boost stacktrace at compile time. This avoids dependencies on helper libraries
like dbgeng.dll.
2023-03-01 09:00:54 -08:00
Larry Gritz b4b4dcd6e3 fix(ImageCache): Avoid bad IC stats when no files were read (#3765) 2023-02-13 13:57:30 -08:00
Russell Greene 92a34f8596 use check_cxx_source_compiles instead (#3774) 2023-02-13 13:57:09 -08:00
Larry Gritz c145b80833 Bump version after release 2023-02-13 09:01:31 -08:00
Larry Gritz f4b38d9c30 Stage v2.4.8.1 2023-02-13 08:59:19 -08:00
Larry Gritz a39692256b fix: race condition in TIFF reader (#3772)
* test: Add a corrupted test file

* fix(IC): upon tile read error, mark the file as broken

The idea is to keep fruitlessly reading from a corrupted file.

* fix: race condition in TIFF reader

TIFFInput::read_native_tiles had a very subtle race condition.  There
is a section where it has a task_set of decompression tasks that are
sent to the thread queue.  When the method ends, the task_set goes out
of scope, and its destructor will wait for all the remaining tasks to
finish. All fine, right? Except that other variables in the function
include unique_ptr's with allocated memory that the tasks need.  So
what can happen is that if the compiler generates the code such that
the destructor of the unique_ptr happens before the destructor of the
task_set, the memory that the unique_ptr held may be deallocated
before some of the tasks still running in threads have finished.

In practice, we seem only to hit this race condition for particular
cases involving corrupted files, because the early `return` seems
quite likely to run those destructors before all the threads are done,
but it was possible to encounter it for valid files as well, if the
timing is just right. Shocking that we never had it reported.

The solution is just to have an explitit tasks.wait(), which will
block until all the tasks have finished before hitting the actual end
of the method and letting the other destructors to run. And for the
"early return" case, change it to a break so that we go through the
wait call at the end.

I believe that this fix addresses TALOS-2023-1709 / CVE-2023-24472.
2023-02-13 08:38:19 -08:00
Larry Gritz 6a7e404804 fix(fits): Make sure to close if open fails to find right magic number (#3771)
There are two ways to fail the FITS magic number check: fail to read
the bytes, or the bytes don't match the magic number. It seemed
suspicious that we call close() for the latter but not the
former. Combine them into a single error response (they had the same
message, anyway).

Also, make sure FitsInput::init() fully clears some other data
structures.  Oversight?

I don't know if any of these things are real bugs, but they look
sloppy and potentially problematic, so fixing them up.
2023-02-12 21:32:49 -08:00
angusdavisadobeandLarry Gritz f222d05930 improve thread safety for concurrent tiff loads (#3767)
* Make lookups of const unordered_maps thread-safe

* added back deleted end brace

* clang-format

---------

Co-authored-by: Larry Gritz <lg@larrygritz.com>
2023-02-10 12:42:32 -08:00
Larry Gritz 209bb4c327 fix(targa): guard against corrupted tga files (#3768)
* Be more careful constructing strings from what we read in the header;
  corrupted files may make them not be zero-terminated.
  Fixes TALOS-2023-1707 / CVE-2023-24473

* Watch out for pixels with palette indices that exceed the size we
  allocated for the palette.
  Fixes TALOS-2023-1708 / CVE-2023-22845

* Check alpha_type for valid range.
2023-02-09 13:35:13 -08:00
jreichel-nvidiaandJoachim Reichel bd319821e8 Initialize OpenEXROutput::m_levelmode() in init(). (#3764)
Avoids conditional jump on uninitialised values in close().

Co-authored-by: Joachim Reichel <joachim.reichel@posteo.de>
2023-02-04 22:18:48 -08:00
Latios96 0ad9b297d8 Fix unresolved external symbol for MSVS 2017 (#3762) (#3763)
If char16_t is used as template argument, this leads to an unresolved symbol for MSVS 2017.
Use int16_t instead of char16_t in this case
2023-02-04 15:37:30 -08:00
Larry Gritz 1a72ae7c31 Bump version after release 2023-02-01 11:16:53 -08:00
Larry Gritz 4991ac482e CHANGES and stage for v2.4.8.0 2023-01-30 14:36:11 -08:00
Larry Gritz 069a1877af Fix CHANGES typo 2023-01-26 14:06:26 -08:00
Larry Gritz bed036cfd6 Update CVE designations in CHANGES 2023-01-19 13:52:32 -08:00
Brecht Van Lommel cf8d6bf5cd Fix wrong oiio:UnassociatedAlpha spec for PSD files (#3750)
Refactoring in #1641 incorrectly caused this to be set on the last layer
rather than the composite image as before. Now set it on the composite
image and every layer, as all of them use unassociated alpha.
2023-01-12 14:28:43 -08:00
Larry Gritz 8bb093b162 Comment out parts of libcineon that are not used by OIIO (#3747) 2023-01-08 19:24:16 -08:00
Larry Gritz d648187d04 Clarify comments in documentation of IBA::make_texture 2023-01-08 19:24:08 -08:00
Larry Gritz 0665bffad3 Additional testing and improved code coverage (and minor fixes) (#3745)
* Better Typedesc testing of 'tostring' with fmt style formatting
  commands, and fix a bug that uncovered.

* Refine 'make CODECOV=1' behavior

* Beef up python-imagecache test to test getpixels, more attribute,
  invalidate.

* Better testing of python IB construction from numpy array.

* testtex: Use correct guard to avoid compiling unused code for
  coverage analysis testtex: get rid of unused 3d warp code.

* Add texture-threadtimes test

* Eliminate redundant code in exroutput.c by implementing
  write_scanline using write_scanlines.
2023-01-08 19:23:57 -08:00
Joris NijsandJoris Nijs fdbf190e2b Add EXIF write support to PNG output. (#3736)
* Add Exif write support to PNG output.

Stores any Exif data from the given ImageSpec into the PNG eXIf chunk.

* add test for writing Exif data in png

* add test reference output for libpng versions not supporting the eXIf chunk.

* Update testsuite/png/ref/out-libpng15.txt

Co-authored-by: Joris Nijs <joris.nijs@esko.com>
2023-01-08 11:47:47 -08:00
Larry Gritz 3edc96fdea Docs: minor improvments in description of ociodisplay and others 2023-01-08 11:14:15 -08:00
Larry Gritz 2b663e0061 ImageSpec:set_colorspace() (#3734)
Sets color space metadata. While conceptually, the main job is to call
`attribute("oiio:ColorSpace",name)`, this is a central spot to add
logic that adjusts or removes other contradictory metadata.
2023-01-07 23:54:22 -08:00
Larry Gritz 161b2a4c12 Docs: for rtd, upgrade sphinx/breathe versions, use furo theme (#3737)
I think this looks better.

Also a few minor tweaks to typos and misquotes.
2023-01-07 23:52:07 -08:00
Larry Gritz 9d514db8c6 CI: Lock down to older icc so it's not broken (#3744)
The new 2023 one on the Intel site seems to require a glibc too new to
be compatible with the one on the ASWF CentOS-7 based containers, so
has been breaking our CI for a couple weeks.
2023-01-07 18:03:03 -08:00
Larry Gritz ad34901684 Testing: get rid of testtex's datatime query, for test consistency (#3741) 2023-01-07 11:59:42 -08:00
Larry Gritz cba5c59fe9 Add testing for maketx --lightprobe, fix bugs (#3732)
We never had a test for `maketx --lightprobe`, so add it to
testsuite/maketx.

Immediately discovered that it only worked correctly for float images,
fails for half or other types. Fix.
2023-01-07 11:59:08 -08:00
Larry Gritz 17daba2ec0 texture3d testing, fixes, refactoring, coverage (#3699)
* More extensive testing of texture3d: handle vs filename, subimages,
  >4 channels, closest sample interpolation.

* Fixes for tex3d > 4 chan that turned out to be broken.

* Some rearrangement for the >4 channel case

* Refactor and simplify accum3d_sample_bilinear so multiple data types
  all use the same templated code path.

* This all reduces the amount of untested code in OIIO by another 0.4%.
2023-01-07 11:59:00 -08:00
Larry Gritz 0433073464 Testing; better tests of environment mapping, minor fixes (#3694)
Would you believe we never had a testsuite test for environment
mapping?  Well, it wasn't totally untested, in the sense that OSL
testsuite had one, and obviously it's used in production all the
time. But OIIO's testsuite didn't have any tests of
TextureSystem::environmemt(). We now remedy that.

* Add testsuite/texture-env, contains several environment tests,
  including handles vs filenames, subimage selection, different interp
  and mip modes, ask for >4 channels.

* New CMake build option OIIO_TEX_IMPLEMENT_VARYINGREF can be used for
  testing to disable implementation of the old 1.x style of batch
  texture calls.  We don't use them, they are deprecated. This option
  give us a way to exclude them from code analysis, because we really
  don't care.

* Fix bug with >4 channels for environment batch shading!

* Avoid unnecessary spec lookup in TileID constructor.

* Avoid building testtex test_hash during code coverage -- it is an
  extremely specialized test, not run in the testsuite, it shouldn't
  really count againt good code coverage.
2023-01-06 23:25:12 -08:00
Larry Gritz 52e5d89129 Testing; Imagecache better testing coverage and some stats improvements (#3654)
* testtex: better control over temp file creation

* Additional texture tests to improve coverage of udim generation,
  and deadling with cache limits.

* Better ImageCache unit tests for perthread create/destroy and
  individual tile retrieval. Fix a bug in get_tile for nonexistant
  subimage or miplevel.

* Dead code removal: ImageCacheFile::udim_to_concrete() and
  find_file_no_add(), which were no longer called anywhere.

* IC stats: fix messed up 'slowest' list ordering when there are broken files

* IC stats: when stats level is high, enable printing of some stats that
  we previously skipped over when they were "uninteresting" (e.g., too
  little time spent on something, no problematic files, etc).

* IC testing: test a variety of get_pixels error conditions

* IC testing: more tests of IC::imagespec() and get_imagespec(), incluing
  error conditions.

* More get_texture_info query testing

* Minor bug fix for int-to-float data conversion in get_image_info

* Test IC query for resolution[3]

* Test IC::reset_stats()

* Fix ImageCache::reset_stats in cases where threads ended
2023-01-06 21:44:40 -08:00
Larry Gritz 7086a599fa CI/Testing: many improvements for testing and code coverage (#3730)
* When checking code coverage, don't abort for failed tests
* Rejigger imagebufalgo_test a bit for better IBA test coverage
* Test zover
* Have testsuite/oiiotool-fixnan test with deep images
* Add to the extisting --fixnan tests a test for 'error' mode.
* [Excluded from backport to 2.4] Make testsuite/oiiotool-color test all colormap names
* Test 2D filters in filter_test
* Exclude python scripts in src/doc from coverage analysis
* Remove redundant attribute-seting code from the python internals
* Remove unused python_array_code function
* Exclude some imported code from coverage testing
* Re-enable and improve coverage testing from 'make CODECOV=1'
* Exclude unused/unexposed parts of xxhash.cpp from compilation
2023-01-06 15:28:34 -08:00
Larry Gritz fae8da1a9f Fix long-broken ref images for texture-icwrite test (#3733) 2023-01-06 14:12:30 -08:00
Larry Gritz 76609e0a8c pbm: Fix for incorrect inverting (#3731)
We didn't have thorough tests of pbm/pgm/ppm files, add some.
That immediately uncovered a problem with pbp files.

By spec, pbm (1 bit) files use 1 to mean black, 0 for white.
Confusing, because pgm (grey) and ppm (rgb) use 0 for black.
2023-01-06 14:12:23 -08:00
Larry Gritz 400fb3dbd4 platform.h: set up macros for detecting MSVS 2019 and 2022 (#3727) 2023-01-06 12:43:40 -08:00
Larry Gritz e82040a939 typedesc.h: Extend TypeDescFromC template to the full set of pixel types (#3726) 2023-01-06 12:43:36 -08:00
Larry Gritz 628726e46a IBAprep should not zero out deep images when creating dst (#3724) 2023-01-06 12:43:26 -08:00
Larry Gritz 58e090e329 Fix static analysis warning about array extent 2023-01-06 12:43:18 -08:00
Larry Gritz ab8027fc42 oiiotool --pdiff: test, be sure to count it as making output (#3723)
We had no testsuite exercise of --pdiff, add it.

Along the way, I saw tha we were getting the "you didn't have any
output" warning when using pdiff, so fix that.

And some other minor changes: formatted output update, some other
tightening up of things.

A little bit of jiggling the contents of XYZtoLAB_color to work around
what I think is a compiler error with icx -- it was generating NaNs
for reasons I was unable to understand or fix, but not if I rearranged
the code slightly. All the other compilers and versions had correct
behavior.
2023-01-06 12:00:12 -08:00
Larry Gritz 417155cc18 BMP: set colorspace to sRGB (#3701)
Seems like a reasonable assumption for BMP files.  It's not strictly
correct -- there are header fields on V4 and V5 BMP files that
communicate color primaries and gamma, but honestly, I do not have any
idea if anybody uses them or whether they're more misleading than
helpful. For now, assuming that a BMP file is meant for output on
an sRGB display seems like it's likely to be true.
2023-01-06 11:29:10 -08:00
Larry Gritz 18caee105a Bump version after release 2023-01-05 23:39:20 -08:00
Larry Gritz b178a54ee3 CHANGES and stage for v2.4.7.1 2023-01-03 19:05:13 -08:00
Larry Gritz 91c3a7c4c4 CMake config should not include a find of fmt if it's internalized (#3739) 2023-01-03 18:12:54 -08:00
Larry Gritz 5590f2403b CI: Temporarily lock fmt to 9.1.0 because its master seems broken (#3738)
Investigate later. For now, this is necessary for us to pass CI.
2023-01-03 17:08:44 -08:00
Larry Gritz 6f684e6261 Update ref output 2023-01-03 17:08:19 -08:00
Larry Gritz 0cafbcd471 Fix typos 2023-01-03 11:41:38 -08:00
Larry Gritz 3fdee625f4 Move ARM_NEON definition and fix possible double define (#3735)
It should not have been set in platform.h (inside the cpuid function!)
in the first place. And apparently, though this was ok for Windows ARM,
on Mac ARM it's an error because that symbol is already defined.
So only redefine it if it's currently undefined. And move the whole
check and definition into simd.h where all the other ARM_NEON stuff
lives.
2023-01-03 11:41:15 -08:00
Larry Gritz 9e94856ff2 Fix date 2023-01-01 09:42:31 -08:00
Larry Gritz 24f253cce3 CHANGES and stage for 2.4.7.0 release 2022-12-31 23:45:00 -08:00
Larry Gritz fcc6cfdf9b Make sure to retrieve oiio-images tests data specific to this branch 2022-12-30 09:34:30 -08:00
Larry Gritz e9cfbfbce8 Retroactively fix release notes to document TALOS-2022-1631/CVE-2022-41649 2022-12-24 15:38:44 -08:00
Larry Gritz be1fd307c2 Build: fmt external version flexibility (#3598)
* Build: fmt external version flexibility

The current default behavior is to
1. Check if there's already a copy of fmt found.
2. If not (or if BUILD_FMT_FORCE is ON), download it locally.
3. Copy the relevant fmt .h files as part of the OIIO install in
   OpenImageIO_ROOT/include/OpenImageIO/detail/fmt

This patch adds a new INTERNALIZE_FMT option, which defaults to ON,
whch is the old behavior. But if set to OFF at build time, the fmt
headers will NOT be copied into OIIO's install area (instead, it will
have dummy files that in turn include the real ones).

Set INTERNALIZE_FMT to OFF if you are really sure you want users of
OIIO to use the system install of fmt and not have OIIO install a new
copy.

When an externalized fmt is used, also make sure our exported cmake
config files cause the downstream user to find fmt and pass on the
dependency properly (necessary because strutil.h actually requires
properly including fmt headers).

Eliminate extraneous include_directories of fmt

Bump the auto-download version of fmtlib to 9.1
2022-12-24 13:59:07 -08:00
Larry Gritz bf4e5a869e ustring.h: cuda guards (#3718)
Hide from Cuda some things that can't possibly work in Cuda.
2022-12-22 16:30:07 -08:00
Larry Gritz 065d36c756 Add testsuite coverage of igrep utility (#3715)
Add exception safety in igrep test.
2022-12-22 16:30:07 -08:00
Larry Gritz c8d49a4358 Add a test of the 'term' pseudo-output (#3714)
A few minor fixe to the term code, add a "term:filename" optional hint
to redirect output rather than go to stdout, and also change to the
new std::format notation for output.
2022-12-22 16:30:07 -08:00
Larry Gritz 39120c722d ARM: Fix signed/unsigned simd mismatch in vbool4::load (#3722)
Fixes #3721

Please read the comments in #3721. This is the "local" fix for the
build break due to the type mismatch. It is a band-aid. And it may be
the best solution for the 2.4 branch if we don't want to potentially
break ABIs by changing the definition of any public types.

Still pending is to examine the issue of whether it was a mistake to
define vbool4 storage for neon as uint32x4_t or if we should change it
to int32x4_t to better match the non-simd reference implementation.
After debating that (and identifying somebody with access to an
ARM-based machine to test the solution for us), we may return to
tackle this more fundamental change.
2022-12-22 16:28:40 -08:00
Larry Gritz fc2c2615d9 IOProxy read/write error handling improvements (#3712)
IOMemReader::pread catch out-of-range read positions.

Fixes #3711

Along the way, I noticed that the system pread & pwrite return a
ssize_t rather than a size_t as our IOProxy methods do, so I need to
catch the negative value returns that they use to indicate errors.
2022-12-18 11:54:23 -08:00
Larry Gritz 4c1bdcc752 Build: Suppress warnings about deprecated std::codecvt_utf8_utf16 (#3710)
Another fix for the latest Apple clang, continuing #3709 (I missed
these other spots).
2022-12-17 17:51:59 -08:00
Larry Gritz af3b98c344 Build: Suppress warnings about deprecated std::codecvt_utf8_utf16 on Apple clang (#3709) 2022-12-17 17:51:53 -08:00
Larry Gritz 6ec28a05d3 Revise changes to add a CVE that was fixed 2022-12-17 17:51:06 -08:00
Larry Gritz 7c4253d9fc CI: Fix iinfo test so it works on windows (#3706) 2022-12-11 16:09:56 -08:00
Larry Gritz 7d73c62e8b Excise the last instances of unsafe sprintf (#3705) 2022-12-11 12:11:25 -08:00
Larry Gritz 2a4a1505e4 Remove useless test in hdrinput (#3704) 2022-12-11 12:11:18 -08:00
Michael Oliver 80ef5cd65e build_openexr.bash: bump default version to 3.1.5 (#3703)
bump to 3.1.5 for vfxreferenceplatform cy2022
2022-12-11 12:11:08 -08:00
Larry Gritz 6617e8c865 CI: Fix broken Mac CI with proper numpy install (#3702)
Something changing in homebrew caused CI on the macos11 test case to
fail, starting a few days ago. This fixes.
2022-12-08 16:23:43 -08:00
Larry Gritz 0ba31990fc Refactor common parts out of iinfo and oiiotool printinfo, testing (#3688)
* There was lots of duplicated code between iinfo and `oiiotool -info`.
  Refactor much of that into a new src/libOpenImageIO/printinfo.cpp.
  These are internal functions, no change to public API.
* Test iinfo --hash, --stats, and with nonzero origin and full size
* Test iinfo and oiiotool --dumpdata of deep image
* Test iinfo for subimages, mips, -f, -s
* Some conversion to new print instead of printf

There is probably more such refactoring to do later, I did the easy
parts for now and that's a start.
2022-12-04 11:14:30 -08:00
Larry Gritz 5fd50a69be span minor improvements (#3685)
* Make sure the cspan alias also allows the Extent template argument.

* Add a custom formatter for {fmt} to print spans, like we did for
  Imath types.
2022-12-04 10:21:25 -08:00
Larry Gritz fddc816e80 Bump version after release 2022-12-04 10:21:25 -08:00
Larry Gritz f15d4f4f2d CMake: Adjust how version overrides work (#3653)
Kai Pastor (dg0yt) made an important observation that the way I
recently made OpenImageIO_VERSION be a cache variable might lead to
unexpeted behavior by inadvertently retaining a version number upon
recompiles if the cache itself was not cleared, and this can happen
unexpectedly even when the user isn't trying to override the version.

This patch changs the behavior as follows:

You must use the special `-DOpenImageIO_VERSION_OVERRIDE=...` to
override the version.

  * if you do so, you are playing with fire and get what you deserve
    if you misuse it or change branches and don't remember to clear
    the cache.

If you do a normal build (without _trying_ to override the version),

  * you will get the real version number because it IS NOT cached
  * if you switch branches, you'll always get the right version number
  * ...but switching branches without clearing the cache can still, as
    always, have other subtle behavior differences versus doing a
    truly fresh build from scratch.

So in short, it still allows a way to override the version if you
really want to, but if you are not trying to do that, you can no
longer get yourself inadvertently into unexpected trouble.
2022-12-03 22:36:58 -08:00
Larry Gritz d737268c82 Bump to 2.4.6.1 to fix readthedocs generation 2022-12-03 22:00:13 -08:00
Larry Gritz 847481997d Fix broken version designation in docs (#3698) 2022-12-03 21:56:22 -08:00
Larry Gritz b06d2aae8a CHANGES, stage for v2.4.6.0 2022-12-01 14:40:09 -08:00
Larry Gritz f86e0999e6 CI: test against latest webp, and deal with its master->main repo change (#3695)
Also be more robust to the libheif and libde265 repos being
occasionally down.
2022-12-01 14:40:09 -08:00
Larry Gritz 745a071080 Fix docs typo 2022-12-01 13:11:04 -08:00
Gerdya df783ef8b9 Some fixes for compilation with MSVC for Windows ARM64 (#3690) 2022-12-01 10:47:45 -08:00
Larry Gritz 190e8f3fef oiiotool --dumpdata : fix channel name output (#3687)
We weren't copying the full spec, so didn't get the channel names.
2022-11-25 18:54:11 -08:00
Larry Gritz 0df4bbd478 oiiotool --point fix problem when there's no alpha (#3684)
We were over-allocating the color vector, and that was throwing off
the operation of IBA::render_point for cases where the image had no
alpha channel.
2022-11-25 18:53:46 -08:00
Larry Gritz f7c0402f7d Catch possible exception, identified by static analysis (#3681) 2022-11-19 09:30:23 -08:00
Larry Gritz e210d934a9 DPXColorConverter.cpp: exclude unused portions (#3682)
Many parts of this imported file are unused by OIIO. `#if 0` them away,
so they aren't part of static analysis or code coverage.
2022-11-19 09:30:15 -08:00
Larry Gritz bf85b2eda8 PSD reading: don't reject padded thumbnails (#3677)
When reading PSD file, if reading the thumbnail doesn't pass basic
sanity checks, we consider that a hard error reading the file.  One
check that we do is to make sure that our computation of the byte
width of the uncompressed thumbnail (`bpp/8 * width`) matches what the
file says the `widthbytes` is.

BUT... it seems that it might round up to an even (or maybe 4-multiple?)
of columns, presumably for scanline alignment reasons. And so we were
considering whole PDF files unreadable if they fell into this case.

This PR primarily loosens the test to allow some padding up to a
multiple of 4.

Fixes #3658
2022-11-19 09:29:55 -08:00
Larry Gritz 99f17b8349 IFF output safety (#3676)
* Maya IFF documentation says IFF file has max resolution of 8192, and
  our implementation only allows writing RGB and RGBA, so check these
  limits when an IFF file is opened for output.

* Make sure scratch space allocates enough for tile padding.

* Check for non-zero image origin coordinates (which are not allowed
  in IFF files).

* Change some 16-bit loop variables to uint32_t to avoid possible
  overflow.

Fixes TALOS-2022-1654, TALOS-2022-1655, TALOS-2022-1656
2022-11-19 09:29:33 -08:00
Larry Gritz c18b3ef72c IOProxy support for IFF files (#3647) 2022-11-19 09:29:24 -08:00
Larry Gritz 3a71e8a162 BMP output safety (#3673)
In open(), check for non-zero image offsets, which is not supported by
BMP, and issue an error if found. If the spec passed in has nonzero
spec.y, other code in the write functions would fail because they
assumed spec.y == 0 and could therefore access memory incorrectly.

More generally, also put checks in the write functions that issue
errors and take early outs if they find that they are called on a
BMPOutput that is not currently open, for example if open() fails but
the user doesn't check the return codes and proceeds to call the write
functions anyway.

This addresses TALOS-2022-1653 / CVE-2022-43594-CVE-2022-43595
2022-11-19 09:22:20 -08:00
Larry Gritz 1413022687 DPX output: fix write errors (#3672)
There was a subtle error where we had a reference to an ImageSpec for
one of the subimages, confusingly called m_spec, which we altered, but
then didn't make the same change to the this->m_spec, and in a later
spot we referenced the `m_spec` meaning the one in `this`. This could
lead to a crash.

Fix, but not only that, also rename to avoid the confusion. `spec0` is the
alias we us for the spec for subimage 0, and `spec_s` is the alias we
use when referencing subimage S, and we really never use m_spec
anymore to avoid any confusion. This should make it easier to reason
about this code in the future and avoid these kinds of mistakes.

A second error resulted from the situation where a failure in open()
would return before one or both of m_buf or m_tilebuf were allocated.
If the return status of open() were ignored and the caller
subsequently attempted calls to write_scanline or write_tile, invalid
memory could be accessed. Fix this with a variety of guards not only
based on the allocation status of these buffers, but also issuing
errors (and exiting early) from write_scanline or write_tile if they
are called on an ImageInput that is not in fact open.

Addresses TALOS-2022-1651 / CVE-2022-43592 and 
TALOS-2022-1652 / CVE-2022-43593
2022-11-19 09:22:07 -08:00
Larry Gritz 7b2f76dc7c PSD: Fix thumbnail extraction for PSD files (#3668)
Fixes #3660

In investigating this issue, I also noticed that now that IOProxy
support can be relied on, the old code that in the psd reader that
directly fumbles with libjpeg is not needed and can be replaced by
just a couple of lines to make an ImageBuf read from an IOProxy.

And it fixes the bug, too. So I'm not even going to try to figure
out what was going wrong with the old code.
2022-11-19 09:21:29 -08:00
Larry Gritz e66ff05314 Try to squash warning in gcc 12.1 + C++20 (#3679) 2022-11-17 22:42:53 -08:00
wayne-arnold-adsk 5d23f2d69f Avoid sanitizer warning unsigned integer overflow (#3678)
/Volumes/DATA/local/S/Maya_master_CI_sanitizer/build/RelWithDebInfo/src/Components/ExternalLibraries/OpenImageIO/install/include/OpenImageIO/string_view.h:252:43: runtime error: unsigned integer overflow: 0 - 17 cannot be represented in type 'unsigned long'
    #0 0x10d0adf61 in OpenImageIOMaya_v2_4::basic_string_view<char, std::__1::char_traits<char> >::compare(OpenImageIOMaya_v2_4::basic_string_view<char, std::__1::char_traits<char> >) const string_view.h:252
2022-11-17 18:02:16 -08:00
Larry Gritz 344f816b2d Fix formatting 2022-11-16 10:47:34 -08:00
Fabien Servant @ TCS 45592eaeab [raw] update exif orientation with raw flip if user flip is set (#3669) 2022-11-16 10:40:20 -08:00
Larry Gritz 5d9ff6294a DPX input: Comment out assertions (#3674)
We shouldn't abort here, we should return and handle the error better
(which we do).
2022-11-15 08:04:41 -08:00
Larry Gritz 13ed669ae5 ImageBuf+IOProxy vs ImageCache subtle fixes (#3666)
I uncovered a very subtle problem that can happen with the interaction
between ImageBuf, using an IOProxy, and the underlying ImageCache.
Remember that when using an IOProxy, it is critical that the lifetime
of the proxy outlasts any ImageInput, ImageBuf, or ImageCache that was
told about it.

Consider the following code:

    IOProxy proxy(...);   // temporary proxy in this local scope
    ImageBuf A ("foo.exr", 0, 0, proxy);

We've set up an ImageBuf that will read from an IOProxy.  Behind the
scenes, it made an ImageCache entry that remembers the IOProxy, as it
has to, since it needs to use that proxy for subsequent reads.
Now we read the image, and we use the `force=true` parameter to
force an immediate read of the file:

    A.read (0, 0, true);

It reads from the proxy. But the IB and the underlying entry in the IC
still know about the proxy. But in the user's mind, they have fully
read the image, will never read from it again, so of course (they
think) it is safe to close or destroy the proxy, knowing that they
made it last past its use:

    proxy.close();

But -- oops! -- the cache entry still has a pointer to the proxy, and
even though it won't need to read from it again, it still will access
it, close it, etc., but the user's proxy may by that point be out of
scope.

This is *technically* not a "bug" in the sense that it is the user who
violated the contract by closing or destroying the proxy before its
last use by anything they passed it to. But in context, it's very easy
to be confused by this -- the user thinks that the only observer of
the proxy is the ImageBuf, and they're done using the ImageBuf at that
point, but because they don't explicitly mention an ImageCache, they
don't realize that the ImageBuf passed the proxy reference along to
the underlying IC that could be backing any ImageBuf.

It's the user's fault in some sense, but let's just say that we have
given them an "attractive nuisance."

That's a long bit of background explanation, but I wanted to force
myself to explain it clearly and make sure it was spelled out in the
commit comments. Now here is the fix:

* When IB::read does an immediate forced read involving an IOProxy,
  after the read is complete, tell the cache to invalidate the entry
  for the file so that it no longer retains a pointer to the proxy.

* When an IB itself is destroyed or cleared, if it used an IOProxy,
  also invalidate the IC entry for that file.

* Unrelated cleanup: avoid a redundant invalidate call in init_spec().
2022-11-14 20:22:10 -08:00
Larry Gritz efffa5f24d OpenColorIO 2.2 support -- preliminaries (#3662)
* Make it so that when we build against OCIO 2.2, it is possible to
  specify the built-in configs. The logic had previously precluded
  this, because at one point it checks to see if the passed config or
  contents of env $OCIO was an existing file. Now you can set OCIO to
  "ocio://default", for example, and it will be used by OIIO.

* Expose getAliases (I think that has been there for a while but we
  didn't expose in in our ColorConfig wrapper).

* Expose isColorSpaceLinear (new to OCIO 2.2)

* New OIIO global getattribute query: "opencolorio_version" returns the
  human-readable version string (such as "2.2.0").

* Some miscellaneous other cleanup in color_ocio.cpp

* Change in color methodology for test suite: Previously, for every
  call to oiiotool in the testsuite, we passed a `--colorconfig`
  argument to oiiotool pointing it to the sample colorconfig that we
  ship in the testsuite. Here, I'm changing it so that the cmake setup
  for tests sets the OCIO env variable for all tests, so no explicit
  --colorconfig is necessary, and thus you won't see a path to the
  config in any of the test output files if they need to echo the
  command line arguments (and you'll see several test outputs altered
  in this way). This is a prelude to later changes that will use the
  built-in configs themselves for tests, when available.

More interesting changes coming in subsequent PRs.
2022-11-14 20:22:02 -08:00
Larry Gritz 811a321f74 Zfile write safety (#3670)
When writing a zfile, anything that causes open() to fail will leave
m_tilebuffer at 0 size. Subsequent calls to write_tiles, and also
to close (which cleans up unwritten parts of the buffer at the end)
did not check for this condition and would access out of bounds memory.

While I was in there, I converted the zfile.cpp error messages to the
new formatting convention.

Fixes TALOS-2022-1657
2022-11-14 20:21:46 -08:00
Larry Gritz d08ca20fe1 CI: No longer add the ppa:ubuntu-toolchain-r/test repository (#3671)
Lately, it has been experiencing intermittent availability problems
that causes our CI to fail while setting up dependencies.

What happens if we don't use the problematic ubuntu-toolchain-r at all?

Nothing, it seems. So eliminate it.

I think that once upon a time, it was necessary to add this repo to
get certain new packages? But maybe they are mainstream enough now
that it's not necessary to add this repo? In any case, it doesn't seem
to hurt anything, it's one less moving part that can't fail if it's
not there.
2022-11-14 14:10:19 -08:00
Larry Gritz 14748d5aa1 Expose OIIO::Strutil::print in the main OIIO namespace (#3667)
We use this all the time in our internals, and I'm tired of having to
write Strutil::print. Too verbose. By putting it in the main OIIO
namespace, OIIO internals can reference as simply print(), and
external users now have a choice of saying Strutil::print() or
OIIO::print().
2022-11-14 08:41:13 -08:00
Larry Gritz 8bcc715235 IOMemReader ctr should take const buffer pointer (#3665)
The ctr is inline, so I don't think it breaks backwards link
compatibility to make this change, so I do intend to backport it.
2022-11-14 08:41:04 -08:00
Larry Gritz ba3f204158 Fix type mismatch warning in JPEG code (#3664)
Fixes #3663
2022-11-12 13:53:21 -08:00
Larry Gritz 43f806d53c Additional Strutil tests (#3655)
Better coverage of edge cases for escape_chars/unescape_chars, stoi
hex conversion, strtod, stod, freestanding c_str(), parse_nested
failure cases, base64_encode, debug.
2022-11-12 13:52:57 -08:00
Larry Gritz 30571a094c Filesystem::is_executable and find_program (#3638)
Also cull some cruft that no longer is used for OIIO >= 2.4
2022-11-12 13:52:24 -08:00
Larry Gritz 8f9bf9973b Fix ColorConfig::getColorSpaceDataType null ptr deref when no OCIO config is found (#3652) 2022-11-12 13:51:58 -08:00
Larry Gritz 750f89cd7f CMake: use of ${PROJECT_NAME} must be after call to project() (#3651) 2022-11-04 17:12:00 -07:00
Larry Gritz 34ea2fb548 oiiotool testing and minor subimage/miplevel fixes (#3649)
* Add casual tests of oiiotool with no args (print brief usage message)
  and when an unknown command.

* Also changed the meaning of -q (quiet mode) to be more quiet -- in
  particular, not to print the full help message for errors when quiet
  mode is used, only print the error.

* oiiotool test sequence errors.

* Test (and fix) --selectmip and --subimage with out of range indices
2022-11-04 17:09:04 -07:00
Larry Gritz 62ff91df5c CI: Test against OpenColorIO 2.2 (#3644) 2022-11-01 23:18:40 -07:00
Larry Gritz 14b6c11847 CI: adjust when workflows are run to cut needless CI runs (#3645)
Changes:

* Scorecards and analysis -- allow newly launched job to cancel
  running old job from the same PR.

* Scorecard only runs on main repo, no need to run on forks.

* Nightly CI only runs on main repo, no need to run on forks.
2022-11-01 23:18:28 -07:00
Larry Gritz c794d877e3 Analysis: more test related fixes to try to increase code coverage (#3643)
* Test oiiotool control flow syntax mistakes
* Test oiiotool --set with array of strings
* oiiotool: better adjust_geometry unit testing

Helper utility additions:

* oiiotool --no-error-exit

  `--no-error-exit` causes an error to not exit immediately, but
  rather to try its best to continue execuing command line
  operations. Use with caution! This is mainly for unit tests and
  debugging.

  `--unittest` also turns this on automatically, so that tests that
  are probing failures don't cause an exit.

* unittest.h: If OIIO_UNIT_TEST_QUIET_SUCCESS is defined, don't print
  anything extra for unit test success
2022-11-01 23:18:18 -07:00
Larry Gritz 9e987d5e5e Squash some alignment problems caught by ubsan (#3646) 2022-11-01 23:18:05 -07:00
Larry Gritz e5bffd8a84 maketexture: Ensure proper setting of some metadata (#3634)
Make extra sure to clear the oiio:ConstantColor, oiio:AverageColor,
and oio:SHA-1 metadata when writing textures, if those things are not
going to be set.
2022-11-01 23:17:45 -07:00
Larry Gritz 6aab6975f5 Analysis: Add tests to improve code coverage of oiiotool (#3637)
* Unit test adjust_geometry
* Tests of --set for various implicit and explicit types not
  previously covered in the testsuite
* Comment out Oiiotool:get_position, which seems to be unused
* Exercise --iconfig for explicit types
* Add test for --origin and --originoffset
* Add test for --ociodisplay
* Add test for --unmip and --selectmip
2022-11-01 23:16:45 -07:00
Larry Gritz c7c2830b45 Strutil: trimmed_whitespace (#3636)
It's similar to trim_whitespace, but returns the trimmed result, rather
than operating in-place on a `string_view&`.

Also add unit testing of trim_whitespace and trimmed_whitespace
2022-11-01 23:16:23 -07:00
Larry Gritz e6b52502ad Bump version after release 2022-10-31 18:55:33 -07:00
Larry Gritz 1e70f7862c CHANGES and stage for 2.4.5.0 2022-10-31 18:07:20 -07:00
Larry Gritz 5563449f01 TIFF: guard against buffer overflow for certain CMYK files (#3632) 2022-10-23 22:55:08 -07:00
Larry Gritz 5bfe48a16d PSD: protect against corrupted embedded thumbnails (#3629) 2022-10-23 14:00:28 -07:00
Larry Gritz 79824feaa4 TIFF: guard against corrupt files with buffer overflows (#3628)
Along the way, improve the runtest.py script by giving the
info_command() fuction the same silent, concat, and failureok
parameters that the oiiotool() function has. (This lets individual
tests assemble iinfo command lines with a little more flexibility.)
2022-10-23 14:00:22 -07:00
Larry Gritz 1a53aa4ade DDS: fix crashes and add tests (#3625)
* In the case of DDS cubemap files where a cube face was not present,
  we were filling m_buf with 0 bytes before allocating it.

* Add check for invalid bits per pixel.

* Add regression test for another bug that was perviously fixed in
  2.4.3.
2022-10-23 13:59:41 -07:00
Larry Gritz 85eae966f8 Fix EXIF bugs where corrupted exif blocks could overrun memory (#3627)
In one case, we actually had a check for this, but an assignment to an
int made the nonsensical offset appear negative, and we only tested
whether the necessary offset it was bigger than the buffer size.
Keeping it as (unsigned) size_t makes the test work as intended.

In another case, there were several places where we never checked that
we were staying within the exif block, and here we address this by
changing the utility decode_ifd so instead of passing it a pointer to
the ifd, it passes the offset (the pointer turned out to always be
inside the buffer) so it can check the extent for subsequent accesses.

Also some fixes related to squashing undefined behavior sanitizer
cases.
2022-10-22 12:48:08 -07:00
Larry Gritz feb2c9c46f RLA: fix potential buffer overrun (#3624) 2022-10-22 12:48:00 -07:00
Larry Gritz 3361e8d89b Custom fmt formatter for ustringhash prints the string, not the hash (#3614)
Also, change `operator<<` to output the string, not the hash itself.
These changes help push us more toward the original intent of
ustringhash being a drop-in replacement for ustring, any time it's
more desirable to be using around the hashes rather than the pointers.
2022-10-22 10:22:19 -07:00
Larry Gritz b288f3ada9 Improve oiiotool test coverage (#3626)
* oiiotool tests for expressions var() and getattribute()

* Make sure we test oiiotool IMG[] expressions and several specific
  special attributes to retrieve.

* Add coverage of oiiotool --keyword and --clear-keywords
2022-10-22 10:22:09 -07:00
Larry Gritz b971489267 Targa: String overflow safety (#3622)
Added utility functions safe_string_view and safe_string to strutil.h.
2022-10-21 09:03:54 -07:00
Larry Gritz 2b542b92c6 BMP: protect against corrupt pixel coordinates (#3620)
When reading the image (which can have signals to jump around in the
array), we checked for out-of-bounds x coordinate, but not y, and some
corrupted files could overrun buffers as a result.
2022-10-21 09:03:45 -07:00
Larry Gritz 2735f38b42 CI: eliminate xxhash and farmhash code from coverage analysis
Because we're not the originators of the code and we use only a tiny
subset of what's in those files.
2022-10-21 09:03:36 -07:00
Larry Gritz 37bb86d116 oiiotool: New metadata expression syntax (#3619)
The existing syntax `TOP.name`, if the name wasn't found, produced
an error.

This PR adds another syntax: `TOP[name]` which is identical if the
named metadata is found. But if not found, this syntax just evaluates
to the empty string, with no error.
2022-10-21 09:03:29 -07:00
Aras Pranckevičius 8701cf7dd0 Docs: write Windows build instructions (#3602)
I recently wrote down how to build OIIO from source for myself (https://gist.github.com/aras-p/6497703c9b52f67761e6191343e43f7b), and maybe a slightly cleaned up version would be good to put into actual docs.
2022-10-20 08:46:28 -07:00
Larry Gritz cc933a0ff7 Fix missing getattribute of limits:channels and limits:imagesize_MB (#3617)
I think it was just inadvertently left out when these were first added.
2022-10-20 08:46:20 -07:00
Larry Gritz 65c61ca759 Testing: optimize oiiotool-control test (#3618)
This test was taking almost 30 seconds to run, without a lot of images
being read or written. Turns out it was just a large number of separte
oiiotool invocations, and the overhead of all those shells and
programs launched adds up. Most of them were just firing up oiiotool
for the sake of doing an `--echo` to print things. A little bit of
restructuring to make fewer oiiotool invocations (each one doing a
bunch of echo commands, each testing a different thing) cuts the time
for the whole test by 50%.

I also made the runtest.py script allow certain test debugging by
letting a test set the `wrapper_cmd`, and if so, will prepend every
oiio utility launch with it. For example, a test could say
`wrapper_cmd='time'` to time every command.
2022-10-20 08:46:00 -07:00
Larry Gritz 3faa66b592 oiiotool: Add unit tests, minor internals utility refactoring (#3616)
Add a hidden --unittest command to oiiotool, only functional for Debug
builds, which enables additional testing of internal utility funcions
and other things that are difficult to fully exercise in the testsuite
from normal oiiotool commands (could be done, but would take tons of
additional tests to get into particular deep edge cases).

Prototype by adding unit tests for scan_box. More will be added later
now that the mechanism exists.

Simplify string_to_dataformat

Make sure to use --list-formats and --runstats during testing.
2022-10-19 13:06:35 -07:00
Larry Gritz 09bba709c5 Testing: eliminate redundant code in Python IBA bindings (#3615)
Also add a test for sub(imagebuf,tuple) that we didn't have before.
2022-10-19 13:06:21 -07:00
Larry Gritz 9379097d7c Add a test that forces stats to be computed (#3612)
Increases code coverage for dynamic analysis and coverage metrics.
2022-10-18 08:47:09 -07:00
Larry Gritz 58a51a3705 Testing: testsuite/iinfo -- make it compute stats, use MIPmaps (#3613)
Better coverage of the functionality of iinfo
2022-10-18 08:47:02 -07:00
Larry Gritz ab887c5c76 Testing: update cineon test image 2022-10-17 11:04:51 -07:00
Larry Gritz 521a6ba64c Fix exr core test options (#3610) 2022-10-17 11:04:40 -07:00
Larry Gritz 6e39b13e78 CI: Sonar analysis should exclude stb_sprintf.h (#3609)
It's not really "our code", and we use very little of that file, so
it's not helpful to include it in coverage or other analysis.
2022-10-16 22:33:23 -07:00
Larry Gritz 69917346c5 Testing: make a test specifically for iinfo (#3605)
Believe it or not, iinfo was never run in the testsuite before this!
2022-10-16 22:33:16 -07:00
Larry Gritz 9d2f6717fa Test fixes (#3608)
* We mis-named color_test, and that caused it to never get run!

* imagespeed_test is meant for benchmarking only, run by hand.
  We don't make a testsuite test, so don't even build the source
  (which would never be counted for code coverage because it doesn't
  run) during CI.
2022-10-16 22:33:04 -07:00
Larry Gritz b1513e8c43 Improve cineon build and test (#3607)
* Add a test for cineon -- we never directly tested it before

* Don't compile code used only for writing. We don't supporting
  writing cineon, so there is no point compiling the cineon module
  used only for writing.

* And of course, once cineon was in the testsuite, we immediately
  found a problem via the sanitizers! So fix buffer overflows when
  reading FilmEdgeCode in Cineon.  (And clean up the equally sloppy,
  though not technically buggy, code in DPX as well.)
2022-10-16 19:29:08 -07:00
Larry Gritz fc94095738 Testing: test both openexr old and core versions (#3604)
On any one platform, our testsuite was only testing the old C++ and
the new C core exr implementations.

Rig it to run the openexr-oriented tests twice -- once in each state
(when using OpenEXR new enough to support the core library).

Doing this cleanly required adding SUFFIX and ENVIRONMENT optional
parameters to the oiio_add_tests utility macro. Once that was added,
the texture batch testing could be implemented that way as well,
removing a bunch of hackier special purpose code.
2022-10-16 19:29:02 -07:00
Larry Gritz 54224dce05 Static analysis related fixes (#3603)
* Protect against 0-sized allocation
* Exception safety in IffOutput destructor
* Using sonar.coverage.exclusions as a better way to exclude files
  from coverage analysis
* Null pointer safety
2022-10-16 19:28:53 -07:00
Aras Pranckevičius 5e15e1cb3b SIMD: extend NEON implementation coverage, and include neon in oiio_simd_caps (#3599)
* Use hardware float<->half conversion (similar to F16C on Intel)
* Use hardware sqrt
* Use horizontal adds in more places ("reduce_add")
* Equivalents of _mm_movemask_ps for NEON in vbool4
* Other smaller bits & bobs

Testing on Apple M1 Max, Release build, notable simd_test Mvals/sec
changes:

vfloat4
* load from half[]: 2457 -> 5890
* store to half[]: 1041 -> 6074
* simd sqrt: 2151 -> 6075

vfloat8
* load from half[]: 2433 -> 10367
* store to half[]: 1235 -> 11192
* reduce_add: 7377 -> 11971

vfloat16
* load from half[]: 2672 -> 14505
* store to half[]: 1322 -> 12558
* reduce_add: 7123 -> 11858
* operator<:  3345 -> 7500 (similar with other compare ops)

vint4
* blend: 4403 -> 5007
* blend0: 5187 -> 6076
* rotl: 1775 -> 2932

vint8
* load from int[]: 9415 -> 12152

vint16
* operator<<: 4656 -> 5865 (similar for >>, srl)
* rotl : 4042 -> 5137

vbool4
* reduce_and: 875 -> 1361
* reduce_or: 985 -> 1373
2022-10-12 21:31:03 -07:00
Larry Gritz 1fdfff056b ustring hashing improvements (#3577)
I realized that the recently added ustringhash class is confusingly
similar to the (obscure, barely used, mostly forgotten) ustringHash
functor. But also ustringHash doesn't need to exist, because it's
equivalent to `std::hash<ustring>`, if we define it. So now we do define
it, and also `std::hash<ustringhash>`, and deprecate ustringHash, to
be removed entirely for 3.0.

Also, add a ustring ctr from ustringhash (explicit only for now),
and `operator<` for ustringhash.

And add from_hash(size_t) method to ustringhash, analogous to
ustring::from_hash().

Modernize a few places we still used `(void)` to just `()`.

Give ustring and ustringhash a `using rep_t =`
rep_t is the type of the underlying representation (const char* for
ustring, size_t for ustringhash).

Modernize some typedef into using.

Make `==` and `!=(ustringhash, const char*)` be constexpr for C++ >= 17
2022-10-12 11:32:03 -07:00
Aras Pranckevičius c1d44d5d5b Windows: fewer windows.h includes from platform.h (#3596)
In particular, defining NOGDI before including <windows.h> achieves
several things amongh others:
- No longer causes ERROR symbol to be defined to 0. ERROR being defined
  prevents using e.g. google/glog library, since it wants ERROR to mean
  something else.
- No longer defines some possibly widely used names e.g. GetObject.
2022-10-11 09:05:53 -07:00
Aras Pranckevičius 7154cc5949 BMP: fix reading 16bpp images (#2808) (#3592)
16 bit per pixel (e.g. 555, 565, 444) formats probably have never
worked. One part of the code was assuming 5 bits in the mask, another
was shifting by 4 bits, and the 16-bit pixel fetch code was reading just
one byte.
2022-10-08 12:31:57 -07:00
jreichel-nvidiaandJoachim Reichel 0195106930 Fix PSD import on ARM. (#3589)
The code assumes "char" is "signed char" (as on x86), but on ARM "char" is
"unsigned char".

Co-authored-by: Joachim Reichel <joachim.reichel@posteo.de>
2022-10-07 12:31:04 -07:00
Aras Pranckevičius c6cb668b88 oiiotool: work around static destruction order issue (#3295) (#3591)
In some cases (at least on Windows, with static linking) the oiiotool
main returns zero, but the full process returns 3 error code due to
abort() being called. And that is called because a global shared
image cache is already destroyed, but the image references from another
global (Oiiotool itself) try to use it, get a call into a "pure virtual
function" stub that is put by MSVC C runtime into a destroyed object
vtable, and that ends up in an abort().

Work around that by making sure various member variables holding
ImageRecRef are cleared before main() finishes and global destructors
are called.
2022-10-07 12:30:17 -07:00
Aras Pranckevičius ecab9e2080 HDR: speed up reading by around 4x (#3590)
Most of the cost in HDR file reading was converting from RGBE to floats,
inside ldexpf(), which at least on Windows/VS2022 spends most of the
time inside _ctrlfp(). But we only have 256 possible exponents in total,
so just use a precomputed table.

On my PC (Windows 10, VS2022, Ryzen 5950X) this change gets file read
time for an 8x resolution .HDR image from 1.10s down to 0.27s
2022-10-07 12:28:04 -07:00
Aras Pranckevičius 9d8aa265b3 HDR: fix read performance regression (#3585) (#3588)
HDR code overhaul to support IOProxy (#3218) changed all reads into
a `pread()` with explicit file position tracking. Turns out, that is
quite a larger overhead compared to simple sequential reads; even more
so on Windows.

On my PC (Windows 10, VS2022, Ryzen 5950X) this change gets file read
time for an 8x resolution .HDR image (with RLE compression) from
8.28s back to 1.10s just like it was in OIIO 2.3.

On Windows the extra cost when using pread() is a bit more extra mutex
locks, but the real cost is in enventual ReadFile; looks like any seek
operations make it take some sort of "way slower" path with various
callbacks and whatnot inside the kernel.

---

Note repoduced from discussion #3588 from LG: 

Switching from IOProxy::pread to using IOProxy::seek + IOProxy::read makes the IOProxy stateful and not thread-safe without an external lock (which this HdrInput has, so it's not going to break anything), precluding any future removal of the locks from read_native_scanline to make the whole ImageInput able to read concurrently. That's probably not important for this file format, but for others (especially crucial those usable as texture), it would be desirable to rely on those stateless pread calls and remove the lock from the ImageInput.

I think this patch is fine. We don't expect a lot of concurrent reads from hdr like we do for tiff and openexr that we use extensively for highly threaded on-demand reading of texture. It fixes the recent performance regression, and it doesn't really cost us concurrency because we already had the lock in HdrInput. But in general, we want to prefer eschewing read/seek and using pread instead, so we can expect maximum concurrency from multiple threads using an ImageInput (as we do in ImageCache/TextureSystem).

So I believe that a revised and more complete diagnosis is that the problem isn't the pread vs read per se, but that for RLE-compressed images we were calling pread separately for every 4 bytes! The calls to read are faster simply because they are buffered (in FILE) and require fewer OS system calls. But the real sin is that we call it way too many times.

I think that the rle case could go back to pread if we want, but do just one pread per scanline (rather than one per pixel value run), asking for the maximum amount that will be needed to read the scanline for the worst case rle representation (it's ok if it's the end of the file, pread will just read up to the end and return the true number of bytes read). In other words, we'd be doing the buffering ourselves.

But anyway, the real misdesign of this HDR reader is ancient, and consists of doing many many tiny reads. Even the buffered fread would be sped up a lot by not doing it separately for every 2-4 bytes of the file. I don't know if it's worth fixing for this format. Depends on whether anybody really needs to maximize its performance or expects multiple threads reading the same hdr file to be fully concurrent.
2022-10-07 12:27:52 -07:00
Larry Gritz f3f375fc5b Revise RELEASING to explain updating oiio-images branch (#3580) 2022-10-06 16:17:02 -07:00
Larry Gritz 34b643922a Build/security: Try FORTIFY_SOURCE (#3575)
Add a new build-time cmake cache variable: FORTIFY_SOURCE

Default to empty, but can be set to 1, 2, or 3, corresponding to
setting the _FORTIFY_SOURCE macro available in recent versions of
clang and gcc. (I'm not sure exactly which minimum compiler version is
needed for each fortification level, except that for level 3, gcc must
be 12+.)

Fortification involves replacing several "unsafe" memory-related
functions such as memcpy, memset, strcpy, etc, with special versions
that do bounds checking, aided by some compiler smarts for
understanding the likely bounds of different buffers. If I understand
correctly, at level 2 it can figure out bounds of constant-sized
arrays, and at level 3 it can figure out certain dynamic cases as
well.

There are two use cases for this:

1. For our own CI, this is yet another bit of static and dynamic
anslysis to enable (currently, just in the gcc12 test) to possibly
catch bugs.

2. Users who are building OIIO to deploy it in security-sensitive
environment may wish to build with some fortification level enabled to
help prevent certain memory errors or security issues, understanding
that it may slightly impact performance.
2022-10-06 16:17:02 -07:00
Larry Gritz 705c25c193 CI: improvements and minor refactoring (#3570)
* Refactor the clang-format job to be part of the aswf batch of jobs
  rather than separate (reduces redundant logic in the workflow file).
* Give proper names to distinguish the two Mac jobs' artifacts for
  broken builds and their caches.
* Revise scorecard workflow triggers: no need to run weekly, and run
  on push only to the main repo, no reason to run on forks.
2022-10-06 16:17:02 -07:00
Larry Gritz 5e8483b758 Use undefined behavior sanitizer (ubsan) as part of CI (#3565)
In addition to address and leak sanitizers, also turn on the undefined
behavior sanitizer in our CI run. We can do it in the same job as
asan/lsan.

Some things that come along for the ride, including fixes for things
that ubsan uncovered:

* src/build-scripts/ubsan-suppressions.txt can hold suppression list
  (though we don't have any now, it just sets up the space for it for
  future needs).

* Split the "targa" test so that the parts that directly need the OIIO
  python module (which are all related to thumbnails) are now in
  "targa-thumbnails" test. That has to be disabled for the sanitizers,
  since we can't arrange for python to b linked to the sanitizer
  libraries.

* Found vint4::store has a potentially unaligned integer store.

* Found Strutil::concat is not necessarily safe if either of the
  strings are empty.
2022-10-06 16:17:02 -07:00
Larry Gritz 7f02d29935 Update one more ref image after recent raw change (#3572)
Also remove three raw test reference output files that we apparently
no longer use (corresponding to platform + libraw combinations that
aren't in our current set of CI configurations).
2022-10-06 16:17:02 -07:00
Larry GritzandVincent Demoulinv 69c40cf320 Update ref output after recent raw change and clang-format (#3569)
This is an addendum to #3561 to fix reference output

Co-authored-by: Vincent Demoulinv <vincent.demoulin@technicolor.com>
2022-10-06 16:17:02 -07:00
demoulinvanddemoulinv c6a9c08bc7 Add color metadata from libraw. (#3561)
2 vectors, pre_mul and cam_mul.
2 matrices, cam_xyz[4][3] and rgb_cam[3][4], delivered as 1D tab.

Co-authored-by: demoulinv <vincent.demoulin@technicolor.com>
2022-10-06 16:17:02 -07:00
Larry Gritz 427406d084 CI/build: build_libtiff.bash should be sure to build shared library (#3586)
Something changed in libtiff master and it doesn't build shared libs
by default, breaking our "bleeding edge" CI test. So when we build it,
be sure to ask for it. It can be overridden in build_libtiff by
invoking it with env variable `LIBTIFF_BUILD_SHARED_LIBS=OFF`.
2022-10-06 16:16:02 -07:00
Larry Gritz fde8de5602 DDS: honor ImageInput thread policy (#3584) 2022-10-05 23:57:39 -07:00
Aras Pranckevičius 8fe2463d30 DDS: optimize loading of compressed images (3-5x) (#3583)
Comparing the time it takes to load DXT/BCn compressed DDS images via
OIIO, I noticed that it's several times slower than in another codebase
(Blender). So I started profiling, and fixing some low hanging fruit.

- After decoding a BCn block (always 4x4 pixels), it was written into
  destination image using quite many branches in the innermost loop.
  Now it still takes care of not writing outside of a destination image
  that might not be multiple-of-4 in size, just with way fewer branches.
- BCn decompression is multi-threaded via parallel_for_chunked, using
  at least 8 block rows per job (i.e. 32 pixel rows). This is
  similar to internal multi-threading done by EXR or TIF readers.
- Avoid one case of std::vector resize (which clears memory) followed
  by immediate overwriting of that buffer with bytes read from the file.
  Switched to using unique_ptr for that array, similar to how other
  input plugins do it.

Performance data: I'm timing how long it takes to do "iinfo --hash" on
24 DDS files, each 4096x4096 in size. Quite a lot of time there is taken
by just the SHA hash calculation which is not related to loading, so
also have timing info for just DDSInput::read_native_scanline where
all the actual DDS loading/decoding happens.

Timings on PC (Windows 10, VS2022 Release build), AMD Ryzen 5950X.
- BC1: total 3.68s -> 2.76s, read_native_scanline 1.54s -> 0.59s
- BC3: total 3.74s -> 2.84s, read_native_scanline 1.83s -> 0.66s
- BC4: total 1.26s -> 0.82s, read_native_scanline 0.74s -> 0.24s
- BC5: total 2.29s -> 1.57s, read_native_scanline 1.31s -> 0.46s
- BC6: total 7.50s -> 4.30s, read_native_scanline 4.67s -> 1.60s
- BC7: total 6.18s -> 3.09s, read_native_scanline 4.34s -> 0.84s

Possible future optimization: implement DDSInput::read_native_scanlines,
that could avoid one extra temporary memory buffer copy. This extra
buffer clear & eventual copy from it into final user destination pixels
is non-trivial cost from profiling. But it's also quite involved
to handle all the possible edge cases (e.g. user requests scanlines
not on 4-pixel row boundaries); the code would have to do similar
juggling as EXR reader does to handle "not on chunk boundaries" reads.
It could potentially also interplay with DDS cubemap/volume texture
reading ("tiled") code paths, for which there is no test coverage at all
right now. Maybe for some other day.
2022-10-05 22:43:16 -07:00
Aras Pranckevičius cddf3e175b DDS: alpha/luminance format fixes, add & enable more tests (#3581)
* DDS: fixes for A8, L8, A8L8 formats

While developing #3573 at one time I had them working properly, but then
while fixing the address sanitizer failure for 3-channel formats I
botched them again. Note to self: never again do a "yeah I'll add tests
later", since if I had all of them running all the time this would
not have happened. 🤦

* DDS: extend test coverage for more formats & channel size cases

With more test images recently added (https://github.com/OpenImageIO/oiio/pull/3459),
start using them for DDS tests. This covers now:
- Alpha, Luminance and Alpha+Luminance formats,
- RGB formats with rarer channel sizes (rgb10 a2, r3g3b2),
- Several "broken" DDS file cases
- Removed usage of sample-DXT1 since it is well covered by others.
2022-10-05 22:43:16 -07:00
Larry Gritz aff5ea242f Remove incorrect OIIO_API from inline method declaration (#3578)
This was causing build issues on MinGW.
2022-10-05 22:43:16 -07:00
Larry Gritz 8a5580c59e Add RELEASING.md to document our release procedures (#3564)
Adapted from the similar document I wrote for OSL.

This serves both as a checklist for me to make sure I don't miss any
steps during a release, but also so that other people could take over
release procedures if necessary or desired.

I also rearranged the order of some lines in CMakeLists.txt for
clarity (but did not change the logic).
2022-10-05 21:09:12 -07:00
Larry Gritz f54a109ffb Python internals: support int8[] metadata and ICCProfile, refactor (#3556)
This patch allows ParamValue, ParamValueList, and ImageSpec to support
attribute/getattribute of metadata consisting of uint8[] arrays, which
is how we store certain binary blobs or raw byte arrays.  We translate
this to Python as a numpy array of type uint8 (dtype='B').

This fixes a limitation where it was not possible to directly retrieve
or set the "ICCProfile" metadata (which is stored as a uint8 array)
from the Python APIs, as you could easily do from the C++ APIs.

In the process, I found similar bits of code in several different
places, in various states of incompleteness. I refactored to make a
single make_pyobject() utility and then used that call in place of
several other redundant pieces of functionality.
2022-10-05 21:09:12 -07:00
Larry Gritz 922ec699a1 Extract metadata from embedded ICC profiles. (#3554)
For a while, we have found embedded ICC profiles in TIFF, JPEG,
JPEG-2000, PNG, and PSD (PhotoShop) files and store them in the
metadata as a byte array with the name "ICCProfile".

With this patch, we further add the facility of parsing the binary ICC
profile data to extract a number of other fields that we add to the
ImageSpec metadata so that "oiiotool -info -v" or "iinfo 'v"
will print this info.

Important caveat: You can read this for informational purposes, but
changing it (e.g. with spec.attribute()) does not change the contents
of the ICCProfile byte array, which is still the canonical ground
truth of the profile. You have to replace the "ICCProfile" byte array
to actually change the profile.
2022-10-05 21:09:12 -07:00
Larry Gritz f2a2d59344 Strutil utf conversion improvements (#3553)
* Add `Strutil::utf16_to_utf8(const std::u16string& utf16str)`.
  This is subtly different from our existing utf16_to_utf8() that
  takes a std::wstring, because wchar_t is not the same on all
  platforms.  If it really and truly is utf16-in-char16_t, you need
  this and can't use the utf-in-wchar_t which may be 32 bit chars.

* Add `Strutil::utf8_to_utf16wstring()` (identical to the old
  utr8_to_utf16) to make it more self-documenting as returning a
  utf16-encoded wstring and NOT a u16string. Note that wchar_t is not
  necessarily char16_t on all platforms (it is on Windows, but it's 32
  bits on Linux).

* Deprecate the ambiguously named `utf8_to_utf16()` for OIIO >= 2.5 and
  remove it for OIIO >= 3.0.
2022-10-05 21:09:12 -07:00
Larry Gritz 8fbf27b69d Build: Make the version number be a cmake cache variable (#3549)
Rather than specify the version in the usual project() statement,

    project (OpenImageIO VERSION 2.5.0.0 ...)

this patch decouples it

    set (OpenImageIO_VERSION "2.5.0.0" CACHE STRING "Version")
    project (OpenImageIO VERSION ${OpenImageIO_VERSION} ...)

thus allowing the possibility of overriding the version number at
build confuguration time (`cmake -DOpenImageIO_VERSION=3.1.4.1`).

This should be used with extreme caution. Probably never used by most
people. I don't need to describe all the ways that things can go
sideways if you make your build of x.y.z.w actually be arbitrarily
different from the x.y.z.w that everyone else uses and that is
documented.

That said, there are two scenarios I have in mind for which this
ability is very useful:

1. Sometimes, we add or deprecate API features "in advance" by having
   an `#if` enable or disable code based on the version, essentially
   putting in place changes that can't be enabled yet because they
   would break compatibility rules, but we want to integrate the code
   now and have it become active upon reaching a particular future
   version in which that incompatibility will be allowed. The version
   number override makes it easy to test this by quickly doing a build
   "as if" we had already bumped the version number to see what will
   happen when we actually do.

2. Every once in a while we need to do an internal build that, to
   conform to version compatibility rules, needs to appear to still be
   part of a past version family. This lets individual sites play some
   games with version number overrides rather than have to create new
   branches and tags for certain one-off internal releases.
2022-10-05 21:09:12 -07:00
Larry Gritz 98181a584e oiiotool --iccread and --iccwrite
--iccread reads a named file and directly adds its contents as the
"ICCProfile" metadata of the top image (as a byte array).

--iccwrite takes the "ICCProfile" metadata of the top image and
writes it to a named file.
2022-10-05 21:09:12 -07:00
Larry Gritz 1983be7f16 oiiotool protect against OpenEXR thread deadlock on Windows (#3582)
Suggested by SideFX: explicitly shut down the OpenEXR thread pool
before exiting oiiotool, because sometimes on Windows it seems to hang
otherwise. A better solution is probably possible on the OpenEXR side,
but I don't know what it would be. (And in any case, we'd still need
to do this be be well behaved when using OpenEXR versions earlier than
where a fix might land.)

Solution tracked down by Edward Lam.
2022-10-05 21:09:12 -07:00
Larry Gritz 5dfe62d56d CI: Re-enable sanitizer tests (#3545)
Oops, at some point, something about the way we set up the CI test
that runs the sanitizers, and ever since then (embarrassingly, perhaps
as much as a couple years ago), the "sanitizer" test has not in fact
been running the sanitizers. Here we fix that up, get sanitizers
running again.
2022-10-03 21:38:36 -07:00
Larry Gritz 78cca33201 PNG fixes (#3544)
* Minor png refactoring to fix some memory leaks for broken png files.

* Remove unused string variable from read_info() and simplify the
  surrounding "if"

* Split png test into png and png-damaged, because I just can't seem
  to squash some very minor memory leaks for broken png files, I think
  it's not worth worrying about and I'll just exclude the broken case
  from testing for the address sanitizer.
2022-10-03 21:38:36 -07:00
Johannes Unterguggenberger 8f7c48dec3 Fixes a warning from an unsuitable format specifier (#3540)
Changed the assert  to use format specifier %d and casting the size to an int.
2022-10-03 21:38:36 -07:00
Larry Gritz e7769b6b0d PNG: fix memory leak when error takes early exit (#3543)
Found by leak sanitizer.
2022-10-03 21:38:36 -07:00
Larry Gritz 8c8c918e5c Targa internals: fix incorrect unique_ptr declaration (#3541) 2022-10-03 21:38:36 -07:00
Larry Gritz fafbec1737 Bump version after release 2022-10-03 21:38:21 -07:00
Larry Gritz 4327cd8560 Stage for 2.4.4.2 patch release 2022-10-02 20:02:14 -07:00
Aras Pranckevičius 6ca23b7753 DDS: various improvements (#3573)
- If a DDS pixel format header contains "this is a normal map" flag
  set, then handle that properly (#3525):
  - For a DXT5, this means it's a "DXT5nm" format. Normal X & Y
    components are in green and alpha channel respectively. Compute Z
    component from those, and the result is a 3-channel tangent space
    normal map.
  - For ATI2/BC5 format that also has a "normal map" flag set, compute
    the Z component automatically too, and result is a 3-channel image.
    However a bunch of ATI2/BC5 normal maps out there in the wild do
    not have that bit set, so also have a global "dds:bc5normal"
    attribute to optionally turn this on.
- Fix support of R10G10B10A2 format - was producing garbage data due to
  code assumption that truncation down to 8 bits never needs to happen.
- Fix bit expansion ("too dark") of very low-bit formats, e.g. R3G3B2.
  Code was simply shifting the bits, instead of properly repeating
  the high bits into new low bit positions (i.e. a 3-bit "111" needs
  to become an 8-bit "11111111" and not a "11100000").
- Support "RXGB" (DXT5, with red & alpha swapped) as well as "BC4U"
  and "BC5U" formats (the latter two are just BC4 and BC5, produced by
  some older tools).
- Support alpha-only (e.g. A8) formats.

All this mostly prompted by doing DDS improvements in Blender, and
wanting to get Cycles renderer (which uses OIIO) to the same feature
parity. See https://developer.blender.org/T101405 and
https://developer.blender.org/D16087.
2022-10-02 15:07:49 -07:00
Larry Gritz aa0550e07f Fix heap overflow in DDS input (#3542)
Reading uncompressed scanlines would copy 4 bytes from each pixel into
an int and then decode the bits, incrementing where it was reading
from by Bpp bytes each time.  But when Bpp == 3, the last pixel of
every row would therefore read an extra byte past the end of the heap
storage. Allocation padding would in practice keep it from crashing,
and that meaningless extra byte was not used in the decode because it
knew it only needed the first 3 of the integer. But found by address
sanitizer!
2022-10-02 15:07:49 -07:00
Larry Gritz a10a88fa12 Bump version after release 2022-10-02 10:52:42 -07:00
Larry Gritz dab1663d6d Full release of 2.4.4.1 -- first official 2.4 release 2022-09-29 17:39:07 -07:00
Larry Gritz c0e7eb56d7 Remove long deprecated/nonfunctional C API headers (#3567)
This was an experiment that was added to master at one point but
removed before we branched for a release. But we forgot to remove a
few headers. Removing them now is not a compatibility break, since we
never shipped a supported release that contained the library that
implemented the functions declared in these headers.
2022-09-27 14:39:41 -07:00
Larry Gritz d02ad116b4 Reinstate missing (obsolete) parallel_for_chunked_2D variant (#3566)
This was part of a set of obsolete calls where we recently removed the
implementations, but for link compatibility, made matching shim calls
and wrap the modern versions. But I missed one case.
2022-09-26 23:40:51 -07:00
Larry Gritz ab7dc1f728 Update ref output after recent python chage 2022-09-24 11:36:17 -07:00
Larry Gritz 31dbd3d699 2.4.4.0-RC2 second release candidate
Changes since RC1:

  - ImageCache/TextureSystem both have added a `getattributetype()`
    method, which retrieves just the type of a named attribute. #3559
    (2.4.4.0)  NOTE: THIS IS AN ABI BREAKING CHANGE
  - Python: Fix the ability to `getattribute()` of int64 and uint64
    metadata or attributes. #3555 (2.4.4.0)
  - Build: Improvements to the generated cmake config files when
    building static libraries. #3552 #3557 (2.4.4.0)
  - Support for gcc 12.1. #3480 (2.4.2.1) #3551 (2.4.4.0)
  - Support building with clang 15.0. #3563 (2.4.4.0)
  - Fix cross-compiling on Android failing due to `-latomic` check. #3560
    (2.4.4.0)
  - Fix building on iOS. #3562 (2.4.4.0)

Note that we bumped the version to from 2.4.3.x 2.4.4.0 to reflect the
ABI break introduced by the last minute by the IC/TS addition of a new
virtual function. ABI will not change again for 2.4.
2022-09-23 08:56:49 -07:00
Larry Gritz d83aee94d5 Changes to take care of new clang 15 warnings (#3563) 2022-09-22 22:59:35 -07:00
Larry Gritz 7c167dab0a IC and TS getattributetype() (#3559)
ImageSpec and ParamValueList have had (since 2.1) a getattributetype()
method, which simply returns the TypeDesc of the named attribute, or
TypeUnknown if no such attribute exits. This goes along well with the
related getattribute() and attribute() family of methods.

The getattribute() method was not present in ImageCache and
TextureSystem, despite their having very similar
getattribute()/attribute() interfaces.

A recent issue made me realize that in the Python bindings, the IC and
TS bindings for `getattribute(name)` did not work properly, always
returning None, and *required* you to use the full
`getattribute(name,type)` variety where you have to supply -- and
already know -- the type. This isn't especially Pythonic, where you
should just be able to ask by name and get a polymorphic result. And
when I went to look at how to repair this, it was going to be very
awkward without getattributetype(), but trivial with it.

So this patch sets up getattributetype() for both IC and TS, and
exposes them to both C++ and Python APIs, and also fully fixes the
getattribute() so that it works properly with the name only.

Unfortunately, because getattributename is a new virtual method, it
changes the vtable, breaking the ABI, and thus cannot be backported to
any supported release that makes ABI compatibility promises.
2022-09-22 22:59:26 -07:00
Povilas Kanapickas fe98cbfb9a Fix build on iOS by not using std::system() (#3562)
iOS and similar Apple platforms only support executing single process
per app. Calling std::system() there fails at compile time.
2022-09-22 22:59:19 -07:00
Povilas Kanapickas 6445022f11 Build: Fix cross-compiling on Android failing due to -latomic check (#3560)
Currently when cross-compiling for Android build fails due to usage of
TRY_RUN(). In the particular case it tries to figure out whether atomics
can be used without the libatomic library.

Fortunately we don't need this check because on Android NDK atomics are
built-in and libatomic.so is not present. Only static dummy libatomic.a
exists for compatibility with -latomic flag.
2022-09-19 18:43:58 -07:00
Larry Gritz ade4132ada Python: add ability to getattribute of int64 and uint64 data (#3555)
Just a couple missing pieces were preventing getattribute() from
retrieving attributes that were stored as int64 or uint64. That
doesn't come up very often, but one place is retrieving certain
statistics that use 64 bit counters. (This comes up in ImageCache,
among other places.)

While we're at it, there was no existing test dedicated to the python
binding of ImageCache. So to add these getattribute calls, I made one.

There is an important caveat about ImageCache.getattribute(): In this
process, I discovered that the flavor of IC.getattribute(name) where
you only pass the name is BROKEN, and will always return None. You
MUST use the form where you pass the type, like

    x = ic.getattribute("foo", "int")

This is unfortunate and not very Pythonic, but it is the workaround
for now. I will addess getting the name-only form working in a
separate PR.

Closes #3537
2022-09-18 14:37:50 -07:00
Povilas Kanapickas c5d17a32c5 cmake: Find TBB dependency in Config.cmake.in when building static (#3557)
TBB::tbb is added as a library dependency via TARGET_NAME_IF_EXISTS.
Therefore if an executable links OpenImageIO static library without the
executable itself depending on TBB, then TBB will not be linked in and
result in link time errors.
2022-09-18 14:36:58 -07:00
Povilas Kanapickas 9900536fce cmake: Add library dependencies in Config.cmake.in when building static (#3552)
This fixes builds in projects that compile OpenImageIO as static
libraries and don't themselves depend on the image libraries used by
OpenImageIO such as PNG, JPEG or TIFF.

When OpenImageIO is built as a static library its targets have e.g.
PNG::PNG among INTERFACE_LINK_LIBRARIES. If the including project does
not itself depend on PNG, the following error would be observed:

Target "<...>" links to target "PNG::PNG" but the target was not found.
Perhaps a find_package() call is missing for an IMPORTED target, or an
ALIAS target is missing?
2022-09-18 14:36:11 -07:00
Larry Gritz 8c40efdcc5 Slight change to avoid gcc12 warning (#3551) 2022-09-13 14:07:11 -07:00
Larry Gritz 449e1c7ea6 Designate as RC1 2022-09-07 21:36:45 -07:00
Larry Gritz 0a28dc0186 Bump version and branch for 2.4 release 2022-08-31 17:03:05 -07:00
1163 changed files with 144314 additions and 95961 deletions
-16
View File
@@ -1,16 +0,0 @@
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# Ignore skills that might be installed locally by a developer, to prevent
# cluttering the output of `git status` and prevent people from accidentally
# checking in locally installed skills.
skills/*
# But don't ignore the ones that belong to this project and are checked in. As
# we add skills that we intend to commit and make available to all project
# developers, they must be individually added here if they don't start with
# "oiio-".
!skills/oiio-*/
!skills/prepare-patch-release/
!skills/release-notes-update/
-294
View File
@@ -1,294 +0,0 @@
#!/usr/bin/env bash
# .agents/setup-agent — Set up AI coding tool integration for this repository.
#
# Creates the tool-specific symlinks and config files needed to use the shared
# resources in AGENTS.md and .agents/ with your preferred AI coding assistant.
# Run "setup-agent <tool>" once after cloning; re-running is always safe.
#
# The canonical project instructions live in AGENTS.md (root) and skills live
# in .agents/skills/<name>/SKILL.md. Everything tool-specific is either a
# symlink into those locations, or a thin wrapper that references them.
# Tool-specific directories (.claude/, .cursor/, etc.) are git-ignored so that
# each developer runs this script for the tool they actually use.
#
# ─────────────────────────────────────────────────────────────────────────────
# TOOL STRATEGIES (update this section when tool conventions change)
# ─────────────────────────────────────────────────────────────────────────────
#
# CLAUDE CODE
# Reads: .claude/CLAUDE.md (project) or CLAUDE.md (root) — NOT AGENTS.md natively.
# If Anthropic eventually adds native AGENTS.md support, the
# .claude/CLAUDE.md wrapper can be retired.
# Skills: .claude/skills/ (each subdirectory is a skill)
# Setup: Write .claude/CLAUDE.md containing "@AGENTS.md" (Claude's include
# syntax), symlink .claude/skills -> ../.agents/skills.
# Docs: https://docs.anthropic.com/en/docs/claude-code/memory
# https://docs.anthropic.com/en/docs/claude-code/skills
#
# OPENAI CODEX
# Reads: AGENTS.md natively — no wrapper needed.
# Skills: .agents/skills/ natively, and also .codex/skills/ as a fallback.
# Setup: Symlink .codex/skills -> ../.agents/skills so either path works.
# Docs: https://developers.openai.com/codex/guides/agents-md
# https://developers.openai.com/codex/skills
#
# CURSOR
# Reads: .cursor/rules/*.mdc files — does NOT read AGENTS.md natively.
# If Cursor adds native AGENTS.md support, the rules symlink can be
# retired.
# Skills: Cursor uses a different slash-command mechanism; .agents/skills/
# are not directly usable today, but the convention may change.
# Setup: Symlink .cursor/rules/project.mdc -> ../../AGENTS.md so Cursor
# picks up our instructions as a project rule.
# Docs: https://docs.cursor.com/context/rules-for-ai
# https://docs.cursor.com/cmdk/overview
#
# OPENCODE
# Reads: AGENTS.md natively — no wrapper needed.
# Skills: Documented to read .agents/skills/ natively, but in practice also
# requires .opencode/commands/<name>.md symlinks (as of 2025-05).
# Remove the per-command symlinks once opencode reliably finds
# .agents/skills/ on its own.
# Setup: Symlink .opencode/skills -> ../.agents/skills (future-proof),
# plus individual .opencode/commands/<name>.md -> skill SKILL.md
# files (current workaround).
# Docs: https://opencode.ai/docs/configuration
# https://opencode.ai/docs/skills
#
# GITHUB COPILOT
# Reads: AGENTS.md natively (VS Code Copilot ≥ 1.99 / GitHub Copilot Chat).
# Also reads .github/copilot-instructions.md as a fallback for older
# clients or non-VS Code surfaces.
# Skills: .agents/skills/ natively supported.
# Setup: Symlink .github/copilot-instructions.md -> ../AGENTS.md so older
# clients also receive our instructions. Remove once all Copilot
# surfaces reliably pick up AGENTS.md directly.
# Docs: https://code.visualstudio.com/docs/copilot/customization/custom-instructions
# https://docs.github.com/en/copilot/concepts/about-prompting-copilot
# https://docs.github.com/en/copilot/concepts/agents/about-agent-skills
# ─────────────────────────────────────────────────────────────────────────────
set -euo pipefail
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
REPO_ROOT="$(cd "$SCRIPT_DIR/.." && pwd)"
SKILLS_DIR=".agents/skills"
SUPPORTED_TOOLS="claude codex cursor opencode copilot"
usage() {
cat <<EOF
Usage: .agents/setup-agent <tool|all|clear|list> [tool...]
Commands:
<tool> [...] Set up one or more tools
all Set up all supported tools
clear Remove all tool-specific setup created by this script
clear <tool> Remove setup for one specific tool
list List supported tools
Supported tools: $SUPPORTED_TOOLS
Examples:
.agents/setup-agent claude
.agents/setup-agent claude cursor
.agents/setup-agent all
.agents/setup-agent clear
.agents/setup-agent clear opencode
EOF
}
rel() { echo "${1#"$REPO_ROOT"/}"; }
# Create a symlink only if the path doesn't already exist.
# Silent if the link already points to the correct target.
safe_symlink() {
local link="$1" target="$2"
if [ -L "$link" ] && [ "$(readlink "$link")" = "$target" ]; then
return 0
elif [ -e "$link" ] || [ -L "$link" ]; then
echo " SKIP (already exists): $(rel "$link")"
return 0
fi
mkdir -p "$(dirname "$link")"
ln -s "$target" "$link"
echo " LINK: $(rel "$link") -> $target"
}
# Write a file only if the path doesn't already exist.
safe_write() {
local file="$1"
shift
local content="$*"
if [ -e "$file" ]; then
echo " SKIP (already exists): $(rel "$file")"
return 0
fi
mkdir -p "$(dirname "$file")"
printf '%s\n' "$content" > "$file"
echo " FILE: $(rel "$file")"
}
# Remove a symlink only if it still points to the expected target.
safe_remove_symlink() {
local link="$1" expected_target="$2"
[ ! -L "$link" ] && return 0
if [ "$(readlink "$link")" = "$expected_target" ]; then
rm "$link"
echo " REMOVED: $(rel "$link")"
else
echo " SKIP (modified, not removing): $(rel "$link")"
fi
}
# Remove a file only if its content still matches what we wrote.
safe_remove_file() {
local file="$1"
shift
local expected="$*"
[ ! -f "$file" ] || [ -L "$file" ] && return 0
if [ "$(cat "$file")" = "$expected" ]; then
rm "$file"
echo " REMOVED: $(rel "$file")"
else
echo " SKIP (modified, not removing): $(rel "$file")"
fi
}
try_rmdir() { rmdir "$1" 2>/dev/null && echo " RMDIR: $(rel "$1")" || true; }
#------------------------------------------------------------------------------
# Claude Code (.claude/)
#------------------------------------------------------------------------------
setup_claude() {
echo "Setting up Claude Code..."
safe_write "$REPO_ROOT/.claude/CLAUDE.md" "@AGENTS.md"
safe_symlink "$REPO_ROOT/.claude/skills" "../.agents/skills"
safe_write "$REPO_ROOT/.claude/.gitignore" "settings.local.json"
}
clear_claude() {
echo "Removing Claude Code setup..."
safe_remove_file "$REPO_ROOT/.claude/CLAUDE.md" "@AGENTS.md"
safe_remove_symlink "$REPO_ROOT/.claude/skills" "../.agents/skills"
safe_remove_file "$REPO_ROOT/.claude/.gitignore" "settings.local.json"
try_rmdir "$REPO_ROOT/.claude"
}
#------------------------------------------------------------------------------
# OpenAI Codex (.codex/)
#------------------------------------------------------------------------------
setup_codex() {
echo "Setting up OpenAI Codex..."
safe_symlink "$REPO_ROOT/.codex/skills" "../.agents/skills"
safe_write "$REPO_ROOT/.codex/.gitignore" "*.log"
}
clear_codex() {
echo "Removing OpenAI Codex setup..."
safe_remove_symlink "$REPO_ROOT/.codex/skills" "../.agents/skills"
safe_remove_file "$REPO_ROOT/.codex/.gitignore" "*.log"
try_rmdir "$REPO_ROOT/.codex"
}
#------------------------------------------------------------------------------
# Cursor (.cursor/)
#------------------------------------------------------------------------------
setup_cursor() {
echo "Setting up Cursor..."
safe_symlink "$REPO_ROOT/.cursor/rules/project.mdc" "../../AGENTS.md"
safe_write "$REPO_ROOT/.cursor/.gitignore" "$(printf 'composer/\nchat/')"
}
clear_cursor() {
echo "Removing Cursor setup..."
safe_remove_symlink "$REPO_ROOT/.cursor/rules/project.mdc" "../../AGENTS.md"
safe_remove_file "$REPO_ROOT/.cursor/.gitignore" "$(printf 'composer/\nchat/')"
try_rmdir "$REPO_ROOT/.cursor/rules"
try_rmdir "$REPO_ROOT/.cursor"
}
#------------------------------------------------------------------------------
# Opencode (.opencode/)
#------------------------------------------------------------------------------
OPENCODE_GITIGNORE="$(printf 'node_modules\npackage.json\npackage-lock.json\nbun.lock')"
setup_opencode() {
echo "Setting up Opencode..."
safe_symlink "$REPO_ROOT/.opencode/skills" "../.agents/skills"
safe_write "$REPO_ROOT/.opencode/.gitignore" "$OPENCODE_GITIGNORE"
# Individual command links (needed in practice despite docs implying otherwise)
for skill_dir in "$REPO_ROOT/$SKILLS_DIR"/*/; do
[ -d "$skill_dir" ] || continue
local skill_name
skill_name="$(basename "$skill_dir")"
safe_symlink "$REPO_ROOT/.opencode/commands/${skill_name}.md" \
"../../$SKILLS_DIR/${skill_name}/SKILL.md"
done
}
clear_opencode() {
echo "Removing Opencode setup..."
safe_remove_symlink "$REPO_ROOT/.opencode/skills" "../.agents/skills"
safe_remove_file "$REPO_ROOT/.opencode/.gitignore" "$OPENCODE_GITIGNORE"
for skill_dir in "$REPO_ROOT/$SKILLS_DIR"/*/; do
[ -d "$skill_dir" ] || continue
local skill_name
skill_name="$(basename "$skill_dir")"
safe_remove_symlink "$REPO_ROOT/.opencode/commands/${skill_name}.md" \
"../../$SKILLS_DIR/${skill_name}/SKILL.md"
done
try_rmdir "$REPO_ROOT/.opencode/commands"
try_rmdir "$REPO_ROOT/.opencode"
}
#------------------------------------------------------------------------------
# GitHub Copilot (.github/copilot-instructions.md)
# Copilot natively reads AGENTS.md, but also checks copilot-instructions.md.
#------------------------------------------------------------------------------
setup_copilot() {
echo "Setting up GitHub Copilot..."
safe_symlink "$REPO_ROOT/.github/copilot-instructions.md" "../AGENTS.md"
}
clear_copilot() {
echo "Removing GitHub Copilot setup..."
safe_remove_symlink "$REPO_ROOT/.github/copilot-instructions.md" "../AGENTS.md"
}
#------------------------------------------------------------------------------
# Dispatch
#------------------------------------------------------------------------------
run_tool() {
local action="$1" tool="$2"
case "$tool" in
claude) "${action}_claude" ;;
codex) "${action}_codex" ;;
cursor) "${action}_cursor" ;;
opencode) "${action}_opencode" ;;
copilot) "${action}_copilot" ;;
*)
echo "Unknown tool: $tool (supported: $SUPPORTED_TOOLS)" >&2
exit 1
;;
esac
}
[ $# -eq 0 ] && { usage; exit 0; }
case "$1" in
all)
for t in $SUPPORTED_TOOLS; do run_tool setup "$t"; done
;;
clear)
shift
if [ $# -eq 0 ]; then
for t in $SUPPORTED_TOOLS; do run_tool clear "$t"; done
else
for t in "$@"; do run_tool clear "$t"; done
fi
;;
list)
echo "Supported tools: $SUPPORTED_TOOLS"
;;
-h|--help|help)
usage
;;
*)
for t in "$@"; do run_tool setup "$t"; done
;;
esac
@@ -1,104 +0,0 @@
---
name: prepare-patch-release
description: Do all the tasks needed for a patch release of the project.
argument-hint: [new-version]
---
Do all the tasks needed for a patch release of the project. These patch
releases generally happen on the first day of every month.
Arguments: `$ARGUMENTS`
- First argument (optional): the version of the upcoming release we are
preparing. If omitted, find the most recent tag on this branch, and the
new version will update the third portion of the version. It might be
either a version number (like `3.1.4.0`) or a tag (like `v3.1.4.0`).
Hint: The numeric "version" is a four-part numeric deignation with the pattern
`MAJOR.MINOR.PATCH.TWEAK`. The "version tag" is usually the numeric version
with a "v" prepended, for example, `v3.1.4.0`.
## Steps and Checklist
- [ ] Determine the version of the new release.
- [ ] Update the main @CMakeLists.txt.
- [ ] Use the "release-notes-update" skill to update @CHANGES.md.
- [ ] Review the release notes to ensure that the changes do not deprecate any
API calls or break API or ABI backward-compatibility, or remove support
for any dependency or toolchain versions. If you think these rules are
being violated, ask for confirmation.
- [ ] Review @README.md for changes.
- [ ] Review @INSTALL.md for changes.
- [ ] Review @CREDITS.md for changes.
- [ ] Review @SECURITY.md for changes.
## Steps to determine the versions of the last and new releases.
1. **Determine the previous tag** if not provided by looking at the
most recent git tag in the current branch, and deducing the 4-part
version number from that.
2. The assumed new version for a patch release has the same major and minor
numbers, the patch number is incremented by one since the last tag, and the
tweak number is "0".
3. If no optional version was present in the arguments, use the assumed new
version.
4. If a version was supplied in the arguments, double check that it differs
from the last tag as explained above. If it does not, ask for verification
that the version requested is correct before proceeding.
## Steps to update CMakeLists.txt
1. In the main @CMakeLists.txt, alter the version to that of the new release,
if it isn't already the same.
2. For a patch release, ensure that `${PROJECT_NAME}_SUPPORTED_RELEASE` should
be set to ON. In main (not yet a supported release) it shold be OFF. If you
find these to not be as expected, ask for confirmation of whether to fix.
3. For a patch release, `PROJECT_VERSEION_RELEASE_TYPE` should be set to empty
(""). In main, it will typically be "dev", "beta", or other designations.
If you find these to not be as expected, ask for confirmation of whether to
fix.
## Reviewing README.md
If this release added support for any new image file formats, be sure that
README.md mentions them in its list of image formats supported.
## Reviewing INSTALL.md
If any of the new commits (as described in the release notes for this version)
appear to add dependencies, or add support for new versions of dependencies,
be sure that INSTALL.md is updated to include that dependency (if not already
listed among the required and optional dependencies), and reflects the latest
version that we claim to support.
Double check @externalpackages.cmake and ensure that any minimum required
versions of dependencies that cmake will enforce match the oldest versions
of those dependencies as documentd in INSTALL.md.
## Reviewing CREDITS.md
The @CREDITS.md file lists all known contributors to the project, sorted alpha
by first name. In cases where an author's actual name is unknown, we use the
GitHub userid.
Ensure that any authors referenced in the new release notes for the version we
are releasing are inserted in the credit list, if they are not already
present. You don't need to check older versions, we presume those have already
been included.
## Reviewing SECURITY.md
The @SECURITY.md file lists which versions are currently supported at what
levels, and lists all previously-fixed SVE's or security advisories. Be sure
to check this file in older branches (the last two releases, say), and if you
are preparing a patch release, also check in main and more recent (higher
numbered) releases for more recently modified SECURITY.md, and be sure that
this branch gets amended with any information that seems to have been updated
more recently in those other branches. Check whichever is newer of the local
and remote copy of that branch, since the local one may have had release notes
or its version in CMakeLists.txt updated, but not yet pushed to GitHub.
## Reference
- Full release procedures: `docs/dev/RELEASING.md`
- Steps for updating release notes: `release-notes-update/SKILL.md`
@@ -1,246 +0,0 @@
---
name: release-notes-update
description: Generate or update release notes for a patch, minor, or major release, or just to update main. Run git-cliff, organize and edit the output per project conventions, and insert into CHANGES.md.
argument-hint: [patch|minor|major|main] [prev-tag]
---
Generate release notes for an OpenImageIO release.
Arguments: `$ARGUMENTS`
- First argument (optional): release type — `patch` (default), `minor`, `major`, or `main`.
- Second argument (optional): previous release tag (e.g. `v3.1.2.0`). If omitted, find the most recent tag automatically. If the release type is `main`, instead of a tag, look for the last commit at which the CHANGES.md file was updated.
## Steps
1. **Determine the previous tag** if not provided:
```
git describe --tags --abbrev=0
```
or look at recent tags: `git tag --sort=-version:refname | head -10`.
However, if the "release type" is `main`, instead of a tag, just find
the commit at which CHANGES.md was last updated.
2. **Run git-cliff** to get raw commit data:
```
git cliff -c src/doc/cliff.toml <prev-tag>..HEAD > /tmp/cliff-out.md
```
Read `/tmp/cliff-out.md` to see the raw output.
3. **Required, do not skip:** Look up the GitHub user ID for each author (use
`gh pr view NNNN --repo AcademySoftwareFoundation/OpenImageIO --json
author` — the login is discernable from the posted PR, but not from the
local commit). Rewrite every git-cliff author credit from `(by First
Last)` to the combined form `(by @githubid / First Last)` before drafting
the formatted notes in step 5. This applies to patch, minor, major, and
main updates alike — the combined format is the standard for every
release type, not just an example in the patch skeleton. Only fall back to
a single form — `(by @githubid)` or `(by First Last)` — if the other half
genuinely cannot be found; don't skip the github lookup just because the
real name is already known from the local commit.
4. **Read CHANGES.md** to see the current top of the file and understand where to insert.
5. **Format the release notes** according to the release type:
### For patch releases:
Follow the skeleton in `docs/dev/Changes-skeleton-patch.md`:
```
Release X.Y.Z.W (Month DD, YYYY) -- compared to X.Y.Z.W-1
---------------------------------------------------------
- *category*: Description. [#NNNN](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/NNNN) (by @authorid / author-full-name)
```
Rules:
- **Remove** the section headings git-cliff generates; patch notes are a flat
list.
- **Add conventional commit prefixes** to any "uncategorized" entries (those
lacking a `feat:`, `fix:`, etc. prefix).
- **Reorder** entries logically: feature enhancements first, then bug fixes,
then build/CI fixes, then internal changes, then test improvements, then
docs/admin.
- **Omit** entries that are purely internal and too minor to matter to users.
Ask for confirmation about entries you propose to omit.
- Author credit is `(by @githubid / Full Name)` per step 3 above. Use just
`(by @githubid)` or `(by Full Name)` only if the other half truly can't be
found — don't drop the githubid merely because the name is already known.
- Omit the author if it is the project leader, Larry Gritz, unless he is not
the dominant author (at least 75% of commits) in this release.
- Keep entries to one line each. Be terse but informative.
- Use the format `*subsystem*:` for the category prefix (e.g., image file
format like `*exr*:`, utility like `*oiiotool*:`, class or API category like
`*IBA*:`, or topic category such as `*build*:`, `*ci*:`, `*docs*:`).
- We aim to make patch releases on the first day of each month. If we are
within a few days of a month end, list the date as the beginning of the
upcoming month. Ask for confirmation that this is the planned release date.
### For minor or major releases:
Follow the skeleton in `docs/dev/Changes-skeleton-major.md`. Sections:
```
Release X.Y.0.0 (Month, YYYY) -- compared to X.Y-1
--------------------------------------------------
### New minimum dependencies and compatibility changes:
### ⛰️ Major new features and public API changes:
* *New image file format support:*
* *oiiotool new features and major improvements*:
* *Command line utilities*:
* *API changes*
* Other notable new feature:
### 🚀 Performance improvements:
### 🐛 Fixes and feature enhancements:
### 🔧 Internals and developer goodies
### 🏗 Build/test/CI and platform ports:
* CMake build system and scripts:
* Dependency and platform support:
* Testing and Continuous integration (CI) systems:
### 📚 Notable documentation changes:
### 🏢 Project Administration
### 🤝 Contributors
```
Note that the section outline may already be present, in which case you
only need to fit items into the existing category outline.
Rules:
- Group commits into sections; within each section, cluster related items together.
- When needed, expand terse one-liners into enough prose that users understand what changed and why it matters.
- For `feat:` commits, make sure the feature is explained sufficiently — don't just copy the commit subject.
- For `api:` or `api!:` commits, clearly call out what changed in the public API.
- Include PR links and author attribution for every entry, in the combined
`(by @githubid / Full Name)` form from step 3.
- The notes should "tell the story" of the release, not just be a dump of commit subjects.
- We aim to make major/minor releases approximately in October 1 of each year. If the anticipted release date is already in the file, don't change it. If it is not present, ask for confirmation of the planned release date.
### For updating release notes in main:
Rules:
- Generally, follow the rules for "major/minor releases", except as noted in other items below.
- Don't apply a new skeleton of category listings unless they are not present for the upcoming release.
5. **Insert the formatted notes** into `CHANGES.md` in the appropriate place (as detailed below). Leave the existing content intact.
- When updating `main` or preparing a `major` or `minor` release, insert the updates in the top section for the upcoming major/minor release. Insert a new set of category sections only if it's not already present.
- When doing a `patch` release, insert the changes immediately above the last patch release of that branch, so that CHANGES.md lists releases in descending numerical (version) order.
- When porting a set of release notes from a release branch into main, or from an older (obsolete) release branch to the current release branch, insert it into the right place to maintain overall descending order.
6. **Double check that the notes are adequately descriptive.** (See more
detailed description of this step below.)
7. **Forward-port release notes from release branches if needed**
8. **Show a summary** of what was inserted and ask the user to review before finalizing.
## Forward-porting release notes
Release notes may have been generated independently in main, and release
branches. When updating one branch, we ensure that any changes from older
branches have been incorporated.
- When preparing `patch` release notes, check the CHANGES.md file in the
"dev-X.(Y-1)" branch for the previous minor release family to identify any
X.(Y-1).Z patch release notes that are not reflected in the current release
notes that we are updating.
- When updating `main` or doing a `major` or `minor` release, check the
CHANGES.md file in both the "dev-X.(Y-1)" and "dev-X.(Y-2)" branches.
Check whichever is newer of the local and remote copy of that branch, since
the local one may have had release notes or its version in CMakeLists.txt
updated, but not yet pushed to GitHub.
- If any patch releases are present in the older dev branches checked, insert
the release notes for those patch releases into the right positions in the
current release notes that we are updating.
- If a change is forward-ported in this manner and the same PR is an update in
the current set of changes we are updating as our main task, document that
in the current set of notes using the following convention: in the line of
the notes, the explanation of the version where it appears should reflect
the first version of all branches where it appeared, for example, `(3.2.0.0,
3.1.3.0, 3.0.8.0)` to indicate that the patch was added to each of those
versions. The versions should be listed in descending order.
## Useful abbreviations for category labels
| Abbrev | Meaning |
|--------|---------|
| IB | ImageBuf |
| IBA | ImageBufAlgo |
| IC | ImageCache |
| TS | TextureSystem |
| oiiotool | the oiiotool command |
| build | CMake/build system |
| deps | Changes to accommodate dependency or toolchain changes |
| ci | CI/GitHub Actions |
| docs | documentation |
| int | internal/refactor |
| test | testsuite or unit tests |
| HEADER.h | Developer utilities in a public header file |
## Combining PRs into single entries
To be more concise and easier to read, within a release's notes, related
PRs/commits can be combined into a single bullet-point line, which would look
like
```
- *category*: Combined Description. [#NNNN1](URL) (by author1) [#NNNN2](URL2) (by author2) [#NNNN2](URL2) (by author2)
```
if fully combined, or if explained one by one,
```
- *category*: Description 1 [#NNNN1](URL) (by author1), amendment 2, [#NNNN2](URL2) (by author2), amendment 3, [#NNNN3](URL3) (by author3)
```
Choose the fully combined or explained one by one based on which is more clear
to the reader.
If the authors are all the same, only have the author designation at the end.
Here are the cases where it's ok to combine commits in this way:
- If it is clear that multiple PRs are part of the same feature or fix,
consisting of an initial commit, and subsequent smaller changes or
continuations of the same topic.
- An initial commit, and a subsequent commit that is obviously a fix to a bug
in the initial commit.
- "CI" changes that all only add new cases to the test matrix.
- "CI" changes that all only fix spontaneous breakages in the GitHub runners.
- "Build" changes that are all just minor updates to versions of dependencies
that we support or test against.
Some more examples of combined commit messages:
```
- feat: Add GPS metadata functionality for TIFF [PR1](PR URL 1) [PR2](PR URL 2) [PR3](PR URL 3) (by author).
- ci: New CI variants for MSVS 2026 [PR1](PR URL 1) (by author1), VFX Platform 2027 [PR2](PR URL 2) (by author2).
- ci: Various fixes for unexpected changes to GitHub Actions runners [PR1](PR URL 1), [PR2](PR URL 2) (by author)
- build: Added support for gcc 15 [PR1](PR URL 1) (by author1), OpenEXR 3.5.1 [PR2](PR URL 2) (by author2), libtiff 4.8 [PR3](PR URL 3) (by author3).
```
Always ask for confirmation before combining commits in this manner. Confirm
separately for each proposed combination of a group of multiple original
commits into a single commit. Give the user the opportunity to revise the
combined description or request other changes for the grouping.
## Double check that the notes are adequately descriptive
For newly added items for this release, read the short descriptions provided
by git-cliff, double check them against the full commit messages to be sure
the one-line summary is adequate. If the summary is misleading, too brief and
leaving out the fact that an important thing was changed, or not adequately
capturing the scope of changes, feel free to propose an alternate wording that
will make it more clear to readers what changed as a result of the PR. Ask for
confirmation on these and explain why you felt the one-line description wasn't
enough.
One example of a case where this is needed is if the one line description
merely mentions a new image processing capability by name, but the full commit
message makes it clear that a new ImageBufAlgo API call was added, and also a
new oiiotool command line argument was added, and that couldn't all be
described in the one-line brief message of the commit.
## Reference
Full release procedures: `docs/dev/RELEASING.md`
Patch skeleton: `docs/dev/Changes-skeleton-patch.md`
Major skeleton: `docs/dev/Changes-skeleton-major.md`
Example good patch notes: https://github.com/AcademySoftwareFoundation/OpenImageIO/releases/tag/v3.0.0.0
Example good major/minor notes: https://github.com/AcademySoftwareFoundation/OpenImageIO/releases/tag/v3.1.6.1
+2 -1
View File
@@ -1,5 +1,6 @@
Language: Cpp
BasedOnStyle: WebKit
SpaceBeforeParens: ControlStatements
AccessModifierOffset: -4
AlignAfterOpenBracket: Align
@@ -121,7 +122,7 @@ SpacesInContainerLiterals: true
SpacesInCStyleCastParentheses: false
SpacesInParentheses: false
SpacesInSquareBrackets: false
Standard: c++17
Standard: c++14
StatementMacros:
- Q_UNUSED
- QT_REQUIRE_VERSION
-7
View File
@@ -36,10 +36,3 @@ f701a76b745b6ddba41c77b24a1ea7e1f48ae0b4
# clang-format: Adjust alignment of line continuation backslashes (#2664)
742173e39588e07cf43cbe7b49dd22d624a48388
d8810c5365ea88e2b1bce6155b7b495c18f2f9bc
# style: update our formatting standard to clang-format 17.0 and C++17 (#4096)
c618d45e13dcc382fb07a948be84b8074d1ed481
b88b82ffe9b3c4fcf04bf17bacc4ee77b2d1ed92
# style: Turn on clang-format for ivmain.cpp (#4382)
55872131ada91e0fa3b8bc4519e335b352d284df
-17
View File
@@ -1,17 +0,0 @@
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# Helpful documentation:
# - https://github.com/github-linguist/linguist/blob/main/docs/overrides.md
# - https://github.com/github-linguist/linguist/blob/main/docs/troubleshooting.md
*.h linguist-language=C++
src/libOpenImageIO/bluenoise.inc -linguist-detectable
# Image test fixtures are binary and must never be CRLF-converted on
# checkout. Some (e.g. tiny/corrupt HDR files) are mostly ASCII and would
# otherwise be misdetected as text, breaking byte-exact reader tests.
*.hdr binary
*.rgbe binary
+13 -27
View File
@@ -1,51 +1,37 @@
---
name: Bug report
about: I think I have identified a legit bug and can describe it.
title: "bug:"
title: "[BUG]"
labels: ''
assignees: ''
---
<!-- THESE ARE JUST SUGGESTIONS. FEEL FREE TO DELETE ALL OF THIS AND -->
<!-- WRITE YOUR OWN THOROUGH BUG REPORT. -->
**Describe the bug**
A clear and concise description of what the bug is. What happened, and
what did you expect to happen instead.
**OpenImageIO version and dependencies**
Please run `oiiotool --buildinfo` and paste the output here.
Also please tell us if there was anything unusual about your environment or
nonstandard build options you used.
**To Reproduce**
Steps to reproduce the behavior:
1. Do this...
2. Then this...
3. Then THIS happens (reproduce the exact error message if you can)
4. Whereas I expected this other specific thing to happen instead.
If the problem occurs in your C++ or Python code that uses the OIIO APIs, can
you also reproduce the problem using oiiotool? If so, please describe the
exact command line that reproduces the problem. (Being able to reproduce the
problem using only OIIO components makes it a lot easier for the developers
investigate and makes it clear it's not your application's fault.)
**Expected behavior**
A clear and concise description of what you expected to happen.
**Evidence**
Do you have error messages? (please quote exactly) Screenshots? Example
command lines or scripts that reliably reproduce the error? If it only
happens with certain image files, can you attach the smallest image you
can make that reproduces the problem?
- Error messages (paste them here exactly)
- Screenshots (if helpful)
- Example input: If the problem only happens with certain image files, please
attach the smallest image you can make that reproduces the problem.
**Platform information:**
- OIIO branch/version:
- OS:
- C++ compiler:
- Any non-default build flags when you build OIIO:
**IF YOU ALREADY HAVE A CODE FIX:** There is no need to file a separate issue,
please just go straight to making a [pull request](https://github.com/AcademySoftwareFoundation/OpenImageIO/pulls).
please just go straight to making a [pull request](https://github.com/OpenImageIO/oiio/pulls).
+4 -5
View File
@@ -1,17 +1,16 @@
---
name: Build problems
about: I'm having trouble building OIIO. Help!
title: "build:"
title: "[BUILD]"
labels: ''
assignees: ''
---
**PLEASE DO NOT REPORT BUILD TROUBLES AS GITHUB "ISSUES" UNLESS YOU ARE REALLY SURE IT'S A BUG**
**PLEASE DO NOT REPORT BUILD TROUBLES AS GITHUB "ISSUES" UNLESS YOU ARE RALLY SURE IT'S A BUG**
The best way to get help with your build problems is to ask a question on the
[oiio-dev developer mail list](https://lists.aswf.io/g/oiio-dev) or on the
[ASWF Slack](https://slack.aswf.io) `#openimageio` channel.
[oiio-dev developer mail list](https://lists.aswf.io/g/oiio-dev).
When you email about this, please attach one or both of the following:
1. The full verbose build log, which you can create like this:
@@ -19,4 +18,4 @@ When you email about this, please attach one or both of the following:
2. The `CMakeCache.txt` file from your build directory.
If you are pretty sure that you have identified a **BUG** in the OpenImageIO
build scripts, please file a [bug report issue](https://github.com/AcademySoftwareFoundation/OpenImageIO/issues/new?template=bug_report.md).
build scripts, please file a [bug report issue](https://github.com/OpenImageIO/oiio/issues/new?template=bug_report.md).
+1 -4
View File
@@ -1,15 +1,12 @@
---
name: Feature request
about: I have a concrete idea about how to improve OpenImageIO.
title: "feat:"
title: "[FEATURE REQUEST]"
labels: ''
assignees: ''
---
<!-- THESE ARE JUST SUGGESTIONS. FEEL FREE TO DELETE ALL OF THIS AND -->
<!-- WRITE YOUR OWN THOROUGH FEATURE REQUEST. -->
**Is your feature request related to a problem? Please describe.**
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+5 -5
View File
@@ -1,7 +1,7 @@
---
name: Question
about: How do I... I need help with...
title: "help:"
title: "[HELP]"
labels: ''
assignees: ''
@@ -10,7 +10,7 @@ assignees: ''
**PLEASE DO NOT ASK USAGE QUESTIONS USING GITHUB "ISSUES"**
If you are pretty sure that you have identified a **BUG** in OpenImageIO,
please file a [bug report issue](https://github.com/AcademySoftwareFoundation/OpenImageIO/issues/new?template=bug_report.md).
please file a [bug report issue](https://github.com/OpenImageIO/oiio/issues/new?template=bug_report.md).
But if you are just asking a question:
* How do I...?
@@ -18,10 +18,10 @@ But if you are just asking a question:
* Am I doing something wrong?
* I can't build OpenImageIO
For anything of this nature, the best way to get help using OpenImageIO is to
ask a question on the [oiio-dev developer mail list](https://lists.aswf.io/g/oiio-dev) or the [ASWF Slack](https://slack.aswf.io) `#openimageio` channel.
For anything of this nature, the best way to get help using OpenImageIO is
to ask a question on the [oiio-dev developer mail list](https://lists.aswf.io/g/oiio-dev).
The [documentation](https://docs.openimageio.org)
The [documentation](https://openimageio.readthedocs.org)
is pretty comprehensive, so please check there first; you may find the answer
more quickly than you can get your question answered on the mail list.
+18 -35
View File
@@ -1,49 +1,32 @@
<!-- This is just a guideline and set of reminders about what constitutes -->
<!-- a good PR. Feel free to delete all this matter and replace it with -->
<!-- your own detailed message about the PR, assuming you hit all the -->
<!-- important points made below. -->
------ :scissors: -------------------------------------------------------------------
YOU MAY DELETE ALL OF THIS IF YOU ALREADY HAVE A DESCRIPTIVE COMMIT MESSAGE!
This is just a template and set of reminders about what constitutes a good PR.
But please look over the checklist at the bottom.
If THIS TEXT is still in your PR description, we'll know you didn't read the
instructions!
### Description
## Description
<!-- Please provide a description of what this PR is meant to fix, and -->
<!-- how it works (if it's not going to be very clear from the code). -->
### Tests
## Tests
<!-- Did you / should you add a testsuite case (new test, or add to an -->
<!-- existing test) to verify that this works? -->
### Checklist:
## Checklist:
<!-- Put an 'x' in the boxes as you complete the checklist items -->
- [ ] **I have read the guidelines** on [contributions](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/CONTRIBUTING.md) and [code review procedures](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/docs/dev/CodeReview.md).
- [ ] **I have read the [Policy on AI Coding Assistants](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/docs/dev/AI_Policy.md)**
and if I used AI coding assistants, I have an `Assisted-by: TOOL / MODEL`
line in the pull request description above.
- [ ] **I have updated the documentation** if my PR adds features or changes
behavior.
- [ ] **I am sure that this PR's changes are tested in the testsuite**.
- [ ] **I have run and passed the testsuite in CI** *before* submitting the
PR, by pushing the changes to my fork and seeing that the automated CI
passed there. (Exceptions: If most tests pass and you can't figure out why
the remaining ones fail, it's ok to submit the PR and ask for help. Or if
any failures seem entirely unrelated to your change; sometimes things break
on the GitHub runners.)
- [ ] **My code follows the prevailing code style of this project** and I
fixed any problems reported by the clang-format CI test.
- [ ] If I added or modified a public C++ API call, I have also amended the
corresponding Python bindings. If altering ImageBufAlgo functions, I also
exposed the new functionality as oiiotool options.
- [ ] I have read the [contribution guidelines](https://github.com/OpenImageIO/oiio/blob/master/CONTRIBUTING.md).
- [ ] I have updated the documentation, if applicable.
- [ ] I have ensured that the change is tested somewhere in the testsuite
(adding new test cases if necessary).
- [ ] If I added or modified a C++ API call, I have also amended the
corresponding Python bindings (and if altering ImageBufAlgo functions, also
exposed the new functionality as oiiotool options).
- [ ] My code follows the prevailing code style of this project. If I haven't
already run clang-format before submitting, I definitely will look at the CI
test that runs clang-format and fix anything that it highlights as being
nonconforming.
+90 -66
View File
@@ -1,6 +1,6 @@
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# SPDX-License-Identifier: BSD-3-Clause
# https://github.com/OpenImageIO/oiio
name: Analysis
@@ -11,32 +11,15 @@ on:
# Run unconditionally once weekly
# - cron: "0 0 * * 0"
push:
# Run on pushes only to main or if the branch name contains "analysis"
branches:
- main
- dev-3.0
- '*analysis*'
- '*sonar*'
paths:
- '**'
- '!**.md'
- '!**.rst'
- '!**/ci.yml'
- '!**/docs.yml'
- '!**/scorecard.yml'
- '!**/wheel.yml'
- '!**.properties'
- '!pyproject.toml'
- '!docs/**'
# Run analysis on PRs only if the branch name indicates that the purpose of
# the PR is related to the Sonar analysis. We don't run on every PR because
# the analysis run is very expensive and just isn't usually necessary.
pull_request:
# Run on pushes only to master or if the branch name contains "analysis"
branches:
- master
- '*analysis*'
- '*sonar*'
# Allow manual kicking off of the workflow from github.com
workflow_dispatch:
# Uncomment the following line if we want to run analysis on all PRs:
# pull_request:
permissions: read-all
@@ -52,59 +35,100 @@ jobs:
name: "SonarCloud Analysis"
# Exclude runs on forks, since only the main org has the SonarCloud
# account credentials.
if: github.event.repository.fork == false
uses: ./.github/workflows/build-steps.yml
# Must let the called steps workflow inherit necessary secrets
secrets:
PASSED_GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
PASSED_SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
with:
nametag: ${{ matrix.nametag || 'unnamed!' }}
runner: ${{ matrix.runner || 'ubuntu-latest' }}
container: ${{ matrix.container }}
cc_compiler: ${{ matrix.cc_compiler }}
cxx_compiler: ${{ matrix.cxx_compiler }}
cxx_std: ${{ matrix.cxx_std || '17' }}
build_type: ${{ matrix.build_type || 'Release' }}
depcmds: ${{ matrix.depcmds }}
extra_artifacts: ${{ matrix.extra_artifacts }}
fmt_ver: ${{ matrix.fmt_ver }}
opencolorio_ver: ${{ matrix.opencolorio_ver }}
openexr_ver: ${{ matrix.openexr_ver }}
pybind11_ver: ${{ matrix.pybind11_ver }}
python_ver: ${{ matrix.python_ver }}
setenvs: ${{ matrix.setenvs }}
simd: ${{ matrix.simd }}
skip_build: ${{ matrix.skip_build }}
skip_tests: ${{ matrix.skip_tests }}
abi_check: ${{ matrix.abi_check }}
build_docs: ${{ matrix.build_docs }}
generator: ${{ matrix.generator }}
ctest_args: ${{ matrix.ctest_args }}
ctest_test_timeout: ${{ matrix.ctest_test_timeout }}
coverage: ${{ matrix.coverage || '0' }}
sonar: ${{ matrix.sonar || '0' }}
if: github.repository == 'OpenImageIO/oiio'
strategy:
fail-fast: false
matrix:
include:
- desc: sonar gcc11/C++17 py311 exr3.2 ocio2.3
- desc: sonar gcc9/C++14 py39 boost1.76 exr3.1 ocio2.1
nametag: static-analysis-sonar
os: ubuntu-latest
container: aswf/ci-oiio:2024.2
cxx_std: 17
python_ver: "3.11"
vfxyear: 2022
vfxsuffix: -clang11
cxx_std: 14
python_ver: 3.9
simd: "avx2,f16c"
opencolorio_ver: v2.3.2
fmt_ver: 10.1.1
pybind11_ver: v2.12.0
fmt_ver: 8.1.1
pybind11_ver: v2.9.0
coverage: 1
# skip_tests: 1
sonar: 1
setenvs: export SONAR_SERVER_URL="https://sonarcloud.io"
BUILD_WRAPPER_OUT_DIR=/__w/OpenImageIO/OpenImageIO/bw_output
OIIO_CMAKE_BUILD_WRAPPER="build-wrapper-linux-x86-64 --out-dir /__w/OpenImageIO/OpenImageIO/bw_output"
OIIO_CMAKE_BUILD_TYPE=Debug
setenvs: export SONAR_SCANNER_VERSION=4.7.0.2747
SONAR_SERVER_URL="https://sonarcloud.io"
BUILD_WRAPPER_OUT_DIR=bw_output
OIIO_CMAKE_BUILD_WRAPPER="build-wrapper-linux-x86-64 --out-dir bw_output"
CMAKE_BUILD_TYPE=Debug
CMAKE_UNITY_BUILD=OFF
CODECOV=1
CTEST_TEST_TIMEOUT=1200
OIIO_CMAKE_FLAGS="-DOIIO_TEX_IMPLEMENT_VARYINGREF=OFF"
runs-on: ${{ matrix.os }}
container:
image: aswf/ci-osl:${{matrix.vfxyear}}${{matrix.vfxsuffix}}
env:
CXX: ${{matrix.cxx_compiler}}
CC: ${{matrix.cc_compiler}}
CMAKE_CXX_STANDARD: ${{matrix.cxx_std}}
USE_SIMD: ${{matrix.simd}}
FMT_VERSION: ${{matrix.fmt_ver}}
OPENEXR_VERSION: ${{matrix.openexr_ver}}
PYBIND11_VERSION: ${{matrix.pybind11_ver}}
PYTHON_VERSION: ${{matrix.python_ver}}
# DEBUG_CI: 1
steps:
# We would like to use harden-runner, but it flags too many false
# positives, every time we download a dependency. We should use it only
# on CI runs where we are producing artifacts that users might rely on.
# - name: Harden Runner
# uses: step-security/harden-runner@248ae51c2e8cc9622ecf50685c8bf7150c6e8813 # v1.4.3
# with:
# egress-policy: audit # TODO: change to 'egress-policy: block' after couple of runs
- uses: actions/checkout@2541b1294d2704b0964813337f33b291d3f8596b # v3.0.2
with:
fetch-depth: '0'
- name: Prepare ccache timestamp
id: ccache_cache_keys
run: echo "::set-output name=date::`date -u +'%Y-%m-%dT%H:%M:%SZ'`"
- name: ccache
id: ccache
uses: actions/cache@c3f1317a9e7b1ef106c153ac8c0f00fed3ddbc0d # v3.0.4
with:
path: /tmp/ccache
key: ${{github.job}}-${{matrix.nametag}}-${{steps.ccache_cache_keys.outputs.date}}
restore-keys: ${{github.job}}-
- name: Build setup
run: |
${{matrix.setenvs}}
src/build-scripts/ci-startup.bash
- name: Dependencies
run: |
${{matrix.depcmds}}
src/build-scripts/gh-installdeps.bash
- name: Build
run: src/build-scripts/ci-build.bash
- name: Testsuite
if: matrix.skip_tests != '1'
run: src/build-scripts/ci-test.bash
- name: Code coverage
if: matrix.coverage == '1'
run: src/build-scripts/ci-coverage.bash
- name: Sonar-scanner
if: matrix.sonar == 1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
run: |
sonar-scanner --define sonar.host.url="${{ env.SONAR_SERVER_URL }}" --define sonar.cfamily.build-wrapper-output="build/bw_output" --define sonar.cfamily.gcov.reportsPath="_coverage"
# - uses: actions/upload-artifact@3cea5372237819ed00197afe530f5a7ea3e805c8 # v3.1.0
# if: failure()
# with:
# name: oiio-${{github.job}}-${{matrix.nametag}}
# path: |
# build/cmake-save
# build/testsuite/*/*.*
# !build/testsuite/oiio-images
# !build/testsuite/openexr-images
# !build/testsuite/fits-images
# !build/testsuite/j2kp4files_v1_5
-322
View File
@@ -1,322 +0,0 @@
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
##########################################################################
# Common steps for all CI workflows
##########################################################################
name: CI Steps
on:
workflow_call:
# This inputs receive values via the "with:" section in ci_workflow.yml
inputs:
build:
type: string
runner:
type: string
container:
type: string
container_volumes:
type: string
default: '[]'
cc_compiler:
type: string
cxx_compiler:
type: string
cxx_std:
type: string
build_type:
type: string
depcmds:
type: string
extra_artifacts:
type: string
fmt_ver:
type: string
fmt_commit:
type: string
gcc_action_ver:
type: string
llvm_action_ver:
type: string
opencolorio_ver:
type: string
openexr_ver:
type: string
pybind11_ver:
type: string
python_action_ver:
type: string
python_ver:
type: string
setenvs:
type: string
simd:
type: string
skip_build:
type: string
skip_tests:
type: string
abi_check:
type: string
benchmark:
type: string
build_docs:
type: string
clang_format:
type: string
generator:
type: string
ctest_args:
type: string
ctest_test_timeout:
type: string
coverage:
type: string
sonar:
type: string
# Note: Remove old_node and everything that handles its being nonzero,
# when we branch for 3.2. We no longer have any CI jobs in main that
# need it, but we are not yet removing it, for the sake of not making
# this file diverge from the release branch quite yet, to make
# backporting CI fixes easy.
old_node:
type: string
default: 0
nametag:
type: string
required_deps:
type: string
optional_deps:
type: string
build_local_deps:
type: string
oiio_python_bindings_backend:
type: string
default: ''
secrets:
PASSED_GITHUB_TOKEN:
required: false
PASSED_SONAR_TOKEN:
required: false
permissions: read-all
jobs:
steps:
name: "${{inputs.cxx_compiler}} c++${{inputs.cxx_std}} py${{inputs.python_ver}}"
runs-on: ${{ inputs.runner }}
container:
image: ${{ inputs.container }}
volumes: ${{ fromJson( inputs.container_volumes ) }}
options: -v /:/host/root ${{ (contains(inputs.runner, 'gpu') && '-e NVIDIA_DRIVER_CAPABILITIES=compute,graphics,utility --gpus all') || '-e A=x' }}
# Extra options:
# - Ensure the GPU runners have OptiX is visible in the container.
# - Mount the native filesystem under /host/root
env:
CXX: ${{inputs.cxx_compiler}}
CC: ${{inputs.cc_compiler}}
CMAKE_BUILD_TYPE: ${{inputs.build_type}}
CMAKE_CXX_STANDARD: ${{inputs.cxx_std}}
CMAKE_GENERATOR: ${{inputs.generator}}
CTEST_ARGS: ${{inputs.ctest_args}}
CTEST_TEST_TIMEOUT: ${{inputs.ctest_test_timeout}}
USE_SIMD: ${{inputs.simd}}
fmt_BUILD_VERSION: ${{inputs.fmt_ver}}
fmt_GIT_COMMIT: ${{inputs.fmt_commit}}
OPENCOLORIO_VERSION: ${{inputs.opencolorio_ver}}
OPENEXR_VERSION: ${{inputs.openexr_ver}}
PYBIND11_VERSION: ${{inputs.pybind11_ver}}
PYTHON_VERSION: ${{inputs.python_ver}}
ABI_CHECK: ${{inputs.abi_check}}
ACTIONS_RUNNER_FORCE_ACTIONS_NODE_VERSION: node16
ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION: true
# For CI, sometimes we want to require all dependencies to be present,
# except for a select few listed explicitly. This ensures that we don't
# accidentally have a situation in which we think we are building
# against and testing an optional dependency, but in fact are not.
OpenImageIO_REQUIRED_DEPS: ${{inputs.required_deps}}
OpenImageIO_OPTIONAL_DEPS: ${{inputs.optional_deps}}
OpenImageIO_BUILD_LOCAL_DEPS: ${{inputs.build_local_deps}}
SETENVS: ${{inputs.setenvs}}
DEPCMDS: ${{inputs.depcmds}}
OIIO_PYTHON_BINDINGS_BACKEND: ${{ inputs.oiio_python_bindings_backend }}
steps:
- name: install nodejs20glibc2.17
if: inputs.old_node == '1'
run: |
curl --silent https://unofficial-builds.nodejs.org/download/release/v20.18.1/node-v20.18.1-linux-x64-glibc-217.tar.xz | tar -xJ --strip-components 1 -C /node20217 -f -
- name: Checkout repo
if: inputs.old_node != '1'
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
- name: Checkout repo-OLD
if: inputs.old_node == '1'
# Must use an old checkout action for old containers
uses: actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955 # v4.3.0
- name: Build setup
shell: bash
run: |
eval "$SETENVS"
src/build-scripts/ci-startup.bash
- name: Prepare ccache timestamp
id: ccache_cache_keys
shell: bash
run: echo "date=`date -u +'%Y-%m-%dT%H:%M:%SZ'`" >> $GITHUB_OUTPUT
- name: ccache-restore
if: inputs.old_node != '1'
id: ccache-restore
uses: actions/cache/restore@cdf6c1fa76f9f475f3d7449005a359c84ca0f306 # v5.0.3
with:
path: ${{ env.CCACHE_DIR }}
key: ${{inputs.nametag}}-${{steps.ccache_cache_keys.outputs.date}}
restore-keys: ${{inputs.nametag}}
- name: ccache-restore-OLD
if: inputs.old_node == '1'
id: ccache-restore-old
# Must use an old cache restore action for old containers
uses: actions/cache/restore@0057852bfaa89a56745cba8c7296529d2fc39830 # v4.3.0
with:
path: ${{ env.CCACHE_DIR }}
# path: ./ccache
key: ${{inputs.nametag}}-${{steps.ccache_cache_keys.outputs.date}}
restore-keys: ${{inputs.nametag}}
- name: Install gcc
if: inputs.gcc_action_ver != ''
run: |
sudo add-apt-repository ppa:ubuntu-toolchain-r/test -y
sudo apt-get update -y
sudo apt-get install -y g++-${{inputs.gcc_action_ver}}
- name: Install python
if: inputs.python_action_ver != ''
uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
with:
python-version: ${{ inputs.python_action_ver }}
- name: Install LLVM and Clang
if: inputs.llvm_action_ver != ''
uses: KyleMayes/install-llvm-action@ebc0426251bc40c7cd31162802432c68818ab8f0 # v2.0.9
with:
version: ${{ inputs.llvm_action_ver }}
- name: Dependencies
shell: bash
run: |
eval "$DEPCMDS"
if [[ "$RUNNER_OS" == "Linux" ]]; then
src/build-scripts/gh-installdeps.bash
elif [[ "$RUNNER_OS" == "macOS" ]]; then
src/build-scripts/install_homebrew_deps.bash
elif [[ "$RUNNER_OS" == "Windows" ]]; then
src/build-scripts/gh-win-installdeps.bash
fi
- name: Install sonar-scanner and build-wrapper
if: inputs.sonar == '1'
uses: sonarsource/sonarqube-scan-action@a31c9398be7ace6bbfaf30c0bd5d415f843d45e9 # v7.0.0
- name: Build
if: inputs.skip_build != '1'
shell: bash
run: src/build-scripts/ci-build.bash
- name: Check out ABI standard
if: inputs.abi_check != ''
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
with:
ref: ${{inputs.abi_check}}
path: abi_standard
- name: Build ABI standard
if: inputs.abi_check != ''
shell: bash
run: |
mkdir -p abi_standard/build
pushd abi_standard
src/build-scripts/ci-build.bash
popd
- name: ccache-save
if: inputs.old_node != '1'
id: ccache-save
uses: actions/cache/save@cdf6c1fa76f9f475f3d7449005a359c84ca0f306 # v5.0.3
with:
path: ${{ env.CCACHE_DIR }}
key: ${{inputs.nametag}}-${{steps.ccache_cache_keys.outputs.date}}
- name: ccache-save-OLD
if: inputs.old_node == '1'
id: ccache-save-old
# Must use an old cache action for old containers
uses: actions/cache/save@0057852bfaa89a56745cba8c7296529d2fc39830 # v4.3.0
with:
path: ${{ env.CCACHE_DIR }}
key: ${{inputs.nametag}}-${{steps.ccache_cache_keys.outputs.date}}
- name: Testsuite
if: inputs.skip_tests != '1'
shell: bash
run: src/build-scripts/ci-test.bash
- name: Benchmarks
if: inputs.benchmark == '1'
shell: bash
run: src/build-scripts/ci-benchmark.bash
- name: clang-format
if: inputs.clang_format == '1'
shell: bash
run: src/build-scripts/run-clang-format.bash
- name: Code coverage
if: inputs.coverage == '1'
run: src/build-scripts/ci-coverage.bash
- name: Sonar-scanner
if: inputs.sonar == '1'
env:
GITHUB_TOKEN: ${{ secrets.PASSED_GITHUB_TOKEN }}
SONAR_TOKEN: ${{ secrets.PASSED_SONAR_TOKEN }}
run: |
which sonar-scanner
ls -l /__w/OpenImageIO/OpenImageIO/bw_output
echo "BUILD_OUTPUT_DIR is ${BUILD_WRAPPER_OUT_DIR}"
find . -name "*.gcov" -print
# sonar-scanner --define sonar.cfamily.compile-commands="${BUILD_WRAPPER_OUT_DIR}/compile_commands.json"
time sonar-scanner --define sonar.host.url="${SONAR_SERVER_URL}" --define sonar.cfamily.compile-commands="$BUILD_WRAPPER_OUT_DIR/compile_commands.json" --define sonar.cfamily.gcov.reportsPath="_coverage" --define sonar.cfamily.threads="$PARALLEL"
# Consult https://docs.sonarcloud.io/advanced-setup/ci-based-analysis/sonarscanner-cli/ for more information and options
- name: Check ABI
if: inputs.abi_check != ''
shell: bash
run: |
src/build-scripts/ci-abicheck.bash ./build abi_standard/build libOpenImageIO libOpenImageIO_Util
- name: Build Docs
if: inputs.build_docs == '1'
shell: bash
run: |
cd src/doc
time make doxygen
time make sphinx
- name: Upload testsuite debugging artifacts
uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
if: ${{ inputs.old_node != '1' && (failure() || inputs.build_docs == '1' || inputs.benchmark == '1' || inputs.abi_check != '') }}
with:
name: oiio-${{github.job}}-${{inputs.nametag}}
path: |
build/cmake-save
build/compat_reports
build/sphinx
build/benchmarks
build/testsuite/*/*.*
!build/testsuite/oiio-images
!build/testsuite/openexr-images
!build/testsuite/fits-images
!build/testsuite/j2kp4files_v1_5
${{ inputs.extra_artifacts }}
- name: Upload testsuite debugging artifacts-OLD
uses: actions/upload-artifact@6f51ac03b9356f520e9adb1b1b7802705f340c2b # v4.5.0
if: ${{ inputs.old_node == '1' && (failure() || inputs.build_docs == '1' || inputs.benchmark == '1' || inputs.abi_check != '') }}
with:
name: oiio-${{github.job}}-${{inputs.nametag}}
path: |
build/cmake-save
build/compat_reports
build/sphinx
build/benchmarks
build/testsuite/*/*.*
!build/testsuite/oiio-images
!build/testsuite/openexr-images
!build/testsuite/fits-images
!build/testsuite/j2kp4files_v1_5
${{ inputs.extra_artifacts }}
+449 -634
View File
File diff suppressed because it is too large Load Diff
-92
View File
@@ -1,92 +0,0 @@
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
name: docs
on:
push:
# Skip jobs when only cpp files are changed. The materials for
# docs are all in md, rst, and .h files.
paths-ignore:
- '**/ci.yml'
- '**/analysis.yml'
- '**/scorecard.yml'
- '**/wheel.yml'
- '**.properties'
- 'src/**.cpp'
- '**.cmake'
- '**/CMakeLists.txt'
- '**/run.py'
- 'src/build-scripts/**'
- './*.md'
- 'pyproject.toml'
pull_request:
paths-ignore:
- '**/ci.yml'
- '**/analysis.yml'
- '**/scorecard.yml'
- '**/wheel.yml'
- '**.properties'
- 'src/**.cpp'
- '**.cmake'
- '**/CMakeLists.txt'
- '**/run.py'
- 'src/build-scripts/**'
- './*.md'
- 'pyproject.toml'
schedule:
# Full nightly build
- cron: "0 8 * * *"
workflow_dispatch:
# This allows manual triggering of the workflow from the web
permissions: read-all
# Allow subsequent pushes to the same PR or REF to cancel any previous jobs.
concurrency:
group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
cancel-in-progress: true
jobs:
docs:
name: "Docs / ${{matrix.desc}}"
if: ${{ github.event_name != 'schedule' || github.event.repository.fork == false }}
uses: ./.github/workflows/build-steps.yml
with:
nametag: ${{ matrix.nametag || 'unnamed!' }}
runner: ${{ matrix.runner || 'ubuntu-latest' }}
container: ${{ matrix.container }}
cc_compiler: ${{ matrix.cc_compiler }}
cxx_compiler: ${{ matrix.cxx_compiler }}
cxx_std: ${{ matrix.cxx_std || '17' }}
build_type: ${{ matrix.build_type || 'Release' }}
depcmds: ${{ matrix.depcmds }}
extra_artifacts: ${{ matrix.extra_artifacts }}
python_ver: ${{ matrix.python_ver }}
setenvs: ${{ matrix.setenvs }}
simd: ${{ matrix.simd }}
skip_build: ${{ matrix.skip_build }}
skip_tests: ${{ matrix.skip_tests }}
abi_check: ${{ matrix.abi_check }}
build_docs: ${{ matrix.build_docs }}
generator: ${{ matrix.generator }}
strategy:
fail-fast: false
matrix:
include:
- desc: docs
nametag: docslinux
runner: ubuntu-latest
cxx_std: 17
python_ver: "3.11"
build_docs: 1
skip_build: 1
skip_tests: 1
setenvs: export EXTRA_DEP_PACKAGES="doxygen sphinx-doc"
PIP_INSTALLS="sphinx breathe==4.34.0 sphinx-tabs furo==2022.6.21"
SKIP_SYSTEM_DEPS_INSTALL=1
USE_OPENCV=0 USE_FFMPEG=0 USE_FREETYPE=0
USE_LIBHEIF=0 QT_VERSION=0 PYBIND11_VERSION=0
-26
View File
@@ -1,26 +0,0 @@
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
name: Publish Release Notice to ASWF Slack
on:
release:
types:
- published
# published should cover both 'released' and 'prereleased'
jobs:
publish:
runs-on: ubuntu-latest
timeout-minutes: 5
steps:
- name: Notify Slack
id: slack
with:
project_name: "OpenImageIO"
slack_bot_token: ${{ secrets.SLACK_BOT_TOKEN }}
slack_channel: "#release-announcements"
project_logo: "https://artwork.aswf.io/projects/openimageio/icon/color/openimageio-icon-color.png"
uses: jmertic/slack-release-notifier@35fad060af5559c24decdec0f701e6ba93566704 # circa Mar 2026
-67
View File
@@ -1,67 +0,0 @@
# SPDX-License-Identifier: Apache-2.0
# Copyright (c) Contributors to the OpenImageIO Project.
#
# Releases are signed via https://github.com/sigstore/sigstore-python.
# See https://docs.sigstore.dev for information about sigstore.
#
# This action creates a .tar.gz of the complete OpenImageIO source tree at
# the given release tag, signs it via sigstore, and uploads the
# .tar.gz and the associated .tar.gz.sigstore credential bundle.
#
# To verify a downloaded release at a given tag:
#
# % pip install sigstore
# % sigstore verify github --cert-identity https://github.com/AcademySoftwareFoundation/OpenImageIO/.github/workflows/release-sign.yml@refs/tags/<tag> OpenImageIO-<tag>.tar.gz
#
name: Sign Release
on:
release:
types: [published]
permissions:
contents: read
jobs:
release:
name: Sign & upload release artifacts
runs-on: ubuntu-latest
env:
TAG: ${{ github.ref_name }}
permissions:
contents: write
id-token: write
repository-projects: write
steps:
- name: Set Prefix
# The tag name begins with a 'v', e.g. "v3.0.3", but the prefix
# should omit the 'v', so the tarball "OpenImageIO-3.0.3.tar.gz"
# extracts files into "OpenImageIO-v3.0.3/...". This matches
# the GitHub release page autogenerated artifact conventions.
run: |
echo OPENIMAGEIO_PREFIX=OpenImageIO-${TAG//v}/ >> $GITHUB_ENV
echo OPENIMAGEIO_TARBALL=OpenImageIO-${TAG//v}.tar.gz >> $GITHUB_ENV
shell: bash
- name: Checkout repo
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
- name: Create archive
run: git archive --format=tar.gz -o ${OPENIMAGEIO_TARBALL} --prefix ${OPENIMAGEIO_PREFIX} ${TAG}
- name: Sign archive with Sigstore
uses: sigstore/gh-action-sigstore-python@a5caf349bc536fbef3668a10ed7f5cd309a4b53d # v3.2.0
with:
inputs: ${{ env.OPENIMAGEIO_TARBALL }}
upload-signing-artifacts: false
release-signing-artifacts: false
- name: Upload release archive
env:
GH_TOKEN: ${{ github.token }}
run: gh release upload ${TAG} ${OPENIMAGEIO_TARBALL} ${OPENIMAGEIO_TARBALL}.sigstore.json
@@ -1,19 +1,15 @@
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
name: Scorecards supply-chain security
on:
# Only the default branch is supported.
branch_protection_rule:
push:
# Run on pushes to main, but only the official repo, not forks
branches: [ "main" ]
# Run on pushes to master, but only the main repo, not forks
branches: [ "master" ]
if: github.event.pull_request.head.repo.full_name == github.repository
pull_request:
# Only run on individual PRs if the workflows changed
# Only run on individual PRs if the workflow file itself is changed.
paths:
- '.github/workflows/**'
- .github/workflows/scorecard.yml
# Declare default permissions as read only.
permissions: read-all
@@ -27,7 +23,7 @@ concurrency:
jobs:
analysis:
name: Scorecards analysis
if: github.event.repository.fork == false
if: github.repository == 'OpenImageIO/oiio'
runs-on: ubuntu-latest
permissions:
# Needed to upload the results to code-scanning dashboard.
@@ -39,13 +35,13 @@ jobs:
actions: read
steps:
- name: Checkout repo
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
- name: "Checkout code"
uses: actions/checkout@a12a3943b4bdde767164f792f33f40b04645d846 # v3.0.0
with:
persist-credentials: false
- name: "Run analysis"
uses: ossf/scorecard-action@4eaacf0543bb3f2c246792bd56e8cdeffafb205a # v2.4.3
uses: ossf/scorecard-action@3e15ea8318eee9b333819ec77a36aca8d39df13e # v1.1.1
with:
results_file: results.sarif
results_format: sarif
@@ -64,7 +60,7 @@ jobs:
# Upload the results as artifacts (optional). Commenting out will disable uploads of run results in SARIF
# format to the repository Actions tab.
- name: "Upload artifact"
uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
uses: actions/upload-artifact@6673cd052c4cd6fcf4b4e6e60ea986c889389535 # v3.0.0
with:
name: SARIF file
path: results.sarif
@@ -72,6 +68,6 @@ jobs:
# Upload the results to GitHub's code scanning dashboard.
- name: "Upload to code-scanning"
uses: github/codeql-action/upload-sarif@820e3160e279568db735cee8ed8f8e77a6da7818 # v3.32.6
uses: github/codeql-action/upload-sarif@5f532563584d71fdef14ee64d17bafb34f751ce5 # v1.0.26
with:
sarif_file: results.sarif
-535
View File
@@ -1,535 +0,0 @@
# SPDX-License-Identifier: Apache-2.0
# Copyright Contributors to the OpenImageIO Project.
#
# This workflow will run on under two independent conditions:
# 1) On the official AcademySoftwareFoundation repo, according to a nightly schedule.
# 2) On forks, when submitting a PR that modifies Python-related files.
name: Wheel
permissions:
contents: read
id-token: write
on:
push:
# Workflow run on tags for v3 only, or pre-tagged pushes of release, or
# dev-3.* branches. Also if the branch name itself contains the substrings
# 'wheel' or 'python'.
tags:
- v3.*
branches:
- release
- dev-3.*
- "*wheel*"
- "*python*"
pull_request:
# Workflow run on pull_request only when related files change, or when the
# branch name itself contains the substrings 'wheel' or 'python'.
paths:
- .github/workflows/wheel.yml
- pyproject.toml
- src/python/*.py
- src/python/*.h
- src/python/*.cpp
- src/cmake/*.cmake
schedule:
# Nightly build
- cron: "0 8 * * *"
workflow_dispatch:
# This allows manual triggering of the workflow from the web
# Allow subsequent pushes to the same PR or REF to cancel any previous jobs.
concurrency:
group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
cancel-in-progress: true
jobs:
# Linux jobs run in Docker containers (manylinux), so the latest OS version
# is OK. macOS and Windows jobs need to be locked to specific virtual
# environment versions to mitigate issues from OS updates, and will require
# maintenance as OS versions are retired.
# ---------------------------------------------------------------------------
# Source Distribution
# ---------------------------------------------------------------------------
sdist:
name: Build SDist
runs-on: ubuntu-latest
if: |
github.event_name != 'schedule' || github.event.repository.fork == false
steps:
- name: Checkout repo
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
- name: Build SDist
run: pipx run build --sdist
- name: Check metadata
run: pipx run twine check dist/*
- uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
with:
name: cibw-sdist
path: dist/*.tar.gz
# ---------------------------------------------------------------------------
# Linux Wheels
# ---------------------------------------------------------------------------
linux:
name: Build wheels on Linux
runs-on: ubuntu-latest
if: |
${{ github.event_name != 'schedule' || github.event.repository.fork == false }}
strategy:
fail-fast: false
matrix:
include:
# -------------------------------------------------------------------
# CPython 64 bits manylinux_2_28
# -------------------------------------------------------------------
- build: CPython 3.9 64 bits manylinux_2_28
manylinux: manylinux_2_28
python: cp39-manylinux_x86_64
arch: x86_64
- build: CPython 3.10 64 bits manylinux_2_28
manylinux: manylinux_2_28
python: cp310-manylinux_x86_64
arch: x86_64
- build: CPython 3.11 64 bits manylinux_2_28
manylinux: manylinux_2_28
python: cp311-manylinux_x86_64
arch: x86_64
- build: CPython 3.12 64 bits manylinux_2_28
manylinux: manylinux_2_28
python: cp312-manylinux_x86_64
arch: x86_64
- build: CPython 3.13 64 bits manylinux_2_28
manylinux: manylinux_2_28
python: cp313-manylinux_x86_64
arch: x86_64
- build: CPython 3.14 64 bits manylinux_2_28
manylinux: manylinux_2_28
python: cp314-manylinux_x86_64
arch: x86_64
steps:
- name: Checkout repo
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
- name: Install Python
uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
with:
python-version: '3.9'
- name: ccache-restore
id: ccache-restore
uses: actions/cache/restore@cdf6c1fa76f9f475f3d7449005a359c84ca0f306 # v5.0.3
with:
path: ~/.ccache
key: wheel-${{runner.os}}-${{matrix.manylinux}}-${{matrix.python}}
restore-keys: wheel-${{runner.os}}-${{matrix.manylinux}}-${{matrix.python}}
- name: Build wheels
# Note: the version of cibuildwheel should be kept in sync with src/python/stubs/CMakeLists.txt
uses: pypa/cibuildwheel@ee02a1537ce3071a004a6b08c41e72f0fdc42d9a # v3.4.0
env:
# pass GITHUB_ACTIONS through to the build container so that custom
# processes can tell they are running in CI.
CIBW_ENVIRONMENT_PASS_LINUX: GITHUB_ACTIONS
CIBW_BEFORE_ALL: "source src/build-scripts/build_ccache.bash && pwd && ext/dist/bin/ccache --max-size=200M && ext/dist/bin/ccache -sv && export CMAKE_C_COMPILER_LAUNCHER=/project/ext/dist/bin/ccache CMAKE_CXX_COMPILER_LAUNCHER=/project/ext/dist/bin/ccache"
CIBW_BEFORE_TEST: "ext/dist/bin/ccache -s"
CIBW_BUILD: ${{ matrix.python }}
CIBW_ARCHS: ${{ matrix.arch }}
CIBW_MANYLINUX_X86_64_IMAGE: ${{ matrix.manylinux }}
CIBW_ENVIRONMENT: >
CCACHE_DIR=/host//home/runner/.ccache
CCACHE_COMPRESSION=yes
CCACHE_PREBUILT=1
CMAKE_BUILD_PARALLEL_LEVEL=4
CTEST_PARALLEL_LEVEL=4
SKBUILD_CMAKE_ARGS="-DLINKSTATIC=1"
SKBUILD_CMAKE_BUILD_TYPE="MinSizeRel"
SKBUILD_BUILD_DIR=/project/build
CXXFLAGS="-Wno-error=stringop-overflow -Wno-pragmas"
WebP_BUILD_VERSION="1.5.0"
WebP_GIT_COMMIT=a4d7a715337ded4451fec90ff8ce79728e04126c
# FIXME: Getting build problems when using WebP 1.6.0, so hold it back
# CMAKE_GENERATOR = "Ninja"
- name: ccache-save
id: ccache-save
uses: actions/cache/save@cdf6c1fa76f9f475f3d7449005a359c84ca0f306 # v5.0.3
with:
path: ~/.ccache
key: wheel-${{runner.os}}-${{matrix.manylinux}}-${{matrix.python}}
- uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
with:
name: cibw-wheels-${{matrix.manylinux}}-${{ matrix.python }}-${{ matrix.manylinux }}
path: |
./wheelhouse/*.whl
- uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
with:
name: stubs-${{ matrix.python }}-${{ matrix.manylinux }}
path: |
./wheelhouse/OpenImageIO/__init__.pyi
# if stub validation fails we want to upload the stubs for users to review.
# keep the python build in sync with the version specified in tool.cibuildwheel.overrides
# section of pyproject.toml
if: always() && contains(matrix.python, 'cp311-manylinux')
# ---------------------------------------------------------------------------
# Linux ARM Wheels
# ---------------------------------------------------------------------------
linux-arm:
name: Build wheels on Linux ARM
runs-on: ubuntu-24.04-arm
if: |
github.event_name != 'schedule' || github.event.repository.fork == false
strategy:
matrix:
include:
# -------------------------------------------------------------------
# CPython ARM 64 bits manylinux2014
# -------------------------------------------------------------------
- build: CPython 3.9 ARM 64 bits manylinux_2_28
manylinux: manylinux_2_28
python: cp39-manylinux_aarch64
arch: aarch64
- build: CPython 3.10 ARM 64 bits manylinux_2_28
manylinux: manylinux_2_28
python: cp310-manylinux_aarch64
arch: aarch64
- build: CPython 3.11 ARM 64 bits manylinux_2_28
manylinux: manylinux_2_28
python: cp311-manylinux_aarch64
arch: aarch64
- build: CPython 3.12 ARM 64 bits manylinux_2_28
manylinux: manylinux_2_28
python: cp312-manylinux_aarch64
arch: aarch64
- build: CPython 3.13 ARM 64 bits manylinux_2_28
manylinux: manylinux_2_28
python: cp313-manylinux_aarch64
arch: aarch64
- build: CPython 3.14 ARM 64 bits manylinux_2_28
manylinux: manylinux_2_28
python: cp314-manylinux_aarch64
arch: aarch64
steps:
- name: Checkout repo
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
- name: Install Python
uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
with:
python-version: '3.9'
- name: ccache-restore
id: ccache-restore
uses: actions/cache/restore@cdf6c1fa76f9f475f3d7449005a359c84ca0f306 # v5.0.3
with:
path: ~/.ccache
key: wheel-${{runner.os}}-${{matrix.python}}
restore-keys: wheel-${{runner.os}}-${{matrix.python}}
- name: Build wheels
uses: pypa/cibuildwheel@ee02a1537ce3071a004a6b08c41e72f0fdc42d9a # v3.4.0
env:
CIBW_ENVIRONMENT_PASS_LINUX: GITHUB_ACTIONS
CIBW_BEFORE_ALL: "source src/build-scripts/build_ccache.bash && pwd && /project/ext/dist/bin/ccache --max-size=200M && /project/ext/dist/bin/ccache -sv && export CMAKE_C_COMPILER_LAUNCHER=/project/ext/dist/bin/ccache CMAKE_CXX_COMPILER_LAUNCHER=/project/ext/dist/bin/ccache"
CIBW_BEFORE_TEST: "ext/dist/bin/ccache -s"
CIBW_BUILD: ${{ matrix.python }}
CIBW_ARCHS: ${{ matrix.arch }}
CIBW_MANYLINUX_AARCH64_IMAGE: ${{ matrix.manylinux }}
CIBW_ENVIRONMENT: >
CCACHE_DIR=/host//home/runner/.ccache
CCACHE_COMPRESSION=yes
CCACHE_PREBUILT=0
CMAKE_BUILD_PARALLEL_LEVEL=6
CTEST_PARALLEL_LEVEL=6
SKBUILD_CMAKE_ARGS="-DLINKSTATIC=1"
SKBUILD_CMAKE_BUILD_TYPE="MinSizeRel"
SKBUILD_BUILD_DIR=/project/build
CXXFLAGS="-Wno-error=stringop-overflow -Wno-pragmas"
WebP_BUILD_VERSION="1.5.0"
WebP_GIT_COMMIT=a4d7a715337ded4451fec90ff8ce79728e04126c
- name: ccache-save
id: ccache-save
uses: actions/cache/save@cdf6c1fa76f9f475f3d7449005a359c84ca0f306 # v5.0.3
with:
path: ~/.ccache
key: wheel-${{runner.os}}-${{matrix.python}}
- uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
with:
name: cibw-wheels-${{ matrix.python }}-${{ matrix.manylinux }}
path: |
./wheelhouse/*.whl
- uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
with:
name: stubs-${{ matrix.python }}-${{ matrix.manylinux }}
path: |
./wheelhouse/OpenImageIO/__init__.pyi
# if stub validation fails we want to upload the stubs for users to review.
# keep the python build in sync with the version specified in tool.cibuildwheel.overrides
# section of pyproject.toml
if: always() && contains(matrix.python, 'cp311-manylinux')
# ---------------------------------------------------------------------------
# macOS Wheels
# ---------------------------------------------------------------------------
macos:
name: Build wheels on macOS
runs-on: macos-15-intel
if: |
github.event_name != 'schedule' || github.event.repository.fork == false
strategy:
fail-fast: false
matrix:
include:
# -------------------------------------------------------------------
# CPython 64 bits
# -------------------------------------------------------------------
- build: CPython 3.9 64 bits
python: cp39-macosx_x86_64
arch: x86_64
- build: CPython 3.10 64 bits
python: cp310-macosx_x86_64
arch: x86_64
- build: CPython 3.11 64 bits
python: cp311-macosx_x86_64
arch: x86_64
- build: CPython 3.12 64 bits
python: cp312-macosx_x86_64
arch: x86_64
- build: CPython 3.13 64 bits
python: cp313-macosx_x86_64
arch: x86_64
- build: CPython 3.14 64 bits
python: cp314-macosx_x86_64
arch: x86_64
steps:
- name: Checkout repo
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
- name: Install Python
uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
with:
python-version: '3.9'
- name: ccache-restore
id: ccache-restore
uses: actions/cache/restore@cdf6c1fa76f9f475f3d7449005a359c84ca0f306 # v5.0.3
with:
path: ~/.ccache
key: wheel-${{runner.os}}-${{matrix.python}}
restore-keys: wheel-${{runner.os}}-${{matrix.python}}
- name: Install build tools
run: |
brew install ninja ccache || true
- name: Brew uninstall problematic dependencies
run: |
brew uninstall -f --ignore-dependencies openexr imath expat cmake || true
- name: Build wheels
uses: pypa/cibuildwheel@ee02a1537ce3071a004a6b08c41e72f0fdc42d9a # v3.4.0
env:
CIBW_BUILD: ${{ matrix.python }}
CIBW_ARCHS: ${{ matrix.arch }}
MACOSX_DEPLOYMENT_TARGET: 10.15
CMAKE_GENERATOR: "Unix Makefiles"
# TODO: Re-enable HEIF when we provide a build recipe that does
# not include GPL-licensed dynamic libraries.
USE_Libheif: 'OFF'
CMAKE_BUILD_PARALLEL_LEVEL: 6
CTEST_PARALLEL_LEVEL: 6
SKBUILD_BUILD_DIR: "/Users/runner/work/OpenImageIO/OpenImageIO/build"
CCACHE_DIR: /Users/runner/.ccache
CCACHE_COMPRESSION: yes
- name: ccache-save
id: ccache-save
uses: actions/cache/save@cdf6c1fa76f9f475f3d7449005a359c84ca0f306 # v5.0.3
with:
path: ~/.ccache
key: wheel-${{runner.os}}-${{matrix.python}}
- uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
with:
name: cibw-wheels-${{ matrix.python }}
path: ./wheelhouse/*.whl
# ---------------------------------------------------------------------------
# macOS ARM Wheels
# ---------------------------------------------------------------------------
macos-arm:
name: Build wheels on macOS ARM
runs-on: macos-14
if: |
github.event_name != 'schedule' || github.event.repository.fork == false
strategy:
fail-fast: false
matrix:
include:
# -------------------------------------------------------------------
# CPython ARM 64 bits
# -------------------------------------------------------------------
- build: CPython 3.9 ARM 64 bits
python: cp39-macosx_arm64
arch: arm64
- build: CPython 3.10 ARM 64 bits
python: cp310-macosx_arm64
arch: arm64
- build: CPython 3.11 ARM 64 bits
python: cp311-macosx_arm64
arch: arm64
- build: CPython 3.12 ARM 64 bits
python: cp312-macosx_arm64
arch: arm64
- build: CPython 3.13 ARM 64 bits
python: cp313-macosx_arm64
arch: arm64
- build: CPython 3.14 ARM 64 bits
python: cp314-macosx_arm64
arch: arm64
steps:
- name: Checkout repo
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
- name: Install Python
uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
with:
python-version: '3.9'
- name: ccache-restore
id: ccache-restore
uses: actions/cache/restore@cdf6c1fa76f9f475f3d7449005a359c84ca0f306 # v5.0.3
with:
path: ~/.ccache
key: wheel-${{runner.os}}-${{matrix.python}}
restore-keys: wheel-${{runner.os}}-${{matrix.python}}
- name: Install build tools
run: |
brew install ninja ccache || true
- name: Build wheels
uses: pypa/cibuildwheel@ee02a1537ce3071a004a6b08c41e72f0fdc42d9a # v3.4.0
env:
CIBW_BUILD: ${{ matrix.python }}
CIBW_ARCHS: ${{ matrix.arch }}
CMAKE_GENERATOR: "Unix Makefiles"
CMAKE_BUILD_PARALLEL_LEVEL: 6
CTEST_PARALLEL_LEVEL: 6
SKBUILD_BUILD_DIR: "/Users/runner/work/OpenImageIO/OpenImageIO/build"
CCACHE_DIR: /Users/runner/.ccache
CCACHE_COMPRESSION: yes
- name: ccache-save
id: ccache-save
uses: actions/cache/save@cdf6c1fa76f9f475f3d7449005a359c84ca0f306 # v5.0.3
with:
path: ~/.ccache
key: wheel-${{runner.os}}-${{matrix.python}}
- uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
with:
name: cibw-wheels-${{ matrix.python }}
path: ./wheelhouse/*.whl
# ---------------------------------------------------------------------------
# Windows Wheels
# ---------------------------------------------------------------------------
windows:
name: Build wheels on Windows
runs-on: windows-2022
if: |
github.event_name != 'schedule' || github.event.repository.fork == false
strategy:
fail-fast: false
matrix:
include:
# -------------------------------------------------------------------
# CPython 64 bits
# -------------------------------------------------------------------
- build: CPython 3.9 64 bits
python: cp39-win_amd64
arch: AMD64
- build: CPython 3.10 64 bits
python: cp310-win_amd64
arch: AMD64
- build: CPython 3.11 64 bits
python: cp311-win_amd64
arch: AMD64
- build: CPython 3.12 64 bits
python: cp312-win_amd64
arch: AMD64
- build: CPython 3.13 64 bits
python: cp313-win_amd64
arch: AMD64
- build: CPython 3.14 64 bits
python: cp314-win_amd64
arch: AMD64
steps:
- name: Checkout repo
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
- name: Install Python
uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
with:
python-version: '3.9'
- name: Build wheels
uses: pypa/cibuildwheel@ee02a1537ce3071a004a6b08c41e72f0fdc42d9a # v3.4.0
env:
CIBW_BUILD: ${{ matrix.python }}
CIBW_ARCHS: ${{ matrix.arch }}
CMAKE_POLICY_VERSION_MINIMUM: 3.5
CMAKE_BUILD_PARALLEL_LEVEL: 4
CTEST_PARALLEL_LEVEL: 4
SKBUILD_BUILD_DIR: "$HOME/OpenImageIO/OpenImageIO/build"
CCACHE_DIR: ~/.ccache
CCACHE_COMPRESSION: yes
- uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
with:
name: cibw-wheels-${{ matrix.python }}
path: ./wheelhouse/*.whl
upload_pypi:
needs: [sdist, linux, linux-arm, macos, macos-arm, windows]
runs-on: ubuntu-latest
permissions:
id-token: write
if: github.event_name == 'push' && (startsWith(github.event.ref, 'refs/tags/v3.0.') || startsWith(github.event.ref, 'refs/tags/v3.1.')) && github.event.repository.fork == false
steps:
- uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
- uses: actions/download-artifact@70fc10c6e5e1ce46ad2ea6f2b72d43f7d47b13c3 # v8.0.0
with:
pattern: cibw-*
path: dist
merge-multiple: true
- uses: pypa/gh-action-pypi-publish@ed0c53931b1dc9bd32cbe73a98c7f6766f8a527e # v1.13.0
+1 -18
View File
@@ -4,19 +4,13 @@ branches/
build/
dist/
ext/
wheelhouse/
_coverage/
.python-version
.idea
.vs
.vscode
.cache
.cproject
.project
.DS_Store
*.pyc
/*.lock
gastest.o
_coverage/
# Exclude test files I tend to leave around at the top level. The leading
# slash ensures that files with these extensions within subdirectories are not
@@ -24,16 +18,5 @@ gastest.o
/*.exr
/*.tif
/*.jpg
/*.png
/*.jxl
/*.tx
/*.log
# AI coding tool directories — generated locally by .agents/setup-agent
.claude/
.codex/
.cursor/
.opencode/
.github/copilot-instructions.md
-70
View File
@@ -1,71 +1 @@
# This file establishes email equivalences so we can resolve what look like
# multiple authors, but actually are the same author who has used multiple
# emails over the course of their involvement with the project.
#
# The format is any of the following:
# <CANONICAL-EMAIL> <alternate-email>
# CANONICAL-NAME <CANONICAL-EMAIL> <alternate-email>
# CANONICAL-NAME <CANONICAL-EMAIL> alternate-name <alternate-email>
#
# You can check for duplicates with this command:
# git shortlog -sne --all
# That command (and others) will use this file to collapse the duplicates.
#
# If you see any duplicates we don't account for here, or if you look at your
# own entry here and want a different name or email to be your canonical one
# (we may not have guessed correctly and matched your preferences), please
# file a PR with the edits to this file.
Alejandro Conty <aconty@imageworks.com> aconty <aconty@gmail.com>
Alejandro Conty <aconty@imageworks.com> Alejandro Conty <aconty@gmail.com>
Anton Dukhovnikov <antond@wetafx.co.nz> Anton Dukhovnikov <131838425+antond-weta@users.noreply.github.com>
Brecht Van Lommel <brecht@blender.org> <brecht@solidangle.com>
Brecht Van Lommel <brecht@blender.org> Brecht Van Lommel <brechtvanlommel@gmail.com>
Brecht Van Lommel <brecht@blender.org> brechtvanlommel@gmail.com <brechtvanlommel@gmail.com>
Chris Kulla <ckulla@gmail.com> <ckulla@imageworks.com>
Chris Kulla <ckulla@gmail.com> <fpsunflower@users.noreply.github.com>
Chris Kulla <ckulla@gmail.com> Christopher Kulla <ckulla@gmail.com>
Chris Kulla <ckulla@gmail.com> fpsunflower <ckulla@gmail.com>
Claire Foster <aka.c42f@gmail.com> <chris42f@gmail.com>
Clément Champetier <cl.champetier@gmail.com> Clement Champetier <cnt@mikrosimage.eu>
Clifford Stein <cstein@imageworks.com> Cliff Stein <clifford.stein@gmail.com>
Clifford Stein <cstein@imageworks.com> cmstein <cstein@imageworks.com>
Dan Wexler <danwexler@gmail.com> Dan Wexler <wex@flarg.com>
Dan Wexler <danwexler@gmail.com> Dan Wexler <wex@the11ers.com>
Edgar Velazquez-Armendariz <eva5@cs.cornell.edu> Edgar Velázquez-Armendáriz <edgarv@users.noreply.github.com>
Fabien Castan <fabcastan@gmail.com> Fabien Castan <fabien.castan@free.fr>
Fabien Servant <55734626+servantf@users.noreply.github.com> Fabien Servant @ TCS <100348063+servantftechnicolor@users.noreply.github.com>
Frédéric Devernay <frederic.devernay@m4x.org> Frédéric Devernay <devernay@users.noreply.github.com>
Harry Mallon <harry.mallon@codex.online> Harry Mallon <1816667+hjmallon@users.noreply.github.com>
Henri Fousse <henri.fousse@free.fr> darkhorse64 <henri.fousse@free.fr>
Jesse Yurkovich <jesse.y@gmail.com> Jesse Y <jesse.y@gmail.com>
Larry Gritz <lg@larrygritz.com> <larrygritz@gmail.com>
Larry Gritz <lg@larrygritz.com> lgritz <lg@larrygritz.com>
Leszek Godlewski <ineqvation@gmail.com> Leszek Godlewski <lg@inequation.org>
lmarz <main@lmarz.org> lmarz <37630820+lmarz@users.noreply.github.com>
Mark Boorer <markboo99@gmail.com> Mark Boorer <mkj@dneg.com>
Mark Boorer <markboo99@gmail.com> Shootfast <markboo99@gmail.com>
Mark Visser <mjmvisser@gmail.com> Mark Visser <mvisser@mokkostudio.com>
Matteo F. Vescovi <mfvescovi@gmail.com> Matteo F. Vescovi <mfv.debian@gmail.com>
Matteo F. Vescovi <mfvescovi@gmail.com> Matteo F. Vescovi <mfvescovi@users.noreply.github.com>
Mikael Sundell <mikael.sundell@gmail.com> Mikael Sundell <mikaelsundell@Mikaels-MacBook-Pro.local>
Nathan Rusch <nathanrusch@gmail.com> Nathan Rusch <nrusch@users.noreply.github.com>
Nick Black <dank@qemfd.net> nick black <dankamongmen@gmail.com>
Nick Black <dank@qemfd.net> Nick Black <dankamongmen@gmail.com>
Pascal Lecocq <plecocq@imageworks.com> Pascal Lecocq <pascal.lecocq@gmail.com>
Ramon Montoya <ramon.montoya@gmail.com> Ramon Montoya Vozmediano <ramon.montoya@gmail.com>
Ramon Montoya <ramon.montoya@gmail.com> rmv <ramon.montoya@gmail.com>
Ray Molenkamp <ray@lazydodo.com> Ray Molenkamp <github@lazydodo.com>
Richard M. Shaw <hobbes1069@gmail.com> Richard <hobbes1069@gmail.com>
Richard M. Shaw <hobbes1069@gmail.com> Richard Shaw <hobbes1069@gmail.com>
Robert Matusewicz <matekm@gmail.com> matekm <matekm@gmail.com>
Robert Matusewicz <matekm@gmail.com> Robert <matekm@gmail.com>
Roman Zulak <marsupial@users.noreply.github.com> marsupial <marsupial@users.noreply.github.com>
Sam Richards <sam_junk@taurich.org> Sam Richards <sam@imageworks.com>
Shane Ambler <FreeBSD@ShaneWare.Biz> sambler <Develop@Shaneware.Biz>
Shane Ambler <FreeBSD@ShaneWare.Biz> SAmbler <Develop@Shaneware.Biz>
Simon Boorer <simonboo99@gmail.com> Simon Boorer <sboorer@localhost.localdomain>
Thiago Ize <thiago@solidangle.com> Thiago Ize <ThiagoIze@users.noreply.github.com>
Vlad (Kuzmin) Erium <shaamaan@gmail.com> Vlad (Kuzmin) Erium <libalias@gmail.com>
Will Rosecrans <wrosecrans@gmail.com> Will <wrosecrans@gmail.com>
Yang Yang <yang.yang@topazlabs.com> YangYangTL <yang.yang@topazlabs.com>
+1 -11
View File
@@ -2,20 +2,9 @@
# Read the Docs configuration file
# See https://docs.readthedocs.io/en/stable/config-file/v2.html for details
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# Required
version: 2
# Set the OS, Python version and other tools you might need
build:
os: ubuntu-22.04
tools:
python: "3.12"
# Build documentation in the docs/ directory with Sphinx
sphinx:
configuration: src/doc/conf.py
@@ -27,5 +16,6 @@ formats:
# Optionally set the version of Python and requirements required to build your docs
python:
version: 3.7
install:
- requirements: src/doc/requirements.txt
-182
View File
@@ -1,182 +0,0 @@
# OpenImageIO Agent Guide
This file provides guidance to coding assistants when working with code in
this repository.
## Project Overview
OpenImageIO (OIIO) is a C++17 library and toolset for reading, writing, and
manipulating image files across many formats, designed for VFX/animation/film
production. Part of the Academy Software Foundation (ASWF). Canonical repo:
http://github.com/AcademySoftwareFoundation/OpenImageIO
**Core libraries:**
- `libOpenImageIO` — Main library: ImageInput/ImageOutput (file I/O), ImageBuf/ImageBufAlgo (image processing), ImageCache/TextureSystem (texture mapping)
- `libOpenImageIO_Util` — Utility library (string_view, ustring, span, threading, filesystem, etc.)
**Command line tools**
- `oiiotool`: general image processing CLI
- `iinfo`: print info & metadata for an image file
- `iconvert`: simple format conversion
- `maketx`: convert images to tiled and MIP-mapped textures.
- `iv`: image viewer
## Repo map
- `src/include/OpenImageIO/` : Public API headers
- `src/libOpenImageIO/` : Core library (ImageBuf, ImageBufAlgo,
ImageInput/ImageOutput base classes)
- `src/libtexture/` : ImageCache, TextureSystem
- `src/libutil/` : Utility class implementations
- `src/<FORMAT>.imageio/` : Per-format ImageInput/ImageOutput plugins.
- `src/python/` : Python bindings using pybind11
- `src/<TOOL>` : CLI tools (oiiotool, iinfo, iconvert, maketx, iv)
- `testsuite/` : End-to-end/regression tests + reference outputs
- `src/cmake/`, `CMakeLists.txt` : Build system
- `.github/workflows/ci.yml` : GitHub Actions CI
- `src/build-scripts` Helper scripts used for build & CI
- `src/doc/` : User manual source (+ Doxygen comments in the public headers)
- `docs/dev/` : Developer documentation
- `docs/dev/Architecture.md` : Major subsystems overview
## Build and verification
Common build commands via the Makefile convenience wrapper:
```bash
make # configure, build, install (Release)
make debug # debug build
make clean # wipe build dir (needed when switching branches/modes)
make clang-format # format all source files
make test # full testsuite
make test TEST=<pattern> # subset matching regex
```
Or directly with cmake:
```bash
cmake -B build -S .
cmake --build build --target install
ctest --test-dir build -R <pattern> --output-on-failure
```
By default, builds into `./build` and installs into `./dist`.
## Testsuite notes
- Test output lands in `build/testsuite/<testname>/`; references in
`testsuite/<testname>/ref/`
- Read `testsuite/TESTSUITE-README.md` before updating references or
diagnosing failures
- For platform-specific diffs, add a variant ref (e.g. `out-win.txt`) rather
than overwriting
- Be conservative loosening image diff thresholds — use the minimum needed
- Check uploaded CI artifacts before changing references when local
reproduction is unclear
## Code formatting and file conventions
- `clang-format` enforced (`.clang-format`); CI rejects non-conforming code —
run `make clang-format` before committing
- Lines ~80 cols; ASCII only in code and comments; `#pragma once` for headers
- New files: standard copyright + SPDX notice
- `CamelCase` classes, `snake_case` locals, `ALL_CAPS` macros, `m_foo` private
members
- 3 blank lines between free functions/classes; 1 between class methods; max 1
blank line inside a function body
- `//` for regular comments; `///` Doxygen for public API
- If a file has a strong local style, imitate that.
## C++ guidelines
- Error handling: prefer `bool` returns, explicit status propagation, and
`errorfmt()`-style reporting — not exceptions — consistent with the
surrounding subsystem
- Preserve API, ABI, and behavior compatibility unless the task explicitly
requires a break
- For hot paths: no hidden allocation in inner loops or parallel regions;
precompute outside hot paths
- For kernel-style image work, use existing `ImageBufAlgo` and
`parallel_image` patterns before inventing a new execution model
## OIIO utility types (prefer over raw C++ equivalents)
Prefer C++17 `std` and Imath types except as noted below. Avoid introducing
new third-party dependencies without a strong reason.
- `OIIO::string_view` — non-owning string/`char*` (like `std::string_view`)
- `OIIO::span` / `OIIO::cspan` — non-owning contiguous data (like
`std::span`); use instead of pointer+length pairs
- `OIIO::image_span` — describes pixel buffer memory layout (pointer, sizes,
strides)
- `OIIO::Filesystem::*` — file/directory utilities (`filesystem.h`)
- `strutil.h` : string processing utilities
- `Strutil::format()` / `Strutil::print()` (= `OIIO::print()`) — string
formatting/output; **never** `printf` or `<<` streams
- `fmath.h` — fast/safe math, avoids NaN/Inf
- `simd.h` — SIMD helpers
- `unittest.h` — unit test macros
## Safe programming in C++
- Try to avoid passing raw pointers as function arguments.
- Use `std::unique_ptr` and `std::shared_ptr` rather than raw ownership when
new ownership must be expressed, but do not churn existing code just to
"modernize" it.
- Prefer `OIIO::string_view` when passing non-mutable strings or C-style
`char*` strings.
- Prefer `OIIO::span` rather than passing raw pointers + a separate length, or
passing a raw pointer with an implied (but not explicitly passed) length.
`OIIO::cspan` is a synonmym when the underlying data is const/non-mutable.
`OIIO::span<std::byte>` or `OIIO::cspan<std::byte>` can be used to represent
contiguous untyped data. These are our equivalent of C++ `std::span`.
- Prefer `OIIO::image_span` to describe the memory layout of multi-dimensional
pixel buffers (such as are used to describe where to read or write image
pixels), rather than passing raw pointers, sizes, and strides.
## Performance and determinism
- For hot image-processing code, avoid hidden allocation in inner loops or
parallel regions.
- Precompute setup work outside hot paths when practical.
- Keep data flow and ownership explicit.
- Preserve deterministic results where practical.
- Avoid unnecessary global state or synchronization.
- For kernel-style work, look for existing `ImageBufAlgo` and
`parallel_image` patterns before inventing a new execution model.
- Prefer incremental performance fixes backed by measurement or concrete
reasoning over speculative rewrites.
## Change impact checklist
- Bug fixes and behavior changes → add/update tests
- Public API changes → update Python bindings, docs, `CHANGES.md`
- `ImageBufAlgo` changes → consider oiiotool exposure, docs, Python, tests
- Format plugin changes → regression coverage for metadata, edge cases,
read/write
- CLI changes → update tests and help text
- Build/dependency changes → check CMake logic, CI, optional-feature coverage
## Commits and PRs
- Keep PRs narrow and easy to review.
- Prefix format: `type(subsystem): message` — subsystem is optional but helpful.
- Valid types: `fix:`, `feat:`, `perf:`, `api:`, `int:`, `build:`, `test:`,
`ci:`, `docs:`, `refactor:`, `style:`, `admin:`, `revert:`.
- Add a subsystem tag when it helps, e.g. `fix(exr):` or `perf(IBA):`.
- Write commit messages and PR descriptions that explain why the change is
needed, what behavior changes, and any non-obvious implementation choices.
## AI policy
Refer to `docs/dev/AI_Policy.md`.
See `docs/dev/AI_Policy.md`. Key rule: if AI assistance contributed materially
to a patch, the commit must include `Assisted-by: <TOOL> / <MODEL>`. The human
author is responsible for understanding, testing, and defending all changes.
## References
- `CONTRIBUTING.md` : general contribution guidelines and recap of coding
conventions.
+21
View File
@@ -0,0 +1,21 @@
OpenImageIO has been accepted to be an ASWF-administered project, by vote of
the ASWF Technical Advisory Council (TAC) on May 3, 2023.
At this time, the ASWF subdirectory contains *proposed* (and sometimes TBD/WIP
placeholders) project organization and policy documents that will be formally
adopted as the OpenImageIO project is formally turned over to ASWF and moved
to the AcademySoftwareFoundation GitHub account. Please file issues or PRs
or review comments against these documents to make any suggested changes while
we are revising the drafts.
Summary of the current state of documents:
| File | Status | Notes |
| ---- | ------ | ----- |
| CLA-corporate.md | Final | Standard ASWF corporate CLA, approved by the TSC. Will take effect when the repo moves. |
| CLA-individual.md | Final | Standard ASWF individual CLA, approved by the TSC. Will take effect when the repo moves. |
| CODE_OF_CONDUCT.md | Final | Links to the standard LF CoC, approved by the TSC and now in effect. |
| CONTRIBUTING.md | Preliminary | Modified version of our existing CONTRIBUTING guidelines, lightly amended to reflect the changes that will come along with moving the repo, the new CLA/DCO rules, etc.
| GOVERNANCE.md | Final | Approved by the TSC and now in effect. |
| project_intake.md | Ongoing | This is the latest ASWF project intake checklist. We will check off items as we get them done. |
| Technical-Charter.md | Final | Approved by the TSC. |
+242
View File
@@ -0,0 +1,242 @@
# Technical Charter (the "Charter") for OpenImageIO a Series of LF Projects, LLC
Adopted July 1, 2023 by unanimous vote of the TSC.
This Charter sets forth the responsibilities and procedures for technical
contribution to, and oversight of, the OpenImageIO open source project, which
has been established as OpenImageIO a Series of LF Projects, LLC (the
“Project”). LF Projects, LLC (“LF Projects”) is a Delaware series limited
liability company. All contributors (including committers, maintainers, and
other technical positions) and other participants in the Project
(collectively, “Collaborators”) must comply with the terms of this Charter.
### 1. Mission and Scope of the Project
* **a.** The mission of the Project is to develop software to read, write,
and manipulate image files of any image file format relevant to vfx /
animation via a format-agnostic API, with a feature set, scalability, and
robustness needed for production.
* **b.** The scope of the Project includes collaborative development under
the Project License (as defined herein) supporting the mission, including
documentation, testing, integration and the creation of other artifacts
that aid the development, deployment, operation or adoption of the open
source project.
### 2. Technical Steering Committee
* **a.** The Technical Steering Committee (the “TSC”) will be responsible
for all technical oversight of the open source Project.
* **b.** The TSC voting members are initially the Project’s Committers. At
the inception of the project, the Committers of the Project will be as set
forth within the “GOVERNANCE” file within the Project’s code repository.
The TSC may choose an alternative approach for determining the voting
members of the TSC, and any such alternative approach will be documented
in the GOVERNANCE file. Any meetings of the Technical Steering Committee
are intended to be open to the public, and can be conducted
electronically, via teleconference, or in person.
* **c.** TSC projects generally will involve Contributors and Committers.
The TSC may adopt or modify roles so long as the roles are documented in
the GOVERNANCE file. Unless otherwise documented:
- **i.** Contributors include anyone in the technical community that
contributes code, documentation, or other technical artifacts to the
Project;
- **ii.** Committers are Contributors who have earned the ability to
modify (“commit”) source code, documentation or other technical
artifacts in a project’s repository; and
- **iii.** A Contributor may become a Committer by a majority approval of
the existing Committers. A Committer may be removed by a majority
approval of the other existing Committers.
* **d.** Participation in the Project through becoming a Contributor and
Committer is open to anyone so long as they abide by the terms of this
Charter.
* **e.** The TSC may (1) establish work flow procedures for the submission,
approval, and closure/archiving of projects, (2) set requirements for the
promotion of Contributors to Committer status, as applicable, and (3)
amend, adjust, refine and/or eliminate the roles of Contributors, and
Committers, and create new roles, and publicly document any TSC roles, as
it sees fit.
* **f.** The TSC may elect a TSC Chair, who will preside over meetings of
the TSC and will serve until their resignation or replacement by the TSC.
The TSC Chair, or any other TSC member so designated by the TSC, will
serve as the primary communication contact between the Project and the
Academy Software Foundation, a directed fund of The Linux Foundation.
* **g.** Responsibilities: The TSC will be responsible for all aspects of
oversight relating to the Project, which may include:
- **i.** coordinating the technical direction of the Project;
- **ii.** approving project or system proposals (including, but not
limited to, incubation, deprecation, and changes to a sub-project’s
scope);
- **iii.** organizing sub-projects and removing sub-projects;
- **iv.** creating sub-committees or working groups to focus on
cross-project technical issues and requirements;
- **v.** appointing representatives to work with other open source or open
standards communities;
- **vi.** establishing community norms, workflows, issuing releases, and
security issue reporting policies;
- **vii.** approving and implementing policies and processes for
contributing (to be published in the CONTRIBUTING file) and coordinating
with the series manager of the Project (as provided for in the Series
Agreement, the “Series Manager”) to resolve matters or concerns that may
arise as set forth in Section 7 of this Charter;
- **viii.** discussions, seeking consensus, and where necessary, voting on
technical matters relating to the code base that affect multiple
projects; and
- **ix.** coordinating any marketing, events, or communications regarding
the Project.
### 3. TSC Voting
* **a.** While the Project aims to operate as a consensus-based community,
if any TSC decision requires a vote to move the Project forward, the
voting members of the TSC will vote on a one vote per voting member basis.
* **b.** Quorum for TSC meetings requires at least fifty percent of all
voting members of the TSC to be present. The TSC may continue to meet if
quorum is not met but will be prevented from making any decisions at the
meeting.
* **c.** Except as provided in Section 7.c. and 8.a, decisions by vote at a
meeting require a majority vote of those in attendance, provided quorum is
met. Decisions made by electronic vote without a meeting require a
majority vote of all voting members of the TSC.
* **d.** In the event a vote cannot be resolved by the TSC, any voting
member of the TSC may refer the matter to the Series Manager for
assistance in reaching a resolution.
### 4. Compliance with Policies
* **a.** This Charter is subject to the Series Agreement for the Project and
the Operating Agreement of LF Projects. Contributors will comply with the
policies of LF Projects as may be adopted and amended by LF Projects,
including, without limitation the policies listed at
https://lfprojects.org/policies/.
* **b.** The TSC may adopt a code of conduct (“CoC”) for the Project, which
is subject to approval by the Series Manager. In the event that a
Project-specific CoC has not been approved, the LF Projects Code of
Conduct listed at https://lfprojects.org/policies will apply for all
Collaborators in the Project.
* **c.** When amending or adopting any policy applicable to the Project, LF
Projects will publish such policy, as to be amended or adopted, on its web
site at least 30 days prior to such policy taking effect; provided,
however, that in the case of any amendment of the Trademark Policy or
Terms of Use of LF Projects, any such amendment is effective upon
publication on LF Project’s web site.
* **d.** All Collaborators must allow open participation from any individual
or organization meeting the requirements for contributing under this
Charter and any policies adopted for all Collaborators by the TSC,
regardless of competitive interests. Put another way, the Project
community must not seek to exclude any participant based on any criteria,
requirement, or reason other than those that are reasonable and applied on
a non-discriminatory basis to all Collaborators in the Project community.
* **e.** The Project will operate in a transparent, open, collaborative, and
ethical manner at all times. The output of all Project discussions,
proposals, timelines, decisions, and status should be made open and easily
visible to all. Any potential violations of this requirement should be
reported immediately to the Series Manager.
### 5. Community Assets
* **a.** LF Projects will hold title to all trade or service marks used by
the Project (“Project Trademarks”), whether based on common law or
registered rights. Project Trademarks will be transferred and assigned to
LF Projects to hold on behalf of the Project. Any use of any Project
Trademarks by Collaborators in the Project will be in accordance with the
license from LF Projects and inure to the benefit of LF Projects.
* **b.** The Project will, as permitted and in accordance with such license
from LF Projects, develop and own all Project GitHub and social media
accounts, and domain name registrations created by the Project community.
* **c.** Under no circumstances will LF Projects be expected or required to
undertake any action on behalf of the Project that is inconsistent with
the tax-exempt status or purpose, as applicable, of the Joint Development
Foundation or LF Projects, LLC.
### 6. General Rules and Operations.
* **a.**. The Project will:
- **i.** engage in the work of the Project in a professional manner
consistent with maintaining a cohesive community, while also maintaining
the goodwill and esteem of LF Projects, Joint Development Foundation and
other partner organizations in the open source community; and
- **ii.** respect the rights of all trademark owners, including any
branding and trademark usage guidelines.
### 7. Intellectual Property Policy
* **a.** Collaborators acknowledge that the copyright in all new
contributions will be retained by the copyright holder as independent
works of authorship and that no contributor or copyright holder will be
required to assign copyrights to the Project.
* **a.** Except as described in Section 7.c., all contributions to the
Project are subject to the following:
- **i.** All new inbound code contributions to the Project must be made
using the Apache License, Version 2.0 available at
http://www.apache.org/licenses/LICENSE-2.0 (the “Project License”).
- **ii.** All new inbound code contributions must also be accompanied by
(i) a Developer Certificate of Origin (http://developercertificate.org)
sign-off in the source code system that is submitted through a
TSC-approved contribution process which will bind the authorized
contributor and, if not self-employed, their employer to the applicable
license and (ii) a duly executed contribution license agreement in the
form approved by the TSC;
- **iii.** All outbound code will be made available under the Project
License.
- **iv.** Documentation will be received and made available by the Project
under the Creative Commons Attribution 4.0 International License
(available at http://creativecommons.org/licenses/by/4.0/).
- **v.** The Project may seek to integrate and contribute back to other
open source projects (“Upstream Projects”). In such cases, the Project
will conform to all license requirements of the Upstream Projects,
including dependencies, leveraged by the Project. Upstream Project code
contributions not stored within the Project’s main code repository will
comply with the contribution process and license terms for the
applicable Upstream Project.
* **c.** The TSC may approve the use of an alternative license or licenses
for inbound or outbound contributions on an exception basis. To request an
exception, please describe the contribution, the alternative open source
license(s), and the justification for using an alternative open source
license for the Project. License exceptions must be approved by a
two-thirds vote of the entire TSC.
* **d.** Contributed files should contain license information, such as SPDX
short form identifiers, indicating the open source license or licenses
pertaining to the file.
### 8. Amendments
* **a.** This charter may be amended by a two-thirds vote of the entire TSC
and is subject to approval by LF Projects.
+66
View File
@@ -0,0 +1,66 @@
# Project Intake checklist
This is a checklist for TSC's to review as part of the intake process. The TSC should review this entire list during the kickoff meeting. For anything outstanding, create an [issue](../issues) to track and link to it in the list
- Existing Project Governance
- [X] A [LICENSE.md](../LICENSE.md) file in every code repository, with the license chosen an OSI-approved license.
- [X] Any third-party components/dependencies included are listed along with thier licenses ( [THIRD-PARTY.md](../THIRD-PARTY.md) )
- [X] A [README.md](../README.md) file welcoming new community members to the project and explaining why the project is useful and how to get started.
- [X] A [CONTRIBUTING.md](../CONTRIBUTING.md) file explaining to other developers and your community of users how to contribute to the project. The file should explain what types of contributions are needed and how the process works, along with how to disclose security issues responsibly ( may also point to a [SECURITY.md](../SECURITY.md) file ).
- [ ] A [CODEOWNERS](../CODEOWNERS) or [COMMITTERS](../COMMITERS.csv) file to define individuals or teams that are responsible for code in a repository; document current project owners and current and emeritus committers.
- [X] A [CODE_OF_CONDUCT.md](../CODE_OF_CONDUCT.md) file that sets the ground rules for participants’ behavior associated and helps to facilitate a friendly, welcoming environment. By default, projects should leverage the Linux Foundation Code of Conduct unless an alternate Code of Conduct was previously approved.
- [X] A [RELEASING.md](../RELEASING.md) file that provides documentation on the release methodology, cadence, criteria, etc.
- [X] A [GOVERNANCE.md](../GOVERNANCE.md) file that documents the project’s technical governance.
- [ ] A [SUPPORT.md](../SUPPORT.md) file to let users and developers know about ways to get help with your project.
- Infrastructure/Assets
- [X] Technical Charter Approved
- [ ] **(Awaiting scan from LF)** License scan completed and no issues found
- [ ] Code repository imported to ASWF GitHub organization or ownership of current GitHub organization given to `thelinuxfoundation` user
- [X] Developer Certificate of Origin past commit signoff done and DCO Probot enabled.
- [X] Issue/feature tracker established (JIRA, GitHub issues)
- [X] Mailing lists ( one of )
- [X] Setup new lists ( -dev@ and -tsc@ ) on [ASWF groups.io](https://lists.aswf.io) ( create [issue on foundation repo](https://github.com/AcademySoftwareFoundation/foundation/issues/new) to setup )
- [X] (In progress) Move to [ASWF groups.io](https://lists.aswf.io) ( create [issue on foundation repo](https://github.com/AcademySoftwareFoundation/foundation/issues/new) to transfer )
- [X] Slack ( create [issue on foundation repo](https://github.com/AcademySoftwareFoundation/foundation/issues/new) to setup project channel on [ASWF Slack](https://slack.aswf.io) )
- [ ] Website
- [X] CI/build environment
- [X] Trademarks/mark ownership rights ( complete 'LF Projects - Form of Trademark and Account Assignment' - create [issue on foundation repo](https://github.com/AcademySoftwareFoundation/foundation/issues/new) - only needed if project using existing name )
- [ ] Domain name ( create [issue with the LF IT staff](https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/group/19) to setup/transfer )
- [ ] Zoom account access ( create [issue on foundation repo](https://github.com/AcademySoftwareFoundation/foundation/issues/new) to get access to credentials )
- [X] (N/A) Social media accounts or other project accounts ( create [issue on foundation repo](https://github.com/AcademySoftwareFoundation/foundation/issues/new) to transfer )
- [X] Logo(s) ( create [issue on artwork repo](https://github.com/AcademySoftwareFoundation/artwork/issues/new) to add in SVG and PNG format and color/black/white )
- New Project Governance
- [X] TSC members identified
- [X] First TSC meeting held
- [X] TSC meeting cadence set and added to project calendar
- [X] CLA Approved ( if used ) ( [CCLA](CLA-corporate.md) and [ICLA](CLA-individual.md) )
- Project charter ( [Technical-Charter.md](Technical-Charter.md) )
- [X] Approved by TSC
- [ ] Filed ( create pull request against [foundation repo](https://github.com/AcademySoftwareFoundation/foundation) )
- [X] [Core Infrastructure Initiative Best Practices Badge](https://bestpractices.coreinfrastructure.org/) achieved as the 'Passing' level.
- Outreach
- [ ] New project announcement done ( create [issue on foundation repo](https://github.com/AcademySoftwareFoundation/foundation/issues/new) to trigger )
- [X] Project added to ASWF website and ASWF landscape
- Incubation Stage requirements
- [X] Have achieved and maintained a [OpenSSF Best Practices Badge at the passing level](https://bestpractices.coreinfrastructure.org/en/criteria).
- [ ] Have had a successful license scan with any critical issues remedied.
- [ ] Have a defined project mission and scope
- [ ] An overview of the project’s architecture and features defined.
- [ ] A project roadmap defined, which should address the following questions.
- What use cases are possible now?
- What does the next year look like in terms of additional features and use cases covered?
- [ ] Community and contributor growth assessment
- The current number of contributors and committers, and the number of different organizations contributing to the project.
- Demonstrate a sustained flow of commits / merged contributions
- A credible plan for developing a thriving user community, in particular expanding the number of committers and contributors?
- Outline of the plan for the project to complete the requirements for Adopted Stage
- [ ] Obtain an affirmative vote of the TAC.
- Adopted Stage graduation requirements
- [ ] Demonstrate a substantial ongoing flow of commits and merged contributions, authored by a healthy number of diverse contributors.
- [ ] Demonstrable roadmap progress.
- [ ] A healthy number of public adopters that are identified within the project ( using an ADOPTERS file or showcased on the project’s website ).
- [ ] Have achieved and maintained an [OpenSSF Best Practices Badge at the gold level](https://bestpractices.coreinfrastructure.org/en/criteria/2).
- [ ] Have a technical lead appointed for voting representation of the project to the TAC.
- [ ] Be deemed by the TAC to add value to the mission of ASWF.
- [ ] 2/3 supermajority vote of the TAC
- [ ] Affirmative majority vote of the Governing Board
+4239 -1706
View File
File diff suppressed because it is too large Load Diff
+58 -140
View File
@@ -1,10 +1,10 @@
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# SPDX-License-Identifier: BSD-3-Clause and Apache-2.0
# https://github.com/OpenImageIO/oiio
cmake_minimum_required (VERSION 3.18.2...4.0)
cmake_minimum_required (VERSION 3.12)
set (OpenImageIO_VERSION "3.2.0.2")
set (OpenImageIO_VERSION "2.4.16.0")
set (OpenImageIO_VERSION_OVERRIDE "" CACHE STRING
"Version override (use with caution)!")
mark_as_advanced (OpenImageIO_VERSION_OVERRIDE)
@@ -19,12 +19,12 @@ project (OpenImageIO VERSION ${OpenImageIO_VERSION}
set (PROJ_NAME OIIO) # short name, caps
string (TOLOWER ${PROJ_NAME} PROJ_NAME_LOWER) # short name lower case
string (TOUPPER ${PROJ_NAME} PROJ_NAME_UPPER) # short name upper case
set (PROJECT_VERSION_RELEASE_TYPE "dev" CACHE STRING
set (PROJECT_VERSION_RELEASE_TYPE "" CACHE STRING
"Build type, for example: dev, beta2, RC1 (empty string for normal release)")
set (${PROJECT_NAME}_VERSION_RELEASE_TYPE ${PROJECT_VERSION_RELEASE_TYPE})
set (PROJECT_AUTHORS "Contributors to the OpenImageIO project")
option (${PROJECT_NAME}_SUPPORTED_RELEASE
"Set ON for supported release branches, OFF for 'main'" OFF)
"Set ON for supported release branch, OFF for master" ON)
if (${PROJECT_NAME}_SUPPORTED_RELEASE)
set (${PROJECT_NAME}_DEV_RELEASE OFF)
else ()
@@ -40,17 +40,6 @@ if (CMAKE_VERSION VERSION_LESS 3.21)
endif ()
endif ()
# Set up module path for our own cmake modules and add some essential ones
list (APPEND CMAKE_MODULE_PATH
"${PROJECT_SOURCE_DIR}/src/cmake/modules"
"${PROJECT_SOURCE_DIR}/src/cmake")
# Utilities
include (colors)
include (set_utils)
include (check_is_enabled)
include (fancy_add_executable)
# If the user wants to use Conan to build dependencies, they will have done
# this prior to the cmake config:
# cd <build area>
@@ -87,11 +76,9 @@ message (STATUS "Build type = ${CMAKE_BUILD_TYPE}")
message (STATUS "Supported release = ${${PROJECT_NAME}_SUPPORTED_RELEASE}")
# Make the build area layout look a bit more like the final dist layout
if (PROJECT_IS_TOP_LEVEL)
set (CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set (CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set (CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
endif()
set (CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set (CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set (CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
if ("${PROJECT_SOURCE_DIR}" STREQUAL "${CMAKE_BINARY_DIR}")
message (FATAL_ERROR "Not allowed to run in-source build!")
@@ -105,21 +92,15 @@ endif ()
option (VERBOSE "Print lots of messages while compiling" OFF)
if (VERBOSE)
set (CMAKE_MESSAGE_LOG_LEVEL "VERBOSE" CACHE STRING "CMake log level to display")
else ()
set (CMAKE_MESSAGE_LOG_LEVEL "STATUS" CACHE STRING "CMake log level to display")
endif ()
set_option (${PROJ_NAME}_BUILD_TOOLS "Build the command-line tools" ON)
set_option (${PROJ_NAME}_BUILD_TESTS "Build the unit tests" ON)
set_option (OIIO_USE_HWY "Enable experimental Google Highway SIMD optimizations (if Highway is available)" OFF VERBOSE)
option (${PROJ_NAME}_BUILD_TOOLS "Build the command-line tools" ON)
option (${PROJ_NAME}_BUILD_TESTS "Build the unit tests" ON)
set (OIIO_LIBNAME_SUFFIX "" CACHE STRING
"Optional name appended to ${PROJECT_NAME} libraries that are built")
set_option (BUILD_OIIOUTIL_ONLY "If ON, will build *only* libOpenImageIO_Util" OFF)
set_option (BUILD_DOCS "If ON, build documentation and man pages." ON)
set_option (INSTALL_DOCS "If ON, install documentation and man pages." ON)
set_option (INSTALL_FONTS "If ON, install default fonts" ON)
set_option (EMBEDPLUGINS "Embed format plugins in libOpenImageIO" ON)
option (BUILD_OIIOUTIL_ONLY "If ON, will build *only* libOpenImageIO_Util" OFF)
option (BUILD_DOCS "If ON, build documentation and man pages." ON)
option (INSTALL_DOCS "If ON, install documentation and man pages." ON)
option (INSTALL_FONTS "If ON, install default fonts" ON)
option (EMBEDPLUGINS "Embed format plugins in libOpenImageIO" ON)
set (PLUGIN_SEARCH_PATH "" CACHE STRING "Default plugin search path")
file (TO_NATIVE_PATH "${PLUGIN_SEARCH_PATH}" PLUGIN_SEARCH_PATH_NATIVE)
set (CMAKE_DEBUG_POSTFIX "_d" CACHE STRING "Library naming postfix for Debug builds")
@@ -134,107 +115,56 @@ message(STATUS "CMAKE_UNITY_BUILD_BATCH_SIZE = ${CMAKE_UNITY_BUILD_BATCH_SIZE}")
option (OIIO_THREAD_ALLOW_DCLP "OIIO threads may use DCLP for speed" ON)
if (NOT OIIO_THREAD_ALLOW_DCLP)
add_compile_definitions (OIIO_THREAD_ALLOW_DCLP=0)
add_definitions ("-DOIIO_THREAD_ALLOW_DCLP=0")
endif ()
set (TEX_BATCH_SIZE "" CACHE STRING "Force TextureSystem SIMD batch size (e.g. 16)")
if (TEX_BATCH_SIZE)
add_compile_definitions (OIIO_TEXTURE_SIMD_BATCH_WIDTH=${TEX_BATCH_SIZE})
add_definitions ("-DOIIO_TEXTURE_SIMD_BATCH_WIDTH=${TEX_BATCH_SIZE}")
endif ()
option (OIIO_TEX_IMPLEMENT_VARYINGREF "Implement the deprecated batch texture functions taking VaryingRef params" ON)
if (NOT OIIO_TEX_IMPLEMENT_VARYINGREF)
add_definitions (-DOIIO_TEX_NO_IMPLEMENT_VARYINGREF=1)
endif ()
# If we're building this just for CI, define a symbol so the code can
# tell (and reduce complexity of some tests)
set_option (OIIO_CI "Set if this build is for our GHA CI" OFF)
if (OIIO_CI)
add_compile_definitions (OIIO_CI=1)
endif ()
# Namespace settings
#
# The "outer namespace" defaults to the project name, but it can be overridden
# to allow custom builds that put everything inside a unique namespace that
# can't conflict with default builds.
set (${PROJ_NAME}_OUTER_NAMESPACE ${PROJECT_NAME} CACHE STRING
"Customized outer namespace")
set (PROJ_NAMESPACE "${${PROJ_NAME}_OUTER_NAMESPACE}") # synonym
# There is also an inner namespace that is either vMAJ_MIN or vMAJ_MIN_PATCH,
# depending on the setting of ${PROJ_NAME}_INNER_NAMESPACE_INCLUDE_PATCH.
option (${PROJ_NAME}_INNER_NAMESPACE_INCLUDE_PATCH
# Set the default namespace
set (${PROJ_NAME}_NAMESPACE ${PROJECT_NAME} CACHE STRING
"Customized outer namespace base name (version will be added)")
option (${PROJ_NAME}_NAMESPACE_INCLUDE_PATCH
"Should the inner namespace include the patch number" ${${PROJECT_NAME}_DEV_RELEASE})
if (${PROJ_NAME}_INNER_NAMESPACE_INCLUDE_PATCH)
set (PROJ_VERSION_NAMESPACE "v${PROJECT_VERSION_MAJOR}_${PROJECT_VERSION_MINOR}_${PROJECT_VERSION_PATCH}")
else ()
set (PROJ_VERSION_NAMESPACE "v${PROJECT_VERSION_MAJOR}_${PROJECT_VERSION_MINOR}")
set (PROJ_NAMESPACE "${${PROJ_NAME}_NAMESPACE}")
set (PROJ_NAMESPACE_V "${PROJ_NAMESPACE}_v${PROJECT_VERSION_MAJOR}_${PROJECT_VERSION_MINOR}")
if (${PROJ_NAME}_NAMESPACE_INCLUDE_PATCH)
set (PROJ_NAMESPACE_V "${PROJ_NAMESPACE_V}_${PROJECT_VERSION_PATCH}")
endif ()
# PROJ_NAMESPACE_V combines the outer and inner namespaces into one symbol
set (PROJ_NAMESPACE_V "${PROJ_NAMESPACE}_${PROJ_VERSION_NAMESPACE}")
message(STATUS "Outer namespace PROJ_OUTER_NAMESPACE: ${PROJ_NAMESPACE}")
message(STATUS "Inner namespace PROJ_VERSION_NAMESPACE: ${PROJ_VERSION_NAMESPACE}")
message(STATUS "Joint namespace PROJ_NAMESPACE_V: ${PROJ_NAMESPACE_V}")
message(STATUS "Setting Namespace to: ${PROJ_NAMESPACE_V}")
# Define OIIO_INTERNAL symbol only when building OIIO itself, will not be
# defined for downstream projects using OIIO.
add_compile_definitions (OIIO_INTERNAL=1)
add_definitions (-DOIIO_INTERNAL=1)
# If CMake variable OIIO_SITE is set, set compile symbol OIIO_SITE_sitename
if (OIIO_SITE)
add_compile_definitions (OIIO_SITE_${OIIO_SITE})
endif ()
list (APPEND CMAKE_MODULE_PATH
"${PROJECT_SOURCE_DIR}/src/cmake/modules"
"${PROJECT_SOURCE_DIR}/src/cmake")
include (GNUInstallDirs)
# Utilities for build instructions of the format-reading plugins
# Utilities
include (colors)
include (check_is_enabled)
include (checked_find_package)
include (fancy_add_executable)
include (add_oiio_plugin)
# All the C++ and compiler related options and adjustments
include (compiler)
# Dependency finding utilities and all dependency-related options
include (dependency_utils)
option (IGNORE_HOMEBREWED_DEPS "If ON, will ignore homebrew-installed dependencies" OFF)
if (IGNORE_HOMEBREWED_DEPS)
# Define the list of prefixes to ignore
set (HOMEBREW_PREFIXES
/opt/homebrew
/opt/homebrew/Cellar
/usr/local
/usr/local/Cellar
/usr/X11
/usr/X11R6
/opt/X11
)
message (STATUS "Ignoring Homebrew dependencies and adjusted environment and CMake variables accordingly.")
foreach (_cmake_var
CMAKE_SYSTEM_INCLUDE_PATH
CMAKE_SYSTEM_LIBRARY_PATH
CMAKE_PREFIX_PATH)
remove_prefixes_from_variable (CMAKE ${_cmake_var} "${HOMEBREW_PREFIXES}")
endforeach ()
# Adjust CMAKE_IGNORE_PATH
foreach (_prefix IN LISTS HOMEBREW_PREFIXES)
list (APPEND CMAKE_IGNORE_PATH
"${_prefix}"
"${_prefix}/lib"
"${_prefix}/bin"
"${_prefix}/include"
)
endforeach ()
message (STATUS "CMAKE_IGNORE_PATH: ${CMAKE_IGNORE_PATH}")
endif ()
# Utilities and options related to finding python and making python bindings
include (pythonutils)
# Dependency finding utilities and all dependency-related options
include (externalpackages)
include (cuda_macros)
# Include all our testing apparatus and utils, but not if it's a subproject
if (PROJECT_IS_TOP_LEVEL)
include (testing)
@@ -257,6 +187,9 @@ include_directories (
# Tell CMake to process the sub-directories
add_subdirectory (src/libutil)
find_or_download_robin_map ()
# Add IO plugin directories -- if we are embedding plugins, we need to visit
# these directories BEFORE the OpenImageIO target is established (in
# src/libOpenImageIO). For each plugin, we append to the lists of source
@@ -267,6 +200,13 @@ set (format_plugin_libs "")
set (format_plugin_include_dirs "")
set (format_plugin_definitions "")
file (GLOB all_format_plugin_dirs src/*.imageio)
if ("${OIIO_SITE}" STREQUAL "SPI")
# SPI only -- because of a workaround for a very weird linkage issue
# specific to our system, we need to be sure libtiff is referenced first.
file (GLOB tiff_format_plugin_dir src/tiff.imageio)
list (REMOVE_ITEM all_format_plugin_dirs ${tiff_format_plugin_dir})
list (INSERT all_format_plugin_dirs 0 ${tiff_format_plugin_dir})
endif ()
if (EMBEDPLUGINS AND NOT BUILD_OIIOUTIL_ONLY)
foreach (plugin_dir ${all_format_plugin_dirs})
add_subdirectory (${plugin_dir})
@@ -277,16 +217,6 @@ if (NOT BUILD_OIIOUTIL_ONLY)
add_subdirectory (src/libOpenImageIO)
endif ()
# Disable building of certain tools when building Python wheels
if (SKBUILD)
set (ENABLE_iconvert OFF)
set (ENABLE_igrep OFF)
set (ENABLE_iinfo OFF)
set (ENABLE_testtex OFF)
set (ENABLE_iv OFF)
endif ()
if (OIIO_BUILD_TOOLS AND NOT BUILD_OIIOUTIL_ONLY)
add_subdirectory (src/iconvert)
add_subdirectory (src/idiff)
@@ -307,23 +237,8 @@ if (NOT EMBEDPLUGINS AND NOT BUILD_OIIOUTIL_ONLY)
endforeach ()
endif ()
if (WIN32)
set (_py_dev_found Python3_Development_FOUND)
else ()
set (_py_dev_found Python3_Development.Module_FOUND)
endif ()
if (USE_PYTHON AND ${_py_dev_found} AND NOT BUILD_OIIOUTIL_ONLY)
if (OIIO_BUILD_PYTHON_PYBIND11
OR OIIO_PYTHON_BINDINGS_BACKEND STREQUAL "nanobind")
add_subdirectory (src/python)
endif ()
if (OIIO_BUILD_PYTHON_NANOBIND
AND OIIO_PYTHON_BINDINGS_BACKEND STREQUAL "both")
add_subdirectory (src/python-nanobind)
endif ()
else ()
message (STATUS "Not building Python bindings: USE_PYTHON=${USE_PYTHON}, Python3_Development.Module_FOUND=${Python3_Development.Module_FOUND}")
if (USE_PYTHON AND Python_Development_FOUND AND NOT BUILD_OIIOUTIL_ONLY)
add_subdirectory (src/python)
endif ()
add_subdirectory (src/include)
@@ -337,6 +252,11 @@ if (NUKE_FOUND)
add_subdirectory (src/nuke/txWriter)
endif ()
# Last minute site-specific instructions, if they exist
if (OIIO_SITE AND EXISTS "${PROJECT_SOURCE_DIR}/site/${OIIO_SITE}/cmake/sitecustom.cmake")
include ("${PROJECT_SOURCE_DIR}/site/${OIIO_SITE}/cmake/sitecustom.cmake")
endif ()
# install pkgconfig file
if (NOT MSVC)
configure_file(src/build-scripts/OpenImageIO.pc.in "${CMAKE_BINARY_DIR}/OpenImageIO.pc" @ONLY)
@@ -385,7 +305,7 @@ install (EXPORT OIIO_EXPORTED_TARGETS
NAMESPACE ${PROJECT_NAME}::)
if (PROJECT_IS_TOP_LEVEL AND BUILD_TESTING AND ${PROJ_NAME}_BUILD_TESTS)
if (PROJECT_IS_TOP_LEVEL AND BUILD_TESTING)
oiio_setup_test_data()
oiio_add_all_tests()
endif ()
@@ -393,5 +313,3 @@ endif ()
if (PROJECT_IS_TOP_LEVEL)
include (packaging)
endif ()
print_package_notfound_report ()
-4
View File
@@ -5,7 +5,3 @@ you can read in full [here](https://lfprojects.org/policies/code-of-conduct).
To report incidents or to appeal reports of incidents, send email to
the Manager of LF Projects at manager@lfprojects.org.
<!-- SPDX-License-Identifier: CC-BY-4.0 -->
<!-- Copyright Contributors to the OpenImageIO Project. -->
+49 -171
View File
@@ -1,33 +1,37 @@
<!-- SPDX-License-Identifier: CC-BY-4.0 -->
<!-- Copyright Contributors to the OpenImageIO Project. -->
Contributing to OpenImageIO
===========================
Code contributions to OpenImageIO are always welcome, and [nearly 250
people](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/CREDITS.md) have done
> NOTE: This is the proposed post-ASWF-move version of CONTRIBUTING. After the
> project is legally transferred and moved to the new repo, this file will
> replace the one at the project root.
>
> TO DO:
>
> - [X] Update the mail list sign-up page after the mail list moves.
> - [ ] Update the repo URL
> - [ ] Double check the security and info email addresses.
>
Code contributions to OpenImageIO are always welcome, and [nearly 200
people](https://github.com/OpenImageIO/oiio/blob/master/CREDITS.md) have done
so over the years. Please review this document to get a briefing on our
process.
General Tips for Open Source Development
----------------------------------------
* GitHub's [Open Source Guides](https://opensource.guide/)
- Especially the guide on [How to Contribute to Open Source](https://opensource.guide/how-to-contribute/)
Mail List and Slack
-------------------
Contributors should be reading the oiio-dev mail list:
* [oiio-dev](https://lists.aswf.io/g/oiio-dev)
For developers of the OpenImageIO code itself, or users who are really
interested in the OIIO internals. This is where we mostly discuss the code
(including bug reports), but are also happy to answer user questions about
use or working of OIIO. You can sign up for the mail list on your own using the link above.
use or working of OIIO.
* [ASWF Slack](https://slack.aswf.io/) has an `openimageio` channel. Sign up
You can sign up for the mail list on your own using the link above.
The [ASWF Slack](https://slack.aswf.io/) has an `openimageio` channel. Sign up
for the Slack on your own, then under "channels", select "browse channels" and
you should see the openimageio channel (among those of the other projects and
working groups).
@@ -47,11 +51,11 @@ Bug Reports and Issue Tracking
------------------------------
We use GitHub's issue tracking system for reporting bugs and requesting
enhancements: https://github.com/AcademySoftwareFoundation/OpenImageIO/issues
enhancements: https://github.com/OpenImageIO/oiio/issues
**If you are merely asking a question ("how do I...")**, please do not file an
issue, but instead ask the question on the [oiio-dev mailing
list](https://lists.aswf.io/g/oiio-dev) or on the Slack channel.
list](https://lists.aswf.io/g/oiio-dev).
If you are submitting a bug report, please be sure to note which version of
OIIO you are using, on what platform (OS/version, which compiler you used,
@@ -68,44 +72,10 @@ following your instructions. Please quote the exact error message you
received. If you are having trouble building, please post the full cmake
output of a fresh VERBOSE=1 build.
[SECURITY.md](SECURITY.md) details our security policies and lists prior security advisories. True exploitable security vulnerabilities
that should be fixed before disclosure should be reported by filing a GitHub
[security advisory](https://github.com/AcademySoftwareFoundation/OpenImageIO/security/advisories/new).
If that is not possible, it is also fine to email your report to
security@openimageio.org. Only the project administrators have access to these
reports. For problems that you don't think are really exploitable
vulnerabilities, you are encouraged to just file a regular issue, as described
above.
Suspected security vulnerabilities should be reported by the same process.
Policy on AI Tools
------------------
Please read our [Policy on AI Coding Assistants](docs/dev/AI_Policy.md)
before contributing or participating in the project in any way mediated by
"AI" assistants.
High-level summary:
- Human must always be in the loop, and is the responsible party for
the contents of a PR (including fully understanding and being able
to explain, defend, and modify it in response to review comments).
- Interact with the project and community yourself, not by agent.
- Disclose what tools you used and how. At a minimum, we require an
"Assisted-by: TOOL/MODEL" line in the commit comments and PR description.
- Don't waste maintainer's time with low quality PRs.
Please do read the whole [Policy on AI Coding Assistants](docs/dev/AI_Policy.md)
for all the details.
The repository supports several AI coding assistants (Claude Code, Cursor,
GitHub Copilot, OpenAI Codex, Opencode). After cloning, run the setup script
for whichever tool(s) you use:
```
.agents/setup-agent claude # or: cursor, codex, opencode, copilot, all
```
See [docs/dev/Agentic_Coding.md](docs/dev/Agentic_Coding.md) for details.
If confidentiality precludes a public question or issue for any reason, you
may contact us privately at [security@openimageio.org](security@openimageio.org).
Contributor License Agreement (CLA) and Intellectual Property
@@ -117,39 +87,26 @@ safety, as it prevents any possible future disputes between code authors and
their employers or anyone else who might think they might own the IP output of
the author.
* [Corporate CLA](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/ASWF/CLA-corporate.md) :
* [Corporate CLA](https://github.com/OpenImageIO/oiio/blob/master/ASWF/CLA-corporate.md) :
If you are writing the code as part of your job, or if there is any
possibility that your employers might think they own any intellectual
property you create. This needs to be executed by someone who has
signatory power for the company.
* [Individual CLA](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/ASWF/CLA-individual.md) :
* [Individual CLA](https://github.com/OpenImageIO/oiio/blob/master/ASWF/CLA-individual.md) :
If you are an individual writing the code on your own time, using your own
equipment, and you're SURE you are the sole owner of any intellectual
property you contribute.
Please note that it is extremely common (nearly ubiquitous in the US and
Canada, and maybe other places) for full-time employees of technology and
entertainment companies to have IP clauses in their employment agreement (in
that pile of paperwork you sign on your first day of work and then promptly
forget about) that give the company rights to any code you write, even on your
own time. The OpenImageIO project expects you to know and follow the rules of
your employer and to have them sign a corporate CLA if necessary.
The easiest way to sign CLAs is digitally [using
EasyCLA](https://corporate.v1.easycla.lfx.linuxfoundation.org). There are
detailed step-by-step instructions about using the EasyCLA system for
[corporate CLAs](https://docs.linuxfoundation.org/lfx/easycla/v2-current/contributors/corporate-contributor)
and [individual CLAs](https://docs.linuxfoundation.org/lfx/easycla/v2-current/contributors/individual-contributor#github).
The easiest way to sign CLAs is digitally [using EasyCLA](https://corporate.v1.easycla.lfx.linuxfoundation.org).
Companies who prefer not to use the online tools may sign, scan, and email
the executed copy to manager@lfprojects.org.
The corporate CLA allows a company to name a "CLA Manager" (who does not need
signatory power) who has the ability to use the online system to add or delete
individual employees of the company who are authorized to submit pull
requests, without needing to get an executive to amend and sign the agreement
each time.
The CLA allows a company to name a "CLA Manager" (who does not need
signatory power) who has the ability to use the online system to add or
delete individual employees of the company who are authorized to submit pull
requests, without needing to get an executive to amend and sign the
agreement each time.
Please note that these CLAs are based on the Apache 2.0 CLAs, and differ
minimally, only as much as was required to correctly describe the EasyCLA
@@ -177,84 +134,6 @@ leverage this [command line tool](https://github.com/coderanger/dco) for
automatically adding the signoff message on commits.
Commit messages
---------------
### Summary heuristic
Look at the commit history of the project to get a sense of the style and
level of detail that is expected in commit messages.
### General guidelines and expectations
The first line of the commit message should be a short (less than 80
characters) summary of the change, prefixed with the general nature of the
change (see below).
The rest of the commit message should be a more detailed explanation of the
changes. Some commits are self-explanatory and don't need more than the
summary line. Others may need a more detailed explanation. Hallmarks of
a good commit message include:
* An explanation of why the change is necessary and what you hope to
accomplish with it.
* A description of any major user- or developer-facing changes that people
should be aware of: changes in APIs or behaviors, new features, etc.
* An explanation of any tricky implementation details or design decisions that
might not be immediately obvious to someone reading the code.
* Guideposts for somebody reviewing the code to understand the rationale and
have any supporting background information to fully understanding the code
changes.
Remember that at some point in the future, a developer unfamiliar with your
change (maybe you, long after you've forgotten the details) might need to
understand or fix your patch. Keep that person in mind as your audience and
strive to write a commit message that explains the context in a way that saves
them time and effort. Be the hero in the story of their future debugging
effort!
### Using "conventional commits" prefixes
We strive to follow the recommendations known as [conventional
commits](https://www.conventionalcommits.org/), which means that we would like
merged commit messages to have their first line start with one of the
following prefixes:
- `feat:` new features
- `fix:` bug fixes
- `perf:` performance improvements
- `api:` changes to the public APIs
- `int:` changes to code internals that don't affect the public API
- `build:` changes to the build system
- `test:` changes to the test suite or unit tests
- `ci:` changes to the CI system
- `docs:` changes to the documentation
- `refactor:` code refactoring
- `style:` formatting or other stylistic non-functional changes to the code
- `admin:` project administration or policy changes
- `revert:` reverting a previous commit
Obviously, some (if not most) PRs may qualify for more than one of these
categories (for example, a new feature may also introduce a new API call, add
tests, and include new documentation). If that is the case, use your best
judgment to pick the category that best captures the essence or most important
aspect of the change. When ambiguous, consider the list above to be a priority
ranking (e.g., a change that fixes a bug and adds a new test should be listed
under `fix:`, because that appears first in the list).
It is also encouraged, when it makes sense to do so, to put a subcategory in
parenthesis after the prefix, like `fix(exr):` or `feat(IBA):`. It's ok to use
obvious abbreviations for major classes or subsections: IB=ImageBuf,
IBA=ImageBufAlgo, IC=ImageCache, TS=TextureSystem, etc. If there is no clear
single format or class that is the man focus of the patch, then you can omit
the subcategory.
API or ABI-breaking changes should additionally be marked with an exclamation
point at the end of the prefix, like `feat!:` or `api!:` to make it easily
identifiable as a breaking change from the first line of the commit message.
Pull Requests and Code Review
-----------------------------
@@ -264,41 +143,38 @@ The best way to submit changes is via GitHub Pull Request. GitHub has a
All code must be formally reviewed before being merged into the official
repository. The protocol is like this:
1. Get a GitHub account, fork AcademySoftwareFoundation/OpenImageIO to create
your own repository on GitHub, and then clone it to get a repository on your
local machine.
1. Get a GitHub account, fork OpenImageIO/oiio to create your own repository
on GitHub, and then clone it to get a repository on your local machine.
2. Edit, compile, and test your changes. Run clang-format (see the
1. Edit, compile, and test your changes. Run clang-format (see the
instructions on coding style below).
3. Push your changes to your fork (each unrelated pull request to a separate
1. Push your changes to your fork (each unrelated pull request to a separate
"topic branch", please).
4. Make a "pull request" on GitHub for your patch.
1. Make a "pull request" on GitHub for your patch.
5. If your patch will induce a major compatibility break, or has a design
2. If your patch will induce a major compatibility break, or has a design
component that deserves extended discussion or debate among the wider OIIO
community, then it may be prudent to email oiio-dev pointing everybody to
the pull request URL and discussing any issues you think are important.
6. All pull requests automatically launch CI jobs on GitHub Actions to
1. All pull requests automatically launch CI jobs on GitHub Actions to
ensure that the build completes and that the tests suite runs correctly, for
a variety of platform, compiler, library, and flag combinations. The status
of the CI tests for your PR will be displayed on the GitHub PR page. We will
not accept PRs that don't build cleanly or pass the existing testsuite.
7. The reviewer will look over the code and critique on the "comments" area.
1. The reviewer will look over the code and critique on the "comments" area.
Reviewers may ask for changes, explain problems they found, congratulate the
author on a clever solution, etc. But until somebody says "LGTM" (looks good
to me), the code should not be committed. Sometimes this takes a few rounds
of give and take. Please don't take it hard if your first try is not
accepted. It happens to all of us.
8. After approval, one of the senior developers (with commit approval to the
official main repository) will merge your fixes into the main branch.
1. After approval, one of the senior developers (with commit approval to the
official main repository) will merge your fixes into the master branch.
Please see the [Code Review](docs/dev/CodeReview.md) document for more
explanaton of the code review process.
Coding Style
------------
@@ -314,7 +190,7 @@ All source files should begin with these three lines:
// Copyright Contributors to the OpenImageIO project.
// SPDX-License-Identifier: Apache-2.0
// https://github.com/AcademySoftwareFoundation/OpenImageIO
// https://github.com/OpenImageIO/oiio
as a comment in the syntax of whatever source code is used in that file.
@@ -379,9 +255,9 @@ capitalize new words: `class CustomerList;` In general, local variables
should start with lower case. Macros should be `ALL_CAPS`, if used at all.
If your class is extremely similar to, or modeled after, something in the
standard library, or something else we interoperate with, it's ok to
standard library, Boost, or something else we interoperate with, it's ok to
use their naming conventions. For example, very general utility classes and
templates (the kind of thing you would normally find in std) should
templates (the kind of thing you would normally find in std or boost) should
be lower case with underscores separating words, as they would be if they
were standards.
@@ -414,8 +290,10 @@ Namespaces: yes, use them!
### Third-party libraries
Prefer C++17 `std` rather than other libraries, where both can do the same
task.
Prefer C++11 `std` rather than Boost, where both can do the same task.
Feel free to use Boost classes you already see in the code base, but don't
use any Boost you don't see us already using, without first checking with
the project leader.
Please do use Imath vector, matrix, and utility classes where applicable.
Don't write your own vector or matrix code!
+1 -66
View File
@@ -4,16 +4,10 @@ by first name.
If you know of somebody that I missed or have corrections, please email:
lg@openimageio.org
* Aamir Raza
* Aaron Colwell
* Adam Mains
* Akihiro Yamasaki
* Alan Jones
* Alejandro Conty
* Alejandro Aguirre
* Aleksandr Motsjonov
* Alex Fuller
* Alex Guirre
* Alex Hughes
* Alex Schworer
* Alexander Kuleshov
@@ -25,16 +19,10 @@ lg@openimageio.org
* Aman Shah
* Ananth Garre
* Anders Langlands
* Andy Chan
* Anthony Roberts
* AngryLoki
* Angus Davis
* Ankit Sinha
* Anton Dukhovnikov
* Anthony Nemoff
* Aras Pranckevičius
* Arkady Shapkin
* Basile Fraboni
* Basileios Anastasatos
* Bastien Montagne
* Ben De Luca
@@ -43,39 +31,26 @@ lg@openimageio.org
* Blair Tennessy
* Blazej Floch
* Brad Smith
* Bram Stolk
* Brecht Van Lommel
* Brent Davis
* Brian Hall
* Brice Gros
* Campbell Barton
* Carine Touraille
* Carl Rand
* Cassian Andrei
* Chad Dombrova
* Changlin Hsieh
* Chaitanya Sharma
* Chris Crosetto
* Chris Foster
* Chris Hellmuth
* Chris Kulla
* Chris Whalen
* Christoph Willing
* Clément Champetier
* Cliff Stein
* Connie Chang
* Curtis Black
* D-Spirits
* Clément Champetier
* Dalai Felinto
* Dan Wexler
* Daniel Dresser
* Daniel Flehner Heen
* Daniel Wyatt
* Danielle Imogu
* Danny Greenstein
* Darby Johnston
* Dharshan Vishwanatha
* David Adler
* David Aguilar
* David Gordon
* Deepak Gopinath
@@ -83,27 +58,22 @@ lg@openimageio.org
* Dieter De Baets
* Dinko Galetik
* Dominik Bartkiewicz
* Dominik Wójt
* Don Olmstead
* Duncan Chan
* Dustin Rodrigues
* Edgar Velazquez-Armendariz
* Eloi Du Bois
* Elvic Liang
* Emil Dohne
* Fabien Castan
* Fabien Servant
* Fredrik Averpil
* Frédéric Devernay
* Gaurav Bansal
* Gerrard Tai
* Gerdya
* Ghislain Antony Vaillant
* Gonzalo Garramuño
* Gregor Mueckl
* Grégoire De Lillo
* Guillaume Chatelet
* Hannah Gulka
* Hanspeter Niederstrasser
* Harry Mallon
* Heiko Becker
@@ -112,23 +82,19 @@ lg@openimageio.org
* Imarz
* Irena Damsky
* Ismael Cortes
* Jackson Sun
* Jan Hettenkofer
* Jan Honsbrok
* Jens Lindgren
* Jep Hill
* Jeph Alapat
* Jeremy Retailleau
* Jeremy Rose
* Jeremy Selan
* Jesse Yurkovich
* Jim Hourihan
* Joachim Reichel
* Johannes Unterguggenberger
* John Burnett
* John Fea
* John Haddon
* Jonathan Brown
* Jonathan Hearn
* Jonathan Scruggs
* Joris Nijs
@@ -136,7 +102,6 @@ lg@openimageio.org
* Julien Enche
* Justin Israel
* Justina Mikonyte
* Kaarrot
* Kazuki Takahashi
* Kevin Brightwell
* Kimball Thurston
@@ -146,22 +111,17 @@ lg@openimageio.org
* LazyDodo
* Leonid Onokhov
* Leszek Godlewski
* Li Ji
* Lucas Panian
* Lucille Caillaud
* Lukas Schrangl
* Lukasz Maliszewski
* Luke Emrose
* Lumina Wang
* Luna Kim
* Lydia Zheng
* M Joonas Pihlaja
* Malcolm Humphreys
* Manuel Gamito
* Manuel Leonhardt
* Marcos Fajardo
* Marie Fetiveau
* Marta Feriani
* Mariusz Szczepanczyk
* Mark Boorer
* Mark Visser
@@ -169,8 +129,6 @@ lg@openimageio.org
* Matteo F. Vescovi
* Matthew E. Levine
* Max Liani
* Maxwell Iverson
* Mel Massadian
* Merwan Achibet
* Michael Cho
* Michael Oliver
@@ -188,21 +146,15 @@ lg@openimageio.org
* Noah Rahm (designer of our logo!)
* Northon Patrick
* Nuno Cardoso
* Oktay Comu
* Ole Gulbrandsen
* omcaif
* Ott Tinn
* Pascal Lecocq
* Patrick Hodoul
* Patrick Piché
* Paul Franz
* Paul Melis
* Paul Molodowitch
* Pavan Madduri
* Pavel Karneliuk
* Pete Larabell
* Peter Horvath
* Peter Kovář
* Philip Nemec
* Pino Toscano
* Povilas Kanapickas
@@ -215,23 +167,18 @@ lg@openimageio.org
* Robert Matusewicz
* Roeland Schoukens
* Roman Zulak
* Rui Chen
* Rui Li
* Russell Greene
* Ryen
* Saket Jalan
* Sam Richards
* Samuel Nicholas
* Scott Milner
* Scott Wilson
* Sebastian Elsner
* SebTV
* Seifeddine Dridi
* Sergey Sharybin
* Sergio Rojas
* Shane Ambler
* Shane Smith
* Shashvat K. Singh
* Simon Boorer
* Solomon Boulos
* SRHMorris
@@ -239,21 +186,15 @@ lg@openimageio.org
* Stefan Stavrev
* Thiago Ize
* Thomas Dinges
* Thomas Klausner
* Thomas Mansencal
* Till Dechent
* Tim D. Smith
* Tim Grant
* Todica Ionut
* Tom Knowles
* Troy James Sobotka
* Valery Angelique
* Vanessa Valderrama
* Vic P
* Vinod Khare
* Vishal Agrawal
* Vitor Franchi
* Vlad (Kuzmin) Erium
* Wayne Arnold
* Will Rosecrans
* William Krick
@@ -261,10 +202,4 @@ lg@openimageio.org
* Xo Wang
* Yang Yang
* Yann Lanthony
* Zach Lewis
* Ziad Khouri
* zomgrolf
<!-- SPDX-License-Identifier: CC-BY-4.0 -->
<!-- Copyright Contributors to the OpenImageIO Project. -->
+10 -13
View File
@@ -27,9 +27,9 @@ beyond the legal forms.
### How to Become a Contributor
* Review the coding standards and [contributing guidelines](CONTRIBUTING.md)
to ensure your contribution is in line with the project's coding and styling
guidelines.
* Review the coding standards and [contributing
guidelines](../CONTRIBUTING.md) to ensure your contribution is in line with
the project's coding and styling guidelines.
* Sign the Individual CLA, or if you are employed by an organization that
might have any claim to IP you create, have your organization sign the
@@ -79,9 +79,8 @@ request that the TSC restore them to active Committer status.
## Technical Steering Committee
The Technical Steering Committee (TSC) has final authority over this project.
As defined in the project [technical charter](https://github.com/AcademySoftwareFoundation/foundation/blob/main/project_charters/openimageio_charter.pdf), in
addition to committer activities, TSC responsibilities also include, but are
not limited to:
As defined in the project charter, in addition to committer activities, TSC
responsibilities also include, but are not limited to:
* Coordinating technical direction of the Project.
@@ -131,12 +130,13 @@ represents the project at all ASWF TAC meetings.
Current voting members of the TSC are:
* **Chair and TAC representative**: Daniel Greenstein - Sony Pictures Imageworks
* **Chair and TAC representative**: Daniel Greenstein - Sony Pictures Imageworks (possibly interim?)
* **Chief Architect**: Larry Gritz - Sony Pictures Imageworks
* Anton Dukhovnikov - Wētā Digital / Unity
* Jesse Yurkovich - Blender
* Joseph Goldstone - ARRI
* Luke Emrose - Animal Logic
* Lewis Wakeland - Disney TV Animation
* Luke Emrose - Animal Logic (interim?)
* Martin Davies - LAIKA
* Robin Rowe - Heroic Robots
* Thiago Ize - Autodesk
@@ -181,8 +181,8 @@ her absence. Meetings may also be streamed online where appropriate;
connection details will be posted to the oiio-dev mail list in advance of the
scheduled meeting.
The biweekly TSC meetings can be found on the [ASWF Calendar](https://calendar.openimageio.org),
just click on the OpenImageIO TSC meeting entries to get the Zoom link.
The biweekly TSC meetings can be found on the [ASWF Calendar](https://www.aswf.io/meeting-calendar),
just click on the OpenImageIO meeting entries to get the Zoom link.
Items are added to the TSC agenda which are considered contentious or are
modifications of governance, contribution policy, TSC membership, or release
@@ -213,6 +213,3 @@ Due to the challenges of scheduling a global meeting with participants in
several time zones, the TSC will seek to resolve as many agenda items as
possible outside of meetings on the public mailing list or through GitHub
issues, discussions, and pull requests.
Meeting notes (usually very brief) can be found at: https://docs.google.com/document/d/1quSh1K5U2jUDi3cB1eX84i9Y2p7r58w1fZMXM8rnH-w/
+134 -207
View File
@@ -14,81 +14,69 @@ NEW or CHANGED MINIMUM dependencies since the last major release are **bold**.
### Required dependencies -- OIIO will not build at all without these
* C++17 or higher (also builds with C++20, C++23, and C++26)
* The default build mode is C++17. This can be controlled by via the
CMake configuration flag: `-DCMAKE_CXX_STANDARD=20`, etc.
* Note that no matter which version you compile with internally,
OIIO's public APIs only require C++17 features.
* Compilers: gcc 9.3 - 15.2, clang 10 - 22, MSVS 2017 - 2026 (v19.14
and up), Intel OneAPI C++ compiler 2022+.
* CMake >= 3.18.2 (tested through 4.3)
* Imath >= 3.1 (tested through 3.2 and main)
* OpenEXR >= 3.1 (tested through 3.4 and main)
* libTIFF >= 4.0 (tested through 4.7 and master)
* OpenColorIO >= 2.3 (tested through 2.5 and main)
* libjpeg >= 8 (tested through jpeg9e), or libjpeg-turbo >= 2.1 (tested
through 3.1)
* zlib >= 1.2.7 (tested through 1.3.2)
* **[fmtlib](https://github.com/fmtlib/fmt) >= 9.0** (tested through 12.2 and master).
If not found at build time, this will be automatically downloaded and built.
* [Robin-map](https://github.com/Tessil/robin-map) (unknown minimum, tested
through 1.4, which is the recommended version). If not found at build time,
this will be automatically downloaded and built.
* C++14 (also builds with C++17, and C++20)
* The default build mode is C++14. This can be controlled by via the
CMake configuration flag: `-DCMAKE_CXX_STANDARD=17`, etc.
* Compilers: gcc 6.1 - 12.1, clang 3.4 - 16, MSVS 2017 - 2019,
Intel icc 17+, **Intel OneAPI C++ compiler 2022+**.
* CMake >= 3.12 (tested through 3.26)
* **OpenEXR/Imath >= 2.3** (recommended: 2.4 or higher; tested through 3.2 and main)
* libTIFF >= 3.9 (recommended: 4.0+; tested through 4.5)
* libjpeg >= 8, or libjpeg-turbo >= 1.1 (tested through jpeg9d and jpeg-turbo
2.1)
* Boost >= 1.53 (recommended: at least 1.66; tested through 1.81)
* [fmtlib](https://github.com/fmtlib/fmt) >= 6.1.2 (tested through 10.0). If
not found at build time, this will be automatically downloaded unless the
build sets `-DBUILD_MISSING_FMT=OFF`.
### Optional dependencies -- features may be disabled if not found
* If you are building the `iv` viewer (which will be disabled if any of
these are not found):
* Qt5 >= 5.6 (tested through 5.15) or Qt6 (tested through 6.11)
* Qt5 >= 5.6 (tested through 5.15) or Qt6 (tested through 6.4)
* OpenGL
* If you are building the Python bindings or running the testsuite:
* Python >= 3.9 (tested through 3.13).
* pybind11 >= 2.7 (tested through 3.0)
* NumPy (tested through 2.4.4)
* If you enable the optional nanobind (WIP) backend for source/CMake
builds (`OIIO_PYTHON_BINDINGS_BACKEND` is `nanobind` or `both`):
* nanobind discoverable by CMake, or installed in the active Python
environment so `python -m nanobind --cmake_dir` works
* If you want support for PNG files:
* libPNG >= 1.6.0 (tested though 1.6.56)
* Python >= 2.7 (tested against 2.7, 3.7, 3.8, 3.9, 3.10, 3.11)
* pybind11 >= 2.4.2 (Tested through 2.11. Note that pybind11 v2.10+ does
not support Python < 3.6.)
* NumPy
* If you want support for camera "RAW" formats:
* LibRaw >= 0.20 (tested though 0.22.0 and master)
* LibRaw >= 0.15 (tested 0.15 - 0.21.1; LibRaw >= 0.18 is necessary for
ACES support and much better recognition of camera metadata; if
building with C++17 or higher, LibRaw >= 0.20 is necessary)
* If you want support for a wide variety of video formats:
* ffmpeg >= 4.0 (tested through 8.1)
* ffmpeg >= 3.0 (tested through 6.0)
* If you want support for jpeg 2000 images:
* OpenJpeg >= 2.0 (tested through 2.5.4; we recommend 2.4 or higher
* OpenJpeg >= 2.0 (tested through 2.5; we recommend 2.4 or higher
for multithreading support)
* If you want support for OpenVDB files:
* OpenVDB >= 9.0 (tested through 13.0).
* OpenVDB >= 5.0 (tested through 10.0)
* If you want to use TBB as the thread pool:
* TBB >= 2018 (tested through 2021 and OneTBB)
* If you want support for converting to and from OpenCV data structures,
or for capturing images from a camera:
* OpenCV 4.x or 5.x (tested through 5.0)
* OpenCV 3.x, or 4.x (tested through 4.5)
* If you want support for GIF images:
* giflib >= 5.0 (tested through 6.1.2)
* giflib >= 4.1 (tested through 5.2; 5.0+ is strongly recommended for
stability and thread safety)
* If you want support for HEIF/HEIC or AVIF images:
* libheif >= 1.11 (1.16 required for correct orientation support and
1.17 required for monochrome HEIC support; tested through 1.22.0)
* libheif >= 1.3 (1.7 required for AVIF support, tested through 1.16)
* libheif must be built with an AV1 encoder/decoder for AVIF support.
* Avoid libheif 1.10 on Mac, it is very broken. Libheif 1.11+ is fine.
* If you want support for DICOM medical image files:
* DCMTK >= 3.6.1 (tested through 3.7.0)
* DCMTK >= 3.6.1 (tested through 3.6.7)
* If you want support for WebP images:
* WebP >= 1.1 (tested through 1.6)
* WebP >= 0.6.1 (tested through 1.3.1)
* If you want support for OpenColorIO color transformations:
* OpenColorIO >= 1.1 (tested through 2.3; 2.0+ is recommended)
* If you want support for Ptex:
* Ptex >= 2.3.1 (probably works for older; tested through 2.5)
* Ptex >= 2.3.1 (probably works for older; tested through 2.4.2)
* If you want to be able to do font rendering into images:
* Freetype >= 2.10.0 (tested through 2.14)
* If you want to be able to read "ultra-HDR" embedded in JPEG files:
* libultrahdr >= 1.3 (tested through 1.4)
* If you want support for JPEG XL images:
* libjxl >= 0.10.1 (tested through 0.12.0)
* If you want support for j2c files:
* OpenJPH >= 0.21.2 (tested through 0.30)
* Freetype (minimum unknown, tested 2.8 through 2.13)
* We use PugiXML for XML parsing. There is a version embedded in the OIIO
tree, but if you want to use an external, system-installed version (as
may be required by some software distributions with policies against
embedding other projects), then just build with `-DUSE_EXTERNAL_PUGIXML=1`.
Any PugiXML >= 1.11 should be fine (we have tested through 1.16).
Any PugiXML >= 1.8 should be fine (we have tested through 1.13).
@@ -135,9 +123,6 @@ build options), maybe one of these packages managers will do it for you:
If these work for you and it's all you need, bingo! You are done.
You may find this guide to versions carried by distributions helpful:
[![OpenImageIO packaging status](https://repology.org/badge/vertical-allrepos/openimageio.svg?exclude_unsupported=1&columns=3&exclude_sources=modules,site&header=OpenImageIO%20packaging%20status)](https://repology.org/project/openimageio/versions)
Building from source
@@ -163,12 +148,6 @@ Make wrapper (`make PkgName_ROOT=...`).
`USE_PYTHON=0` : Omits building the Python bindings.
`OIIO_PYTHON_BINDINGS_BACKEND=pybind11|nanobind|both` : Select which Python
binding backend(s) to configure for source/CMake builds. `both` keeps the
existing pybind11 module and also builds the nanobind (WIP) module. The
Python packaging path driven by `pyproject.toml` still targets the production
pybind11 bindings today.
`OIIO_BUILD_TESTS=0` : Omits building tests (you probably don't need them
unless you are a developer of OIIO or want to verify that your build
passes all tests).
@@ -197,11 +176,11 @@ Building OpenImageIO on Linux or OS X
The following dependencies must be installed to build the core of
OpenImageIO:
* Boost
* libjpeg
* libtiff
* libpng
* Imath
* OpenEXR
* OpenEXR.
These can be installed using the standard package managers on your system.
Optionally, to build the image viewing tools, you will need Qt and OpenGL.
@@ -250,29 +229,28 @@ Make targets you should know about:
Additionally, a few helpful modifiers alter some build-time options:
| Target | Command |
| ----------------------------- | ------------------------------------------------------------------------- |
| make VERBOSE=1 ... | Show all compilation commands |
| make STOP_ON_WARNING=0 | Do not stop building if compiler warns |
| make EMBEDPLUGINS=0 ... | Don't compile the plugins into libOpenImageIO |
| make USE_OPENGL=0 ... | Skip anything that needs OpenGL |
| make USE_QT=0 ... | Skip anything that needs Qt |
| make MYCC=xx MYCXX=yy ... | Use custom compilers |
| make USE_PYTHON=0 ... | Don't build the Python binding |
| make OIIO_PYTHON_BINDINGS_BACKEND=both ... | For source/CMake builds, build the existing pybind11 bindings and the nanobind (WIP) module |
| make BUILD_SHARED_LIBS=0 | Build static library instead of shared |
| make IGNORE_HOMEBREWED_DEPS=1 | Ignore homebrew-managed dependencies |
| make LINKSTATIC=1 ... | Link with static external libraries when possible |
| make SOVERSION=nn ... | Include the specified major version number in the shared object metadata |
| make NAMESPACE=name | Wrap everything in another namespace |
| Target | Command |
| ------------------------- | ---------------------------------------------- |
| make VERBOSE=1 ... | Show all compilation commands |
| make STOP_ON_WARNING=0 | Do not stop building if compiler warns |
| make EMBEDPLUGINS=0 ... | Don't compile the plugins into libOpenImageIO |
| make USE_OPENGL=0 ... | Skip anything that needs OpenGL |
| make USE_QT=0 ... | Skip anything that needs Qt |
| make MYCC=xx MYCXX=yy ... | Use custom compilers |
| make USE_PYTHON=0 ... | Don't build the Python binding |
| make BUILD_SHARED_LIBS=0 | Build static library instead of shared |
| make LINKSTATIC=1 ... | Link with static external libraries when possible |
| make SOVERSION=nn ... | Include the specified major version number in the shared object metadata |
| make NAMESPACE=name | Wrap everything in another namespace |
The command 'make help' will list all possible options.
You can also ignore the top level Makefile wrapper, and instead use
CMake directly:
cmake -B build -S .
cmake --build build --target install
mkdir build
cd build
cmake ..
If the compile stops because of warnings, try again with
@@ -281,9 +259,8 @@ If the compile stops because of warnings, try again with
or, if you are using CMake directly,
rm -rf build
cmake -B build -S . -DSTOP_ON_WARNING=0
cmake --build build --target install
cd build
cmake -DSTOP_ON_WARNING=0 ..
@@ -295,71 +272,73 @@ Building on Windows
You will need to have Git, CMake and Visual Studio installed.
The minimal set of dependencies for OIIO is: zlib, libTIFF, Imath, OpenEXR,
OpenColorIO, and libjpeg or libjpeg-turbo. If you have them built somewhere
then if you set the environment variable `CMAKE_PREFIX_PATH` to include those
areas so CMake will find them, the OpenImageIO build will find those pre-built
packages and use them. If you don't have them build, or are unsure, the
`OpenImageIO_BUILD_MISSING_DEPS=all` CMake option will cause the build process
to download the sources of those dependencies, build them, and use them.
The minimal set of dependencies for OIIO is: Boost, zlib, libTIFF, OpenEXR, and libjpeg or libjpeg-turbo. If you have them built somewhere then you skip
the section below, and will only have to point OIIO build process so their locations.
To build OpenImageIO, you first need to clone the OIIO repository
and check out the desired branch or tag:
* Boost: get the boost source archive, extract into `{BOOST_ROOT}`.
```
cd {BOOST_ROOT}
bootstrap
b2
```
* zlib: this will build it, and then delete the non-static library, so they don't get picked up:
```
cd {ZLIB_ROOT}
git clone https://github.com/madler/zlib .
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=. ..
cmake --build . --config Release --target install
del lib\zlib.lib
```
* libTIFF:
```
cd {TIFF_ROOT}
git clone https://gitlab.com/libtiff/libtiff.git .
cd build
cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF -DCMAKE_INSTALL_PREFIX=. ..
cmake --build . --target install
```
* libjpeg-turbo:
```
cd {JPEG_ROOT}
git clone https://github.com/libjpeg-turbo/libjpeg-turbo .
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release -DENABLE_SHARED=OFF -DCMAKE_INSTALL_PREFIX=. ..
cmake --build . --config Release --target install
```
* OpenEXR: you'll have to point it to your `{ZLIB_ROOT}` location from the above. If copy-pasting the multi-line command (with lines ending in `^`) into
cmd.exe prompt, make sure to copy all the lines at once.
```
cd {EXR_ROOT}
git clone https://github.com/AcademySoftwareFoundation/openexr .
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=dist ^
-DBUILD_TESTING=OFF -DBUILD_SHARED_LIBS=OFF -DOPENEXR_BUILD_TOOLS=OFF ^
-DOPENEXR_INSTALL_TOOLS=OFF -DOPENEXR_INSTALL_EXAMPLES=OFF ^
-DZLIB_ROOT={ZLIB_ROOT}\build ..
cmake --build . --target install --config Release
```
Now get the OIIO source and do one-time CMake configuration step. Replace `{*_ROOT}` below with folders where you have put the 3rd party
dependencies.
```
cd {OIIO_ROOT}
git clone https://github.com/AcademySoftwareFoundation/OpenImageIO .
git checkout release
git clone https://github.com/OpenImageIO/oiio .
mkdir build
cd build
cmake -DVERBOSE=ON -DCMAKE_BUILD_TYPE=Release ^
-DBoost_USE_STATIC_LIBS=ON -DBoost_NO_WARN_NEW_VERSIONS=ON -DBoost_ROOT={BOOST_ROOT} ^
-DZLIB_ROOT={ZLIB_ROOT}\build ^
-DTIFF_ROOT={TIFF_ROOT}\build ^
-DOpenEXR_ROOT={EXR_ROOT}\build\dist ^
-DImath_DIR={EXR_ROOT}\build\dist\lib\cmake\Imath ^
-DJPEG_ROOT={JPEG_ROOT}\build ^
-DUSE_PYTHON=0 -DUSE_QT=0 -DBUILD_SHARED_LIBS=0 -DLINKSTATIC=1 ..
```
OIIO_ROOT is the directory where you want to place the OIIO source code.
Note the `git checkout release` line. There are a few choices here:
- `release` - always will be the latest stable supported release, which is the
recommended choice for most users.
- `v3.0.3.0` - a specific release version, which is the recommended choice for
most users who want to use a specific version of OIIO. Note that this is
just an example, and by the time you are reading these instructions, it will
likely be out of date. Adjust the version number to match the one you want.
Note that `release` is a shortcut for the latest stable release, if you
aren't sure which version you want.
- `main` - the latest development version, which may be unstable, but is
probably what you want if you are a developer and are working on new
contributions to OIIO.
Next, you need to do the "cmake configure" step:
```
cmake -S . -B build -DOpenImageIO_BUILD_MISSING_DEPS=all ^
-DBUILD_SHARED_LIBS=0 -DLINKSTATIC=1
```
If that command succeeds, you can either do the full build and install
from the command line, or open the generated Visual Studio solution.
Note that you can speed up the build by disabling certain components if you
know you won't need them: Adding `-DUSE_PYTHON=0` to the command above will
skip building the Python bindings, `-DUSE_QT=0` will disable looking for and
using Qt (needed only for the `iv` viewer), and `-DOIIO_BUILD_TESTS=0` will
skip building certain unit tests (which you only need if you want to OIIO's
tests).
If you just want a one-step build/install from the command line, you can run:
```
cmake --build build --target install --config Release
```
and that will build the package and install it into the `{OIIO_ROOT/dist`
area. (If you instead wanted the install to end up elsewhere, the easiest way
is on the earlier config step, to add the option
`-DCMAKE_INSTALL_PREFIX=somewhere_else`.)
On the other hand, if you would prefer to open the generated Visual Studio
solution, the "cmake configure" will have produced
`{OIIO_ROOT}/build/OpenImageIO.sln` that can be opened in Visual Studio IDE.
Note that the solution will be only for the Intel x64 architecture only; and
will only target "min-spec" (SSE2) SIMD instruction set.
This will produce `{OIIO_ROOT}/build/OpenImageIO.sln` that can be opened in Visual Studio IDE. Note that the solution will be
only for the Intel x64 architecture only; and will only target "min-spec" (SSE2) SIMD instruction set.
Optional packages that OIIO can use (e.g. libpng, Qt) can be build and pointed to OIIO build process in a similar way.
@@ -386,81 +365,29 @@ produce a dynamic-linked version.
3. Execute the PowerShell command from where vcpkg is located in directory. ``vcpkg install openimageio``
**Note: Importing the OpenImageIO Python Module**
As of OpenImageIO 3.0.3.0, the default DLL-loading behavior for Python 3.8+ has changed.
If you've built OIIO from source and ``import OpenImageIO`` is throwing a ModuleNotFound exception, revert to the legacy DLL-loading behavior by setting environment variable
``OPENIMAGEIO_PYTHON_LOAD_DLLS_FROM_PATH=1``.
Python-based Builds and Installs
--------------------------------
**Installing from prebuilt binary distributions**
If you're only interested in the Python module and the CLI tools, you can install with `pip` or `uv`:
> ```pip install OpenImageIO```
**Building and installing from source**
If you have a C++ compiler installed, you can also use the Python build-backend to compile and install
from source by navigating to the root of the repository and running: ```pip install .```
This will download and install CMake and Ninja if necessary, and invoke the CMake build system; which,
in turn, will build missing dependencies, compile OIIO, and install the Python module, the libraries,
the headers, and the CLI tools to a platform-specific, Python-specific location.
See the [scikit-build-core docs](https://scikit-build-core.readthedocs.io/en/latest/configuration.html#configuring-cmake-arguments-and-defines)
for more information on customizing and overriding build-tool options and CMake arguments.
This repo contains python type stubs which are generated from `pybind11` signatures.
The workflow for releasing new stubs is as follows:
- Install [`uv`](https://docs.astral.sh/uv/getting-started/installation/) and `docker`
- Run `make pystubs` locally to generate updated stubs in `src/python/stubs/__init__.pyi`
- Run `make test-pystubs` locally to use mypy to test the stubs against the code in
the python testsuite.
- Commit the new stubs and push to Github
- In CI, the stubs will be included in the wheels built by `cibuildwheel`, as defined in `.github/wheel.yml`
- In CI, one of the `cibuildwheel` Github actions will rebuild the stubs to a
temp location and verify that they match what has been committed to the repo.
This step ensures that if changes to the C++ source code and bindings results
in a change to the stubs, developers are notified of the need to regenerate
the stubs, so that changes can be reviewed and the rules in `generate_stubs.py`
can be updated, if necessary.
Note that if you can't (or don't want to) build the stubs locally, you can
download an artifact containing the wheel and `__init__.pyi` file from any job
that fails the stub validation.
Test Images
-----------
There are several projects containing sets of sample images for testing
OpenImageIO.
We have yet another project containing a set of sample images for testing
OpenImageIO. We split test images into a separate project in order to make
the main source code tree smaller and simpler for people who don't need the
test suite.
They are kept separate in order to make the main source code
tree smaller and simpler for people who don't need the test suite.
Additionally, some of these packages are maintained outside the OpenImageIO
project by their respective organizations.
git clone https://github.com/OpenImageIO/oiio-images.git
| Download | Directory Placement | Notes |
| --- | --- | --- |
| git clone https://github.com/AcademySoftwareFoundation/OpenImageIO-images.git | `<path>/../oiio-images` | CMake will download if not present |
| git clone https://github.com/AcademySoftwareFoundation/openexr-images.git | `<path>/../openexr-images` | CMake will download if not present |
| http://www.cv.nrao.edu/fits/data/tests/ | `<path>/../fits-images` | Manual download required |
| https://www.itu.int/net/ITU-T/sigdb/speimage/ImageForm-s.aspx?val=10100803 | `<path>/../j2kp4files_v1_5` | Manual download required |
Where `<path>` is the location of the main `OpenImageIO` repository.
Also, there are collections of images for some of the file formats we
support, and make test expects them to also be present. To run full tests,
you will need to download and unpack the test image collections from:
* http://www.simplesystems.org/libtiff/images.html
* http://www.openexr.com/downloads.html
* http://www.itu.int/net/ITU-T/sigdb/speimage/ImageForm-s.aspx?val=10100803
* http://www.cv.nrao.edu/fits/data/tests/
These images should be placed in a sibling directory to the OpenImageIO
repository named oiio-testimages.
You do not need any of these packages in order to build or use
OpenImageIO. But if you are going to contribute to OpenImageIO
development, you probably want them, since it is required for executing
OpenImageIO's test suite (when you run "make test").
<!-- SPDX-License-Identifier: CC-BY-4.0 -->
<!-- Copyright Contributors to the OpenImageIO Project. -->
+27
View File
@@ -0,0 +1,27 @@
Copyright (c) 2008-present by Contributors to the OpenImageIO project.
All Rights Reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
3. Neither the name of the copyright holder nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+37 -21
View File
@@ -9,8 +9,8 @@
# Run 'make help' to list helpful targets.
#
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# SPDX-License-Identifier: BSD-3-Clause and Apache-2.0
# https://github.com/OpenImageIO/oiio
#########################################################################
@@ -18,6 +18,9 @@
working_dir := ${shell pwd}
# Figure out which architecture we're on
include ${working_dir}/src/make/detectplatform.mk
MY_MAKE_FLAGS ?=
MY_NINJA_FLAGS ?=
MY_CMAKE_FLAGS ?=
@@ -26,6 +29,14 @@ NINJA ?= ninja
CMAKE ?= cmake
CMAKE_BUILD_TYPE ?= Release
# Site-specific build instructions
OPENIMAGEIO_SITE ?= ${shell uname -n}
ifneq (${shell echo ${OPENIMAGEIO_SITE} | grep imageworks.com},)
include ${working_dir}/site/spi/Makefile-bits
endif
# Set up variables holding the names of platform-dependent directories --
# set these after evaluating site-specific instructions
build_dir ?= build
dist_dir ?= dist
@@ -34,11 +45,12 @@ INSTALL_PREFIX ?= ${working_dir}/${dist_dir}
VERBOSE ?= ${SHOWCOMMANDS}
ifneq (${VERBOSE},)
MY_MAKE_FLAGS += VERBOSE=${VERBOSE}
MY_CMAKE_FLAGS += -DVERBOSE:BOOL=${VERBOSE} --log-level=VERBOSE
MY_CMAKE_FLAGS += -DVERBOSE:BOOL=${VERBOSE}
ifneq (${VERBOSE},0)
MY_NINJA_FLAGS += -v
TEST_FLAGS += -V
endif
$(info OPENIMAGEIO_SITE = ${OPENIMAGEIO_SITE})
$(info dist_dir = ${dist_dir})
$(info INSTALL_PREFIX = ${INSTALL_PREFIX})
endif
@@ -79,6 +91,10 @@ ifneq (${OPENEXR_ROOT},)
MY_CMAKE_FLAGS += -DOPENEXR_ROOT:STRING=${OPENEXR_ROOT}
endif
ifneq (${ILMBASE_ROOT},)
MY_CMAKE_FLAGS += -DILMBASE_ROOT:STRING=${ILMBASE_ROOT}
endif
ifneq (${NUKE_VERSION},)
MY_CMAKE_FLAGS += -DNUKE_VERSION:STRING=${NUKE_VERSION}
endif
@@ -159,7 +175,7 @@ MY_CMAKE_FLAGS += -DTEX_BATCH_SIZE:STRING="${TEX_BATCH_SIZE}"
endif
ifneq (${TEST},)
TEST_FLAGS += -R '${TEST}'
TEST_FLAGS += -R ${TEST}
endif
ifneq (${USE_CCACHE},)
@@ -180,6 +196,10 @@ ifeq (${CODECOV},1)
MY_CMAKE_FLAGS += -DCODECOV:BOOL=${CODECOV}
endif
ifneq (${SANITIZE},)
MY_CMAKE_FLAGS += -DSANITIZE=${SANITIZE}
endif
ifneq (${CLANG_TIDY},)
MY_CMAKE_FLAGS += -DCLANG_TIDY:BOOL=1
endif
@@ -202,6 +222,11 @@ ifneq (${CLANG_FORMAT_EXCLUDES},)
MY_CMAKE_FLAGS += -DCLANG_FORMAT_EXCLUDES:STRING=${CLANG_FORMAT_EXCLUDES}
endif
ifneq (${BUILD_MISSING_DEPS},)
MY_CMAKE_FLAGS += -DBUILD_MISSING_DEPS:BOOL=${BUILD_MISSING_DEPS}
endif
#$(info MY_CMAKE_FLAGS = ${MY_CMAKE_FLAGS})
#$(info MY_MAKE_FLAGS = ${MY_MAKE_FLAGS})
@@ -243,18 +268,6 @@ build: config
${CMAKE} --build . --config ${CMAKE_BUILD_TYPE} \
)
# generate python stubs and add them to the repo
pystubs: config
@ ( cd ${build_dir} ; \
${CMAKE} --build . --config ${CMAKE_BUILD_TYPE} --target pystubs \
)
# run mypy on python tests to confirm the stubs are working
test-pystubs: pystubs
@ ( uv export --quiet --no-dev --no-build --no-emit-project --no-hashes -o ${build_dir}/requirements.txt ; \
uvx --with-requirements ${build_dir}/requirements.txt mypy==1.15.0 \
)
# 'make install' builds everthing and installs it in 'dist'.
# Suppress pointless output from docs installation.
install: build
@@ -293,7 +306,7 @@ test: build
@ ${CMAKE} -E cmake_echo_color --switch=$(COLOR) --cyan "Running tests ${TEST_FLAGS}..."
@ ( cd ${build_dir} ; \
PYTHONPATH=${PWD}/${build_dir}/lib/python/site-packages \
ctest ${TEST_FLAGS} \
ctest -E broken ${TEST_FLAGS} \
)
@ ( if [[ "${CODECOV}" == "1" ]] ; then \
cd ${build_dir} ; \
@@ -354,8 +367,9 @@ help:
@echo " C++ compiler and build process:"
@echo " VERBOSE=1 Show all compilation commands"
@echo " STOP_ON_WARNING=0 Do not stop building if compiler warns"
@echo " OPENIMAGEIO_SITE=xx Use custom site build mods"
@echo " MYCC=xx MYCXX=yy Use custom compilers"
@echo " CMAKE_CXX_STANDARD=20 C++ standard to build with (default is 17)"
@echo " CMAKE_CXX_STANDARD=14 C++ standard to build with (default is 14)"
@echo " USE_LIBCPLUSPLUS=1 For clang, use libc++"
@echo " GLIBCXX_USE_CXX11_ABI=1 For gcc, use the new string ABI"
@echo " EXTRA_CPP_ARGS= Additional args to the C++ command"
@@ -363,7 +377,7 @@ help:
@echo " USE_CCACHE=0 Disable ccache (even if available)"
@echo " UNITY=BATCH Do a 'Unity' build (BATCH or GROUP or nothing)"
@echo " CODECOV=1 Enable code coverage tests"
@echo " SANITIZE=name1,... Enable sanitizers (address, leak, thread, undefined)"
@echo " SANITIZE=name1,... Enable sanitizers (address, leak, thread)"
@echo " CLANG_TIDY=1 Run clang-tidy on all source (can be modified"
@echo " by CLANG_TIDY_ARGS=... and CLANG_TIDY_FIX=1"
@echo " CLANG_FORMAT_INCLUDES=... CLANG_FORMAT_EXCLUDES=..."
@@ -382,15 +396,16 @@ help:
@echo " LibRaw OpenColorIO OpenCV OpenGL OpenJpeg OpenVDB"
@echo " PTex R3DSDK TBB TIFF Webp"
@echo " Finding and Using Dependencies:"
@echo " BOOST_ROOT=path Custom Boost installation"
@echo " OPENEXR_ROOT=path Custom OpenEXR installation"
@echo " ILMBASE_ROOT=path Custom IlmBase installation"
@echo " USE_EXTERNAL_PUGIXML=1 Use the system PugiXML, not the one in OIIO"
@echo " USE_QT=0 Skip anything that needs Qt"
@echo " USE_PYTHON=0 Don't build the Python binding"
@echo " PYTHON_VERSION=3.9 Specify the Python version"
@echo " PYTHON_VERSION=2.6 Specify the Python version"
@echo " USE_NUKE=0 Don't build Nuke plugins"
@echo " Nuke_ROOT=path Custom Nuke installation"
@echo " NUKE_VERSION=ver Custom Nuke version"
@echo " IGNORE_HOMEBREWED_DEPS=1 Don't use dependencies installed by Homebrew"
@echo " OIIO build-time options:"
@echo " INSTALL_PREFIX=path Set installation prefix (default: ./${INSTALL_PREFIX})"
@echo " NAMESPACE=name Override namespace base name (default: OpenImageIO)"
@@ -403,6 +418,7 @@ help:
@echo " 0, sse2, sse3, ssse3, sse4.1, sse4.2, f16c,"
@echo " avx, avx2, avx512f)"
@echo " TEX_BATCH_SIZE=16 Override TextureSystem SIMD batch size"
@echo " BUILD_MISSING_DEPS=1 Try to download/build missing dependencies"
@echo " make test, extra options:"
@echo " TEST=regex Run only tests matching the regex"
@echo ""
+67 -93
View File
@@ -1,23 +1,15 @@
<!-- SPDX-License-Identifier: CC-BY-4.0 -->
<!-- Copyright Contributors to the OpenImageIO Project. -->
<p align="center">
<img src="ASWF/logos/openimageio-horizontal-gradient.png">
</p>
[![License](https://img.shields.io/badge/license-Apache2.0-blue.svg?style=flat-square)](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/LICENSE.md)
[![CI](https://github.com/AcademySoftwareFoundation/OpenImageIO/actions/workflows/ci.yml/badge.svg)](https://github.com/AcademySoftwareFoundation/OpenImageIO/actions/workflows/ci.yml)
[![License](https://img.shields.io/badge/license-Apache2.0-blue.svg?style=flat-square)](https://github.com/OpenImageIO/oiio/blob/master/LICENSE.md)
[![CI](https://github.com/OpenImageIO/oiio/actions/workflows/ci.yml/badge.svg)](https://github.com/OpenImageIO/oiio/actions/workflows/ci.yml)
[![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/2694/badge)](https://bestpractices.coreinfrastructure.org/projects/2694)
[![latest packaged version(s)](https://repology.org/badge/latest-versions/openimageio.svg)](https://repology.org/project/openimageio/versions)
Introduction
------------
**Mission statement**: OpenImageIO is a toolset for reading, writing, and
manipulating image files of any image file format relevant to VFX / animation
via a format-agnostic API with a feature set, scalability, and robustness
needed for feature film production.
The primary target audience for OIIO is VFX studios and developers of
tools such as renderers, compositors, viewers, and other image-related
software you'd find in a production pipeline.
@@ -37,7 +29,7 @@ OpenImageIO consists of:
plugin can be found at runtime.
* Plugins implementing I/O for several popular image file formats,
including TIFF, JPEG/JFIF, JPEG XL, OpenEXR, PNG, HDR/RGBE, ICO, BMP, Targa,
including TIFF, JPEG/JFIF, OpenEXR, PNG, HDR/RGBE, ICO, BMP, Targa,
JPEG-2000, RMan Zfile, FITS, DDS, Softimage PIC, PNM, DPX, Cineon,
IFF, OpenVDB, Ptex, Photoshop PSD, Wavefront RLA, SGI, WebP,
GIF, DICOM, HEIF/HEIC/AVIF, many "RAW" digital camera formats, and a variety
@@ -71,110 +63,92 @@ OpenImageIO consists of:
🏢 Project administration and Licensing
---------------------------------------
Licensing
---------
OpenImageIO is (c) Copyright Contributors to the OpenImageIO project.
For original code, we use the [Apache-2.0 license](LICENSE.md), and for
documentation, the [Creative Commons Attribution 4.0 Unported
License](http://creativecommons.org/licenses/by/4.0/). In 2023 we asked
historical users to [relicense](RELICENSING.md) from the original BSD-3-clause
license to Apache-2.0, and over 99.86% of lines of code have been relicensed
to Apache-2.0. A small amount of code incorporated into this repository from
other projects are covered by compatible [third-party open source
licenses](THIRD-PARTY.md).
OpenImageIO is distributed using primarily the Apache 2.0 license -- see the
[LICENSE.md](LICENSE.md) file for details. The documentation is licensed
under the [Creative Commons Attribution 4.0 Unported
License](http://creativecommons.org/licenses/by/4.0/). A small amount of code
imported from other projects, and also some pre-July-2023 code that has not
yet been relicensed under Apache-2.0, is covered by other compatible licenses
-- see [THIRD-PARTY](THIRD-PARTY.md) file for details.
The OpenImageIO project is part of the [Academy Software
Foundation](https://www.aswf.io/), a part of the Linux Foundation formed in
collaboration with the Academy of Motion Picture Arts and Sciences. The
[technical charter](https://github.com/AcademySoftwareFoundation/foundation/blob/main/project_charters/openimageio_charter.pdf) and [Project
Governance](GOVERNANCE.md) explain how the project is run, who makes
decisions, etc. Please be aware of our [Code of Conduct](CODE_OF_CONDUCT.md).
The plain English bottom line is that OpenImageIO is free, as well as
freely modifiable and redistributable (in both source and binary form).
You may use part or all of it in your own applications, whether
proprietary or open, free or commercial. Using it in a commercial or
proprietary application DOES NOT obligate you to pay us, or to use any
particular licensing terms in your own application.
Some code and resources are distributed along with OIIO that have highly
compatible, though slightly different, licenses (generally MIT or Apache).
See the PDF documentation Acknowledgements section, and the
[THIRD-PARTY](THIRD-PARTY.md) file for details.
💁 User Documentation
---------------------
Building and Installation
-------------------------
[OpenImageIO Documentation](https://docs.openimageio.org)
is the best place to start if you are interested in how to use OpenImageIO,
its APIs, its component programs (once they are built). There is also a [PDF
version](https://readthedocs.org/projects/openimageio/downloads/pdf/latest/).
Please read the [INSTALL.md](INSTALL.md) file for detailed instructions on
how to build and install OpenImageIO.
Additional resources:
- [User quick start](docs/QuickStart.md) is a quick example of using
OpenImageIO in Python, C++, and the command line.
- [Releases](https://github.com/AcademySoftwareFoundation/OpenImageIO/releases) -- see this for the latest release notes, also found in the [CHANGES.md](CHANGES.md) file.
If you build with `EMBEDPLUGINS=0`, remember that you need to set the
environment variable `OIIO_LIBRARY_PATH` to point to the 'lib' directory
where OpenImageIO is installed, or else it will not be able to find the
plugins.
👷 Building and installing OpenImageIO
--------------------------------------
- [Build and installation instructions](INSTALL.md) for OpenImageIO. Such
as it is. This could use some work, particularly for Windows.
Documentation
-------------
The primary user and programmer documentation can be found
on [openimageio.readthedocs.io](https://openimageio.readthedocs.io/en/latest/)
as html or as [PDF](https://readthedocs.org/projects/openimageio/downloads/pdf/latest/).
🚑 Contact & reporting problems
-------------------------------
Contact & reporting problems
----------------------------
Simple "how do I...", "I'm having trouble", or "is this a bug" questions are
best asked on the [oiio-dev developer mail
list](https://lists.aswf.io/g/oiio-dev). That's where the most people will see
it and potentially be able to answer your question quickly (more so than a GH
"issue"). For quick questions, you could also try the [ASWF
Slack](https://slack.aswf.io) `#openimageio` channel.
list](https://lists.aswf.io/g/oiio-dev).
That's where the most people will see it and potentially be able to answer
your question quickly (more so than a GH "issue").
A bug or build problem that you are relatively certain is a legit problem in
the code, and **for which you can give clear instructions for how to
reproduce**, should be [reported as
issues](https://github.com/AcademySoftwareFoundation/OpenImageIO/issues).
To report a security vulnerability that is serious enough that it should not
be discussed publicly until a patch is ready, please file a GitHub [security
advisory](https://github.com/AcademySoftwareFoundation/OpenImageIO/security/advisories/new).
Bugs, build problems, and discovered vulnerabilities that you are relatively
certain is a legit problem in the code, and for which you can give clear
instructions for how to reproduce, should be [reported as
issues](https://github.com/OpenImageIO/oiio/issues).
If confidentiality precludes a public question or issue, you may contact us
privately at [info@openimageio.org](mailto:info@openimageio.org), or for
security-related issues [security@openimageio.org](mailto:security@openimageio.org).
privately at [info@openimageio.org](info@openimageio.org), or for
security-related issues [security@openimageio.org](security@openimageio.org).
🔧 Contributing and developer documentation
-------------------------------------------
Contributing
------------
OpenImageIO welcomes code contributions, and [nearly 250 people](CREDITS.md)
OpenImageIO welcomes code contributions, and [nearly 200 people](CREDITS.md)
have done so over the years. We take code contributions via the usual GitHub
pull request (PR) mechanism.
* [Architecture overview](docs/dev/Architecture.md) is a high-level
description of the major classes and their relationships.
* [CONTRIBUTING](CONTRIBUTING.md) has detailed instructions about the
development process.
* [AI Policy](docs/dev/AI_Policy.md) decribes our policies on AI coding
assistance tools.
* [ROADMAP](docs/ROADMAP.md) is a high-level overview of the current
development priorities for the next annual release.
* [RELEASING](docs/dev/RELEASING.md) explains our policies and procedures for
making releases. We have a major, possibly-compatibility-breaking, release
annually in September/October, and minor bug fix and safe feature addition
release at the beginning of every month.
* [Building the docs](src/doc/Building_the_docs.md) has instructions for
building the documentation locally, which may be helpful if you are editing
the documentation in nontrivial ways and want to preview the appearance.
* Other developer documentation is in the [docs/dev](docs/dev) directory.
* You may also have luck learning a bit about the organization and
architecture of the project by reading the [DeepWiki Analysis of
OpenImageIO](https://deepwiki.com/AcademySoftwareFoundation/OpenImageIO).
But take it with a grain of salt -- like any LLM-generated summary, there
may be inaccuracies lurking.
pull request (PR) mechanism. Please see [CONTRIBUTING](CONTRIBUTING.md) for
detailed instructions.
☎️ Communications channels and additional resources
--------------------------------------------------
Web Resources
-------------
* [Main web page](http://www.openimageio.org)
* [GitHub project page](http://github.com/AcademySoftwareFoundation/OpenImageIO)
* [Developer mail list](https://lists.aswf.io/g/oiio-dev)
* [ASWF Slack](https://slack.aswf.io) (look for the `#openimageio` channel)
* Biweekly Technical Steering Committee (TSC) Zoom meetings are on the [ASWF
Calendar](https://calendar.openimageio.org) (click on the OpenImageIO
meeting entries, every second Monday, to get the Zoom link, anyone may join)
* Main web page: http://www.openimageio.org
* GitHub page: http://github.com/OpenImageIO/oiio
* Developer mail list subscriptions and archives:
https://lists.aswf.io/g/oiio-dev
* ASWF Slack: https://slack.aswf.io
(look for the `#openimageio` channel)
* Biweekly TSC meetings are on the ASWF Calendar: https://www.aswf.io/meeting-calendar/
(click on the OpenImageIO meeting entries, every second Monday, to get the Zoom link, anyone may join)
+352
View File
@@ -0,0 +1,352 @@
<!-- SPDX-License-Identifier: CC-BY-4.0 -->
<!-- Copyright Contributors to the OpenImageIO Project. -->
# Release Procedures for OpenImageIO
## Version nomenclature and release cadence
### The meaning of the version parts
Our release numbers are of the form `MAJOR.MINOR.PATCH.TWEAK`, and we follow
an almost-semantic-versioning scheme.
MAJOR changes are those that break backward-compatibility of the public APIs,
requiring existing application code to change their source code where it calls
OIIO API functions in order to compile and work correctly.
MINOR changes guarantee API backward-compatibility with prior releases that
have the same major number, but can introduce ABI or link incompatibilities.
Applications using OIIO need to be recompiled to move to a new minor release,
but should not need to change their source code. Minor releases are allowed
to drop support for sufficiently old compilers and dependencies.
PATCH changes guarantee both API and ABI/link backward-compatibility with
prior releases that have the same minor number. Features and new public API
calls may be added (thus deviating from strict semantic versioning), but only
if they preserve ABI/link compatibility. This means that standalone functions
or static methods may be added, but existing functions will not change their
parameters, and no new virtual methods or struct data layouts change for patch
releases (for classes in public header files). Application code can be
re-linked to a new patch release without needing to be recompiled. We also
guarantee that any compilers or dependencies supported for the first release
of a minor series will continue to be supported for all patches to that minor
series.
TWEAK changes are restricted to critical bug fixes or build breaks that do
not alter public APIs in any way.
### Cadence of releases
Major (arbitrarily incompatible) releases happen rarely, usually with multiple
years between them.
Minor (API backward-compatible) releases are scheduled annually, targeted at
late summer (SIGGRAPH time) to be in beta, and early autumn for a full
release.
Patch (API and ABI backward-compatible) releases are scheduled monthly,
usually aiming for the first day of each month.
Tweak (fully forward and backward compatible) releases are not regularly
scheduled, and only happen sporadically, when a critical fix is needed in
between scheduled patch releases.
### Things are different in "master"
The "master" branch is where ongoing development occurs without any
compatibility guarantees. We don't always know if the next year's release from
master will turn out to be major (API breaking) or minor (only ABI breaking).
Some studios or products need the most up-to-date enhancements, and thus tend
to build OIIO from the "master" branch rather than using tagged releases. For
these users, we try to set version numbers and occasionally tag in master, to
send a signal about which points in master seem safe to rely on various
compatibility levels. However, the rules are slightly different than we use
for releases.
In the "master" branch:
- TWEAK changes within "master" only guarantee ABI back-compatibility, but may
have additions or non-bug-fix behavior changes (akin to patch releases
within a release branch).
- PATCH changes within "master" are allowed to break ABI or API (changes that
would require minor or major releases, if they were not in "master").
- Beware of unmarked breaks in compatibility of commits in master that are
in between developer preview tags.
---
## Branch and tag names
**Branches** are places where commits containing new development may be added
(and thus the branch markers will move over time). Branch names obey the
following conventions:
- `master` is the area for arbitrary changes intended for the next year's
major or minor release.
- `dev-1.2` are the areas for staging additions to the next month's patch
release for the designated minor version series.
- `release` is a special branch marker that is always set to the latest tag of
the currently supported, stable release family. People can count on
"release" always being the latest stable release, whatever that may be at
the time.
**Tags** indicate releases or developer previews, and once a commit is
tagged, it is permanent and will never be moved. Tag names obey the following
conventions:
- `v1.2.3.4` is a specific public stable release, corresponding to official
major, minor, public, or tweak releases.
- `v1.2.3.4-alpha`, `v1.2.3.4-beta`, or `v1.2.3.4-RC1` are pre-releases for an
upcoming public stable release, at the alpha, beta, or release candidate
stages, respectively.
- `v1.2.3.4-dev` is a "developer preview" within "master." It is not an official
supported release, and while the numbering may indicate compatibility versus
other recent developer previews, they should not be assumed to be compatible
with any prior official stable releases.
*Very* occasionally, other branch or tag names (with custom suffixes or
different naming schemes) may be used for special purposes by particular
developers or users, but should not be considered reliable or permanent, and
in general should be ignored by anyone who didn't make the tag or branch.
---
## Release Procedures
### Soft freeze for monthly tweak releases:
We freely backport *safe*, non-ABI-breaking changes by cherry-picking them
from master to the supported branch continually throughout most of the month.
In the seven days before the new month, we do a "soft freeze" where only
important bug fixes are backported. Hold on to any other patches you wish to
backport until after the monthly patch release (i.e., save them for the next
month's release so you never have a release that contains changes that are
only a few days old, and therefore not as well tested). You may, of course,
continue to backport fixes to documentation or other non-code parts of the
project during this soft freeze.
### Branching for annual major/minor releases
By mid-June (about 1-2 months before the beta of a new annual big release),
you should branch and mark it as an alpha.
At the tip of "master", create a new branch named `dev-MAJOR.MINOR` that will
be the staging area for the next release.
Customarily, at that point we add a commit to master (but not to the new
dev-MAJ.MIN branch) that bumps master's version to the next minor level, to
avoid any confusion between builds from master versus what will be the next
release branch. This starts the divergence between master and the release
branch, and henceforth, any big or compatibility-breaking changes will only be
committed to master and not backported to the release branch. (Though we are
loose about this rule during the alpha period and allow continued breaking
changes in the alpha, but by the time we call it beta, we allow no more
breaking changes.) Also at this stage, the master branch's CHANGES.md should
have a heading added at the top for the *next* version.
### Prior to a release
1. Update CI dependencies: Ensure that the "latest" CI test specifies the
current releases of the dependencies and compilers (check their home
pages), and that the [INSTALL.md](../INSTALL.md) file correctly documents
the version ranges that we expect to work and that we actively test.
2. Release notes: [CHANGES.md](../CHANGES.md) should be updated to reflect
all the new features and fixes. Looking at the notes from older releases
should provide a good example of what we're aiming for.
- Patch and tweak releases can be brief one-line descriptions (often the
first line of the commit messages involved), presented in a single
section in either chronological or any other order that seems right.
- Minor or major releases have a much more extensive, prose-based
description of all changes since the last minor release, broken into
sections (dependency changes, major new features, enhancements and fixes,
internals and developer goodies, testing/CI/ports, etc.) and ordered for
readability and relevance.
3. Ensure docs are up to date:
- Actually read the [README.md](README.md), [INSTALL.md](INSTALL.md),
and other repository docs and make sure all the information is up to
date. Check the [CREDITS.md](CREDITS.md) against the recent repo history
to be sure new contributors are listed.
- Skim the primary user documentation to look for any obvious errors,
especially the parts that describe new features.
- If we are using any online docs (like readthedocs), make sure it is
building and looks correct on the web site.
4. Make sure the the top-level CMakeLists.txt file is updated:
- The `OpenImageIO_VERSION` should be correct.
- The `PROJECT_VERSION_RELEASE_TYPE` variable should be set to "alpha" or
"beta" if appropriate, "RC" for release candidate, or empty string `""`
for most supported releases, and "dev" only for the master branch or
developer previews.
- The `${PROJECT_NAME}_SUPPORTED_RELEASE` variable should be `ON` for any
release branch, `OFF` for master.
5. In the https://github.com/OpenImageIO/oiio-images project, create a branch
`RB-x.y` for the major/minor branch, and in the main oiio repo, update
src/build-scripts/install_test_images.bash to specify `-b RB-x.y` in the
checkout of oiio-images to ensure CI tests are against the set of test
images corresponding to that major/minor release (just in the branch, not
in master!).
6. Make sure everything passes the usual CI workflow. Also check the daily or
weekly "analysis" workflows to make sure there aren't any important
warnings that should be fixed.
### Staging alpha / beta / release candidate (annual minor/major releases only)
For monthly patch releases, we don't have any formal alpha/beta/RC stages.
For the annual minor or major releases we have a staged release:
- `alpha` is everything after we have branched, in which we think all the big
new features have been added, and while we will make continued changes and
fixes, we are aiming for increased stability and to minimize additional
breaking changes prior to the release.
- `beta` should be about one month prior to the final release date. We create
a tag `v1.2.3.4-beta` and announce the beta (see below "Making the
release"). Once we tag a beta, we try very hard not to allow any further
changes that change the API or are not ABI-compatible (i.e., safe fixes
only).
- `RC` or release candidates around one week prior to the final release date.
This is a trial run, hopefully identical to the final release (except for
removing the RC label and making a new tag). The only changes allowed after
RC are fixes to the most critical bugs or build breaks that would be bad for
users to encounter. If critical problems are found with RC1, they should be
fixed and immediately re-tagged as RC2, etc. All other fixes should be
postponed until the next month's patch release.
### Making the release
A final release is made on the scheduled date, provided the latest RC has
survived for at least a few days of testing without finding any critical
problems. Don't make the release final until you are sure there are no
truly critical bugs or build breaks that users will encounter.
The following are the steps for making the release:
1. Edit the top-level CMakeLists.txt to remove any RC designation
(i.e., `PROJECT_VERSION_RELEASE_TYPE` should be set to `""`).
2. Edit CHANGES.md to reflect the correct date of the release and ensure it
includes any last-minute changes that were made during beta or release
candidate stages.
3. Push it to **your** GitHub, make sure it passes CI.
4. Tag the release: `git tag v1.2.3.4` (no more beta, RC, or dev suffix).
5. If this will now be the recommended stable release, move the `release`
branch marker to the same position.
6. Push it to GitHub: `git push OpenImageIO release --tags`
(This example assumes "OpenImageIO" is the name of the remote for the
GitHub `OpenImageIO/oiio` repo.)
7. Draft a release on GitHub: On https://github.com/OpenImageIO/oiio/releases
select "Draft a new release." Choose the new tag you just pushed. Make the
release title "OpenImageIO v1.2.3.4" (and beta, etc., designation
if applicable). In the description, paste the release notes for this
release (from CHANGES.md). If this is a beta or release candidate, check
"this is a pre-release" box at the bottom.
8. Announce the release on the [oiio-dev mail list](https://lists.aswf.io/g/oiio-dev)
with the subject "Release: OpenImageIO v1.2.3.4" and using one of these
templates for the body of the email.
For a monthly patch release:
> We have tagged v1.2.3.4 as the latest production release and moved the
> "release" branch marker to that point. This is guaranteed to be API,
> ABI, and link back-compatible with prior 1.2 releases. Release notes
> are below.
>
> (Paste the full set of 1.2 changes here, just copy the appropriate
> part of CHANGES.md)
For an annual major/minor release:
> OpenImageIO version 1.2 has been released! Officially tagged as
> "v1.2.3.4", we have also moved the "release" branch tag to this
> position. Henceforth, 1.2 is the supported production release family.
> The API is now frozen -- we promise that subsequent 1.2.x releases
> (which should happen monthly) will not break back-compatibility of API,
> ABI, or linkage, compared to this release. Please note that this release
> is *not* ABI or link compatible with 1.1 or older releases.
>
> Release notes for 1.2 outlining all the changes since last year's
> release are below.
>
> Please note that a few of the build and runtime dependencies have
> changed their minimum supported versions. (List here any important
> changes to dependencies, compilers, or C++ standard that users should be
> aware of.)
>
> (List here anything else that people should know about this release
> family that may be surprising if they haven't followed the last year of
> development closely, or that they must know even if they are too lazy to
> read the release notes. If this is a major release that is not
> backward-compatible with prior versions, warn about that here.)
>
> Enjoy, and please report any problems. We will continue to make patch
> releases to the 1.2 family roughly monthly, which will contain bug fixes
> and non-breaking enhancements.
>
> The older 1.1 series of releases is now considered obsolete. We will
> continue for now to make 1.1 patch releases, but over time, these will
> become less frequent and be reserved for only the most critical bug
> fixes.
>
> The "master" branch is now progressing toward an eventual 1.3 release next
> summer. As usual, you are welcome to use master for real work, but we do
> not make any compatibility guarantees and don't guarantee continuing API
> compatibility in master.
>
> (Paste the full set of 1.2 changes here, just copy the appropriate
> part of CHANGES.md)
For a beta leading up to the annual major/minor release:
> OpenImageIO version 1.2 is now in beta, tagged as "v1.2.3.4-beta". We
> will try very hard not to make any further API or ABI changes between
> now and the final release (unless it is absolutely necessary to fix
> an important problem identified during beta testing). The final 1.2
> release is scheduled for [DATE GOES HERE], so please try building and
> testing the beta so we are sure to find any problems.
>
> Release notes for 1.2 outlining all the changes since last year's
> release are below.
>
> (Paste the full set of 1.2 changes here, just copy the appropriate
> part of CHANGES.md)
### After the release
Odds and ends to do after the tag is pushed and the announcements are sent:
- Re-read RELEASING.md and ensure that the instructions match what you
have done. Update as necessary.
- Go to readthedocs.org, and ensure that the new release is built and visible
and is the default release shown (specified in the Admin section). I tend to
keep the latest patch of each minor release available for reference
indefinitely, but hide the docs for earlier patch releases within that minor
release series.
- Edit the top-level CMakeList.txt to update the version to the *next*
anticipated release on the branch, in order to ensure that anybody building
from subsequent patches won't get a release number that advertises itself
incorrectly as a prior tagged release. Also edit CHANGES.md to add a new
(blank) heading for the next patch or release.
+3 -32
View File
@@ -1,15 +1,8 @@
<!-- SPDX-License-Identifier: CC-BY-4.0 -->
<!-- Copyright Contributors to the OpenImageIO Project. -->
New code entering the OpenImageIO repository from July 1 2023 onward is
subject to the [Apache 2.0 license](LICENSE.md).
Code dating from earlier than July 1 2023 was contributed under the [BSD
3-clause license](https://opensource.org/license/bsd-3-clause), unless
relicensed below.
Stragglers who haven't relicensed yet, it's never too late, just sign onto the
PR: https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/3905
3-clause license](LICENSE-BSD-3-Clause.md), unless relicensed below.
The following copyright holders agree that all of their contributions
originally submitted to this project under the 3-Clause BSD License are hereby
@@ -126,31 +119,9 @@ the Developer Certificate of Origin, version 1.1:
- johnfea
- Max Liani (maxliani)
- Michael Görner (v4hn)
- Philip Nemec (p-nemec)
- Google
- Nandan Dubey (ndubey)
- NVIDIA
- Jonathan Hearn (splidje)
- Michael Root
- Ott Tinn
- Lukas Shrangl (luhk)
- Manuel Gamito (mgamito)
- Rémi Achard (remia)
- Joseph Goldstone (JGoldstone)
- Matthew Levine (melevine)
- Yang Yang (yangyangl, but now cometyang)
- Merwan Achibet (merwaaan)
- Anthony Nemoff (ix-anemoff)
- Damien Courtois (ix-dcourtois)
- Carl Rand (crand)
- Gregor Mückl (gmueckl)
- Jep Hill (jephill)
- John Haddon (johnhaddon)
...
**Prior authors, please follow the directions for adding your name to
[this PR](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/3905).
If, at the time of your prior contributions, you were employed by a
**Prior authors, please submit a PR against this file that adds your name
above. If, at the time of your prior contributions, you were employed by a
company who would have owned your IP output, then please have someone from
that company who is authorized to do so submit a PR to add their company’s
name to the list under the statement in this file.**
+10 -123
View File
@@ -7,132 +7,19 @@ security vulnerabilities.
| Version / branch | Supported |
| ----------------- | ---------------------------------------------------- |
| main | :white_check_mark: :construction: ALL fixes immediately, but this is a branch under development with a frequently unstable ABI and occasionally unstable API. |
| 3.1.x | :white_check_mark: All fixes that can be backported without breaking ABI compatibility. New tagged releases monthly. |
| 3.0.x | :warning: Important fixes that can be easily backported without breaking ABI compatibility. New tagged releases as needed, and becoming less frequent over time. |
| <= 2.5.x | :x: No longer receiving patches of any kind. |
| master | :white_check_mark: :construction: ALL fixes immediately, but this is a branch under development with a frequently unstable ABI and occasionally unstable API. |
| 2.4.x | :white_check_mark: All fixes that can be backported without breaking ABI compatibility. New tagged releases monthly. |
| 2.3.x | :x: Only receives occasional critical fixes, upon request. |
| <= 2.2.x | :x: No longer receiving patches of any kind. |
## Reporting a Vulnerability
If you think you've found a potential vulnerability in OpenImageIO, please
report it to the maintainers. Include detailed steps to reproduce the issue,
and any other information that could aid an investigation.
report it by emailing security@openimageio.org. Only the project administrators
have access to these messages. Include detailed steps to reproduce the issue,
and any other information that could aid an investigation. Our policy is to
respond to vulnerability reports within 14 days.
The best way to report a vulnerability is to file a GitHub [security
advisory](https://github.com/AcademySoftwareFoundation/OpenImageIO/security/advisories/new).
If that is not possible, it is also fine to email your report to
security@openimageio.org. Only the project administrators have access to these
reports.
Our policy is to respond to vulnerability reports within 14 days, and to
address critical security vulnerabilities rapidly and post patches quickly,
usually at the next scheduled patch release at the beginning of every month.
For especially severe vulnerabilities, or when a flaw is believed to be
exploited in the wild, we will try to make a special patch release as soon as
possible.
## What do we consider a vulnerability?
A true vulnerability, by our definition, requires the following:
- It allows arbitrary code execution, privilege escalation, exfiltration of
secrets beyond network boundaries, destruction of data or equipment, or
similarly serious outcome.
- It can be plausibly exploited by an untrusted party through normal product
inputs (for example, a maliciously crafted input image).
We would like to hear about these through the confidential GitHub
vulnerability reporting mechanism described above.
The following are examples of problems that we DO NOT consider
vulnerabilities:
- A crash or program termination that does not directly present the
opportunity for further exploits. This includes hardening assertions that
terminate the program rather than allow undefined behavior.
- Out-of-memory errors, as long as the program terminates in a reasonable
amount of time. (But if a tiny crafted input can make it loop infinitely or
spin for minutes, then it might qualify as a DOS vulnerability. Use your
best judgment.)
- Misuse or incorrect use of the APIs. We consider all programs directly using
OIIO's APIs to be trusted.
- Flaws whose root cause lies in a dependency. These should be reported and
fixed upstream; the upstream project owns the CVE when one is warranted.
Please do not use the GitHub vulnerability reporting mechanism for these, and
instead file ordinary Issues and PRs. We do not support requesting a CVE for
these kinds of problems.
Users operating in an environment in which it might encounter untrusted inputs
that could be malicious, and are be running in a situation where real damage
could occur are expected to:
- Enable all the OpenImageIO build-time options for safety checks, hardening,
etc. A problem that only occurs when these are disabled is not considered a
vulnerability.
- Ensure that all the dependencies OIIO builds against are on their latest
patched versions, and not rely on the OS distribution default, or even
OIIO's own "dependency auto-build" scripts. A problem that depends on
having anything but the lastest dependencies is not an OIIO vulnerbility.
## Other security features
### Signed tags
Starting with OpenImageIO 3.0, we cryptographically sign release tags.
To verify a tag, you can use the `git tag -v` command, which will check
the signature against the public key that is included in the repository.
For example,
```bash
git tag -v v3.0.0.3
```
## Outstanding Security Issues
None known
## History of CVE Fixes
Most recent fixes listed first, more or less:
- CVE-2026-63638: Cineon invalid bit depth heap out-of-bounds write [advisory](https://github.com/AcademySoftwareFoundation/OpenImageIO/security/advisories/GHSA-9hxv-jvgr-3x8g) / [Fix: PR #5283](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/5283) (fixed in 3.1.16.0)
- CVE-2026-63635: PSD RawColor invalid color mode causes global out-of-bounds read and allocation DoS [advisory](https://github.com/AcademySoftwareFoundation/OpenImageIO/security/advisories/GHSA-3c8w-9xvm-r6gf) / [Fix: PR #5282](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/5282) (fixed in 3.1.16.0)
- CVE-2026-63635: PSD RawColor invalid color mode causes global out-of-bounds read and allocation DoS [advisory](https://github.com/AcademySoftwareFoundation/OpenImageIO/security/advisories/GHSA-3c8w-9xvm-r6gf) / [Fix: PR #5282, 3.1.16.0](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/5282) (fixed in 3.1.16.0)
- CVE-2026-63422 OpenEXR plugin partial edge tile heap out-of-bounds write [advisory](https://github.com/AcademySoftwareFoundation/OpenImageIO/security/advisories/GHSA-xh5r-whph-qmc5) / [Fix: PR #5295](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/5295) (fixed in 3.1.16.0)
- CVE-2026-63420: PSD RawColor indexed image out-of-bounds read in `interleave_row` [advisory](https://github.com/AcademySoftwareFoundation/OpenImageIO/security/advisories/GHSA-x877-h4xx-5m5j) / [Fix: PR #5307](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/5307) (fixed in 3.1.16.0)
- CVE-2026-63419: OpenImageIO IFF ZBUFFER tile read writes past caller tile buffer [advisory](https://github.com/AcademySoftwareFoundation/OpenImageIO/security/advisories/GHSA-w6wc-gcf4-5pj2) / [Fix: PR #5268](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/5268) (fixed in 3.1.16.0)
- CVE-2026-59956: Heap-buffer-overread in IffInput::readimg() when ZBUFFER flag is set [advisory](https://github.com/AcademySoftwareFoundation/OpenImageIO/security/advisories/GHSA-hjfv-gvxc-qgvh) / [Fix: PR #5251](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/5251) (fixed in 3.0.20.0, 3.1.15.0)
- CVE-2026-59181: Stack buffer overflow in OpenImageIO Cineon reader via unchecked numberOfElements [advisory](https://github.com/AcademySoftwareFoundation/OpenImageIO/security/advisories/GHSA-xh8r-vmqq-56pp) / [Fix: PR #5250](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/5250) (fixed in 3.0.20.0, 3.1.15.0)
- CVE-2026-59156: Unbounded recursion in FITS header parser leads to stack overflow [advisory](https://github.com/AcademySoftwareFoundation/OpenImageIO/security/advisories/GHSA-xvwr-x6ch-v2fq) / [Fix: PR #5248](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/5248) (fixed in 3.0.20.0, >= 3.1.15.0)
- CVE-2026-50291: Segmentation Fault in BmpInput::read_native_scanline / [advisory](https://github.com/AcademySoftwareFoundation/OpenImageIO/security/advisories/GHSA-q3c7-3225-66h7) / [Fix: PR #5030](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/5030) (Fixed in 3.0.16.0, 3.1.11.0)
- CVE-2026-43909: Signed integer overflow in SwapRGBABytes loop index leads to out-of-bounds read/write in DPX ABGR decoder / [advisory](https://github.com/AcademySoftwareFoundation/OpenImageIO/security/advisories/GHSA-g267-j53j-5258) / [Fix: PR5170](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/5170) (Fixed in 3.0.18.1, 3.1.13.1)
- CVE-2026-43908: Signed integer overflow in ConvertCbYCrYToRGB leads to heap out-of-bounds write in DPX 4:2:2 decoder / [advisory](https://github.com/AcademySoftwareFoundation/OpenImageIO/security/advisories/GHSA-2jr5-q49v-3858) / [Fix: PR5170](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/5170) (Fixed in 3.0.18.1, 3.1.13.1)
- CVE-2026-43907: Integer overflow in QueryRGBBufferSizeInternal leads to heap out-of-bounds write in DPX decoder (kCbYCr and kABGR) / [advisory](https://github.com/AcademySoftwareFoundation/OpenImageIO/security/advisories/GHSA-cq46-hp4h-cvfr) / [Fix: PR5170](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/5170) (Fixed in 3.0.18.1, 3.1.13.1)
- CVE-2026-43996: Integer wraparound in bounds check of decode_pixel leads to out-of-bounds read in TGA paletted image decoder / [advisory](https://github.com/AcademySoftwareFoundation/OpenImageIO/security/advisories/GHSA-mq8j-73c4-cr55) / [Fix: PR5165](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/5165) (Fixed in 3.2.0.1, 3.1.13.0, 3.0.18.0)
- CVE-2026-43906: HEIF Heap overflow / [advisory](https://github.com/AcademySoftwareFoundation/OpenImageIO/security/advisories/GHSA-gmrp-x952-3m66) / [Fix: PR5166](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/5166) (Fixed in 3.2.0.1, 3.1.13.0, 3.0.18.0)
- CVE-2026-43905: JPEG2000 (OpenJPH) signed integer overflow in buffer allocation / [advisory](https://github.com/AcademySoftwareFoundation/OpenImageIO/security/advisories/GHSA-pj45-cf3g-28gq) / [Fix: PR5143](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/5143) (Fixed in 3.2.0.1, 3.1.13.0, 3.0.18.0)
- CVE-2026-43904: Softimage PIC RLE decoder heap buffer overflow — longCount not clamped to image width / [advisory](https://github.com/AcademySoftwareFoundation/OpenImageIO/security/advisories/GHSA-4499-j545-7q33) / [Fix: PR5142](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/5142) (Fixed in 3.2.0.1, 3.1.13.0, 3.0.18.0)
- CVE-2026-43903: SGI RLE decoder heap buffer overflow — OIIO_DASSERT bounds checks are no-ops in release builds / [advisory](https://github.com/AcademySoftwareFoundation/OpenImageIO/security/advisories/GHSA-jg3q-vm3q-2j35) / [#5141](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/5141) (Fixed in 3.2.0.1, 3.1.13.0, 3.0.18.0)
- CVE-2026-7582: DDS Image ddsinput.cpp out-of-bounds write / [advisory](https://github.com/AcademySoftwareFoundation/OpenImageIO/security/advisories/GHSA-5pm7-8r3j-2x67). [Fix: #5131](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/5131) (Fixed in 3.2.0.1, 3.1.13.0, 3.0.18.0)
- CVE-2024-55194: Broken pgm had memory access error leading to heap overflow / [advisory](https://github.com/AcademySoftwareFoundation/OpenImageIO/security/advisories/GHSA-583r-43f7-cw8w) / [#4559](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4559) (Fixed in 3.0.2.0, 3.1.4.0)
- CVE-2024-40630: Fixed incorrect image size for certain HEIC files.
[advisory](https://github.com/AcademySoftwareFoundation/OpenImageIO/security/advisories/GHSA-jjm9-9m4m-c8p2) (Fixed in 2.5.13.1)
- CVE-2023-42295: Fix signed integer overflow when computing total number of pixels while reading BMP files. [#3948](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/3948) (by xiaoxiaoafeifei) (Fixed in 2.5.3.0/2.6.0.1)
- CVE-2023-36183: Heap-buffer-overflow while reading ICO files [#3872](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/3872) (by xiaoxiaoafeifei)
- TALOS-2023-1709 / CVE-2023-24472: Race condition in TIFF reader. [#3772](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/3772) (2.5.1.0/2.4.8.1)
- TALOS-2023-1707 / CVE-2023-24473, TALOS-2023-1708 / CVE-2023-22845: Guard against corrupted Targa. [#3768](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/3768) (2.5.1.0/2.4.8.1)
- TALOS-2022-1654 / CVE-2022-43596, TALOS-2022-1655 / CVE-2022-43597 CVE-2022-43598, TALOS-2022-1656 / CVE-2022-43599 CVE-2022-43600 CVE-2022-43601 CVE-2022-43602: Fix possible IFF write errors [#3676](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/3676) (2.4.6/2.5.0.0)
- TALOS-2022-1653 / CVE-2022-43594: Fix possible errors when writing BMP files. [#3673](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/3673) (by lgritz) (2.4.6/2.5.0.0)
- TALOS-2022-1651 / CVE-2022-43592, TALOS-2022-1652 / CVE-2022-4359: Fix possible DPX write errors. [#3672](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/3672) (2.4.6/2.5.0.0)
- TALOS-2022-1657 / CVE-2022-43603: Zfile write safety. [#3670](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/3670) (2.4.6/2.5.0.0)
- TALOS-2022-1633 / CVE-2022-41639, TALOS-2022-1643 / CVE-2022-41988: Guard TIFF against buffer overflow for certain CMYK files. [#3632](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/3632) (2.4.5/2.5.0.0)
- TALOS-2022-1626, CVE-2022-41794: PSD files protect against corrupted embedded thumbnails. [#3629](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/3629) (2.4.5/2.5.0.0)
- TALOS-2022-1627, CVE-2022-41977: Guard TIFF reads against corrupt files with buffer overflows. [#3628](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/3628) (2.4.5/2.5.0.0)
- TALOS-2022-1626 / CVE-2022-41794, TALOS-2022-1632 / CVE-2022-41684, TALOS-2022-1636 / CVE-2022-41837: Exif (all formats that support it, TIFF/JPEG/PSD) fix bugs where corrupted Exif blocks could overrun memory. [#3627](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/3627) (2.4.5/2.5.0.0)
- TALOS-2022-1634 / CVE-2022-41838, TALOS-2022-1635 / CVE-2022-41999: Fix DDS reading crashes for cubemap files when a cube face was not present, and check for invalid bits per pixel. [#3625](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/3625) (2.4.5/2.5.0.0) #3625 (2.4.5/2.5.0.0)
- TALOS-2022-1629, CVE-2022-36354: RLA potential buffer overrun. [#3624](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/3624) (2.4.5/2.5.0.0)
- TALOS-2022-1628, CVE-2022-41981: Targa file string overflow safety. [#3622](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/3622) (2.4.5/2.5.0.0)
- TALOS-2022-1630, CVE-2022-38143: Protect against corrupt pixel coordinates while reading BMP files. [#3620](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/3620) (by lgritz) (Fixed in 2.4.5/2.5.0.0)
<!-- - CVE-xxx: description [advisory](https://github.com/AcademySoftwareFoundation/OpenImageIO/security/advisories/GHSA-yyy) / [Fix: PR #nnnn](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/nnnn)
-->
Our policy is to address critical security vulnerabilities rapidly and post
patches as quickly as possible.
+4 -12
View File
@@ -9,15 +9,15 @@ In no particular order:
-------------------------------------------------------------------------
BSD 3-Clause License (https://opensource.org/license/bsd-3-clause)
BSD 3-Clause License
SPDX-License-Identifier: BSD-3-Clause
* OpenImageIO prior to July 1, 2023
Code that was contributed to OpenImageIO prior to July 1 2023, and has not
yet been [relicensed](RELICENSING.md), was contributed under the BSD
3-clause license. Currently, less than 0.15% of the codebase (by lines of
code) remains under this license.
yet been [relicensed](RELICENSING.md), was contributed under the [BSD
3-clause license](LICENSE-BSD.md). Currently, this is less than 2% of the
codebase (by lines of code).
* Gelato, Copyright (c) 2004 by NVIDIA Corp.
@@ -54,11 +54,6 @@ SPDX-License-Identifier: BSD-3-Clause
* FindOpenVDB.cmake (c) Copyright 2015 Blender Foundation, BSD license.
* Cryptomatte project, Copyright (c) 2014, 2015, 2016 Psyop Media Company,
LLC. https://github.com/Psyop/Cryptomatte
The test image in testsuite/cryptomatte/src/cryptoasset.exr is a small crop
of a sample image from the Cryptomatte project.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
@@ -179,9 +174,6 @@ SPDX-License-Identifier: Apache-2.0
This is licensed under the Apache 2.0 license with LLVM Exceptions.
https://llvm.org/docs/DeveloperPolicy.html#open-source-licensing-terms
* ninjatracing.py utility for build profiling is Apache-2.0 licensed
and comes from https://github.com/nico/ninjatracing.
Copyright 2018 Nico Weber.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
+1 -4
View File
@@ -1,12 +1,9 @@
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
[requires]
zlib/1.2.11
libtiff/4.0.9
libpng/1.6.37
openexr/2.4.0
boost/1.70.0
libjpeg/9c
libjpeg-turbo/2.0.2
giflib/5.1.4
-5143
View File
File diff suppressed because it is too large Load Diff
-286
View File
@@ -1,286 +0,0 @@
<!-- SPDX-License-Identifier: CC-BY-4.0 -->
<!-- Copyright Contributors to the OpenImageIO Project. -->
OpenImageIO 3.0 Deprecations
============================
For minor or patch releases, we try very hard to never fully remove
functionality that will force downstream applications using OpenImageIO to
change their source code. However, for major releases (e.g., 2.x -> 3.0),
which only occur once every several years, we allow removal of functionality.
OpenImageIO v3.0 is a major release that includes removal of many
long-deprecated API facets. This document lists the deprecations and removals.
NOTE: This is an in-progress document. Some things currently only warning
about being deprecated will be removed in the final 3.0 release.
### Glossary
- "Marked as deprecated" means that we consider an API facet to be obsolete,
and document it as such in the comments or documentation (or remove it from
the documentation).
- "Deprecation warning" means that a deprecated function is tagged with
attributes that should cause a compiler warning if the function is used. The
warning can be disabled by the downstream project, but it is recommended
that you fix the code to use the new API before it is permanently removed.
- "Removed" means that the deprecated API facet has been removed from the
library completely.
---
---
## argparse.h
* Several long-deprecated old method names now will give deprecation warnings
if used. Most notable are `parse()` (you should use `parse_args()` instead)
and `usage()` (use `print_help()` instead).
## array_view.h
* This header has been eliminated. It originally had the template `array_view`,
which many years ago was renamed `span<>` and lives in span.h, and since then
the array_view.h header has merely made an alias.
## bit.h
* The `bit_cast` template, which was deprecated and warned since 2.5, has been
removed. It was confusing because C++23 has a `std::bit_cast` that used the
reverse order of arguments. Users should instead use `std::bit_cast` (if
C++23) or the equivalent `OIIO::bitcast`.
* The `rotl32` and `rotl64` functions which have been marked as deprecated
since 2.1 now have deprecation warnings. Use `rotl` instead.
## benchmark.h
* The full `time_trial()` function now has deprecation warnings. Users should
generally use the `Benchmrker` class instead.
* The abbreviated `time_trial()` function (that lacks a `repeats` parameter
has been removed.
## color.h
* `ColorConfig::error()` now has a deprecation warning. Use
`ColorConfig::has_error()` instead.
* The versions of `createDisplayTransform()` that lack an `inverse` parameter
now have deprecation warnings. Use the version that takes an `inverse` bool.
## dassert.h
* Poorly named `ASSERT`, `DASSERT`, and `ASSERTMSG` macros have been removed.
They were deprecated since 2.1, since they could easily clash with macros
from other projects. Please instead use the `OIIO_ASSERT`, `OIIO_DASSERT`,
and `OIIO_ASSERT_MSG` macros.
## errorhandler.h
* All of the old methods that did printf-style formatting have been deprecated
(info/infof, warning/warningf, error/errorf, severe/severef,
message/messagef, debug/debugf). Instead, use infofmt, warningfmt, errorfmt,
severefmt, messagefmt, debugfmt, respectively, which all use the std::format
notation.
## imagebuf.h
* Add deprecation warnings to the varieties of ImageBuf constructor and
`reset()` that don't take subimage and miplevel parameters, which have been
marked as deprecated since OIIO 2.2. The equivalent is to just pass `0` for
both of those parameters.
* The misspelled `ImageBuf::make_writeable()` has been given deprecation
warnings. Since OIIO 2.2, we have used the correct spelling,
`make_writable`.
* The `ImageBuf::error()` method that uses printf-style formatting conventions
now has deprecation warnings. Use `ImageBuf::errorfmt()` instead.
* The `ImageBuf::interppixel_NDC_full()` method, which has been marked as
deprecated since OIIO 1.5, now has deprecation warnings. Use
`interppixel_NDC()` instead.
## imageio.h
* The global OIIO::attribute query "opencv_version" has been removed. The
libOpenImageIO library itself no longer has OpenCV as a dependency or links
against it. (However, the IBA functions involving OpenCV still exist and are
defined in `imagebufalgo_opencv.h` as inline functions, so it is up to the
application calling these API functions to find and link against OpenCV.)
* The old varieties of ImageInput::read_scanlines, read_tiles, and read_image
that did not take `subimage` and `miplevel` parameters, and were not
thread-safe, have been removed. These have been marked as deprecated since
OIIO 2.0.
* The type aliases ImageIOParameter and ImageIOParameterList, which have been
marked as deprecated since OIIO 2.0, have been removed. Use ParamValue and
ParamValueList instead.
* The utility functions convert_image and parallel_convert_image (the variety
that took alpha_channel and z_channel arguments) that have been deprecated
since OIIO 2.0 have been removed.
## imagebuf.h
* The style of ImageBuf constructor that "wraps" a caller-owned memory buffer
now has a new, preferred, version that takes a `span<>` or `cspan<>` instead
of a raw pointer. The old versions is considered deprecated.
* New span-based versions of get_pixels, set_pixels, setpixel, getpixel,
interppixel, interppixel_NDC, interppixel_bicubic, interppixel_bicubic_NDC.
These are preferred over the old versions that took raw pointers.
## imagebufalgo.h
* The old versions (deprecated since 2.0) of IBA::compare() and
computePixelStats() that took a reference to the CompareResults or
PixelStats structure now have deprecation warnings. Use the versions that
return the structure instead.
* The deprecated (often since as far back as 2.0) versions of functions that
took raw pointers to color values now have deprecations warnings. Use the
versions that take `span<>` or `cspan<>` instead. These include versions of:
isConstantColor, isConstantChannel, isMonochrome, isConstantChannel,
colorconvert, fill, checker, add, sub, absdiff, mul, div, mad, pow,
channel_sum, channels, clamp, color_count, color_range_check, render_text.
* The `histogram()` function that takes a reference to a result vector
(deprecated since 2.0 and previously warned) has been removed. Use the
version that returns the vector instead. The `histogram_draw()` (deprecated
since 2.0 and previously warned) has been removed and has no replacement
since it was always silly.
* The versions of ociodisplay that lacked an `inverse` parameter, which were
marked as deprecated since 2.5, now have deprecation warnings. Use the
version that takes an `inverse` bool.
* The OpenCV-related functions that take old-style IplImage pointers
(deprecated since 2.0) have been removed. Use the modern ones that use
cv::Mat.
* The pre-KWArgs versions of resize, warp, and fit now have deprecation
warnings. Use the versions that take KWArgs instead.
* The OpenCV-related functions `to_OpenCV()`, `from_OpenCV()`, and
`capture_image()` have moved to the `imagebufalgo_opencv.h` header.
## imagebufalgo_util.h
* IBA::type_merge, deprecated since 2.3, now has a deprecation warning.
Instead, use TypeDesc::basetype_merge().
## imagecache.h
* `ImageCache::create()` now returns a `std::shared_ptr<ImageCache>` instead
of a raw pointer.
## missingmath.h
* This header has been removed entirely. It has was originally needed for
pre-C++11 MSVS, but has been unused since OIIO 2.0 (other than transitively
including fmath.h).
## paramlist.h
* Removed some ParamValue constructor variants that have been deprecated since
OIIO 2.4. The removed variants took an optional `bool` parameter indicating
whether the value was copied. If you need to override the usual copy
behavior, please use the newer variety of constructors that instead use a
"strong" type where you pass `ParamValue:Copy(bool)`.
## parallel.h
* Removed several varieties of `parallel_for` functions where the task
functions took a thread ID argument in addition to the range, which have
been considered deprecated since OIIO 2.3. Please use task functions that do
not take a thread ID parameter.
## platform.h
* Removed macros `OIIO_CONSTEXPR`, `OIIO_CONSTEXPR14`, and
`OIIO_CONSTEXPR_OR_CONST` and deprecated `OIIO_CONSTEXPR17` (use regular C++
`constexpr` in place of all of these). Removed macro `OIIO_NOEXCEPT` (use
C++ `noexcept`).
* Removed macro `OIIO_UNUSED_OK`, which had been deprecated since 2.0. Marked
`OIIO_MAYBE_UNUSED` as deprecated as well, now that C++17 is the minimum,
there's no reason not to directly use the C++ attribute `[[maybe_unused]]`.
## simd.h
* The old (OIIO 1.x) type names float3, float4, float8, int4, int8, mask4,
bool4, bool8 have been removed. Use the new vbool4, vint4, vfloat4, etc.
* The old rotl32 functions have been removed. They had been deprecated since
OIIO 2.1. Please use `rotl()` intead.
* The old floori functions have been removed. They had been deprecated since
OIIO 1.8. Please use ifloor() instead.
* The old OIIO_SIMD_HAS_FLOAT8 macro has been removed. It was deprecated since
OIIO 1.8.
## string_view.h
* The string_view::c_str() method has been marked as deprecated, since
it is not present in C++17 std::string_view. If you must use this
functionality (with caution about when it is safe), then use the
freestanding OIIO::c_str(string_view) function instead.
## strutil.h
* The default behavior of `Strutil::format()` has been changed to use the
`std::format` conventions. If you want the old behavior, use
`Strutil::old::format()` instead.
* Added deprecation warnings to all the old (printf-convention) string
`format()` function.
## texture.h
* `TextureSystem::create()` now returns a `std::shared_ptr<TextureSystem>`
instead of a raw pointer.
* Removed stochastic-related tokens from the MipMode and InterpMode enums.
These were originally experimental but never removed.
* Removed the `bias` field from the TextureOpt structure. This was originally
there for the sake of shadow maps, but was never used because we never
implemented shadow maps in OIIO's TextureSystem.
* Removed the TextureOptions, which hasn't been used since OIIO 1.x. We
switched to the alternate TextureOpt structure in OIIO 2.0.
* Fully removed the long-deprecated methods of TextureSystem that operated
on batches using the VaryingRef class. These were replaced by alternatives
a long time ago.
## thread.h
* `OIIO::yield()` now has a deprecation warning, having been marked as
deprecatd since OIIO 2.4. Use `std::this_thread::yield()`.
## tiffutils.h
* Removed the version of decode_exif that takes a pointer and length
(deprecated since 1.8). Use the version that takes a `string_view`, or the
one that takes a `cspan<uint8_t>`.
## type_traits.h
* Removed the `OIIO::void_t` template, which now should be replaced with
`std::void_t`.
## ustring.h
* Removed old `ustringHash` (which was just an alias for `std::hash<ustring>`,
which should be used instead).
## varyingref.h
* This header has been removed completely, since we no longer use the classes
it defines.
## python bindings
* The `ImageBufAlgo.capture_image()` function has been removed from the
Python bindings. Python scripts that wish to capture images from live
cameras should use OpenCV or other capture APIs of choice and then
pass the results to OIIO to construct an ImageBuf.
* Static type names within the `TypeDesc` class (such as `TypeDesc.TypeFloat`)
have been removed after being considered deprecated since OIIO 1.8. Use the
names in the overall OpenImageIO namespace instead.
* Older versions of `ImageBufAlgo.fit()` have been removed. Use the newer
function signatures.
* Older versions of `ImageInput::read_native_deep_scanlines()` and
`read_native_deep_tiles()` have been removed. They had been deprecated
since OIIO 2.0.
## maketx
* The `--noresize` option has been removed. It was deprecated since OIIO 2.0,
when it became the default behavior.
* The `--stats` option has been removed. It was deprecated since OIIO 1.6,
when it was renamed `--runstats`.
-98
View File
@@ -1,98 +0,0 @@
OpenImageIO Usage Quick Start
=============================
> [!NOTE]
> For information about how to *install* or *build* OpenImageIO, please see
> the [INSTALL guide](../INSTALL.md). This "Usage Quick Start" guide is
> intended to help you get started using OpenImageIO once you have it
> installed.
To illustrate how to do a simple common image operation -- reading a TIFF file
and writing it back as an OpenEXR file, with all necessary conversions -- we
will show how this can be accomplished through several different OpenImageIO
APIs and programs.
In all cases, we will assume we have a file called `input.tif` and we wish to
convert it to `output.exr`.
### Using `oiiotool` command-line utility
```bash
$ oiiotool input.tif -o output.exr
```
### High-level ImageBuf API
In C++:
```cpp
#include <OpenImageIO/imagebuf.h>
void main()
{
OIIO::ImageBuf image("input.tif");
image.write("output.exr");
}
```
In Python:
```python
import OpenImageIO as oiio
image = oiio.ImageBuf("input.tif")
image.write("output.exr")
```
### Low level ImageInput/ImageOutput API
In C++:
```cpp
#include <OpenImageIO/imageio.h>
#include <cstddef>
#include <memory>
void main()
{
auto input = oiio.ImageInput.open("input.tif")
OIIO::ImageSpec spec = input.spec()
size_t nbytes = spec.image_bytes();
std::unique_ptr<std::byte[]> pixels = new std::byte[nbytes];
input->read_image(0, 0, 0, spec.nchanels, OIIO::TypeUnknown, pixels.get());
input->close();
auto output = oiio.ImageOutput.create("output.exr");
output->open("output.exr", spec);
output->write_image(TypeUnknown, pixels.get());
output->close();
}
```
In Python:
```python
import OpenImageIO as oiio
input = oiio.ImageInput.open("input.tif")
spec = input.spec()
pixels = input.read_image()
# Note: read_image will return a NumPy multi-dimensional array holding
# all the pixel values of the image.
output = oiio.ImageOutput.create("output.exr")
output.open("output.exr", spec)
output.write_image(pixels)
# Note: write_image expects a NumPy multi-dimensional array holding
# all the pixel values of the image.
```
### Next Steps
This is just a simple example to give you a flavor of the different major
interfaces. For more advanced usage, you may want to explore the
[documentation](https://docs.openimageio.org).
<!-- SPDX-License-Identifier: CC-BY-4.0 -->
<!-- Copyright Contributors to the OpenImageIO Project. -->
-103
View File
@@ -1,103 +0,0 @@
<!-- SPDX-License-Identifier: CC-BY-4.0 -->
<!-- Copyright Contributors to the OpenImageIO Project. -->
# 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](https://github.com/orgs/AcademySoftwareFoundation/projects/28))
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](https://github.com/AcademySoftwareFoundation/OpenImageIO/discussions/4151).
See the [Dependency proposal wiki page](https://github.com/AcademySoftwareFoundation/OpenImageIO/discussions/4151)
* [x] Big required upgrades with potentially widespread impact on the code base
- [x] C++17 [#4155](https://github.com/AcademySoftwareFoundation/OpenImageIO/issues/4155)
- [x] Python 3.7 [#4157](https://github.com/AcademySoftwareFoundation/OpenImageIO/issues/4157)
- [x] OpenEXR/Imath 3.1 [#4156](https://github.com/AcademySoftwareFoundation/OpenImageIO/issues/4156)
* [x] 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:
- [X] CMake 3.18 (from 3.15). [#4472](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4472)
- [x] OpenColorIO 2.2, and make it required. [#4367](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4367)
- [ ] fmt 8.0 (from 7.0), which has many improvements. CANCELLED: fmt 8.0+
does not work with the old icc compiler.
- [x] GIFlib 5.0 (from 4.0), which adds thread safety. [#4349](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4349)
- [x] libheif 1.11 (from 1.3), which supports many additional features of that format. [#4380](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4380)
- [x] WebP 1.2 (from 0.6) which lets us use their exported CMake configs and retire FindWebP.cmake. [#4354](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4354)
- [x] pybind11 2.6 or 2.7 (from 2.4). [#4297](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4297)
- [x] [#4158](https://github.com/AcademySoftwareFoundation/OpenImageIO/issues/4158) Eliminate the last few places where we use Boost and eliminate it as a dependency.
<br>
## API Modernization
- [ ] [#4159](https://github.com/AcademySoftwareFoundation/OpenImageIO/issues/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](https://github.com/AcademySoftwareFoundation/OpenImageIO/issues/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](https://github.com/AcademySoftwareFoundation/OpenImageIO/issues/4164) Better color management
Regardless of OCIO availability, version, or contents of any configs, have universal support for the [canonical color spaces](https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/documents/Specification/MaterialX.Specification.md#color-spaces-and-color-management-systems) that seem to be the common consensus of ACES, MaterialX, and USD.
- [ ] Preliminary Rust bindings for most of the OpenImageIO APIs.
- [x] Python wheel construction so `pip install openimageio` will be an easy way
for users to install the whole banana. [#4428](https://github.com/AcademySoftwareFoundation/OpenImageIO/issues/4428)
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 2026 release of OIIO 3.2.
...
-14
View File
@@ -1,14 +0,0 @@
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# Ignore temporary specs that may be ephemeral or local to an individual
# developer, to prevent cluttering the output of `git status` and prevent
# people from accidentally checking in specs that are only meant for them.
specs/*
# But don't ignore the ones that belong to this project and are checked in. As
# we add specs that we intend to commit and make available to all project
# developers, they must be individually added here.
# !specs/example
-170
View File
@@ -1,170 +0,0 @@
Policy on AI Coding Assistants
==============================
- Initial policy merged 23-Mar-2026
Use of "AI coding assistants" is permitted on this project, with the following
guidelines and principles.
Summary of our core values:
- Human must always be in the loop, and is the responsible party for
the contents of a PR (including fully understanding and being able
to explain, defend, and modify it in response to review comments).
- Interact with the project and community yourself, not by agent.
- Disclose what tools you used and how. At a minimum, we require an
"Assisted-by: TOOL/MODEL" line in the commit comments and PR description.
- Don't waste maintainer's time with low quality PRs.
The long version:
### Human authorship and interaction with the project
**The human making a PR is considered the author** and is fully responsible
for the code they submit.
**No PRs should be submitted, reviewed/merged, or deployed without a human
fully in the loop.** You may use agents locally to help you write code (and
docs, tests, etc.), but you may not use agents to autonomously interact with
the project community. Submit your own PRs, write your own discussion
comments, respond to community members in your own words, approve or reject
code in review using your own brain.
Code autonomously submitted without an identifiable human author and
responsible party will be immediately closed, and the account associated with
the submission may be banned from future project participation.
**DO NOT "vibe code."** This term refers to a pure prompt-to-behavior cycle
where the human accepts un-inspected code based on the program behavior alone.
We don't want this. Code that must be maintained by the project should be
truly understood. Project code is ideally the result of discussion / pair
programming between the author and assistant, but even if the machine is doing
most of the work, all code should be approved and fully understood by the
author prior to PR submission.
### Professionalism and quality
**The usual high quality level of PRs should be maintained regardless of tools
used.** This includes not only code, but also the design, testing, PR
preparation, and the author's ability to explain and defend the code and
respond to questions and requests for changes. We never want to hear "but the
AI..." as an excuse for anything.
**PRs should always be [reviewed](CodeReview.md) and approved by someone other
than their author if at all possible.** This is especially true of code with
machine-generated components, because of the additional risk that the
submitter/operator may not fully understand what they did not write
themselves. This is part of the reason for AI tool disclosure -- to ensure
that another pair of eyes is on it. AI code review may be requested for
additional input, but the AI cannot give "approval", nor merge code itself.
Even when using a coding assistant to write the code, you are strongly
encouraged to write your own PR description, in your own words, if for no
other reason than to force yourself to understand the code well enough to
describe it to others.
### Disclosure
**Disclosure is required.** Patches that were written with the aid of AI
coding assistants must have, at a minimum, the following line in the commit
comment and PR description body:
Assisted-by: TOOL / MODEL
Ideally, to the extent practical, the PR description should also have a brief
description of how the tool was used, including the gist of key prompts or
summarizing the direction of the dialog. A full log is not necessary; a short
summary will do.
There are several reasons for this disclosure/documentation, even though it
will sometimes be inconvenient:
- Reproducibility: We want even automated work to be reproducible by others in
principle, just like a scientific paper.
- Education: We want to actively teach each other what tools, prompts, or
methods are successful at making high quality results for the project.
- Metrics: We would like the ability to look back and compare assisted vs
non-assisted code for things like defect rate (how often were new bugs
introduced or commits needed to be reverted), whether people are more likely
to write comprehensive tests when using assistants, etc.
- Compliance: Many key users and developers are in companies where they need
to disclose how AI tools were used in their work, and in other software that
they use. Let's make it easy for them.
- Insurance: Should future legal decisions radically change the IP status of
AI-generated code, or if particular models are implicated in copyright
violations, we want a way to find out which contributions might need to be
revisited in order to bring the project back into compliance.
### Intellectual Property
Regardless of how the code came to be -- from your head alone, from a friend,
from Stack Overflow, from a blog post, from reading other code bases, or from
a coding assistant -- we expect the terms of the
[DCO](https://developercertificate.org/) and CLA to apply, and for the author
to take reasonable care that code is not copied from a source with an
incompatible license.
You may find that your confidence about complying with the DCO+CLA depends on:
- If you provided a detailed specification and how much you edited or guided
the results yourself.
- Whether you are modifying or extending existing code versus writing large
amounts of entirely new code.
- The degree to which the generated code seems to fit into our structure and
idiomatic style, and therefore seems unlikely to be copied from elsewhere.
- Whether your tool has guardrails to prevent answers that are too similar to
existing code, for example as claimed by [Claude](https://privacy.claude.com/en/articles/10023638-why-am-i-receiving-an-output-blocked-by-content-filtering-policy-error) and [Copilot](https://docs.github.com/en/copilot/how-tos/manage-your-account/).
### Extractive submissions
**Maintainer time and attention are precious commodities**, and use of coding
assistants is not an excuse to submit poor PRs or to externalize costs onto
maintainers/reviewers (such as responsibility for understanding, testing, or
fixing PRs that the human author does not have a full understanding of).
Maintainers are free to take counter-measures against submitters of sub-par
PRs, or other violations of this policy, up to and including banning habitual
abusers from future participation in the project.
**We discourage use of AI tools to fix GitHub issues labeled as "good first
issue" or for "Dev Days" work.** Cultivating and educating new contributors is
important, and as such, we do not want people to swoop in and use automated
tools to trivially solve tasks that were curated specifically for somebody to
actually learn from. We expect each developer to implement at most one "good
first issue" per Dev Days occasion, and we encourage you to solve the problem
with your own brain to maximize the learning experience.
### Exceptions
This AI tool use policy is not meant to encompass cases such as:
- "Smart auto-complete", spell-checking, grammar checking, or other uses that
aren't really contributing substantively to authorship.
- Use of LLMs to explain code or learn about the codebase, answer basic
programming questions, help with background research, or audit the code
for bugs that are subsequently confirmed and fixed by people.
- Language translation for non-fluent English speakers or other accessibility
accommodations.
- Trivial or de-minimis fixes such as fixing a typo, obviously wrong variable
use, etc.
- Reviewing your own code for mistakes prior to submitting a PR (as long as it
isn't making the fixes for you).
### Creative contributions -- out of scope
This project repository contains code for tools, and their documentation. We
don't really directly host any artistically creative work here, so we have not
addressed additional policy issues that might come up in such a context.
If you are representing a different project that is using this document for
guidance or inspiration for your own policies, please be aware that you may
have needs that are not covered by these policies but deserve well-crafted
guidance.
### References and inspiration
Our policy has been informed and inspired by the following efforts in other communities:
- [LLVM AI Tool Policy](https://llvm.org/docs/AIToolPolicy.html)
- [Fedora Project policy on AI-assisted contributions](https://communityblog.fedoraproject.org/council-policy-proposal-policy-on-ai-assisted-contributions/)
- [Linux Foundation policy on Generative AI](https://www.linuxfoundation.org/legal/generative-ai)
- [Rust policy on rejecting burdensome PRs](https://github.com/rust-lang/compiler-team/issues/893)
- The METR paper [Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)
- [GitHub Blog: Rethinking open source mentorship in the AI era](https://github.blog/open-source/maintainers/rethinking-open-source-mentorship-in-the-ai-era/)
-57
View File
@@ -1,57 +0,0 @@
<!-- SPDX-License-Identifier: CC-BY-4.0 -->
<!-- Copyright Contributors to the OpenImageIO Project. -->
# Agentic coding / coding assistants
Please start by reading [our policy on using "AI" coding
assistsants](AI_Policy.md).
## Multi-tool setup
We aim to allow people to use whatever agentic or coding assistant tools they
want. The repository ships with a setup script that configures tool-specific
files locally for whichever assistant(s) you use.
### Generic: `AGENTS.md` and `.agents/`
As much as possible, we use identical instructions and files across all coding
assistants.
`AGENTS.md` is the main file providing overall repo-specific instructions and
context to agents. Many coding agents already read this file directly; for
those that don't, the setup script creates the necessary links or wrappers.
`.agents/skills/` is where shared skill files live. Many tools find skills
here automatically; for those that need them elsewhere, the setup script
creates the appropriate links.
### Running the setup script
After cloning, run `.agents/setup-agent <tool>` for the tool(s) you use:
```
.agents/setup-agent claude # Claude Code
.agents/setup-agent cursor # Cursor
.agents/setup-agent codex # OpenAI Codex
.agents/setup-agent opencode # Opencode
.agents/setup-agent copilot # GitHub Copilot
.agents/setup-agent all # all of the above
```
The script is idempotent — running it multiple times is safe. To undo:
```
.agents/setup-agent clear # remove all tool setup
.agents/setup-agent clear claude # remove setup for one tool
```
Tool-specific directories (`.claude/`, `.cursor/`, `.codex/`, `.opencode/`,
`.github/copilot-instructions.md`) are created locally only and are listed in
`.gitignore`. Each developer runs the script for the tool they use; nothing
tool-specific is committed to the repository.
The script header contains per-tool documentation (what each tool reads
natively, what requires setup, and links to relevant docs) — consult it when
adding support for a new tool or updating the strategy for an existing one.
-207
View File
@@ -1,207 +0,0 @@
OpenImageIO's Architecture
==========================
```mermaid
block-beta
columns 3
Apps
style Apps fill:#0000,stroke:#0000
cmd["oiiotool, iinfo, maketx, ..."]:2
Classes["Image and caching\nclasses"]
style Classes fill:#0000,stroke:#0000
block:IB
style IB fill:#0000,stroke:#0000
columns 1
ImageBufAlgo ImageBuf
end
block:ICTA
style ICTA fill:#0000,stroke:#0000
columns 1
TextureSystem ImageCache
end
file["File reading/writing\nclasses"]:1
style file fill:#0000,stroke:#0000
ImageInput ImageOutput
plugins["File format\nimplementations"]
style plugins fill:#0000,stroke:#0000;
block:formats:2
style formats fill:#0000,stroke:#0000
columns auto
TIFF OpenEXR JPEG DPX etc["..."]
style etc fill:#0000,stroke:#0000
end
```
## Core level / file abstraction: ImageInput and ImageOutput
At the heart of OpenImageIO are the `ImageInput` and `ImageOutput` classes,
which are the abstract interfaces for reading and writing image files using a
simple file-format-agnostic API. These classes provide a file-oriented
abstraction, with operations such as opening an image file, reading the
resolution and other metadata about the image in the file, reading or writing
scanlines or tiles to/from caller-provided memory, and closing the file.
All the details of the individual file formats and how the data is arranged or
stored in the file are hidden by these classes. Furthermore, when reading or
writing scanlines or tiles, the caller-side memory can use any of several
different common data types (sometimes called "data formats" or "formats" in
OIIO) such as `float`, `half`, 8 or 16 bit integers, etc. The `ImageInput` and
`ImageOutput` classes will automatically convert the data to or from the
format stored in the file.
This level of abstraction imposes some conceptual constraints on the
presentation of the image data, for the sake of simplification, so that every
application doesn't need to consider every possible combination of choices
that all the different file formats might make. For example, on the
"application side" of the `ImageInput` and `ImageOutput` classes, all images
have pixels that are 8- 16- or 32-bit int (signed or unsigned), 16- 32- or
64-bit float. If the pixel data in the file uses another data type, or a
number of bits per channel that is not 8, 16, or 32, those details are hidden
from the application. There are many other such simplifications.
## Low level: File format implementations
If the `ImageInput` and `ImageOutput` present the *interface* for reading and
writing image files, the implementations of each individual file format are
implemented in the file format plugins. (We call them "plugins" because it's
possible to organize them as an extensible list of dynamically loaded modules,
but all the common file formats have their plugins compiled into the
OpenImageIO library itself, so are not dynamically loaded and not generally
experienced as "plugins" in the usual sense.)
Each file format plugin consists of a concrete subclass of `ImageInput`, and
usually `ImageOutput`. Most format plugins are capable of both reading and
writing the file format, but some of them only include the reading portion.
## Higher level / Image abstraction: ImageBuf and ImageBufAlgo
For many applications, you just want to manipulate whole images, without
worrying about the details of opening and closing files, reading and writing
of individual scanlines or tiles, or how and where the pixel data is stored.
The `ImageBuf` class provides such an interface. It is a higher-level
abstraction that encapsulates an entire image.
For an ImageBuf that is meant to read an image file, it is simply told the
name of the file, and it will handle all the details of how and when to open,
close, and read the file, including handling all the combinations of tiles,
scanlines, and so on. Similarly, an ImageBuf can be written to an image file
on disk simply by providing the filename and telling it to `write()`, without
needing to specify any scanline-by-scanline instructions. The internal
implementation of ImageBuf uses ImageInput and ImageOutput to read and write
the image data from and to files, and so can read or write any file format for
which there is an ImageInput or ImageOutput plugin available.
ImageBuf typically owns the memory holding its pixel data and is responsible
for allocating and freeing it. Thus, file reads and writes are to/from this
internal memory, as opposed to ImageInput and ImageOutput, which must be
supplied with memory by the caller as the source or destination of the pixel
data. (That said, there is also a way to make an ImageBuf "wrap" memory owned
by the application rather than allocate internally.)
In addition to restricting the pixel data types to a limited set, ImageBuf
further imposes the simplification that all color channels are stored in the
same data type. This is a simplification that is not present in the ImageInput
and ImageOutput classes, which can handle files where different channels are
stored in different data types. For such a file, the ImageBuf will "promote"
all the channels of an image to a single same data type (usually the "widest"
or "most precise" used by any of its channels).
If `ImageBuf` is the in-memory representation of an entire image, then
`ImageBufAlgo` is a collection of algorithms that operate on `ImageBuf`
objects. These algorithms include simple operations like copying, resizing,
and compositing images, as well as more complex operations like color
conversions, resizing, filtering, etc.
Some performance-critical `ImageBufAlgo` implementations have SIMD-accelerated
paths using Google Highway. For implementation details and guidance for adding
new kernels, see `docs/dev/ImageBufAlgo_Highway.md`.
## Image caching: TextureSystem and ImageCache
There are situations where ImageBuf is still not the right abstraction,
and you have so many images -- potentially tens of thousands of images
totalling multiple terabytes of pixel data -- that they can't possibly
be held in memory at once. This is actually a typical case for a
high-quality film renderer, where the renderer needs to be able to
access a texture data set of that size range.
In such cases, you want to handle both the pixel memory and the set of
open files as a *pool* centrally managed. This is done by the
`ImageCache` class. In short, it manages two central caches:
- A pool of image files currently held open, with a limit on the number of
files that can be open at once (typically hundreds to thousands). When the
limit is reached, a file that has not been accessed recently is closed to
make room for a new file to be opened.
- A pool of pixel memory, organized into image *tiles*, with a limit on the
total amount of tile memory to be used (typically a small number of GB).
Accesses to pixel values check if the tile is in the cache, in which case no
read from disk is necessary. If pixel access requires a tile not currently
in the cache and the tile memory limit is reached, a tile that has not been
accessed recently is evicted from the cache to make room for the new tile.
The TextureSystem is a level of abstraction above the ImageCache that further
adds the ability to do texture lookups with texture filtering, MIP-mapping,
and other features typical of texture mapping in a renderer.
## Command line applications
OpenImageIO has several command line utilities that use various combinations
of ImageBuf, ImageInput, and ImageOutput.
`oiiotool` is the most important of these (and technically can do everything
that the other tools can do, and more). It is a general-purpose image
manipulation tool that can read and write images, apply various image
operations, and write the results to disk.
Other command line tools include `iinfo` (which prints out information about
an image file), `iconvert` (which converts between different file formats),
and `maketx` (which generates tiled mipmaps in an efficient arrangement for
texture mapping in a renderer).
## Language Bindings
The main APIs, and the underlying implementation, are in C++ (currently
using C++17 features).
A Python binding is provided, currently using the pybind11 library to
generate the Python bindings for each C++ class or function.
There is an effort underway to eventually provide a Rust binding.
## Helper classes
Several image-related auxiliary classes are used by the public APIs of the
image- and file-oriented classes described above. The most important ones are:
- `ImageSpec` stores the specification for an image: its resolution, pixel data
type, number of channels (as well as their names and individual data types),
pixel and display windows, and all other metadata from the image file.
- `ParamValueList` is used to store a list of of name/value pairs (each
individual name+value is a `ParamValue`), such as arbitrary image metadata.
- `ROI` describes a region of interest: the x, y, z, and channel range of
pixels on which to perform some operation.
Additionally, there are many small utility classes that are not about images
per se, but also are used by the public interfaces of our main image classes.
A few of them that you will see commonly used are:
- `string_view` is a non-owning reference to a string (of any of several
types, or partial substrings thereof), akin to `std::string_view` in C++17.
- `span` is a non-owning reference to a contiguous sequence of objects, akin
to `std::span` in C++20.
- `ustring` is a string class where the characters are stored in an internal
shared pool of strings, so all ustrings that have the same character
sequence point to the same character memory. In addition to saving memory,
this makes string assignment and equality comparison as inexpensive as
integer operations.
<!-- SPDX-License-Identifier: CC-BY-4.0 -->
<!-- Copyright Contributors to the OpenImageIO Project. -->
-51
View File
@@ -1,51 +0,0 @@
<!-- SPDX-License-Identifier: CC-BY-4.0 -->
<!-- Copyright Contributors to the OpenImageIO Project. -->
# Build profiling
These are instructions for profiling the build process of OpenImageIO --
useful for figuring out where the build process is spending its time, and
where it might be optimized.
## Profiling module compilation with clang -ftime-trace
These instructions are based on the following references:
- general instructions: https://www.superfunc.zone/posts/001-speeding-up-c-builds/
- ninjatracing.py script: https://github.com/nico/ninjatracing
- Background info: https://aras-p.info/blog/2019/01/16/time-trace-timeline-flame-chart-profiler-for-Clang/
The steps are as follows, and they require the use of clang, ninja, and
the chrome browser:
1. Build with clang using the `-ftime-trace`, flag which is set when you use
the OIIO build option -DOIIO_BUILD_PROFILE=1. You MUST use clang, as this
is a clang-specific feature, and you must use the ninja builder (use CMake
arguments `-G ninja`). This must be a *fresh* build, not an incremental
build (or the results will only reflect the incrementally build parts).
This will result in a file, build/.ninja_log, containing timings from
the build process.
2. Prepare the output using the `ninjatracing.py` script as follows:
```
python3 src/build-scripts/ninjatracing.py -a build/.ninja_log > top_level.json
```
3. Running the Chrome browser, visit the URL `chrome://tracing`, and LOAD that
json file created in the previous step. This will display a timeline of the
build process, showing which thread, in what order, and how long each
module took to compile.
4. For even more detail on what's happening within the compilation of each
module, you can use the `-e` flag to expand the output:
```
python3 src/build-scripts/ninjatracing.py -a -e -g 50000 build/.ninja_log > expanded.json
```
Loading this in Chrome's tracing view, as above, will show a full flame
chart of the build process, showing the time spent in the different
functional parts of the compiler and which functions of OIIO it is
compiling or which templates are being instantiated.
-48
View File
@@ -1,48 +0,0 @@
Release 3.0 (Fall 2024) -- compared to 2.5
-------------------------------------------------
### New minimum dependencies and compatibility changes:
* *Blah*: Raise minimum to 1.2...
### ⛰️ Major new features and public API changes:
* *New feature*: item
* *New image file format support:*
- Format1 explanation
- Format2 explanation
* *oiiotool*:
- item
* *ImageBuf/ImageBufAlgo*:
- item
* *Other categories or subsystems as needed*:
### 🚀 Performance improvements:
- *subsystem*: item
### 🐛 Fixes and feature enhancements:
* *subsystem*: item
* *oiiotool*: item
* *ImageBuf/ImageBufAlgo*:
- item
* *ImageCache/TextureSystem*:
- item
* *format*:
- item
### 🔧 Internals and developer goodies
- *int*: item
- *header.h*: developer item
### 🏗 Build/test/CI and platform ports:
* CMake build system and scripts:
- item
* Testing and Continuous integration (CI) systems:
- *test*: item
- *ci*: item
* Platform support:
- *win*: item
### 📚 Notable documentation changes:
- *docs*: item
### 🏢 Project Administration
- *admin*: item
-4
View File
@@ -1,4 +0,0 @@
Release 1.2.3.4 (Month DD, YYYY) -- compared to 1.2.3.3
-------------------------------------------------------
- *category*: Description [#1234](https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/1234) (by someuser)
-194
View File
@@ -1,194 +0,0 @@
<!-- SPDX-License-Identifier: CC-BY-4.0 -->
<!-- Copyright Contributors to the OpenImageIO Project. -->
Code Review Procedures
======================
### Why do we code review?
Code review is a process where someone other than the author of a patch
examines the proposed changes and approves or critiques them. The main
benefits are to:
- Encourage submitters to ensure that their changes are well thought out,
tested, and documented so that their intent and wisdom will be clear to
others.
- Directly find shortcomings in or suggest improvements to the proposed
changes, and ensure that the changes are consistent with the project's best
practices.
- Minimize the amount of the code base that has only been seen or is only
understood by one person.
- Improve security and robustness of the code base by assuring that at least
two people (submitter and reviewer) agree that every patch is reasonable and
safe.
### Reviewer guidelines -- what you should be looking for
Code review is not difficult, and it doesn't require you to be a senior
developer or a domain expert. Even if you don't particularly understand that
region of the code and are not a domain expert in the feature being changed,
you can still provide a helpful second pair of eyes to look for obvious red
flags and give an adequate review:
- This may seem too obvious to say explicitly, but a big part of review is
just looking at the PR and seeing that it doesn't appear to deface,
purposely/obviously break, or introduce malware into the project.
- Does the explanation of the PR make logical sense and appear to match (as
near as you can tell) the changes in the code? Does it seem sensible, even
if you don't understand all the details?
- Does the test pass all of our existing CI tests? (If it does, at least we
are reasonably sure it doesn't break commonly used features.)
- Is there any evidence that the changes have been tested? Ideally, something
already in, or added to the testsuite by this PR, exercises the new or
altered code. (Though sometimes a patch addresses an edge case that's very
hard to reproduce in the testsuite, and you have to rely on the submitter's
word and the sensibility of their explanation.)
- Not required, but nice if we can get it: You're an expert in the part of
the code being changed, and you agree that this is the best way to achieve
an improvement.
- Any objections should be explained in detail and invite counter-arguments
from the author or other onlookers. A reviewer should never close a PR
unless it fails to conform to even the basic requirements of any submitted
PR, or if enough time has passed that it's clear that the PR has been
abandoned by its author. It's ok to ultimately say "no" to a PR that can't
be salvaged, but that should be the result of a dialogue.
Obviously, you also want any review comments you give to be constructive and
helpful. If you don't understand something, ask for clarification. If you
think something is wrong, suggest a fix if you know how to fix it. If you
think something is missing, suggest what you think should be added. Follow the
expected kind and constructive tone of the project's community.
### Submitter guidelines -- how to encourage good reviews and timely merges
A few tips for submitters to help ensure that your PRs get reviewed and merged
in a timely manner and are respectful of the reviewers' time and effort:
- Aim for small PRs that do a specific thing in a clear way. It is better to
implement a large change with a series of PRs that each take a small,
obvious step forward, than to have one huge PR that makes changes so
extensive that nobody quite knows how to evaluate it.
- Make sure your PR commit summary message clearly explains the why and how of
your changes. You want someone to read that and judge whether it's a
sensible approach, know what to look for in the code, and have their
examination of the code make them say "yes, I see, of course, great, just as
I expected!"
- Make sure your PR includes a test (if not covered by existing tests).
- Make sure your PR fully passes our CI tests.
- Make sure your PR modifies the documentation as necessary if it adds new
features, changes any public APIs, or alters behavior of existing features.
- If your PR alters the C++ API, make sure that the changes are also reflected
in the Python bindings and any other language bindings we support.
- If your PR adds to or alters any ImageBufAlgo function, make sure you have
exposed those changes with appropriate `oiiotool` commands as well.
### Code review procedures -- in the ideal case
In the best of circumstances, the code review process should be as follows for
**EVERY** pull request:
- At least one reviewer critiques and eventually (possibly after changes are
made) approves the pull request. Reviewers, by definition, are not the same
person as the author.
- Reviewers should indicate their approval by clicking the "Approve" button in
GitHub, or by adding a comment that says "LGTM" (looks good to me).
- If possible, reviewers should have some familiarity with the code being
changed (though for a large code base, this is not always possible).
- At least a few work days should elapse between posting the PR and merging
it, even if an approving review is received immediately. This is to allow
additional reviewers or dissenting voices to get a chance to weigh in.
- If the reviewer has suggestions for improvement, it's the original author
who should make the changes and push them to the PR, or at the very least,
the author should okay any changes made by the reviewer before a merge
occurs (if at all practical).
Not all patches need the highest level of scrutiny. Reviews can be cursory and
quick, and merges performed without additional delay, in some common low-risk
circumstances:
- The patch fixes broken CI, taking the project from a verifiably broken state
to passing all of our CI builds and tests.
- The changes are only to documentation, comments, or other non-code files,
and so cannot break the build or introduce new bugs.
- The code changes are trivial and are obviously correct. (This is a judgment
call, but if the author or reviewer or both are among the project's senior
developers, they don't need to performatively pretend that they aren't sure
it's a good patch.)
- The changes are to *localized* and *low risk* code, that even if wrong,
would only have the potential to break individual non-critical features or
rarely-used code paths.
Conversely, some patches are so important or risky that if possible, they
should be reviewed by multiple people, preferably from different stakeholder
institutions than the author, and ensure that the approval is made with a
detailed understanding of the issues. In these cases, it may also be worth
bringing up the issue up at a TSC meeting to ensure the attention of many
stakeholders. These include:
- *New directions*: Addition of major new features, new strategic initiatives,
or changes to APIs that introduce new idioms or usage patterns should give
ample time for all stakeholders to provide feedback. In such cases, it may
be worth having the PR open for comments for weeks, not just days.
- *Risky changes*: Changes to core classes or code that could subtly break
many things if not done right, or introduce performance regressions to
critical cases.
- *Compatibility breaks*: changes that propose to break backward API
compatibility with existing code or data files, or that change the required
toolchain or dependencies needed to build the project.
- *Security*: Changes that could introduce security vulnerabilities, or that
fix tricky security issues where the best fix is not obvious.
### Code review compromises -- because things are rarely ideal
We would love to have many senior reviewers constantly watching for PRs, doing
thorough reviews immediately, and following the above guidelines without
exception. Wouldn't that be great! But in reality, we have to compromise,
hurry, or cut corners, or nothing would ever get done. Some of these
compromises are understandable and acceptable if they aren't happening too
often.
- Lack of reviews: If no reviews are forthcoming after a couple days, a "are
there any objections?" comment may be added to the PR, and if no objections
are raised within another few days, the PR may be merged by the author if
they are a senior developer on the project. This is a fact of life, but
should be minimized (with a rigor proportional to where the patch falls on
the "low risk / high risk" scale described above). If this is done, you
should leave an additional comment explaining why it was merged without
review and inviting people to submit post-merge comments if they
subsequently spot something that can be improved.
- Time-critical patches: urgent security fixes, broken CI or builds, critical
bugs affecting major stakeholders who are waiting for a repaired release,
fixes that are blocking other work or preventing other PRs from advancing.
In such cases, it is understandable for senior developers to try to speed up
the process of getting the changes integrated (though the very nature of
their criticality also indicates that it's worth getting a review if at all
possible).
- Failing tests: Sometimes a PR must be merged despite failing CI tests.
Usually this is for one of two reasons: (1) spurious CI failures are known
to be occurring at that time and are unrelated to the PR; (2) the PR is part
of a series of patches that are only expected to fully pass CI when the last
piece is completed.
These changes are understandable, but we still are striving to reduce their
frequency. It is the responsibility of the senior developers, TSC members, and
major stakeholders to be monitoring the incoming PRs and helping with reviews
as much as possible, to ensure that review exceptions are rare.
### Code review pathologies -- things to avoid
These are anti-patterns that generally are indications of an unhealthy open
source project:
* An author merging their own PR without any review comments that indicate
meaningful scrutiny or approval from another party, and without giving
adequate warning that a merge will occur if no reviews are received.
* PRs languishing for weeks or months without any review or merge.
* PRs that don't adequately test their changes (basically crossing your
fingers and hoping it works).
* PRs that are merged despite failing CI that might be related or, if
unrelated, that might be masking problems with the PR being evaluated.
Again, sometimes these things happen out of necessity to keep the project
moving forward under constrained development resources. But we strive as much
as possible to ensure that they are rare exceptions.
-264
View File
@@ -1,264 +0,0 @@
ImageBufAlgo Highway (hwy) Implementation Guide
==============================================
This document explains how OpenImageIO uses Google Highway (hwy) to accelerate
selected `ImageBufAlgo` operations, and how to add or modify kernels in a way
that preserves OIIO semantics while keeping the code maintainable.
This is a developer-facing document about the implementation structure in
`src/libOpenImageIO/`. It does not describe the public API behavior of the
algorithms.
Goals and non-goals
-------------------
Goals:
- Make the hwy-backed code paths easy to read and easy to extend.
- Centralize repetitive boilerplate (type conversion, tails, ROI pointer math).
- Preserve OIIO's numeric semantics (normalized integer model).
- Keep scalar fallbacks as the source of truth for tricky layout cases.
Non-goals:
- Explain Highway itself. Refer to the upstream Highway documentation.
- Guarantee that every ImageBufAlgo op has a hwy implementation.
Where the code lives
--------------------
Core helpers:
- `src/libOpenImageIO/imagebufalgo_hwy_pvt.h`
Typical hwy call sites:
- `src/libOpenImageIO/imagebufalgo_addsub.cpp`
- `src/libOpenImageIO/imagebufalgo_muldiv.cpp`
- `src/libOpenImageIO/imagebufalgo_mad.cpp`
- `src/libOpenImageIO/imagebufalgo_pixelmath.cpp`
- `src/libOpenImageIO/imagebufalgo_xform.cpp` (some ops are hwy-accelerated)
Enabling and gating the hwy path
-------------------------------
The hwy path is only used when:
- Highway usage is enabled at runtime (`OIIO::pvt::enable_hwy`).
- The relevant `ImageBuf` objects have local pixel storage (`localpixels()` is
non-null), meaning the data is in process memory rather than accessed through
an `ImageCache` tile abstraction.
- The operation can be safely expressed as contiguous streams of pixels/channels
for the hot path, or the code falls back to a scalar implementation for
strided/non-contiguous layouts.
The common gating pattern looks like:
- In a typed `*_impl` dispatcher: check `OIIO::pvt::enable_hwy` and `localpixels`
and then call a `*_impl_hwy` function; otherwise call `*_impl_scalar`.
Important: the hwy path is an optimization. Correctness must not depend on hwy.
OIIO numeric semantics: why we promote to float
----------------------------------------------
OIIO treats integer image pixels as normalized values:
- Unsigned integers represent [0, 1].
- Signed integers represent approximately [-1, 1] with clamping for INT_MIN.
Therefore, most pixel math must be performed in float (or double) space, even
when the stored data is integer. This is why the hwy layer uses the
"LoadPromote/Operate/DemoteStore" pattern.
For additional discussion (and pitfalls of saturating integer arithmetic), see:
- `HIGHWAY_SATURATING_ANALYSIS.md`
The core pattern: LoadPromote -> RunHwy* -> DemoteStore
-------------------------------------------------------
The helper header `imagebufalgo_hwy_pvt.h` defines the reusable building blocks:
1) Computation type selection
- `SimdMathType<T>` selects `float` for most types, and `double` only when
the destination type is `double`.
Rationale:
- Float math is significantly faster on many targets.
- For OIIO, integer images are normalized to [0,1] (or ~[-1,1]), so float
precision is sufficient for typical image processing workloads.
2) Load and promote (with normalization)
- `LoadPromote(d, ptr)` and `LoadPromoteN(d, ptr, count)` load values and
normalize integer ranges into the computation space.
Rationale:
- Consolidates all normalization and conversion logic in one place.
- Prevents subtle drift where each operation re-implements integer scaling.
- Ensures tail handling ("N" variants) is correct and consistent.
3) Demote and store (with denormalization/clamp/round)
- `DemoteStore(d, ptr, v)` and `DemoteStoreN(d, ptr, v, count)` reverse the
normalization and store results in the destination pixel type.
Rationale:
- Centralizes rounding and clamping behavior for all destination types.
- Ensures output matches OIIO scalar semantics.
4) Generic kernel runners (streaming arrays)
- `RunHwyUnaryCmd`, `RunHwyCmd` (binary), `RunHwyTernaryCmd`
- These are the primary entry points for most hwy kernels.
Rationale:
- Encapsulates lane iteration and tail processing once.
- The call sites only provide the per-lane math lambda, not the boilerplate.
Native integer runners: when they are valid
-------------------------------------------
Some operations are "scale-invariant" under OIIO's normalized integer model.
For example, for unsigned integer add:
- `(a/max + b/max)` in float space, then clamped to [0,1], then scaled by max
matches saturated integer add `SaturatedAdd(a, b)` for the same bit depth.
For those cases, `imagebufalgo_hwy_pvt.h` provides:
- `RunHwyUnaryNativeInt<T>`
- `RunHwyBinaryNativeInt<T>`
These should only be used when all of the following are true:
- The operation is known to be scale-invariant under the normalization model.
- Input and output types are the same integral type.
- The operation does not depend on mixed types or float-range behavior.
Rationale:
- Avoids promotion/demotion overhead and can be materially faster.
- Must be opt-in and explicit, because many operations are NOT compatible with
raw integer arithmetic (e.g. multiplication, division, pow).
Local pixel pointer helpers: reducing boilerplate safely
-------------------------------------------------------
Most hwy call sites need repeated pointer and stride computations:
- Pixel size in bytes.
- Scanline size in bytes.
- Base pointer to local pixels.
- Per-row pointer for a given ROI and scanline.
- Per-pixel pointer for non-contiguous fallbacks.
To centralize that, `imagebufalgo_hwy_pvt.h` defines:
- `HwyPixels(ImageBuf&)` and `HwyPixels(const ImageBuf&)`
returning a small view (`HwyLocalPixelsView`) with:
- base pointer (`std::byte*` / `const std::byte*`)
- `pixel_bytes`, `scanline_bytes`
- `xbegin`, `ybegin`, `nchannels`
- `RoiNChannels(roi)` for `roi.chend - roi.chbegin`
- `ChannelsContiguous<T>(view, nchannels)`:
true only when the pixel stride exactly equals `nchannels * sizeof(T)`
- `PixelBase(view, x, y)`, `ChannelPtr<T>(view, x, y, ch)`
- `RoiRowPtr<T>(view, y, roi)` for the start of the ROI row at `roi.xbegin` and
`roi.chbegin`.
Rationale:
- Avoids duplicating fragile byte-offset math across many ops.
- Makes it visually obvious what the code is doing: "get row pointer" vs
"compute offset by hand."
- Makes non-contiguous fallback paths less error-prone by reusing the same
pointer computations.
Important: these helpers are only valid for `ImageBuf` instances with local
pixels (`localpixels()` non-null). The call sites must check that before using
them.
Contiguous fast path vs non-contiguous fallback
-----------------------------------------------
Most operations implement two paths:
1) Contiguous fast path:
- Used when pixels are tightly packed for the ROI's channel range.
- The operation is executed as a 1D stream of length:
`roi.width() * (roi.chend - roi.chbegin)`
- Uses `RunHwy*Cmd` (or native-int runner) and benefits from:
- fewer branches
- fewer pointer computations
- auto tail handling
2) Non-contiguous fallback:
- Used when pixels have padding, unusual strides, or channel subsets that do
not form a dense stream.
- Typically loops pixel-by-pixel and channel-by-channel.
- May still use the `ChannelPtr` helpers to compute correct addresses.
Rationale:
- The contiguous path is where SIMD delivers large gains.
- Trying to SIMD-optimize arbitrary strided layouts often increases complexity
and risk for marginal benefit. Keeping a scalar fallback preserves
correctness and maintainability.
How to add a new hwy kernel
---------------------------
Step 1: Choose the kernel shape
- Unary: `R = f(A)` -> use `RunHwyUnaryCmd`
- Binary: `R = f(A, B)` -> use `RunHwyCmd`
- Ternary: `R = f(A, B, C)` -> use `RunHwyTernaryCmd`
Step 2: Decide if a native-int fast path is valid
- Only for scale-invariant ops and same-type integral inputs/outputs.
- Use `RunHwyUnaryNativeInt` / `RunHwyBinaryNativeInt` when safe.
- Otherwise, always use the promote/demote runners.
Step 3: Implement the hwy body with a contig check
Typical structure inside `*_impl_hwy`:
- Acquire views once:
- `auto Rv = HwyPixels(R);`
- `auto Av = HwyPixels(A);` etc.
- In the parallel callback:
- compute `nchannels = RoiNChannels(roi)`
- compute `contig = ChannelsContiguous<...>(...)` for each image
- for each scanline y:
- `Rtype* r_row = RoiRowPtr<Rtype>(Rv, y, roi);`
- `const Atype* a_row = RoiRowPtr<Atype>(Av, y, roi);` etc.
- if contig: call `RunHwy*` with `n = roi.width() * nchannels`
- else: fall back per pixel, per channel
Step 4: Keep the scalar path as the reference
- The scalar implementation should remain correct for all layouts and types.
- The hwy path should match scalar results for supported cases.
Design rationale summary
------------------------
This design intentionally separates concerns:
- Type conversion and normalization are centralized (`LoadPromote`,
`DemoteStore`).
- SIMD lane iteration and tail handling are centralized (`RunHwy*` runners).
- Image address computations are centralized (`HwyPixels`, `RoiRowPtr`,
`ChannelPtr`).
- Operation-specific code is reduced to short lambdas expressing the math.
This makes the hwy layer:
- Easier to maintain: fewer places to fix bugs when semantics change.
- Easier to extend: adding an op mostly means writing the math lambda and the
dispatch glue.
- Safer: correctness for unusual layouts remains in scalar fallbacks.
Notes on `half`
---------------
The hwy conversion helpers handle `half` by converting through
`hwy::float16_t`. This currently assumes the underlying `half` representation
is compatible with how Highway loads/stores 16-bit floats.
If this assumption is revisited in the future, it should be changed as a
separate, explicit correctness/performance project.
<!-- SPDX-License-Identifier: CC-BY-4.0 -->
<!-- Copyright Contributors to the OpenImageIO Project. -->
-481
View File
@@ -1,481 +0,0 @@
<!-- SPDX-License-Identifier: CC-BY-4.0 -->
<!-- Copyright Contributors to the OpenImageIO Project. -->
# Release Procedures for OpenImageIO
## Version nomenclature and release cadence
### The meaning of the version parts
Our release numbers are of the form `MAJOR.MINOR.PATCH.TWEAK`, and we follow
an almost-semantic-versioning scheme.
MAJOR releases are those that break backward-compatibility of the public APIs,
requiring existing application code to change their source code where it calls
OIIO API functions in order to compile and work correctly.
MINOR releases guarantee API backward-compatibility with prior releases that
have the same major number, but can introduce ABI or link incompatibilities.
Applications using OIIO need to be recompiled to move to a new minor release,
but should not need to change their source code (except, of course, to take
advantage of new features). Minor releases are allowed to drop support for
sufficiently old compilers and dependencies.
PATCH releases guarantee both API and ABI/link backward-compatibility with
prior releases that have the same minor number. Features and new public API
calls may be added (thus deviating from strict semantic versioning), but only
if they preserve ABI/link compatibility. This means that standalone functions
or static methods may be added, but existing functions will not change their
parameters, and no new virtual methods or struct data layouts change for patch
releases (for classes in public header files). Application code can be
re-linked to a new patch release without needing to be recompiled. We also
guarantee that any compilers or dependencies supported for the first release
of a minor series will continue to be supported for all patches to that minor
series.
TWEAK releases are restricted to critical bug fixes or build breaks that do
not alter public APIs in any way.
### Cadence of releases
Major (arbitrarily incompatible) releases happen rarely, usually with multiple
years between them.
Minor (API backward-compatible) releases are scheduled annually, targeted at
late summer (SIGGRAPH time) to be in beta, and early autumn for a full
release.
Patch (API and ABI backward-compatible) releases are scheduled monthly,
usually aiming for the first day of each month.
Tweak (fully forward and backward compatible) releases are not regularly
scheduled, and only happen sporadically, when a critical fix is needed in
between scheduled patch releases.
### Things are different in "main"
The "main" branch is where ongoing development occurs without any
compatibility guarantees. We don't always know if the next year's release from
main will turn out to be major (API breaking) or minor (only ABI breaking).
Some studios or products need the most up-to-date enhancements, and thus tend
to build OIIO from the "main" branch rather than using tagged releases. For
these users, we try to set version numbers and occasionally tag in main, to
send a signal about which points in main seem safe to rely on various
compatibility levels. However, the rules are slightly different than we use
for releases.
In the "main" branch:
- TWEAK tags within "main" only guarantee ABI back-compatibility, but may
have additions or non-bug-fix behavior changes (akin to patch releases
within a release branch).
- PATCH tags within "main" are allowed to break ABI or API (changes that
would require minor or major releases, if they were not in "main").
- Beware of unmarked breaks in compatibility of commits in main that are
in between developer preview tags.
---
## Branch and tag names
**Branches** are places where commits containing new development may be added
(and thus the branch markers will move over time). Branch names obey the
following conventions:
- `main` is the area for arbitrary changes intended for the next year's
major or minor release.
- `dev-1.2` are the areas for staging additions that will become the next
tweak or patch release for the minor version series.
- `release` is a special branch marker that is always set to the latest tag of
the currently supported, stable release family. People can count on
"release" always being the latest stable release, whatever that may be at
the time.
**Tags** indicate releases or developer previews, and once a commit is
tagged, it is permanent and will never be moved. Tag names obey the following
conventions:
- `v1.2.3.4` is a specific public stable release, corresponding to official
major, minor, public, or tweak releases.
- `v1.2.3.4-alpha`, `v1.2.3.4-beta`, or `v1.2.3.4-RC1` are pre-releases for an
upcoming public stable release, at the alpha, beta, or release candidate
stages, respectively.
- `v1.2.3.4-dev` is a "developer preview" within "main." It is not an official
supported release, and while the numbering may indicate compatibility versus
other recent developer previews, they should not be assumed to be compatible
with any prior official stable releases.
*Very* occasionally, other branch or tag names (with custom suffixes or
different naming schemes) may be used for special purposes by particular
developers or users, but should not be considered reliable or permanent, and
in general should be ignored by anyone who didn't make the tag or branch.
---
## Release Procedures
### Soft freeze for monthly tweak releases:
We freely backport *safe*, non-ABI-breaking changes by cherry-picking them
from main to the supported branch continually throughout most of the month.
In the seven days before the new month, we do a "soft freeze" where only
important bug fixes are backported. Hold on to any other patches you wish to
backport until after the monthly patch release (i.e., save them for the next
month's release so you never have a release that contains changes that are
only a few days old, and therefore not as well tested). You may, of course,
continue to backport fixes to documentation or other non-code parts of the
project during this soft freeze.
### Branching for annual major/minor releases
By mid-June (about 1-2 months before the beta of a new annual big release),
you should branch and mark it as an alpha.
At the tip of "main", create a new branch named `dev-MAJOR.MINOR` that will
be the staging area for the next release.
Customarily, at that point we add a commit to main (but not to the new
dev-MAJ.MIN branch) that bumps main's version to the next minor level, to
avoid any confusion between builds from main versus what will be the next
release branch. This starts the divergence between main and the release
branch, and henceforth, any big or compatibility-breaking changes will only be
committed to main and not backported to the release branch. (Though we are
loose about this rule during the alpha period and allow continued breaking
changes in the alpha, but by the time we call it beta, we allow no more
breaking changes.) Also at this stage, the main branch's CHANGES.md should
have a heading added at the top for the *next* version.
### Prior to a release
1. Update CI dependencies: Ensure that the "latest" CI test specifies the
current releases of the dependencies and compilers (check their home
pages), and that the [INSTALL.md](../INSTALL.md) file correctly documents
the version ranges that we expect to work and that we actively test.
2. Update deprecations: Deprecations tend to happen in stages, spread over a
few releases, taking steps forward depending on what kind of release is
occurring:
- Tweak releases (a.b.c.d -> a.b.c.D+1): should not introduce new
deprecations.
- Monthly patch releases (a.b.c.d -> a.b.C+1.0): advertise that a function
is deprecated in its comments, documentation, and release notes. Remember
that these releases are not allowed to break ABI/link compatibility.
- Annual minor releases (a.b.c.d -> a.B+1.0.0): functions previously
marked/documented as deprecated should receive deprecation warnings by
adding `OIIO_DEPRECATED` macros to function or class declarations where
possible, if that has not already been done. Use good judgment about
whether to add these warnings, or postpone to a later release, based on
the amount of disruption that they will likely cause, and how important
it is to rapidly discourage people from using the deprecated function.
For a minor release, we don't allow backwards-incompatible API changes,
so only *remove* a function if there is another function that will accept
the same call signature in the source code. It's allowed to break ABI for
minor releases, so it's ok/encouraged to make a deprecated function from
linked to inline, for example (which might allow it to be removed later
without an ABI change).
- Major releases (a.b.c.d -> A+1.0.0.0): API compatibility breaks are
allowed here, so this is the time to completely remove any functions that
have already had a full minor release where they had been given
deprecation warning macros.
3. Release notes: [CHANGES.md](../CHANGES.md) should be updated to reflect
all the new features and fixes. Looking at the notes from older releases
should provide a good example of what we're aiming for.
- Patch and tweak releases can be brief one-line descriptions (often the
first line of the commit messages involved), presented in a single
section in either chronological or any other order that seems right.
- Minor or major releases have a much more extensive, prose-based
description of all changes since the last minor release, broken into
sections (dependency changes, major new features, enhancements and fixes,
internals and developer goodies, testing/CI/ports, etc.) and ordered for
readability and relevance.
4. Ensure docs are up to date:
- [README.md](README.md): Actually read it! Make sure it all seems
accurate and up to date.
- [INSTALL.md](INSTALL.md): Be sure that it accurately reflects the
current minimum and latest-tested versions of each dependency.
- [CREDITS.md](CREDITS.md): Check against the recent repo history to be
sure new contributors are listed.
- [SECURITY.md](SECURITY.md): Make sure it accurately reflects the
status of which branches get updates.
- Skim the [user documentation](https://docs.openimageio.org) to
ensure it's building correctly and doesn't have any obvious errors,
especially the parts that describe new features.
5. Make sure the the top-level CMakeLists.txt file is updated:
- The `OpenImageIO_VERSION` should be correct.
- The `PROJECT_VERSION_RELEASE_TYPE` variable should be set to "alpha" or
"beta" if appropriate, "RC" for release candidate, or empty string `""`
for most supported releases, and "dev" only for the main branch or
developer previews.
- The `${PROJECT_NAME}_SUPPORTED_RELEASE` variable should be `ON` for any
release branch, `OFF` for main.
6. In the https://github.com/AcademySoftwareFoundation/OpenImageIO-images project, create a branch
`dev-x.y` for the major/minor branch, and in the main oiio repo, update
src/build-scripts/install_test_images.bash to specify `-b dev-x.y` in the
checkout of oiio-images to ensure CI tests are against the set of test
images corresponding to that major/minor release (just in the branch, not
in main!).
7. Make sure everything passes the usual CI workflow. Also check the daily or
weekly "analysis" workflows to make sure there aren't any important
warnings that should be fixed.
### Staging alpha / beta / release candidate (annual minor/major releases only)
For monthly patch releases, we don't have any formal alpha/beta/RC stages.
For the annual minor or major releases we have a staged release:
- `alpha` is everything after we have branched, in which we think all the big
new features have been added, and while we will make continued changes and
fixes, we are aiming for increased stability and to minimize additional
breaking changes prior to the release.
- `beta` should be about one month prior to the final release date. We create
a tag `v1.2.3.4-beta` and announce the beta (see below "Making the
release"). Once we tag a beta, we try very hard not to allow any further
changes that change the API or are not ABI-compatible (i.e., safe fixes
only).
- `RC` or release candidates around one week prior to the final release date.
This is a trial run, hopefully identical to the final release (except for
removing the RC label and making a new tag). The only changes allowed after
RC are fixes to the most critical bugs or build breaks that would be bad for
users to encounter. If critical problems are found with RC1, they should be
fixed and immediately re-tagged as RC2, etc. All other fixes should be
postponed until the next month's patch release.
### Making the release
A final release is made on the scheduled date, provided the latest RC has
survived for at least a few days of testing without finding any critical
problems. Don't make the release final until you are sure there are no
truly critical bugs or build breaks that users will encounter.
The following are the steps for making the release:
1. Double check the top-level CMakeLists.txt to ensure the right version
number and type of version designation (i.e.,
`PROJECT_VERSION_RELEASE_TYPE` should be set appropriately).
2. Edit CHANGES.md to reflect the correct date of the release and ensure it
includes any last-minute changes that were made during beta or release
candidate stages. Please see the section "Generating release notes" below.
3. Push it to **your** GitHub fork, make sure it passes CI.
4. Tag the release with a signed tag:
$ git tag -s v1.2.3.4 # add a signed tag
$ git tag -v v1.2.3.4 # verify the tag
Be sure that the tag also reflects if it's an alpha (v1.2.3.4-alpha),
beta (v1.2.3.4-beta), release candidate (v1.2.3.4-RC1), or developer
preview (v1.2.3.4-dev). If it's a final release, just use the plain
version number (v1.2.3.4).
Note that the tag signing requires you to have a GPG key set up and
associated with your GitHub account. Please see [GitHub's signed tagging instructions](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-tags) for more information.
If you get errors messages "gpg: signing failed: Inappropriate ioctl for device", then the solution is to first:
$ export GPG_TTY=$(tty)
5. If this will now be the recommended stable release, move the `release`
branch marker to the same position.
6. Push it to GitHub: `git push OpenImageIO release --tags`
(This example assumes "OpenImageIO" is the name of the remote for the
GitHub `AcademySoftwareFoundation/OpenImageIO` repo.)
7. Draft a release on GitHub: On https://github.com/AcademySoftwareFoundation/OpenImageIO/releases
select "Draft a new release." Choose the new tag you just pushed. Make the
release title "OpenImageIO v1.2.3.4" (and beta, etc., designation
if applicable). In the description, paste the release notes for this
release (from CHANGES.md). If this is a beta or release candidate, check
"this is a pre-release" box at the bottom.
8. Announce the release on the [oiio-dev mail list](https://lists.aswf.io/g/oiio-dev)
with the subject "Release: OpenImageIO v1.2.3.4" and using one of these
templates for the body of the email.
For a monthly patch release:
> We have tagged v3.1.0.0 as the latest production release and moved the
> "release" branch marker to that point. This is guaranteed to be API,
> ABI, and link back-compatible with prior 3.1 releases. Release notes
> can be found at *LINK TO THE GITHUB RELEASE PAGE.*
For an annual major/minor release:
> OpenImageIO version 3.1 has been released! Officially tagged as
> "v3.1.0.0", we have also moved the "release" branch tag to this
> position. Henceforth, 3.1 is the supported production release family.
> The API is now frozen -- we promise that subsequent 3.1.x releases
> (which should happen monthly) will not break back-compatibility of API,
> ABI, or linkage, compared to this release. Please note that this release
> is *not* ABI or link compatible with 3.0 or older releases.
>
> Release notes for 3.1 outlining all the changes since last year's
> release can be found at *LINK TO THE GITHUB RELEASE PAGE.*
> (Optionally, you can include a brief summary of the most important
> changes in this email.)
>
> Please note that a few of the build and runtime dependencies have
> changed their minimum supported versions. (List here any important
> changes to dependencies, compilers, or C++ standard that users should be
> aware of.)
>
> (List here anything else that people should know about this release
> family that may be surprising if they haven't followed the last year of
> development closely, or that they must know even if they are too lazy to
> read the release notes. If this is a major release that is not
> backward-compatible with prior versions, warn about that here.)
>
> Enjoy, and please report any problems. We will continue to make patch
> releases to the 3.1 family roughly monthly, which will contain bug fixes
> and non-breaking enhancements.
>
> The older 3.0 series of releases is now considered obsolete. We will
> continue for now to make 3.0 patch releases, but over time, these will
> become less frequent and be reserved for only the most critical bug
> fixes.
>
> The "main" branch is now progressing toward an eventual 3.2 release next
> fall. As usual, you are welcome to use main for real work, but we do
> not make any compatibility guarantees and don't guarantee continuing API
> compatibility within main.
>
> (Paste the full set of 3.1 changes here, just copy the appropriate
> part of CHANGES.md)
For a beta leading up to the annual major/minor release:
> OpenImageIO version 3.1 is now in beta, tagged as "v3.1.0.0-beta". We
> will try very hard not to make any further API or ABI changes between
> now and the final release (unless it is absolutely necessary to fix
> an important problem identified during beta testing). The final 3.1
> release is scheduled for [DATE GOES HERE], so please try building and
> testing the beta so we are sure to find any problems.
>
> Release notes for 3.1 outlining all the changes since last year's
> release are below.
>
> (Paste the full set of 3.1 changes here, just copy the appropriate
> part of CHANGES.md)
### After the release
Odds and ends to do after the tag is pushed and the announcements are sent:
- Re-read RELEASING.md and ensure that the instructions match what you
have done. Update as necessary.
- Go to [OIIO's docs hosted on readthedocs.org](https://docs.openimageio.org),
and ensure that the new release is built, visible, and is the default
release shown (specified in the Admin section). I tend to keep the latest
patch of each minor release available for reference indefinitely, but hide
the docs for earlier patch releases within that minor release series.
- Edit the top-level CMakeList.txt to update the version to the *next*
anticipated release on the branch, in order to ensure that anybody building
from subsequent patches won't get a release number that advertises itself
incorrectly as a prior tagged release. Also edit CHANGES.md to add a new
(blank) heading for the next patch or release.
## Generating release notes
We strongly encourage the use of "conventional commit" prefixes in commit
messages. See [CONTRIBUTING.md](CONTRIBUTING.md#commit-messages) for details.
Many PRs are submitted (even by the author of this section you are now
reading!) without the conventional commit prefix. The person who approves and
merges the commit should take responsibility during the merge process to edit
the commit message to add the appropriate prefix (and for that matter, to edit
any part of the commit message for clarity). But at the end of the day, if we
end up with some commits lacking a conventional commit prefix, it's no big
deal -- we can fix it all up by hand when we make the release notes. But
having CC prefixes in as many commit messages possible helps make the release
notes process be simpler and more automated.
We have been using the [git-cliff](https://github.com/orhun/git-cliff) tool
as the starting point for release notes. The command we use is:
git cliff -c src/doc/cliff.toml v3.1.2.3..HEAD > cliff.out.md
where v3.1.2.3 in this example is the tag of the last release. You could also
use commit hashes to denote the range of changes you want to document.
**For monthly patch releases**
We have found that the git-cliff output is most of what we need for the patch
releases, and can be copied into the CHANGES.md file with only some minor
editing needed. The template for the patch release notes can be found in
[Changes-skeleton-patch.md](docs/dev/Changes-skeleton-patch.md).
* Get rid of the headings that git-cliff generates. We don't use the headings
for the patch releases.
* Add prefixes to any commits that don't have them (they will be marked as
"uncategorized" by git-cliff), and feel free to change any of the existing
prefixes that you think are wrong or could be improved for clarity.
* Rearrange the order of the entries to be logical and readable. I prefer the
order: feature enhancements, bug fixes, build system fixes that might impact
users, internal changes, test improvements, documentation and administrative
changes.
* For patch releases, feel free to omit any entries that you think are not
user-facing and are too minor to be worth mentioning in the release notes.
Strive to keep the release notes just long enough for users to know if the
patch contains any fixes relevant to them, but short enough to be read at a
glance and without extraneous detail.
Here is an example of well-constructed monthly patch release notes:
https://github.com/AcademySoftwareFoundation/OpenImageIO/releases/tag/v2.5.12.0
**For annual major/minor releases**
For major releases, the git-cliff output is just a starting point and need
significant editing to get the detail and quality level we expect for our
major releases. A simple bullet list of commits is not sufficient -- we aim
for a prose-based description of important changes that "tell the story" of
the year's work and will be thoroughly understood by our stakeholders who need
to understand what has changed.
* Copy all the headings from [Changes-skeleton-major.md](docs/dev/Changes-skeleton-major.md)
or the previous year's release notes to get the skeleton of the major and
minor headers that you fit everything into. Note that it mostly corresponds
to sections of the git-cliff output, but with a more carefully constructed
hierarchy of categories.
* Add prefixes to any commits that don't have them (they will be marked as
"uncategorized" by git-cliff), and feel free to change any of the existing
prefixes that you think are wrong or could be improved for clarity.
* Rearrange the git-cliff output into the hierarchy of our preferred major
release notes organization. Within each section and subsection, group
similar changes together. The chronological order of the commits isn't as
important as clearly explaining what changed over the course of the year.
* The git-cliff output is a good starting point for populating the notes with
every PR, plus automatically adding a reference and link to the PR and the
name of the author of the patch.
* Look with a skeptical eye at the one-line bullet points from git-cliff (i.e,
from the first line of each PR's commit message). Often, they are too terse
or tend to [bury the lede](https://www.dictionary.com/e/slang/bury-the-lede/).
Expand into as much explanation is necessary for users who need to know
about the change or feature to know whether it is relevant and have some
idea what to do or that they should look at the relevant PRs for more
detail.
Here is an example of well-constructed annual major release notes:
https://github.com/AcademySoftwareFoundation/OpenImageIO/releases/tag/v2.5.4.0
-167
View File
@@ -1,167 +0,0 @@
# See docs at https://cibuildwheel.pypa.io/en/stable/options
# for description of all the options in this file.
[project]
name = "OpenImageIO"
# The build backend ascertains the version from the CMakeLists.txt file.
dynamic = ["version"]
description = "Reading, writing, and processing images in a wide variety of file formats, using a format-agnostic API, aimed at VFX applications."
authors = [
{name = "Larry Gritz", email = "lg@larrygritz.com"},
{name = "OpenImageIO Contributors", email = "oiio-dev@lists.aswf.io"}
]
maintainers = [
{name = "OpenImageIO Contributors", email="oiio-dev@lists.aswf.io"},
]
readme = "README.md"
license = {text = "Apache-2.0"}
classifiers = [
"Natural Language :: English",
"Operating System :: OS Independent",
"Programming Language :: Python :: 3",
"Programming Language :: Python :: 3.9",
"Programming Language :: Python :: 3.10",
"Programming Language :: Python :: 3.11",
"Programming Language :: Python :: 3.12",
"Programming Language :: Python :: 3.13",
"Programming Language :: Python :: 3.14",
"License :: OSI Approved :: Apache Software License",
"Topic :: Multimedia :: Graphics",
"Topic :: Multimedia :: Video",
"Topic :: Multimedia :: Video :: Display",
"Topic :: Software Development :: Libraries :: Python Modules",
]
requires-python = ">= 3.9"
dependencies = [
"numpy>=2.0,<3",
]
[project.urls]
Homepage = "https://openimageio.org/"
Source = "https://github.com/AcademySoftwareFoundation/OpenImageIO"
Documentation = "https://docs.openimageio.org"
Issues = "https://github.com/AcademySoftwareFoundation/OpenImageIO/issues"
[project.scripts]
# Use the convention below to expose CLI tools as Python scripts.
idiff = "OpenImageIO:_command_line"
maketx = "OpenImageIO:_command_line"
oiiotool = "OpenImageIO:_command_line"
[build-system]
build-backend = "scikit_build_core.build"
requires = [
"scikit-build-core>=0.10.6,<1",
"pybind11>=2.13,<4",
]
[tool.scikit-build]
build.verbose = true
# Exclude unnecessary directories from the source distribution.
sdist.exclude = [".github", "testsuite", "ASWF", "docs"]
# Pin minimum scikit-build-core to that specified in build-system.requires.
minimum-version = "build-system.requires"
# Pin minimum CMake version to that specified in CMakeLists.txt.
cmake.version = "CMakeLists.txt"
wheel.license-files = ["LICENSE.md", "THIRD-PARTY.md"]
# Make sure the package is structured as expected.
wheel.install-dir = "OpenImageIO"
# Only install the user and fonts components.
install.components = ["user", "fonts"]
[tool.scikit-build.cmake.define]
# Build missing dependencies. See src/cmake for details.
OpenImageIO_BUILD_MISSING_DEPS = "all"
# Don't build tests. Dramatically improves build time.
OIIO_BUILD_TESTS = "0"
# Prefer linking static dependencies when possible.
LINKSTATIC = "1"
# Standardize the install directory for libraries, as expected by
# other parts of the wheels build process.
CMAKE_INSTALL_LIBDIR = "lib"
# Dynamically set the package version metadata by pasrsing CMakeLists.txt.
[tool.scikit-build.metadata.version]
provider = "scikit_build_core.metadata.regex"
input = "CMakeLists.txt"
regex = 'set \(OpenImageIO_VERSION "(?P<value>[0-9a-z.]+)"\)'
# On macOS, ensure dependencies are only built for the target architecture.
[[tool.scikit-build.overrides]]
if.platform-system = "darwin"
if.platform-machine = "arm64"
inherit.cmake.define = "append"
cmake.define.CMAKE_OSX_ARCHITECTURES = "arm64"
cmake.define.CMAKE_OSX_DEPLOYMENT_TARGET = "11"
[[tool.scikit-build.overrides]]
if.platform-system = "darwin"
if.platform-machine = "x86_64"
inherit.cmake.define = "append"
cmake.define.CMAKE_OSX_ARCHITECTURES = "x86_64"
cmake.define.CMAKE_OSX_DEPLOYMENT_TARGET = "10.15"
[tool.cibuildwheel]
build-verbosity = 1
skip = [
# Skip 32-bit builds
"*-win32",
"*-manylinux_i686",
# Building with musl seems to work, but the repair-wheel step seems to fail...
# This may be a bug in repairwheel (or auditwheel)?
"*musllinux*",
# Skip free-threading builds
"cp3??t-*",
]
test-command = "oiiotool --buildinfo"
[tool.cibuildwheel.macos.environment]
CC = "/usr/bin/clang"
CXX = "/usr/bin/clang++"
SKBUILD_CMAKE_ARGS = "-DLINKSTATIC=1; -DIGNORE_HOMEBREWED_DEPS=1"
# Optimize for size (not speed).
SKBUILD_CMAKE_BUILD_TYPE = "MinSizeRel"
[tool.cibuildwheel.linux.environment]
SKBUILD_CMAKE_ARGS = "-DLINKSTATIC=1"
# Suppress warnings that cause linux cibuildwheel build to fail
CXXFLAGS = "-Wno-error=stringop-overflow -Wno-pragmas"
SKBUILD_CMAKE_BUILD_TYPE = "MinSizeRel"
# FIXME: Getting build problems when using WebP 1.6.0, so hold it back
WebP_BUILD_VERSION = "1.5.0"
[tool.cibuildwheel.windows.environment]
SKBUILD_CMAKE_BUILD_TYPE = "MinSizeRel"
# Temporarily disabled test below. The CI stub generation seems broken, and
# is failing CI every time. Just turn off this check until we can figure out
# why it is broken.
# ----
# [[tool.cibuildwheel.overrides]]
# # Trigger the build & validation of the python stubs for certain platforms.
# # The test command acts as a kind of "post-build" callback where it's possible
# # for the stub-generator to import the freshly-built wheel.
# # There are two entry-points which are designed to call generate_stubs.py through
# # this test command:
# # - `make pystubs` is called during local development to generate the
# # stubs and copy them into the git repo to be committed and reviewed.
# # - in CI, the cibuildwheel action is used to validate that the stubs match what
# # has been committed to the repo.
# test-requires = "mypy~=1.15.0 stubgenlib~=0.1.0"
# # Note: the python version here must be kept in sync with src/python/stubs/CMakeLists.txt
# select = "cp311-manylinux_*64"
# inherit.test-command = "append"
# test-command = [
# "python {project}/src/python/stubs/generate_stubs.py --out-path '/output' --validate-path '{project}/src/python/stubs/OpenImageIO/__init__.pyi'",
# ]
# ----
[tool.mypy]
files = [
"testsuite/python-*/src/",
]
mypy_path = [
"src/python/stubs",
]
check_untyped_defs = true
+259
View File
@@ -0,0 +1,259 @@
# SPI-specific settings
ifneq (${VERBOSE},)
$(info Including spi/Makefile-bits)
endif
# For Arnold builds, do:
#
# make OIIO_ARNOLD=1
#
# Otherwise a default 'make' will make a fully generic OIIO build.
OIIO_ARNOLD ?= 0
OIIO_VERS = $(shell grep "OpenImageIO VERSION" CMakeLists.txt | egrep -o "[0-9.]+")
ifeq (${OIIO_ARNOLD},1)
$(info Building for Arnold)
NAMESPACE ?= 'OpenImageIO_Arnold'
$(info Building generic OpenImageIO)
# NAMESPACE ?= 'OpenImageIO'
endif
#$(info MAKECMDGOALS = $(MAKECMDGOALS))
## Detect which SPI platform and set $platform, $COMPILER, $SPCOMP2_COMPILER,
## and PYTHON_VERSION. Lots of other decisions are based on these.
ifeq (${SP_OS}, rhel7)
# Rhel7 (current)
platform := rhel7
SPI_COMPILER_PLATFORM ?= gcc-6.3
ifeq (${SPI_COMPILER_PLATFORM},gcc-6.3)
SPCOMP2_COMPILER ?= gcc63
CMAKE_CXX_STANDARD ?= 14
LLVM_VERSION ?= 12.0.1
endif
SP_PLATFORM ?= linux
else ifeq (${platform}, macosx)
# Generic OSX machines (including LG's laptop)
COMPILER ?= clang
SPCOMP2_COMPILER ?= clang
CMAKE_CXX_STANDARD ?= 14
SP_OS ?= macosx
SP_PLATFORM ?= macosx
else
$(error Unknown SP_OS=${SP_OS} platform=${platform})
endif # endif ${SP_OS}
MY_CMAKE_FLAGS += -DSP_OS=${SP_OS} -DSP_PLATFORM=${SP_PLATFORM}
MY_CMAKE_FLAGS += -DSPI_COMPILER_PLATFORM=${SPI_COMPILER_PLATFORM}
MY_CMAKE_FLAGS += -DEXTRA_CPP_ARGS:STRING="-DOIIO_SPI=1" -DOIIO_SITE:STRING=spi
MY_CMAKE_FLAGS += -DSPI_TESTS=1 -DPROJECT_VERSION_RELEASE_TYPE=spi
MY_CMAKE_FLAGS += -DOIIO_NAMESPACE_INCLUDE_PATCH=1
MY_CMAKE_FLAGS += -DCMAKE_DEBUG_POSTFIX=${CMAKE_DEBUG_POSTFIX:-_d}
REZ_PACKAGE_ROOT ?= /shots/spi/home/software/packages
SPCOMP2_ROOT ?= /shots/spi/home/lib/SpComp2
## Rhel7 (current)
ifeq (${SP_OS}, rhel7)
PYTHON_VERSION ?= 2.7
USE_SIMD ?= sse4.1,aes
CMAKE ?= cmake
USE_NINJA ?= 1
NINJA ?= ninja
ifeq ($(USE_NINJA),1)
MY_CMAKE_FLAGS += -DCMAKE_MAKE_PROGRAM=${NINJA}
endif
export CCACHE_CPP2 ?= 1
# Override lib64 and use SPI convention of lib
MY_CMAKE_FLAGS += -DCMAKE_INSTALL_LIBDIR="${INSTALL_PREFIX}/lib"
ifeq (${OIIO_SPCOMP2},1)
MY_CMAKE_FLAGS += -DPYTHON_SITE_DIR="${INSTALL_PREFIX}/python"
else ifeq (${OIIO_ARNOLD},1)
OIIO_LIBNAME_SUFFIX=_Arnold
endif
#
# Compilers:
#
# A variety of tags can be used to try specific versions of gcc or
# clang from the site-specific places we have installed them.
LLVM_DIRECTORY ?= ${REZ_PACKAGE_ROOT}/llvm/${LLVM_VERSION}/${SPI_COMPILER_PLATFORM}
ifeq (${COMPILER},clang9)
LLVM_DIRECTORY := ${REZ_PACKAGE_ROOT}/llvm/9.0.1-1/${SPI_COMPILER_PLATFORM}
MY_CMAKE_FLAGS += -DCMAKE_C_COMPILER=${LLVM_DIRECTORY}/bin/clang -DCMAKE_CXX_COMPILER=${LLVM_DIRECTORY}/bin/clang++
else ifeq (${COMPILER},clang10)
LLVM_DIRECTORY := ${REZ_PACKAGE_ROOT}/llvm/10.0.0-1/${SPI_COMPILER_PLATFORM}
MY_CMAKE_FLAGS += -DCMAKE_C_COMPILER=${LLVM_DIRECTORY}/bin/clang -DCMAKE_CXX_COMPILER=${LLVM_DIRECTORY}/bin/clang++
else ifeq (${COMPILER},clang11)
LLVM_DIRECTORY := ${REZ_PACKAGE_ROOT}/llvm/11.0.0/${SPI_COMPILER_PLATFORM}
MY_CMAKE_FLAGS += -DCMAKE_C_COMPILER=${LLVM_DIRECTORY}/bin/clang -DCMAKE_CXX_COMPILER=${LLVM_DIRECTORY}/bin/clang++
else ifeq (${COMPILER},clang)
MY_CMAKE_FLAGS += -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++
else ifeq (${COMPILER}, gcc6)
MY_CMAKE_FLAGS += \
-DCMAKE_C_COMPILER=/opt/rh/devtoolset-6/root/usr/bin/gcc \
-DCMAKE_CXX_COMPILER=/opt/rh/devtoolset-6/root/usr/bin/g++
else ifeq (${COMPILER},gcc)
MY_CMAKE_FLAGS += -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++
else ifeq (${COMPILER},)
# default compiler is clang, taken from the LLVM directory
MY_CMAKE_FLAGS += \
-DCMAKE_C_COMPILER=${LLVM_DIRECTORY}/bin/clang \
-DCMAKE_CXX_COMPILER=${LLVM_DIRECTORY}/bin/clang++
endif
#
# Boost
#
BOOSTVERS ?= 1.70
SPBOOST_INC_DIR := /usr/include/boostroot/boost${BOOSTVERS}.0
SPBOOST_LIB_DIR := /usr/lib64/boostroot/boost${BOOSTVERS}.0
MY_CMAKE_FLAGS += \
-DBOOST_INCLUDEDIR=${SPBOOST_INC_DIR} \
-DBOOST_LIBRARYDIR=${SPBOOST_LIB_DIR}
#
# Python
#
PYTHON_INCLUDE_DIR ?= /usr/include/python${PYTHON_VERSION}
PYTHON_LIBRARY_DIR ?= /usr/lib64
PYTHON_LIBRARY ?= ${PYTHON_LIBRARY_DIR}/libpython${PYTHON_VERSION}.so
ifeq (${PYTHON_VERSION},3.7)
# Special sauce for Python 3.7
PYTHON_INCLUDE_DIR := /usr/include/python${PYTHON_VERSION}m
PYTHON_LIBRARY := ${PYTHON_LIBRARY_DIR}/libpython${PYTHON_VERSION}m.so
MY_CMAKE_FLAGS += \
-DPYTHONINTERP_FOUND=1 \
-DPYTHON_VERSION_STRING=3.7.3 \
-DPYTHON_VERSION_MAJOR=3 \
-DPYTHON_VERSION_MINOR=7 \
-DPYTHON_VERSION_PATCH=3 \
-DPython_ADDITIONAL_VERSIONS="${PYTHON_VERSION}"
else ifeq (${PYTHON_VERSION},2.7)
# Special sauce for Python 2.7
PYTHON_INCLUDE_DIR := /usr/include/python${PYTHON_VERSION}
PYTHON_LIBRARY := ${PYTHON_LIBRARY_DIR}/libpython${PYTHON_VERSION}.so
MY_CMAKE_FLAGS += \
-DPYTHONINTERP_FOUND=1 \
-DPYTHON_VERSION_STRING=2.7.5 \
-DPYTHON_VERSION_MAJOR=2 \
-DPYTHON_VERSION_MINOR=7 \
-DPYTHON_VERSION_PATCH=5 \
-DPython_ADDITIONAL_VERSIONS="${PYTHON_VERSION}"
endif
MY_CMAKE_FLAGS += \
-DPYTHON_INCLUDE_DIR:STRING=${PYTHON_INCLUDE_DIR} \
-DPYTHON_LIBRARY:STRING=${PYTHON_LIBRARY} \
-Dpybind11_ROOT:STRING=${REZ_PACKAGE_ROOT}/pybind11/2.6.2/python-${PYTHON_VERSION}
# Set our preferred OpenEXR path, but allow env variable to override
# with custom/test version.
OPENEXR_VERSION ?= 2.4.3
OpenEXR_ROOT ?= ${REZ_PACKAGE_ROOT}/OpenEXR/${OPENEXR_VERSION}/${SPI_COMPILER_PLATFORM}
MY_CMAKE_FLAGS += -DOpenEXR_ROOT=${OpenEXR_ROOT}
#
# SpComp2 and other weird SPI-installed packages
#
NUKE_VERSION ?= 11.2v3
SPCOMP2_FULLBOOST_SUFFIX = ${SP_OS}-${SPCOMP2_COMPILER}-boost${shell echo ${BOOSTVERS} | sed "s/\\.//"}
# $(info SPCOMP2_FULLBOOST_SUFFIX ${SPCOMP2_FULLBOOST_SUFFIX})
OPENCOLORIO_VERSION ?= 2.1.0
OpenColorIO_ROOT ?= ${REZ_PACKAGE_ROOT}/OpenColorIO/${OPENCOLORIO_VERSION}/${SPI_COMPILER_PLATFORM}/python-${PYTHON_VERSION}
#MY_CMAKE_FLAGS += -DOPENCOLORIO_LIBRARY=${OpenColorIO_ROOT}/lib/libOpenColorIO_SPI.so
OPENVDB_VERSION ?= 8.0.0-2
OpenVDB_ROOT ?= ${REZ_PACKAGE_ROOT}/OpenVDB/${OPENVDB_VERSION}/${SPI_COMPILER_PLATFORM}/python-${PYTHON_VERSION}/boost-${BOOSTVERS}
TBB_ROOT ?= /net/apps/rhel7/intel/tbb
TBB_LIBRARY ?= /net/apps/rhel7/intel/tbb/lib/intel64/gcc4.7
Libheif_ROOT ?= /shots/spi/home/lib/arnold/rhel7/libheif-1.3.2
MY_CMAKE_FLAGS += \
-DOpenColorIO_ROOT=${OpenColorIO_ROOT} \
-DOpenVDB_ROOT=${OpenVDB_ROOT} \
-DTBB_ROOT=${TBB_ROOT} \
-DTBB_LIBRARY=${TBB_LIBRARY} \
-DTBB_USE_DEBUG_BUILD=0 \
-DHDF5_CUSTOM=1 \
-DHDF5_LIBRARIES=/usr/lib64/libhdf5.so \
-DNuke_ROOT=/net/apps/rhel7/foundry/nuke${NUKE_VERSION} \
-DLibheif_ROOT=${Libheif_ROOT} \
-DFFMPEG_INCLUDES=/usr/include/ffmpegroot/ffmpeg42 \
-DFFMPEG_LIBRARIES="/usr/lib64/ffmpegroot/ffmpeg424/libavcodec.so;/usr/lib64/ffmpegroot/ffmpeg424/libavformat.so;/usr/lib64/ffmpegroot/ffmpeg424/libavutil.so;/usr/lib64/ffmpegroot/ffmpeg424/libswscale.so;" \
-DUSE_OPENCV=0 \
-DVISIBILITY_MAP_FILE:STRING="${working_dir}/site/spi/hidesymbols.map"
# LibRaw
LibRaw_ROOT ?= ${REZ_PACKAGE_ROOT}/LibRaw/0.21.0.0/${SPI_COMPILER_PLATFORM}
MY_CMAKE_FLAGS += -DLibRaw_ROOT=${LibRaw_ROOT}
LIBRAW_LIBDIR = ${LibRaw_ROOT}/lib
MY_CMAKE_FLAGS += -DWebP_ROOT=${REZ_PACKAGE_ROOT}/webp/1.2.1/${SPI_COMPILER_PLATFORM}
# Use libtiff I built myself, static, and try to hide its symbols.
MY_CMAKE_FLAGS += \
-DTIFF_INCLUDE_DIR:STRING=/usr/include \
-DTIFF_LIBRARIES:STRING=/net/soft_scratch/users/lg/tiff-4.0.3/rhel7/lib/libtiff.a \
-DEXTRA_DSO_LINK_ARGS:STRING="-Wl,--exclude-libs,libtiff.a"
# end rhel7
## Generic OSX machines (including LG's laptop)
else ifeq (${platform}, macosx)
USE_SIMD ?= sse4.2
MY_CMAKE_FLAGS += \
-DCMAKE_BUILD_WITH_INSTALL_RPATH=1 \
-DCMAKE_INSTALL_NAME_DIR="${working_dir}/dist/lib"
# A variety of tags can be used to try specific versions of gcc or
# clang from the site-specific places we have installed them.
ifeq (${COMPILER}, gcc6)
MY_CMAKE_FLAGS += \
-DCMAKE_C_COMPILER=gcc-6 -DCMAKE_CXX_COMPILER=g++-6
USE_LIBCPLUSPLUS := 0
else ifeq (${COMPILER}, gcc9)
MY_CMAKE_FLAGS += \
-DCMAKE_C_COMPILER=gcc-9 -DCMAKE_CXX_COMPILER=g++-9
USE_LIBCPLUSPLUS := 0
else ifeq (${COMPILER}, gcc10)
MY_CMAKE_FLAGS += \
-DCMAKE_C_COMPILER=gcc-10 -DCMAKE_CXX_COMPILER=g++-10
USE_LIBCPLUSPLUS := 0
else ifeq (${COMPILER}, gcc11)
MY_CMAKE_FLAGS += \
-DCMAKE_C_COMPILER=gcc-11 -DCMAKE_CXX_COMPILER=g++-11
USE_LIBCPLUSPLUS := 0
else ifeq (${COMPILER},clang13)
MY_CMAKE_FLAGS += -DCMAKE_C_COMPILER=/usr/local/opt/llvm@13/bin/clang \
-DCMAKE_CXX_COMPILER=/usr/local/opt/llvm@13/bin/clang++
else ifeq (${COMPILER},clang14)
MY_CMAKE_FLAGS += -DCMAKE_C_COMPILER=/usr/local/opt/llvm@14/bin/clang \
-DCMAKE_CXX_COMPILER=/usr/local/opt/llvm@14/bin/clang++
else ifeq (${COMPILER},clang15)
MY_CMAKE_FLAGS += -DCMAKE_C_COMPILER=/usr/local/opt/llvm@15/bin/clang \
-DCMAKE_CXX_COMPILER=/usr/local/opt/llvm@15/bin/clang++
else ifeq (${COMPILER},clang16)
MY_CMAKE_FLAGS += -DCMAKE_C_COMPILER=/usr/local/opt/llvm@16/bin/clang \
-DCMAKE_CXX_COMPILER=/usr/local/opt/llvm@16/bin/clang++
else ifeq (${COMPILER},clang)
MY_CMAKE_FLAGS += -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++
else ifeq (${COMPILER},gcc)
MY_CMAKE_FLAGS += -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++
else ifeq (${COMPILER},)
# default compiler is clang, taken from the LLVM directory
MY_CMAKE_FLAGS += \
-DCMAKE_C_COMPILER=${LLVM_DIRECTORY}/bin/clang \
-DCMAKE_CXX_COMPILER=${LLVM_DIRECTORY}/bin/clang++
endif
# end generic OSX
else
$(error Unknown SP_OS=${SP_OS} platform=${platform})
endif # endif ${SP_OS}
ifneq (${VERBOSE},)
$(info MY_CMAKE_FLAGS: $(MY_CMAKE_FLAGS))
endif
+6
View File
@@ -0,0 +1,6 @@
<cfg>
<version>@PROJECT_VERSION_MAJOR@.@PROJECT_VERSION_MINOR@.@PROJECT_VERSION_PATCH@.@PROJECT_VERSION_TWEAK@</version>
<appdir architecture="@SP_OS@">@OIIO_REZ_INSTALL_PATH@</appdir>
<launchprogram></launchprogram>
<setup></setup>
</cfg>
+7
View File
@@ -0,0 +1,7 @@
option (${PROJ_NAME}_SPIREZ "Enable extra bits for building for SPI Rez install" OFF)
set (${PROJ_NAME}_REZ_PACKAGE_NAME CACHE STRING "${PROJECT_NAME}")
if (${PROJ_NAME}_SPIREZ)
set (appcfg_filename "${CMAKE_BINARY_DIR}/${PROJECT_NAME}_${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}.${PROJECT_VERSION_PATCH}.${PROJECT_VERSION_TWEAK}.xml")
configure_file ("${PROJECT_SOURCE_DIR}/site/spi/appcfg.xml.in" "${appcfg_filename}")
endif ()
+4
View File
@@ -0,0 +1,4 @@
{
global: *;
local: TIFF*; _TIFF*; _tiff*;
};
+9 -11
View File
@@ -1,27 +1,25 @@
# SPDX-License-Identifier: Apache-2.0
# SPDX-License-Identifier: BSD-3-Clause and Apache-2.0
# Copyright Contributors to the OpenImageIO Project.
sonar.host.url=https://sonarcloud.io
# Required metadata
sonar.organization=academysoftwarefoundation
sonar.organization=openimageio
sonar.projectName=OpenImageIO
sonar.projectVersion=3.1
sonar.projectKey=AcademySoftwareFoundation_OpenImageIO
# Project links
sonar.links.homepage=https://github.com/AcademySoftwareFoundation/OpenImageIO
sonar.links.ci=https://github.com/AcademySoftwareFoundation/OpenImageIO/actions
sonar.links.scm=https://github.com/AcademySoftwareFoundation/OpenImageIO
sonar.links.issue=https://github.com/AcademySoftwareFoundation/OpenImageIO/issues
sonar.projectVersion=1.0
sonar.projectKey=OpenImageIO_oiio
# Source properties
sonar.sources=src
sonar.exclusions=src/doc/**,src/build-scripts/**,src/include/OpenImageIO/detail/pugixml/**,src/libutil/stb_sprintf.h,src/libutil/xxhash.cpp,src/include/OpenImageIO/detail/farmhash.h,src/libutil/farmhash.cpp
sonar.exclusions=src/doc/**,src/include/OpenImageIO/detail/pugixml/**,src/libutil/stb_sprintf.h,src/libutil/xxhash.cpp,src/include/OpenImageIO/detail/farmhash.h,src/libutil/farmhash.cpp
sonar.sourceEncoding=UTF-8
# C/C++ analyzer properties
sonar.cfamily.build-wrapper-output=build/bw_output
sonar.cfamily.gcov.reportsPath=_coverage
sonar.coverage.exclusions=src/iv/**,src/include/OpenImageIO/detail/pugixml/**,src/include/OpenImageIO/detail/fmt/**,src/libOpenImageIO/kissfft.hh
sonar.cfamily.cache.enabled=true
sonar.cfamily.cache.path=/tmp/sonarcache
sonar.verbose=false
+1 -1
View File
@@ -1,5 +1,5 @@
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# https://github.com/OpenImageIO/oiio
add_oiio_plugin (bmpinput.cpp bmpoutput.cpp bmp_pvt.cpp)
+1 -1
View File
@@ -1,6 +1,6 @@
// Copyright Contributors to the OpenImageIO project.
// SPDX-License-Identifier: Apache-2.0
// https://github.com/AcademySoftwareFoundation/OpenImageIO
// https://github.com/OpenImageIO/oiio
#include <OpenImageIO/filesystem.h>
+1 -1
View File
@@ -1,6 +1,6 @@
// Copyright Contributors to the OpenImageIO project.
// SPDX-License-Identifier: Apache-2.0
// https://github.com/AcademySoftwareFoundation/OpenImageIO
// https://github.com/OpenImageIO/oiio
#pragma once
+27 -58
View File
@@ -1,11 +1,10 @@
// Copyright Contributors to the OpenImageIO project.
// SPDX-License-Identifier: Apache-2.0
// https://github.com/AcademySoftwareFoundation/OpenImageIO
// https://github.com/OpenImageIO/oiio
#include <cstdio>
#include <OpenImageIO/filesystem.h>
#include <OpenImageIO/fmath.h>
#include <OpenImageIO/imageio.h>
#include "bmp_pvt.h"
@@ -24,7 +23,7 @@ public:
{
return feature == "ioproxy";
}
bool valid_file(Filesystem::IOProxy* ioproxy) const override;
bool valid_file(const std::string& filename) const override;
bool open(const std::string& name, ImageSpec& newspec) override;
bool open(const std::string& name, ImageSpec& newspec,
const ImageSpec& config) override;
@@ -95,13 +94,11 @@ OIIO_PLUGIN_EXPORTS_END
bool
BmpInput::valid_file(Filesystem::IOProxy* ioproxy) const
BmpInput::valid_file(const std::string& filename) const
{
if (!ioproxy || ioproxy->mode() != Filesystem::IOProxy::Mode::Read)
return false;
bmp_pvt::BmpFileHeader header;
return header.read_header(ioproxy) && header.isBmp();
Filesystem::IOFile file(filename, Filesystem::IOProxy::Read);
return file.opened() && header.read_header(&file) && header.isBmp();
}
@@ -186,14 +183,20 @@ BmpInput::open(const std::string& name, ImageSpec& newspec,
const int height = (m_dib_header.height >= 0) ? m_dib_header.height
: -m_dib_header.height;
m_spec = ImageSpec(m_dib_header.width, height, nchannels, TypeDesc::UINT8);
if (!check_open(m_spec, { 0, 1 << 16, 0, 1 << 16, 0, 1, 0, 4 }))
return false;
if (m_dib_header.hres > 0 && m_dib_header.vres > 0) {
m_spec.attribute("XResolution", (int)m_dib_header.hres);
m_spec.attribute("YResolution", (int)m_dib_header.vres);
m_spec.attribute("ResolutionUnit", "m");
}
if (m_spec.width < 1 || m_spec.height < 1 || m_spec.nchannels < 1
|| m_spec.image_bytes() < 1
|| m_spec.image_pixels() > std::numeric_limits<uint32_t>::max()) {
errorfmt(
"Invalid image size {} x {} ({} chans, {}), is likely corrupted",
m_spec.width, m_spec.height, m_spec.nchannels, m_spec.format);
close();
return false;
}
// Compute channel shifts & masks (only relevant for 16bpp case)
if (m_dib_header.red_mask == 0 || m_dib_header.green_mask == 0
@@ -253,17 +256,10 @@ BmpInput::open(const std::string& name, ImageSpec& newspec,
case WINDOWS_V5: m_spec.attribute("bmp:version", 5); break;
}
if (m_dib_header.cpalete && !m_colortable.size()) {
errorfmt(
"BMP error: bad BPP ({}) for palette image -- presumed corrupt file",
m_dib_header.bpp);
return false;
}
// Default presumption is that a BMP file is meant to look reasonable on a
// display, so assume it's sRGB. This is not really correct -- see the
// comments below.
m_spec.attribute("oiio:ColorSpace", "srgb_rec709_scene");
m_spec.attribute("oiio:ColorSpace", "sRGB");
#if 0
if (m_dib_header.size >= WINDOWS_V4
&& m_dib_header.cs_type == CSType::CalibratedRGB) {
@@ -303,8 +299,8 @@ BmpInput::read_rle_image()
m_uncompressed.clear();
m_uncompressed.resize(m_spec.image_pixels());
// Note: the clear+resize zeroes out the buffer
bool ok = true;
int64_t y = 0, x = 0;
bool ok = true;
int y = 0, x = 0;
while (ok) {
// Strutil::print("currently at {},{}\n", x, y);
unsigned char rle_pair[2];
@@ -315,7 +311,7 @@ BmpInput::read_rle_image()
}
if (y >= m_spec.height) { // out of y bounds
errorfmt(
"BMP might be corrupted, it is referencing an out-of-bounds pixel coordinate ({},{})",
"BMP might be corrupted, it is referencing an out-of-bounds pixel coordinte ({},{})",
x, y);
ok = false;
break;
@@ -392,31 +388,14 @@ BmpInput::read_native_scanline(int subimage, int miplevel, int y, int /*z*/,
size_t scanline_bytes = m_spec.scanline_bytes();
uint8_t* mscanline = (uint8_t*)data;
if ((m_dib_header.compression == RLE4_COMPRESSION
|| m_dib_header.compression == RLE8_COMPRESSION)
&& m_colortable.size()) {
if (m_spec.nchannels == 1) {
OIIO_CONTRACT_ASSERT(m_allgray);
for (int x = 0; x < m_spec.width; ++x) {
int p
= m_uncompressed[int64_t(m_spec.height - 1 - y) * m_spec.width
+ x];
auto& c = colortable(p);
mscanline[x] = c.r;
// For the "all gray" case, rgb are equal and we're filling in
// a 1-channel data buffer.
}
} else {
OIIO_CONTRACT_ASSERT(m_spec.nchannels == 3);
for (int x = 0; x < m_spec.width; ++x) {
int p
= m_uncompressed[int64_t(m_spec.height - 1 - y) * m_spec.width
+ x];
auto& c = colortable(p);
mscanline[3 * x] = c.r;
mscanline[3 * x + 1] = c.g;
mscanline[3 * x + 2] = c.b;
}
if (m_dib_header.compression == RLE4_COMPRESSION
|| m_dib_header.compression == RLE8_COMPRESSION) {
for (int x = 0; x < m_spec.width; ++x) {
int p = m_uncompressed[(m_spec.height - 1 - y) * m_spec.width + x];
auto& c = colortable(p);
mscanline[3 * x] = c.r;
mscanline[3 * x + 1] = c.g;
mscanline[3 * x + 2] = c.b;
}
return true;
}
@@ -425,19 +404,9 @@ BmpInput::read_native_scanline(int subimage, int miplevel, int y, int /*z*/,
if (m_dib_header.height >= 0)
y = m_spec.height - y - 1;
const int64_t scanline_off = y * m_padded_scanline_size;
const int64_t scanline_pos = int64_t(m_bmp_header.offset) + scanline_off;
// A corrupt header can place the scanline outside the file. The IOProxy
// will reject such a read, but validate the position explicitly so we
// fail cleanly instead of relying on a bad seek being caught downstream.
if (m_padded_scanline_size < 0 || scanline_pos < 0
|| scanline_pos + m_padded_scanline_size > int64_t(ioproxy()->size())) {
errorfmt("Invalid scanline position in BMP file");
return false;
}
fscanline.resize(m_padded_scanline_size);
ioseek(scanline_pos);
ioseek(m_bmp_header.offset + scanline_off);
if (!ioread(fscanline.data(), m_padded_scanline_size)) {
return false; // Read failed
}
+55 -5
View File
@@ -1,11 +1,10 @@
// Copyright Contributors to the OpenImageIO project.
// SPDX-License-Identifier: BSD-3-Clause and Apache-2.0
// https://github.com/AcademySoftwareFoundation/OpenImageIO
// https://github.com/OpenImageIO/oiio
#include <cstdio>
#include <OpenImageIO/filesystem.h>
#include <OpenImageIO/fmath.h>
#include <OpenImageIO/imageio.h>
#include <OpenImageIO/strutil.h>
@@ -27,6 +26,9 @@ public:
bool close(void) override;
bool write_scanline(int y, int z, TypeDesc format, const void* data,
stride_t xstride) override;
bool write_tile(int x, int y, int z, TypeDesc format, const void* data,
stride_t xstride, stride_t ystride,
stride_t zstride) override;
private:
int64_t m_padded_scanline_size;
@@ -35,6 +37,7 @@ private:
bmp_pvt::DibInformationHeader m_dib_header;
int64_t m_image_start;
unsigned int m_dither;
std::vector<unsigned char> m_tilebuffer;
std::vector<unsigned char> m_scratch;
std::vector<unsigned char> m_buf; // more tmp space for write_scanline
@@ -78,11 +81,27 @@ BmpOutput::supports(string_view feature) const
bool
BmpOutput::open(const std::string& name, const ImageSpec& spec, OpenMode mode)
{
if (!check_open(mode, spec, { 0, 65535, 0, 65535, 0, 1, 0, 4 },
uint64_t(OpenChecks::Disallow2Channel)))
if (mode != Create) {
errorfmt("{} does not support subimages or MIP levels", format_name());
return false;
}
// saving 'name' and 'spec' for later use
m_filename = name;
m_spec = spec;
if (m_spec.nchannels != 1 && m_spec.nchannels != 3
&& m_spec.nchannels != 4) {
errorfmt("{} does not support {}-channel images\n", format_name(),
m_spec.nchannels);
return false;
}
if (m_spec.x || m_spec.y || m_spec.z) {
errorfmt("{} does not support images with non-zero image origin offset",
format_name());
return false;
}
// Only support 8 bit channels for now.
m_spec.set_format(TypeDesc::UINT8);
@@ -106,6 +125,11 @@ BmpOutput::open(const std::string& name, const ImageSpec& spec, OpenMode mode)
m_image_start = iotell();
// If user asked for tiles -- which this format doesn't support, emulate
// it by buffering the whole image.
if (m_spec.tile_width && m_spec.tile_height)
m_tilebuffer.resize(m_spec.image_bytes());
return true;
}
@@ -148,6 +172,23 @@ BmpOutput::write_scanline(int y, int z, TypeDesc format, const void* data,
}
bool
BmpOutput::write_tile(int x, int y, int z, TypeDesc format, const void* data,
stride_t xstride, stride_t ystride, stride_t zstride)
{
if (!ioproxy_opened()) {
errorfmt("write_tile called but file is not open.");
return false;
}
// Emulate tiles by buffering the whole image
return copy_tile_to_image_buffer(x, y, z, format, data, xstride, ystride,
zstride, m_tilebuffer.data());
}
bool
BmpOutput::close(void)
{
@@ -156,8 +197,17 @@ BmpOutput::close(void)
return true;
}
bool ok = true;
if (m_spec.tile_width && m_tilebuffer.size()) {
// Handle tile emulation -- output the buffered pixels
OIIO_DASSERT(m_tilebuffer.size());
ok &= write_scanlines(m_spec.y, m_spec.y + m_spec.height, 0,
m_spec.format, m_tilebuffer.data());
std::vector<unsigned char>().swap(m_tilebuffer);
}
init();
return true;
return ok;
}
-60
View File
@@ -1,60 +0,0 @@
#!/usr/bin/env bash
# Utility script to download and build Freetype
#
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# Exit the whole script if any command fails.
set -ex
# Repo and branch/tag/commit of Freetype to download if we don't have it yet
FREETYPE_REPO=${FREETYPE_REPO:=https://github.com/freetype/freetype.git}
FREETYPE_VERSION=${FREETYPE_VERSION:=VER-2-14-1}
# Where to put Freetype repo source (default to the ext area)
LOCAL_DEPS_DIR=${LOCAL_DEPS_DIR:=${PWD}/ext}
FREETYPE_SRC_DIR=${FREETYPE_SRC_DIR:=${LOCAL_DEPS_DIR}/Freetype}
FREETYPE_BUILD_DIR=${FREETYPE_BUILD_DIR:=${FREETYPE_SRC_DIR}/build}
FREETYPE_INSTALL_DIR=${FREETYPE_INSTALL_DIR:=${LOCAL_DEPS_DIR}/dist}
FREETYPE_BUILD_TYPE=${FREETYPE_BUILD_TYPE:=Release}
# Fix for freetype breaking against cmake 4.0 because of too-old cmake min.
# Remove when freetype is fixed to declare its own minimum high enough.
export CMAKE_POLICY_VERSION_MINIMUM=3.5
pwd
echo "Freetype install dir will be: ${FREETYPE_INSTALL_DIR}"
mkdir -p ./ext
pushd ./ext
# Clone Freetype project from GitHub and build
if [[ ! -e ${FREETYPE_SRC_DIR} ]] ; then
echo "git clone ${FREETYPE_REPO} ${FREETYPE_SRC_DIR}"
git clone ${FREETYPE_REPO} ${FREETYPE_SRC_DIR}
fi
cd ${FREETYPE_SRC_DIR}
echo "git checkout ${FREETYPE_VERSION} --force"
git checkout ${FREETYPE_VERSION} --force
if [[ -z $DEP_DOWNLOAD_ONLY ]]; then
time cmake -S . -B ${FREETYPE_BUILD_DIR} \
-DCMAKE_BUILD_TYPE=${FREETYPE_BUILD_TYPE} \
-DBUILD_SHARED_LIBS=${FREETYPE_BUILD_SHARED_LIBS:-ON} \
-DCMAKE_INSTALL_PREFIX=${FREETYPE_INSTALL_DIR} \
-DCMAKE_POSITION_INDEPENDENT_CODE=ON \
${FREETYPE_CONFIG_OPTS}
time cmake --build ${FREETYPE_BUILD_DIR} --config ${FREETYPE_BUILD_TYPE} --target install
fi
# ls -R ${FREETYPE_INSTALL_DIR}
popd
# Set up paths. These will only affect the caller if this script is
# run with 'source' rather than in a separate shell.
export Freetype_ROOT=$FREETYPE_INSTALL_DIR
+8 -12
View File
@@ -4,14 +4,14 @@
#
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# https://github.com/OpenImageIO/oiio
# Exit the whole script if any command fails.
set -ex
# Repo and branch/tag/commit of OpenJPEG to download if we don't have it yet
OPENJPEG_REPO=${OPENJPEG_REPO:=https://github.com/uclouvain/openjpeg.git}
OPENJPEG_VERSION=${OPENJPEG_VERSION:=v2.5.4}
OPENJPEG_VERSION=${OPENJPEG_VERSION:=v2.4.0}
# Where to put OpenJPEG repo source (default to the ext area)
LOCAL_DEPS_DIR=${LOCAL_DEPS_DIR:=${PWD}/ext}
@@ -20,10 +20,6 @@ OPENJPEG_BUILD_DIR=${OPENJPEG_BUILD_DIR:=${OPENJPEG_SRC_DIR}/build}
OPENJPEG_INSTALL_DIR=${OPENJPEG_INSTALL_DIR:=${LOCAL_DEPS_DIR}/dist}
#OPENJPEG_CONFIG_OPTS=${OPENJPEG_CONFIG_OPTS:=}
# Fix for openjpeg breaking against cmake 4.0 because of too-old cmake min.
# Remove when openjpeg is fixed to declare its own minimum high enough.
export CMAKE_POLICY_VERSION_MINIMUM=3.5
pwd
echo "OpenJPEG install dir will be: ${OPENJPEG_INSTALL_DIR}"
@@ -40,15 +36,15 @@ cd ${OPENJPEG_SRC_DIR}
echo "git checkout ${OPENJPEG_VERSION} --force"
git checkout ${OPENJPEG_VERSION} --force
mkdir -p ${OPENJPEG_BUILD_DIR} && true
cd ${OPENJPEG_BUILD_DIR}
if [[ -z $DEP_DOWNLOAD_ONLY ]]; then
time cmake -S . -B ${OPENJPEG_BUILD_DIR} \
-DCMAKE_BUILD_TYPE=Release \
time cmake -DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_PREFIX=${OPENJPEG_INSTALL_DIR} \
-DBUILD_CODEC=OFF \
-DCMAKE_POSITION_INDEPENDENT_CODE=ON \
-DBUILD_SHARED_LIBS=${OPENJPEG_BUILD_SHARED_LIBS:-ON} \
${OPENJPEG_CONFIG_OPTS}
time cmake --build ${OPENJPEG_BUILD_DIR} --config Release --target install
${OPENJPEG_CONFIG_OPTS} ..
time cmake --build . --config Release --target install
fi
# ls -R ${OPENJPEG_INSTALL_DIR}
+6 -5
View File
@@ -4,7 +4,7 @@
#
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# https://github.com/OpenImageIO/oiio
# Exit the whole script if any command fails.
set -ex
@@ -31,11 +31,12 @@ cd ${PTEX_SRC_DIR}
echo "git checkout ${PTEX_VERSION} --force"
git checkout ${PTEX_VERSION} --force
time cmake -S . -B ${PTEX_BUILD_DIR} -DCMAKE_BUILD_TYPE=Release \
mkdir -p ${PTEX_BUILD_DIR}
cd ${PTEX_BUILD_DIR}
time cmake -DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_PREFIX=${PTEX_INSTALL_DIR} \
-DCMAKE_CXX_STANDARD=17 \
${PTEX_CONFIG_OPTS}
time cmake --build ${PTEX_BUILD_DIR} --config Release --target install
${PTEX_CONFIG_OPTS} ..
time cmake --build . --config Release --target install
# ls -R ${PTEX_INSTALL_DIR}
popd
-31
View File
@@ -1,31 +0,0 @@
#!/usr/bin/env bash
# Utility script to download and build abi checking tools
#
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# Exit the whole script if any command fails.
set -ex
# Where to install the final results
: ${LOCAL_DEPS_DIR:=${PWD}/ext}
: ${ABITOOLS_INSTALL_DIR:=${LOCAL_DEPS_DIR}/dist}
mkdir -p ${LOCAL_DEPS_DIR}
pushd ${LOCAL_DEPS_DIR}
git clone https://github.com/lvc/vtable-dumper
pushd vtable-dumper ; make install prefix=${ABITOOLS_INSTALL_DIR} ; popd
git clone https://github.com/lvc/abi-dumper
pushd abi-dumper ; make install prefix=${ABITOOLS_INSTALL_DIR} ; popd
git clone https://github.com/lvc/abi-compliance-checker
pushd abi-compliance-checker ; make install prefix=${ABITOOLS_INSTALL_DIR} ; popd
popd
# ls -R ${LOCAL_DEPS_DIR}
export PATH=${PATH}:${ABITOOLS_INSTALL_DIR}/bin
-77
View File
@@ -1,77 +0,0 @@
#!/usr/bin/env bash
# Utility script to download or build ccacheccache
#
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# Exit the whole script if any command fails.
set -ex
echo "Building ccache"
uname
ARCH=`uname -m`
echo "HOME=$HOME"
echo "PWD=$PWD"
echo "ARCH=$ARCH"
CCACHE_PREBUILT=${CCACHE_PREBUILT:=1}
# Repo and branch/tag/commit of ccache to download if we don't have it yet
CCACHE_REPO=${CCACHE_REPO:=https://github.com/ccache/ccache}
CCACHE_VERSION=${CCACHE_VERSION:=4.12}
CCACHE_TAG=${CCACHE_TAG:=v${CCACHE_VERSION}}
LOCAL_DEPS_DIR=${LOCAL_DEPS_DIR:=${PWD}/ext}
# Where to put ccache repo source (default to the ext area)
CCACHE_SRC_DIR=${CCACHE_SRC_DIR:=${LOCAL_DEPS_DIR}/ccache}
# Temp build area (default to a build/ subdir under source)
CCACHE_BUILD_DIR=${CCACHE_BUILD_DIR:=${CCACHE_SRC_DIR}/build}
# Install area for ccache (default to ext/dist)
CCACHE_INSTALL_DIR=${CCACHE_INSTALL_DIR:=${PWD}/ext/dist}
CCACHE_CONFIG_OPTS=${CCACHE_CONFIG_OPTS:=}
# if [[ `uname` == "Linux" && `uname -m` == "x86_64" ]] ; then
if [[ `uname` == "Linux" ]] ; then
mkdir -p ${CCACHE_SRC_DIR}
pushd ${CCACHE_SRC_DIR}
if [[ "$CCACHE_PREBUILT" != "0" ]] ; then
#
# Try to download -- had trouble with this on runners
#
CCACHE_DESCRIPTOR="ccache-${CCACHE_VERSION}-linux-x86_64"
curl --location "${CCACHE_REPO}/releases/download/${CCACHE_TAG}/${CCACHE_DESCRIPTOR}.tar.xz" -o ccache.tar.xz
tar xJvf ccache.tar.xz
mkdir -p ${CCACHE_INSTALL_DIR}/bin
cp ${CCACHE_SRC_DIR}/${CCACHE_DESCRIPTOR}/ccache ${CCACHE_INSTALL_DIR}/bin
else
# Clone ccache project from GitHub and build
if [[ ! -e ${CCACHE_SRC_DIR}/.git ]] ; then
echo "git clone ${CCACHE_REPO} ${CCACHE_SRC_DIR}"
git clone ${CCACHE_REPO} ${CCACHE_SRC_DIR}
fi
echo "git checkout ${CCACHE_TAG} --force"
git checkout ${CCACHE_TAG} --force
if [[ -z $DEP_DOWNLOAD_ONLY ]]; then
time cmake -S . -B ${CCACHE_BUILD_DIR} -DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_PREFIX=${CCACHE_INSTALL_DIR} \
-DENABLE_TESTING=OFF -DENABLE_DOCUMENTATION=OFF \
${CCACHE_CONFIG_OPTS}
time cmake --build ${CCACHE_BUILD_DIR} --config Release --target install
fi
fi
popd
ls ${CCACHE_INSTALL_DIR}
ls ${CCACHE_INSTALL_DIR}/bin
echo "CCACHE_INSTALL_DIR=$CCACHE_INSTALL_DIR"
echo "CCACHE_DIR=$CCACHE_DIR"
mkdir -p $CCACHE_DIR
ls $CCACHE_DIR || true
export PATH=${CCACHE_INSTALL_DIR}/bin:$PATH
${CCACHE_INSTALL_DIR}/bin/ccache -sv
fi
+4 -4
View File
@@ -4,7 +4,7 @@
#
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# https://github.com/OpenImageIO/oiio
# Exit the whole script if any command fails.
set -ex
@@ -12,7 +12,7 @@ set -ex
echo "Building cmake"
uname
CMAKE_VERSION=${CMAKE_VERSION:=3.31.3}
CMAKE_VERSION=${CMAKE_VERSION:=3.12.4}
LOCAL_DEPS_DIR=${LOCAL_DEPS_DIR:=${PWD}/ext}
CMAKE_INSTALL_DIR=${CMAKE_INSTALL_DIR:=${LOCAL_DEPS_DIR}/cmake}
@@ -25,8 +25,8 @@ fi
if [[ `uname` == "Linux" && `uname -m` == "aarch64" ]] ; then
mkdir -p ${CMAKE_INSTALL_DIR} || true
curl --location "https://github.com/Kitware/CMake/releases/download/v${CMAKE_VERSION}/cmake-${CMAKE_VERSION}-Linux-aarch64.sh" -o "cmake.sh"
sh cmake.sh --skip-license --prefix=${CMAKE_INSTALL_DIR}
curl --location https://anaconda.org/conda-forge/cmake/3.17.0/download/linux-aarch64/cmake-3.17.0-h28c56e5_0.tar.bz2 -o cmake-3.17.0-h28c56e5_0.tar.bz2
tar -xjf cmake-3.17.0-h28c56e5_0.tar.bz2 -C ${CMAKE_INSTALL_DIR}
export PATH=${CMAKE_INSTALL_DIR}/bin:$PATH
# In case we ever need to build from scratch:
+1 -1
View File
@@ -2,7 +2,7 @@
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# https://github.com/OpenImageIO/oiio
# Utility script to download and build giflib
+10 -9
View File
@@ -4,22 +4,21 @@
#
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# https://github.com/OpenImageIO/oiio
# Exit the whole script if any command fails.
set -ex
# Repo and branch/tag/commit of libjpeg-turbo to download if we don't have it yet
LIBJPEGTURBO_REPO=${LIBJPEGTURBO_REPO:=https://github.com/libjpeg-turbo/libjpeg-turbo.git}
LIBJPEGTURBO_VERSION=${LIBJPEGTURBO_VERSION:=3.1.2}
LIBJPEGTURBO_VERSION=${LIBJPEGTURBO_VERSION:=2.0.5}
# Where to put libjpeg-turbo repo source (default to the ext area)
LOCAL_DEPS_DIR=${LOCAL_DEPS_DIR:=${PWD}/ext}
LIBJPEGTURBO_SRC_DIR=${LIBJPEGTURBO_SRC_DIR:=${LOCAL_DEPS_DIR}/libjpeg-turbo}
LIBJPEGTURBO_SRC_DIR=${LIBJPEGTURBO_SRC_DIR:=${PWD}/ext/libjpeg-turbo}
# Temp build area (default to a build/ subdir under source)
LIBJPEGTURBO_BUILD_DIR=${LIBJPEGTURBO_BUILD_DIR:=${LIBJPEGTURBO_SRC_DIR}/build}
# Install area for libjpeg-turbo (default to ext/dist)
LIBJPEGTURBO_INSTALL_DIR=${LIBJPEGTURBO_INSTALL_DIR:=${LOCAL_DEPS_DIR}/dist}
LIBJPEGTURBO_INSTALL_DIR=${LIBJPEGTURBO_INSTALL_DIR:=${PWD}/ext/dist}
#LIBJPEGTURBO_CONFIG_OPTS=${LIBJPEGTURBO_CONFIG_OPTS:=}
pwd
@@ -37,11 +36,14 @@ cd ${LIBJPEGTURBO_SRC_DIR}
echo "git checkout ${LIBJPEGTURBO_VERSION} --force"
git checkout ${LIBJPEGTURBO_VERSION} --force
mkdir -p ${LIBJPEGTURBO_BUILD_DIR}
cd ${LIBJPEGTURBO_BUILD_DIR}
if [[ -z $DEP_DOWNLOAD_ONLY ]]; then
time cmake -S . -B ${LIBJPEGTURBO_BUILD_DIR} -DCMAKE_BUILD_TYPE=Release \
time cmake -DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_PREFIX=${LIBJPEGTURBO_INSTALL_DIR} \
${LIBJPEGTURBO_CONFIG_OPTS}
time cmake --build ${LIBJPEGTURBO_BUILD_DIR} --config Release --target install
${LIBJPEGTURBO_CONFIG_OPTS} ..
time cmake --build . --config Release --target install
fi
# ls -R ${LIBJPEGTURBO_INSTALL_DIR}
@@ -51,5 +53,4 @@ popd
# Set up paths. These will only affect the caller if this script is
# run with 'source' rather than in a separate shell.
export JPEGTurbo_ROOT=$LIBJPEGTURBO_INSTALL_DIR
export libjpegturbo_ROOT=$LIBJPEGTURBO_INSTALL_DIR
+9 -6
View File
@@ -4,14 +4,14 @@
#
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# https://github.com/OpenImageIO/oiio
# Exit the whole script if any command fails.
set -ex
# Repo and branch/tag/commit of libpng to download if we don't have it yet
LIBPNG_REPO=${LIBPNG_REPO:=https://github.com/pnggroup/libpng.git}
LIBPNG_VERSION=${LIBPNG_VERSION:=v1.6.50}
LIBPNG_REPO=${LIBPNG_REPO:=https://github.com/glennrp/libpng.git}
LIBPNG_VERSION=${LIBPNG_VERSION:=v1.6.35}
# Where to put libpng repo source (default to the ext area)
LIBPNG_SRC_DIR=${LIBPNG_SRC_DIR:=${PWD}/ext/libpng}
@@ -38,13 +38,16 @@ cd ${LIBPNG_SRC_DIR}
echo "git checkout ${LIBPNG_VERSION} --force"
git checkout ${LIBPNG_VERSION} --force
mkdir -p ${LIBPNG_BUILD_DIR}
cd ${LIBPNG_BUILD_DIR}
if [[ -z $DEP_DOWNLOAD_ONLY ]]; then
time cmake -S . -B ${LIBPNG_BUILD_DIR} -DCMAKE_BUILD_TYPE=Release \
time cmake -DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_PREFIX=${LIBPNG_INSTALL_DIR} \
-DPNG_EXECUTABLES=OFF \
-DPNG_TESTS=OFF \
${LIBPNG_CONFIG_OPTS}
time cmake --build ${LIBPNG_BUILD_DIR} --config Release --target install
${LIBPNG_CONFIG_OPTS} ..
time cmake --build . --config Release --target install
fi
# ls -R ${LIBPNG_INSTALL_DIR}
+2 -2
View File
@@ -2,7 +2,7 @@
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# https://github.com/OpenImageIO/oiio
# Utility script to download and build LibRaw
@@ -11,7 +11,7 @@ set -ex
# Which LibRaw to retrieve, how to build it
LIBRAW_REPO=${LIBRAW_REPO:=https://github.com/LibRaw/LibRaw.git}
LIBRAW_VERSION=${LIBRAW_VERSION:=0.21.5}
LIBRAW_VERSION=${LIBRAW_VERSION:=0.20.2}
# Where to install the final results
LOCAL_DEPS_DIR=${LOCAL_DEPS_DIR:=${PWD}/ext}
+9 -13
View File
@@ -2,7 +2,7 @@
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# https://github.com/OpenImageIO/oiio
# Utility script to download and build libtiff
@@ -13,9 +13,9 @@ LIBTIFF_REPO=${LIBTIFF_REPO:=https://gitlab.com/libtiff/libtiff.git}
LOCAL_DEPS_DIR=${LOCAL_DEPS_DIR:=${PWD}/ext}
LIBTIFF_BUILD_DIR=${LIBTIFF_BUILD_DIR:=${LOCAL_DEPS_DIR}/libtiff}
LIBTIFF_INSTALL_DIR=${LIBTIFF_INSTALL_DIR:=${PWD}/ext/dist}
LIBTIFF_VERSION=${LIBTIFF_VERSION:=v4.7.1}
LIBTIFF_VERSION=${LIBTIFF_VERSION:=v4.3.0}
LIBTIFF_BUILD_TYPE=${LIBTIFF_BUILD_TYPE:=Release}
if [[ `uname` == "Linux" ]] ; then
if [[ `uname` == `Linux` ]] ; then
LIBTIFF_CXX_FLAGS=${LIBTIFF_CXX_FLAGS:="-O3 -Wno-unused-function -Wno-deprecated-declarations -Wno-cast-qual -Wno-write-strings"}
fi
LIBTIFF_BUILDOPTS="${LIBTIFF_BUILDOPTS}"
@@ -36,19 +36,16 @@ cd libtiff
echo "git checkout ${LIBTIFF_VERSION} --force"
git checkout ${LIBTIFF_VERSION} --force
mkdir -p build
cd build
if [[ -z $DEP_DOWNLOAD_ONLY ]]; then
time cmake -S . -B build \
-DCMAKE_BUILD_TYPE=${LIBTIFF_BUILD_TYPE} \
time cmake -DCMAKE_BUILD_TYPE=${LIBTIFF_BUILD_TYPE} \
-DCMAKE_INSTALL_PREFIX=${LIBTIFF_INSTALL_DIR} \
-DCMAKE_CXX_FLAGS="${LIBTIFF_CXX_FLAGS}" \
-DBUILD_SHARED_LIBS=${LIBTIFF_BUILD_SHARED_LIBS:-ON} \
-Dtiff-tools=${LIBTIFF_BUILD_TESTS:-OFF} \
-Dtiff-contrib=${LIBTIFF_BUILD_TESTS:-OFF} \
-Dtiff-tests=${LIBTIFF_BUILD_TESTS:-OFF} \
-Dtiff-docs=${LIBTIFF_BUILD_TESTS:-OFF} \
-Dlibdeflate=ON \
${LIBTIFF_BUILDOPTS}
time cmake --build build --target install
${LIBTIFF_BUILDOPTS} ..
time cmake --build . --target install
fi
popd
@@ -61,6 +58,5 @@ popd
# Set up paths. These will only affect the caller if this script is
# run with 'source' rather than in a separate shell.
export LIBTIFF_ROOT=$LIBTIFF_INSTALL_DIR
export Tiff_ROOT=$LIBTIFF_INSTALL_DIR
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${LIBTIFF_INSTALL_DIR}/lib
+8 -23
View File
@@ -4,7 +4,7 @@
#
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# https://github.com/OpenImageIO/oiio
# Exit the whole script if any command fails.
set -ex
@@ -12,11 +12,10 @@ set -ex
echo "Building LLVM"
uname
: ${LLVM_VERSION:=18.1.8}
: ${LLVM_INSTALL_DIR:=${PWD}/llvm-install}
mkdir -p $LLVM_INSTALL_DIR || true
if [[ `uname` == "Linux" ]] ; then
: ${LLVM_VERSION:=13.0.0}
: ${LLVM_INSTALL_DIR:=${PWD}/llvm-install}
: ${LLVM_DISTRO_NAME:=ubuntu-18.04}
LLVMTAR=clang+llvm-${LLVM_VERSION}-x86_64-linux-gnu-${LLVM_DISTRO_NAME}.tar.xz
echo LLVMTAR = $LLVMTAR
@@ -24,24 +23,10 @@ if [[ `uname` == "Linux" ]] ; then
ls -l $LLVMTAR
tar xf $LLVMTAR
rm -f $LLVMTAR
echo "Installed ${LLVM_VERSION} in ${LLVM_INSTALL_DIR}"
mkdir -p $LLVM_INSTALL_DIR && true
mv clang+llvm*/* $LLVM_INSTALL_DIR
elif [[ `uname -s` == "Windows" || "${RUNNER_OS}" == "Windows" ]] ; then
echo "Installing Windows LLVM"
: ${LLVM_DISTRO_NAME:=ubuntu-18.04}
LLVMTAR=clang+llvm-${LLVM_VERSION}-x86_64-pc-windows-msvc.tar.xz
echo LLVMTAR = $LLVMTAR
curl --location https://github.com/llvm/llvm-project/releases/download/llvmorg-${LLVM_VERSION}/${LLVMTAR} -o $LLVMTAR
ls -l $LLVMTAR
tar xf $LLVMTAR
rm -f $LLVMTAR
mv clang+llvm*/* $LLVM_INSTALL_DIR
else
echo Bad uname `uname`
export LLVM_DIRECTORY=$LLVM_INSTALL_DIR
export PATH=${LLVM_INSTALL_DIR}/bin:$PATH
# ls -a $LLVM_DIRECTORY
fi
echo "Installed LLVM ${LLVM_VERSION} in ${LLVM_INSTALL_DIR}"
ls -a $LLVM_INSTALL_DIR || true
ls -a $LLVM_INSTALL_DIR/* || true
export LLVM_DIRECTORY=$LLVM_INSTALL_DIR
export PATH=${LLVM_INSTALL_DIR}/bin:$PATH
export LLVM_ROOT=${LLVM_INSTALL_DIR}
+3 -6
View File
@@ -2,7 +2,7 @@
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# https://github.com/OpenImageIO/oiio
# Exit the whole script if any command fails.
set -ex
@@ -14,11 +14,8 @@ NINJA_VERSION=${NINJA_VERSION:=1.10.2}
NINJA_BRANCH=${NINJA_BRANCH:=v${NINJA_VERSION}}
NINJA_INSTALL_DIR=${NINJA_INSTALL_DIR:=${LOCAL_DEPS_DIR}/dist/bin}
mkdir -p "$DOWNLOADS_DIR"
# Check if the tar exist, download it if not
if [ ! -f $DOWNLOADS_DIR/ninja-v${NINJA_VERSION}.tar.gz ]; then
curl --location ${NINJA_REPO}/archive/refs/tags/${NINJA_BRANCH}.tar.gz -o $DOWNLOADS_DIR/ninja-${NINJA_BRANCH}.tar.gz
if [ ! -f $DOWNLOADS_DIR/ninja-${NINJA_VERSION}.zip ]; then
curl --location ${NINJA_REPO}/archive/${NINJA_BRANCH}.tar.gz -o $DOWNLOADS_DIR/ninja-${NINJA_BRANCH}.tar.gz
fi
tar xf $DOWNLOADS_DIR/ninja-${NINJA_BRANCH}.tar.gz
+9 -12
View File
@@ -2,7 +2,7 @@
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# https://github.com/OpenImageIO/oiio
# Utility script to download and build OpenColorIO
@@ -11,14 +11,14 @@ set -ex
# Which OCIO to retrieve, how to build it
OPENCOLORIO_REPO=${OPENCOLORIO_REPO:=https://github.com/AcademySoftwareFoundation/OpenColorIO.git}
OPENCOLORIO_VERSION=${OPENCOLORIO_VERSION:=v2.4.2}
OPENCOLORIO_VERSION=${OPENCOLORIO_VERSION:=v2.2.1}
# Where to install the final results
LOCAL_DEPS_DIR=${LOCAL_DEPS_DIR:=${PWD}/ext}
OPENCOLORIO_SOURCE_DIR=${OPENCOLORIO_SOURCE_DIR:=${LOCAL_DEPS_DIR}/OpenColorIO}
OPENCOLORIO_BUILD_DIR=${OPENCOLORIO_BUILD_DIR:=${LOCAL_DEPS_DIR}/OpenColorIO-build}
OPENCOLORIO_INSTALL_DIR=${OPENCOLORIO_INSTALL_DIR:=${LOCAL_DEPS_DIR}/dist}
OPENCOLORIO_BUILD_TYPE=${OPENCOLORIO_BUILD_TYPE:=Release}
OPENCOLORIO_CXX_FLAGS=${OPENCOLORIO_CXX_FLAGS:="-Wno-unused-function -Wno-deprecated-declarations -Wno-cast-qual -Wno-write-strings"}
# Just need libs:
OPENCOLORIO_BUILDOPTS="-DOCIO_BUILD_APPS=OFF -DOCIO_BUILD_NUKE=OFF \
-DOCIO_BUILD_DOCS=OFF -DOCIO_BUILD_TESTS=OFF \
@@ -26,11 +26,6 @@ OPENCOLORIO_BUILDOPTS="-DOCIO_BUILD_APPS=OFF -DOCIO_BUILD_NUKE=OFF \
-DOCIO_BUILD_PYTHON=OFF -DOCIO_BUILD_PYGLUE=OFF \
-DOCIO_BUILD_JAVA=OFF \
-DBUILD_SHARED_LIBS=${OPENCOLORIO_BUILD_SHARED_LIBS:=ON}"
# Fix yaml-cpp which breaks against cmake 4.0 because of too-old cmake min.
# Remove when yaml-cpp is fixed to declare its own minimum high enough.
export CMAKE_POLICY_VERSION_MINIMUM=3.5
BASEDIR=`pwd`
pwd
echo "OpenColorIO install dir will be: ${OPENCOLORIO_INSTALL_DIR}"
@@ -47,11 +42,13 @@ cd ${OPENCOLORIO_SOURCE_DIR}
echo "git checkout ${OPENCOLORIO_VERSION} --force"
git checkout ${OPENCOLORIO_VERSION} --force
time cmake -S . -B ${OPENCOLORIO_BUILD_DIR} \
-DCMAKE_BUILD_TYPE=${OPENCOLORIO_BUILD_TYPE} \
mkdir -p ${OPENCOLORIO_BUILD_DIR}
cd ${OPENCOLORIO_BUILD_DIR}
time cmake -DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_PREFIX=${OPENCOLORIO_INSTALL_DIR} \
${OPENCOLORIO_BUILDOPTS}
time cmake --build ${OPENCOLORIO_BUILD_DIR} --config Release --target install
-DCMAKE_CXX_FLAGS="${OPENCOLORIO_CXX_FLAGS}" \
${OPENCOLORIO_BUILDOPTS} ${OPENCOLORIO_SOURCE_DIR}
time cmake --build . --config Release --target install
popd
# ls -R ${OPENCOLORIO_INSTALL_DIR}
+40 -20
View File
@@ -1,17 +1,17 @@
#!/usr/bin/env bash
# Utility script to download and build OpenEXR & Imath
# Utility script to download and build OpenEXR & IlmBase
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# SPDX-License-Identifier: BSD-3-Clause and Apache-2.0
# https://github.com/OpenImageIO/oiio
# Exit the whole script if any command fails.
set -ex
# Which OpenEXR to retrieve, how to build it
OPENEXR_REPO=${OPENEXR_REPO:=https://github.com/AcademySoftwareFoundation/openexr.git}
OPENEXR_VERSION=${OPENEXR_VERSION:=v3.3.5}
OPENEXR_VERSION=${OPENEXR_VERSION:=v3.1.9}
# Where to install the final results
LOCAL_DEPS_DIR=${LOCAL_DEPS_DIR:=${PWD}/ext}
@@ -28,31 +28,50 @@ echo "Building OpenEXR ${OPENEXR_VERSION}"
echo "OpenEXR build dir will be: ${OPENEXR_BUILD_DIR}"
echo "OpenEXR install dir will be: ${OPENEXR_INSTALL_DIR}"
echo "OpenEXR Build type is ${OPENEXR_BUILD_TYPE}"
echo "CMAKE_PREFIX_PATH is ${CMAKE_PREFIX_PATH}"
# Clone OpenEXR project (including Imath) from GitHub and build
# Clone OpenEXR project (including IlmBase) from GitHub and build
if [[ ! -e ${OPENEXR_SOURCE_DIR} ]] ; then
echo "git clone ${OPENEXR_REPO} ${OPENEXR_SOURCE_DIR}"
git clone ${OPENEXR_REPO} ${OPENEXR_SOURCE_DIR}
fi
mkdir -p ${OPENEXR_INSTALL_DIR} && true
mkdir -p ${OPENEXR_BUILD_DIR} && true
pushd ${OPENEXR_SOURCE_DIR}
git checkout ${OPENEXR_VERSION} --force
cmake -S . -B ${OPENEXR_BUILD_DIR} \
-DCMAKE_BUILD_TYPE=${OPENEXR_BUILD_TYPE} \
-DCMAKE_INSTALL_PREFIX="${OPENEXR_INSTALL_DIR}" \
-DCMAKE_PREFIX_PATH="${CMAKE_PREFIX_PATH}" \
-DBUILD_SHARED_LIBS=${OpenEXR_LOCAL_BUILD_SHARED_LIBS:=ON} \
-DOPENEXR_BUILD_UTILS=0 \
-DBUILD_TESTING=0 \
-DOPENEXR_VIEWERS_ENABLE=0 \
-DINSTALL_OPENEXR_EXAMPLES=0 \
-DOPENEXR_INSTALL_EXAMPLES=0 \
-DCMAKE_INSTALL_LIBDIR=lib \
-DCMAKE_CXX_FLAGS="${OPENEXR_CXX_FLAGS}" \
${OPENEXR_CMAKE_FLAGS}
time cmake --build ${OPENEXR_BUILD_DIR} --target install --config ${OPENEXR_BUILD_TYPE}
if [[ ${OPENEXR_VERSION} == "v2.3.0" ]] ; then
# Simplified setup for 2.3+
cd ${OPENEXR_BUILD_DIR}
cmake -DCMAKE_BUILD_TYPE=${OPENEXR_BUILD_TYPE} \
-DCMAKE_INSTALL_PREFIX="${OPENEXR_INSTALL_DIR}" \
-DCMAKE_PREFIX_PATH="${CMAKE_PREFIX_PATH}" \
-DILMBASE_PACKAGE_PREFIX="${OPENEXR_INSTALL_DIR}" \
-DOPENEXR_BUILD_UTILS=0 \
-DOPENEXR_BUILD_TESTS=0 \
-DOPENEXR_BUILD_PYTHON_LIBS=0 \
-DCMAKE_CXX_FLAGS="${OPENEXR_CXX_FLAGS}" \
${OPENEXR_CMAKE_FLAGS} ${OPENEXR_SOURCE_DIR}
time cmake --build . --target install --config ${OPENEXR_BUILD_TYPE}
else
# Simplified setup for 2.4+
cd ${OPENEXR_BUILD_DIR}
cmake -DCMAKE_BUILD_TYPE=${OPENEXR_BUILD_TYPE} \
-DCMAKE_INSTALL_PREFIX="${OPENEXR_INSTALL_DIR}" \
-DCMAKE_PREFIX_PATH="${CMAKE_PREFIX_PATH}" \
-DILMBASE_PACKAGE_PREFIX="${OPENEXR_INSTALL_DIR}" \
-DOPENEXR_BUILD_UTILS=0 \
-DBUILD_TESTING=0 \
-DPYILMBASE_ENABLE=0 \
-DOPENEXR_VIEWERS_ENABLE=0 \
-DINSTALL_OPENEXR_EXAMPLES=0 \
-DOPENEXR_INSTALL_EXAMPLES=0 \
-DCMAKE_INSTALL_LIBDIR=lib \
-DCMAKE_CXX_FLAGS="${OPENEXR_CXX_FLAGS}" \
${OPENEXR_CMAKE_FLAGS} ${OPENEXR_SOURCE_DIR}
time cmake --build . --target install --config ${OPENEXR_BUILD_TYPE}
fi
popd
@@ -60,8 +79,9 @@ popd
# Set up paths. These will only affect the caller if this script is
# run with 'source' rather than in a separate shell.
export OpenEXR_ROOT=$OPENEXR_INSTALL_DIR
export ILMBASE_ROOT=$OPENEXR_INSTALL_DIR
export OPENEXR_ROOT=$OPENEXR_INSTALL_DIR
export ILMBASE_LIBRARY_DIR=$OPENEXR_INSTALL_DIR/lib
export OPENEXR_LIBRARY_DIR=$OPENEXR_INSTALL_DIR/lib
export LD_LIBRARY_PATH=$OPENEXR_ROOT/lib:$LD_LIBRARY_PATH
-56
View File
@@ -1,56 +0,0 @@
#!/usr/bin/env bash
# Utility script to download and build openjph
#
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# Exit the whole script if any command fails.
set -ex
# Repo and branch/tag/commit of openjph to download if we don't have it yet
OPENJPH_REPO=${OPENJPH_REPO:=https://github.com/aous72/OpenJPH.git}
OPENJPH_VERSION=${OPENJPH_VERSION:=0.30.1}
# Where to put openjph repo source (default to the ext area)
LOCAL_DEPS_DIR=${LOCAL_DEPS_DIR:=${PWD}/ext}
OPENJPH_SRC_DIR=${OPENJPH_SRC_DIR:=${LOCAL_DEPS_DIR}/openjph}
OPENJPH_BUILD_DIR=${OPENJPH_BUILD_DIR:=${OPENJPH_SRC_DIR}/build}
OPENJPH_INSTALL_DIR=${OPENJPH_INSTALL_DIR:=${LOCAL_DEPS_DIR}/dist}
OPENJPH_BUILD_TYPE=${OPENJPH_BUILD_TYPE:=${CMAKE_BUILD_TYPE:-Release}}
#OPENJPH_CONFIG_OPTS=${OPENJPH_CONFIG_OPTS:=}
pwd
echo "openjph install dir will be: ${OPENJPH_INSTALL_DIR}"
mkdir -p ./ext
pushd ./ext
# Clone openjph project from GitHub and build
if [[ ! -e ${OPENJPH_SRC_DIR} ]] ; then
echo "git clone ${OPENJPH_REPO} ${OPENJPH_SRC_DIR}"
git clone ${OPENJPH_REPO} ${OPENJPH_SRC_DIR}
fi
cd ${OPENJPH_SRC_DIR}
echo "git checkout ${OPENJPH_VERSION} --force"
git checkout ${OPENJPH_VERSION} --force
if [[ -z $DEP_DOWNLOAD_ONLY ]]; then
time cmake -S . -B ${OPENJPH_BUILD_DIR} -DCMAKE_BUILD_TYPE=${OPENJPH_BUILD_TYPE} \
-DCMAKE_INSTALL_PREFIX=${OPENJPH_INSTALL_DIR} \
-DOJPH_BUILD_EXECUTABLES=OFF \
-DCMAKE_POSITION_INDEPENDENT_CODE=ON \
-DBUILD_SHARED_LIBS=${OPENJPH_BUILD_SHARED_LIBS:-ON} \
${OPENJPH_CONFIG_OPTS}
time cmake --build ${OPENJPH_BUILD_DIR} --target install
fi
# ls -R ${OPENJPH_INSTALL_DIR}
popd
# Set up paths. These will only affect the caller if this script is
# run with 'source' rather than in a separate shell.
export openjph_ROOT=$OPENJPH_INSTALL_DIR
+7 -4
View File
@@ -4,14 +4,14 @@
#
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# https://github.com/OpenImageIO/oiio
# Exit the whole script if any command fails.
set -ex
# Repo and branch/tag/commit of pugixml to download if we don't have it yet
PUGIXML_REPO=${PUGIXML_REPO:=https://github.com/zeux/pugixml.git}
PUGIXML_VERSION=${PUGIXML_VERSION:=v1.16}
PUGIXML_VERSION=${PUGIXML_VERSION:=v1.11.4}
# Where to put pugixml repo source (default to the ext area)
PUGIXML_SRC_DIR=${PUGIXML_SRC_DIR:=${PWD}/ext/pugixml}
@@ -38,13 +38,16 @@ cd ${PUGIXML_SRC_DIR}
echo "git checkout ${PUGIXML_VERSION} --force"
git checkout ${PUGIXML_VERSION} --force
mkdir -p ${PUGIXML_BUILD_DIR}
cd ${PUGIXML_BUILD_DIR}
if [[ -z $DEP_DOWNLOAD_ONLY ]]; then
time cmake -S . -B ${PUGIXML_BUILD_DIR} -DCMAKE_BUILD_TYPE=Release \
time cmake -DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_PREFIX=${PUGIXML_INSTALL_DIR} \
-DBUILD_SHARED_LIBS=ON \
-DBUILD_TESTS=OFF \
${PUGIXML_BUILD_OPTS} ..
time cmake --build ${PUGIXML_BUILD_DIR} --config Release --target install
time cmake --build . --config Release --target install
fi
# ls -R ${PUGIXML_INSTALL_DIR}
+8 -9
View File
@@ -2,7 +2,7 @@
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# https://github.com/OpenImageIO/oiio
# Utility script to download and build pybind11
@@ -11,7 +11,7 @@ set -ex
# Repo and branch/tag/commit of pybind11 to download if we don't have it yet
PYBIND11_REPO=${PYBIND11_REPO:=https://github.com/pybind/pybind11.git}
PYBIND11_VERSION=${PYBIND11_VERSION:=v3.0.1}
PYBIND11_VERSION=${PYBIND11_VERSION:=v2.8.1}
# Where to put pybind11 repo source (default to the ext area)
PYBIND11_SRC_DIR=${PYBIND11_SRC_DIR:=${PWD}/ext/pybind11}
@@ -22,10 +22,6 @@ LOCAL_DEPS_DIR=${LOCAL_DEPS_DIR:=${PWD}/ext}
PYBIND11_INSTALL_DIR=${PYBIND11_INSTALL_DIR:=${LOCAL_DEPS_DIR}/dist}
#PYBIND11_BUILD_OPTS=${PYBIND11_BUILD_OPTS:=}
# Fix for pybind11 breaking against cmake 4.0 because of too-old cmake min.
# Remove when pybind11 is fixed to declare its own minimum high enough.
export CMAKE_POLICY_VERSION_MINIMUM=3.5
if [[ "${PYTHON_VERSION}" != "" ]] ; then
PYBIND11_BUILD_OPTS+=" -DPYBIND11_PYTHON_VERSION=${PYTHON_VERSION}"
fi
@@ -46,12 +42,15 @@ cd ${PYBIND11_SRC_DIR}
echo "git checkout ${PYBIND11_VERSION} --force"
git checkout ${PYBIND11_VERSION} --force
mkdir -p ${PYBIND11_BUILD_DIR}
cd ${PYBIND11_BUILD_DIR}
if [[ -z $DEP_DOWNLOAD_ONLY ]]; then
time cmake -S . -B ${PYBIND11_BUILD_DIR} -DCMAKE_BUILD_TYPE=Release \
time cmake -DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_PREFIX=${PYBIND11_INSTALL_DIR} \
-DPYBIND11_TEST=OFF \
${PYBIND11_BUILD_OPTS}
time cmake --build ${PYBIND11_BUILD_DIR} --config Release --target install
${PYBIND11_BUILD_OPTS} ..
time cmake --build . --config Release --target install
fi
# ls -R ${PYBIND11_INSTALL_DIR}
+9 -6
View File
@@ -4,14 +4,14 @@
#
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# https://github.com/OpenImageIO/oiio
# Exit the whole script if any command fails.
set -ex
# Repo and branch/tag/commit of webp to download if we don't have it yet
WEBP_REPO=${WEBP_REPO:=https://github.com/webmproject/libwebp.git}
WEBP_VERSION=${WEBP_VERSION:=v1.6.0}
WEBP_VERSION=${WEBP_VERSION:=v1.1.0}
# Where to put webp repo source (default to the ext area)
LOCAL_DEPS_DIR=${LOCAL_DEPS_DIR:=${PWD}/ext}
@@ -37,8 +37,11 @@ cd ${WEBP_SRC_DIR}
echo "git checkout ${WEBP_VERSION} --force"
git checkout ${WEBP_VERSION} --force
mkdir -p ${WEBP_BUILD_DIR}
cd ${WEBP_BUILD_DIR}
if [[ -z $DEP_DOWNLOAD_ONLY ]]; then
time cmake -S . -B ${WEBP_BUILD_DIR} -DCMAKE_BUILD_TYPE=${WEBP_BUILD_TYPE} \
time cmake -DCMAKE_BUILD_TYPE=${WEBP_BUILD_TYPE} \
-DCMAKE_INSTALL_PREFIX=${WEBP_INSTALL_DIR} \
-DWEBP_BUILD_ANIM_UTILS=OFF \
-DWEBP_BUILD_CWEBP=OFF \
@@ -47,9 +50,9 @@ if [[ -z $DEP_DOWNLOAD_ONLY ]]; then
-DWEBP_BUILD_GIF2WEBPx=OFF \
-DWEBP_BUILD_IMG2WEBP=OFF \
-DWEBP_BUILD_EXTRAS=OFF \
-DBUILD_SHARED_LIBS=${WEBP_BUILD_SHARED_LIBS:-ON} \
${WEBP_CONFIG_OPTS}
time cmake --build ${WEBP_BUILD_DIR} --target install
-DBUILD_SHARED_LIBS=ON \
${WEBP_CONFIG_OPTS} ..
time cmake --build . --target install
fi
+8 -8
View File
@@ -4,7 +4,7 @@
#
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# https://github.com/OpenImageIO/oiio
# Exit the whole script if any command fails.
set -ex
@@ -21,10 +21,6 @@ ZLIB_BUILD_DIR=${ZLIB_BUILD_DIR:=${ZLIB_SRC_DIR}/build}
ZLIB_INSTALL_DIR=${ZLIB_INSTALL_DIR:=${PWD}/ext/dist}
#ZLIB_CONFIG_OPTS=${ZLIB_CONFIG_OPTS:=}
# Fix zlib which breaks against cmake 4.0 because of too-old cmake min.
# Remove when zlib is fixed to declare its own minimum high enough.
export CMAKE_POLICY_VERSION_MINIMUM=3.5
pwd
echo "zlib install dir will be: ${ZLIB_INSTALL_DIR}"
@@ -41,11 +37,15 @@ cd ${ZLIB_SRC_DIR}
echo "git checkout ${ZLIB_VERSION} --force"
git checkout ${ZLIB_VERSION} --force
mkdir -p ${ZLIB_BUILD_DIR} && true
cd ${ZLIB_BUILD_DIR}
if [[ -z $DEP_DOWNLOAD_ONLY ]]; then
time cmake -S . -B ${ZLIB_BUILD_DIR} -DCMAKE_BUILD_TYPE=Release \
time cmake -DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_PREFIX=${ZLIB_INSTALL_DIR} \
${ZLIB_CONFIG_OPTS}
time cmake --build ${ZLIB_BUILD_DIR} --config Release --target install
${ZLIB_CONFIG_OPTS} ..
time cmake --build . --config Release --target install
fi
# ls -R ${ZLIB_INSTALL_DIR}
-54
View File
@@ -1,54 +0,0 @@
#!/usr/bin/env bash
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# Important: set -ex causes this whole script to terminate with error if
# any command in it fails. This is crucial for CI tests.
set -e
# Arguments to this script are:
# BUILDDIR_NEW BUILDDIR_OLD LIBRARIES...
BUILDDIR_NEW=$1
shift
BUILDDIR_OLD=$1
shift
LIBS=$*
#
# First, create ABI dumps from both builds
#
ABI_ARGS="-bin-only -skip-cxx -public-headers $PWD/dist/include/OpenImageIO "
echo "ABI_CHECK: PWD=${PWD} "
ls -l $BUILDDIR_NEW
ls -l $BUILDDIR_OLD
for dir in $BUILDDIR_NEW $BUILDDIR_OLD ; do
for lib in $LIBS ; do
abi-dumper $ABI_ARGS ${dir}/lib/${lib}.so -o ${dir}/abi-${lib}.dump
done
done
echo "Saved ABI dumps"
#
# Run the ABI compliance checker, saving the outputs to files
#
for lib in $LIBS ; do
abi-compliance-checker -l $lib -old $BUILDDIR_OLD/abi-$lib.dump -new $BUILDDIR_NEW/abi-$lib.dump | tee ${lib}-abi-results.txt || true
echo -e "\x1b[33;1m"
echo -e "$lib"
fgrep "Binary compatibility:" ${lib}-abi-results.txt
echo -e "\x1b[33;0m"
done
cp -r compat_reports ${BUILDDIR_NEW}/compat_reports || true
#
# If the "Binary compatibility" summary results say anything other than 100%,
# we fail!
#
for lib in $LIBS ; do
if [[ `fgrep "Binary compatibility:" ${lib}-abi-results.txt | grep -v 100\%` != "" ]] ; then
exit 1
fi
done
-27
View File
@@ -1,27 +0,0 @@
#!/usr/bin/env bash
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
BUILD_BIN_DIR=build/bin
if [[ "${RUNNER_OS}" == "Windows" ]] ; then
BUILD_BIN_DIR+=/${CMAKE_BUILD_TYPE}
fi
ls build
ls $BUILD_BIN_DIR
mkdir -p build/benchmarks
for t in image_span_test span_test ; do
echo
echo
echo "$t"
echo "========================================================"
OpenImageIO_CI=0 ${BUILD_BIN_DIR}/$t | tee build/benchmarks/$t.out
# Note: set OpenImageIO_CI=0 to avoid CI-specific automatic reduction of
# the number of trials and iterations.
echo "========================================================"
echo "========================================================"
echo
done
+11 -27
View File
@@ -2,31 +2,20 @@
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# https://github.com/OpenImageIO/oiio
# Important: set -ex causes this whole script to terminate with error if
# any command in it fails. This is crucial for CI tests.
set -ex
OIIO_CMAKE_FLAGS="$MY_CMAKE_FLAGS $OIIO_CMAKE_FLAGS"
export OIIO_SRC_DIR=${OIIO_SRC_DIR:=$PWD}
export OIIO_BUILD_DIR=${OIIO_BUILD_DIR:=${OIIO_SRC_DIR}/build}
export OIIO_INSTALL_DIR=${OIIO_INSTALL_DIR:=${OIIO_SRC_DIR}/dist}
export OIIO_CMAKE_BUILD_TYPE=${OIIO_CMAKE_BUILD_TYPE:=${CMAKE_BUILD_TYPE:=Release}}
# Allow OIIO_specific overrides for CC, CXX
if [[ "$OIIO_CC" != "" ]] ; then
CC=$OIIO_CC
fi
if [[ "$OIIO_CXX" != "" ]] ; then
CXX=$OIIO_CXX
fi
if [[ "$USE_SIMD" != "" ]] ; then
OIIO_CMAKE_FLAGS="$OIIO_CMAKE_FLAGS -DUSE_SIMD=$USE_SIMD"
fi
if [[ -n "${OIIO_PYTHON_BINDINGS_BACKEND:-}" ]] ; then
OIIO_CMAKE_FLAGS="$OIIO_CMAKE_FLAGS -DOIIO_PYTHON_BINDINGS_BACKEND=${OIIO_PYTHON_BINDINGS_BACKEND}"
if [[ -n "$FMT_VERSION" ]] ; then
OIIO_CMAKE_FLAGS="$OIIO_CMAKE_FLAGS -DBUILD_FMT_VERSION=$FMT_VERSION"
fi
if [[ -n "$CODECOV" ]] ; then
@@ -38,32 +27,28 @@ if [[ ${GITHUB_ACTIONS} == true ]] ; then
OIIO_CMAKE_FLAGS+=" -DCMAKE_UNITY_BUILD=${CMAKE_UNITY_BUILD:=ON} -DCMAKE_UNITY_BUILD_MODE=${CMAKE_UNITY_BUILD_MODE:=BATCH}"
fi
# pushd $OIIO_BUILD_DIR
cmake -S $OIIO_SRC_DIR -B $OIIO_BUILD_DIR -G "$CMAKE_GENERATOR" \
-DCMAKE_BUILD_TYPE="${OIIO_CMAKE_BUILD_TYPE}" \
pushd build
cmake .. -G "$CMAKE_GENERATOR" \
-DCMAKE_BUILD_TYPE="${CMAKE_BUILD_TYPE}" \
-DCMAKE_PREFIX_PATH="$CMAKE_PREFIX_PATH" \
-DCMAKE_INSTALL_PREFIX="$OpenImageIO_ROOT" \
-DPYTHON_VERSION="$PYTHON_VERSION" \
-DCMAKE_INSTALL_LIBDIR="lib" \
-DCMAKE_INSTALL_LIBDIR="$OpenImageIO_ROOT/lib" \
-DCMAKE_CXX_STANDARD="$CMAKE_CXX_STANDARD" \
-DOIIO_DOWNLOAD_MISSING_TESTDATA=ON \
-DEXTRA_CPP_ARGS="${OIIO_EXTRA_CPP_ARGS}" \
$OIIO_CMAKE_FLAGS -DVERBOSE=1
# Save a copy of the generated files for debugging broken CI builds.
mkdir ${OIIO_BUILD_DIR}/cmake-save || true
cp -r ${OIIO_BUILD_DIR}/CMake* ${OIIO_BUILD_DIR}/*.cmake ${OIIO_BUILD_DIR}/cmake-save
mkdir cmake-save || /bin/true
cp -r CMake* *.cmake cmake-save
: ${BUILDTARGET:=install}
if [[ "$BUILDTARGET" != "none" ]] ; then
echo "Parallel build ${CMAKE_BUILD_PARALLEL_LEVEL} of target ${BUILDTARGET}"
if [[ ${OIIO_CMAKE_BUILD_WRAPPER} != "" ]] ; then
echo "Using build wrapper '${OIIO_CMAKE_BUILD_WRAPPER}'"
fi
time ${OIIO_CMAKE_BUILD_WRAPPER} cmake --build ${OIIO_BUILD_DIR} --target ${BUILDTARGET} --config ${CMAKE_BUILD_TYPE}
ccache --show-stats || true
time ${OIIO_CMAKE_BUILD_WRAPPER} cmake --build . --target ${BUILDTARGET} --config ${CMAKE_BUILD_TYPE}
fi
# popd
popd
if [[ "${DEBUG_CI:=0}" != "0" ]] ; then
echo "PATH=$PATH"
@@ -74,7 +59,6 @@ if [[ "${DEBUG_CI:=0}" != "0" ]] ; then
fi
if [[ "$BUILDTARGET" == clang-format ]] ; then
echo "Running " `which clang-format` " version " `clang-format --version`
git diff --color
THEDIFF=`git diff`
if [[ "$THEDIFF" != "" ]] ; then
+1 -6
View File
@@ -2,7 +2,7 @@
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# https://github.com/OpenImageIO/oiio
# Run code coverage analysis
# This assumes that the build occurred with CODECOV=1 and tests have already
@@ -25,9 +25,4 @@ for g in $(find ../build -name "*.gcno" -type f); do
echo "dirname $g = $(dirname $g) to " `$(echo "$g" | sed -e 's/\/build\//\//' -e 's/\.gcno/\.cpp/' -e 's/\.cpp\.cpp/\.cpp/' -e 's/\/CMakeFiles.*\.dir\//\//')`
gcov -l -p -o $(dirname "$g") $(echo "$g" | sed -e 's/\/build\//\//' -e 's/\.gcno/\.cpp/' -e 's/\/CMakeFiles.*\.dir\//\//')
done
# Remove pointless .gcov files so we don't analyze them
rm -f "*opt*include*"
rm -f "*usr*local*"
popd
@@ -1,6 +0,0 @@
# CI-only: nanobind for CMake (`python -m nanobind --cmake_dir`). Used on Linux
# (gh-installdeps) and Windows (gh-win-installdeps) with pip --require-hashes.
# macOS CI uses `brew install nanobind` instead (install_homebrew_deps.bash).
# When bumping pip pin: https://pypi.org/pypi/nanobind/<ver>/json → wheel sha256.
nanobind==2.12.0 \
--hash=sha256:a10d3d88e691dcdf22696f9acd893fda3c5a05635763aea238829d274fcad480
+14 -41
View File
@@ -2,7 +2,7 @@
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# https://github.com/OpenImageIO/oiio
# This script is run when CI system first starts up.
# Since it sets many env variables needed by the caller, it should be run
@@ -12,13 +12,9 @@
export PATH=/usr/local/bin/_ccache:/usr/lib/ccache:$PATH
export USE_CCACHE=${USE_CCACHE:=1}
export CCACHE_CPP2=
export CCACHE_DIR=$HOME/.ccache
export CCACHE_COMPRESSION=yes
if [[ "$(which ccache)" != "" ]] ; then
# Try to coax dependency building into also using ccache
export CMAKE_CXX_COMPILER_LAUNCHER="ccache"
export CMAKE_C_COMPILER_LAUNCHER="ccache"
ccache -z
export CCACHE_DIR=/tmp/ccache
if [[ "${RUNNER_OS}" == "macOS" ]] ; then
export CCACHE_DIR=$HOME/.ccache
fi
mkdir -p $CCACHE_DIR
@@ -31,16 +27,22 @@ export LSAN_OPTIONS=suppressions=$PWD/src/build-scripts/nosanitize.txt
export ASAN_OPTIONS=print_suppressions=0
export UBSAN_OPTIONS=suppressions=$PWD/src/build-scripts/ubsan-suppressions.txt
export PYTHON_VERSION=${PYTHON_VERSION:="3.7"}
export PYTHON_VERSION=${PYTHON_VERSION:="2.7"}
export PYTHONPATH=$OpenImageIO_ROOT/lib/python${PYTHON_VERSION}/site-packages:$PYTHONPATH
export BUILD_MISSING_DEPS=${BUILD_MISSING_DEPS:=1}
export COMPILER=${COMPILER:=gcc}
export CC=${CC:=gcc}
export CXX=${CXX:=g++}
export OpenImageIO_CI=1
export OpenImageIO_CI=true
export USE_NINJA=${USE_NINJA:=1}
export CMAKE_GENERATOR=${CMAKE_GENERATOR:=Ninja}
export CMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE:=Release}
export CMAKE_CXX_STANDARD=${CMAKE_CXX_STANDARD:=17}
export CMAKE_CXX_STANDARD=${CMAKE_CXX_STANDARD:=11}
export PARALLEL=${PARALLEL:=4}
export PAR_MAKEFLAGS=-j${PARALLEL}
export CMAKE_BUILD_PARALLEL_LEVEL=${CMAKE_BUILD_PARALLEL_LEVEL:=${PARALLEL}}
export CTEST_PARALLEL_LEVEL=${CTEST_PARALLEL_LEVEL:=${PARALLEL}}
export LOCAL_DEPS_DIR=${LOCAL_DEPS_DIR:=$HOME/ext}
export PATH=${LOCAL_DEPS_DIR}/dist/bin:$PATH
@@ -48,36 +50,9 @@ export LD_LIBRARY_PATH=${LOCAL_DEPS_DIR}/dist/lib:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=${LOCAL_DEPS_DIR}/dist/lib64:$LD_LIBRARY_PATH
export DYLD_LIBRARY_PATH=${LOCAL_DEPS_DIR}/dist/lib:$DYLD_LIBRARY_PATH
export OCIO="$PWD/testsuite/common/OpenColorIO/nuke-default/config.ocio"
export TESTSUITE_CLEANUP_ON_SUCCESS=${TESTSUITE_CLEANUP_ON_SUCCESS:=1}
# For CI, default to building missing dependencies automatically
export OpenImageIO_BUILD_MISSING_DEPS=${OpenImageIO_BUILD_MISSING_DEPS:=all}
# Sonar
export BUILD_WRAPPER_OUT_DIR="${PWD}/bw_output"
export BW_OUTPUT_DIR="${PWD}/bw_output"
# Parallel builds
if [[ `uname -s` == "Linux" ]] ; then
echo "procs: " `nproc`
head -40 /proc/cpuinfo
export PARALLEL=${PARALLEL:=$((2 + `nproc`))}
elif [[ "${RUNNER_OS}" == "macOS" ]] ; then
echo "procs: " `sysctl -n hw.ncpu`
sysctl machdep.cpu.features
export PARALLEL=${PARALLEL:=$((2 + `sysctl -n hw.ncpu`))}
elif [[ "${RUNNER_OS}" == "Windows" ]] ; then
# Presumably Windows
export PARALLEL=${PARALLEL:=$((2 + ${NUMBER_OF_PROCESSORS}))}
else
export PARALLEL=${PARALLEL:=6}
fi
export PAR_MAKEFLAGS=-j${PARALLEL}
export CMAKE_BUILD_PARALLEL_LEVEL=${CMAKE_BUILD_PARALLEL_LEVEL:=${PARALLEL}}
export CTEST_PARALLEL_LEVEL=${CTEST_PARALLEL_LEVEL:=${PARALLEL}}
export OIIO_USE_CUDA=1
export CUDAToolkit_ROOT=/usr/local/cuda
mkdir -p build dist
echo "HOME = $HOME"
@@ -92,10 +67,8 @@ ls
env | sort
if [[ `uname -s` == "Linux" ]] ; then
echo "nprocs: " `nproc`
head -40 /proc/cpuinfo
elif [[ "${RUNNER_OS}" == "macOS" ]] ; then
echo "nprocs: " `sysctl -n hw.ncpu`
sysctl machdep.cpu.features
fi
+2 -8
View File
@@ -2,7 +2,7 @@
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# https://github.com/OpenImageIO/oiio
# Important: set -ex causes this whole script to terminate with error if
# any command in it fails. This is crucial for CI tests.
@@ -19,13 +19,11 @@ fi
# debugging info in the CI logs.
#
echo ; echo "Results of oiiotool --version:"
$OpenImageIO_ROOT/bin/oiiotool --version
$OpenImageIO_ROOT/bin/oiiotool --version || true
echo ; echo "Results of oiiotool brief help:"
$OpenImageIO_ROOT/bin/oiiotool || true
echo ; echo "Results of oiiotool full --help:"
$OpenImageIO_ROOT/bin/oiiotool --help || true
echo ; echo "Results of oiiotool --colorconfiginfo:"
$OpenImageIO_ROOT/bin/oiiotool --colorconfiginfo
echo ; echo "Results of oiiotool with no args (should get short help message):"
$OpenImageIO_ROOT/bin/oiiotool || true
echo ; echo "Run unit tests and simple stats:"
@@ -34,10 +32,6 @@ $OpenImageIO_ROOT/bin/oiiotool --unittest --list-formats --threads 0 \
echo ; echo "Try unknown command:"
$OpenImageIO_ROOT/bin/oiiotool -q --unknown || true
if [[ `uname -s` == "Linux" ]] ; then
echo ; echo "ldd oiiotool:"
ldd $OpenImageIO_ROOT/bin/oiiotool
fi
#
# Full test suite
+80 -128
View File
@@ -3,77 +3,60 @@
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# https://github.com/OpenImageIO/oiio
set -ex
# Make extra space on the runners
df -h .
time rm -rf /usr/local/lib/android /host/root/usr/local/lib/android &
sleep 3
# rather than block, delete in background, but give it a few secs to start
# clearing things out before moving on.
# Other candidates, if we need it: /usr/share/dotnet /usr/local/.ghcup
#
# Install system packages when those are acceptable for dependencies.
#
if [[ "$ASWF_ORG" != "" ]] ; then
# Using ASWF container
# Using ASWF CentOS container
#ls /etc/yum.repos.d
# This will show how much space is taken by each installed package, sorted
# by size in KB.
# rpm -qa --queryformat '%10{size} - %-25{name} \t %{version}\n' | sort -n
# I would like this to free space by removing packages we don't need.
# BUT IT DOESN'T, because uninstalling a package just ends is visibility
# to the runtime, it doesn't remove it from the static container image
# that's taking up the disk space. So this is pointless. But leaving it
# here to remind myself not to waste time trying it again.
# time sudo yum remove -y nsight-compute-2022.3.0 libcublas-devel-11-8 libcublas-11-8 libcusparse-devel-11-8 libnpp-devel-11-8 libnpp-11-8 libcurand-devel-11-8 libcurand-11-8 || true
# time sudo yum remove -y nsight-compute-2024.3.1 libcublas-devel-12-6 libcublas-12-6 libcusparse-devel-12-6 libnpp-devel-12-6 libnpp-12-6 libcurand-devel-12-6 libcurand-12-6 || true
# time sudo dnf upgrade --refresh || true
if [[ "${DO_RPMFUSION_REPO:-0}" != "0" ]] ; then
time sudo dnf install --nogpgcheck https://mirrors.rpmfusion.org/free/el/rpmfusion-free-release-$(rpm -E %rhel).noarch.rpm -y || true
fi
if [[ "$ASWF_VFXPLATFORM_VERSION" == "2022" ]] ; then
# CentOS 7 based containers need the now-nonexistent centos repo to be
# excluded or all the subsequent yum install commands will fail.
yum-config-manager --disable centos-sclo-rh || true
sed -i 's,^mirrorlist=,#,; s,^#baseurl=http://mirror\.centos\.org/centos/$releasever,baseurl=https://vault.centos.org/7.9.2009,' /etc/yum.repos.d/CentOS-Base.repo
fi
# time time sudo yum install -y giflib giflib-devel || true
if [[ "${USE_OPENCV}" != "0" ]] ; then
time sudo yum install -y opencv opencv-devel || true
fi
if [[ "${USE_FFMPEG}" != "0" ]] ; then
time sudo dnf install -y ffmpeg ffmpeg-devel || true
fi
if [[ "${USE_FREETYPE:-1}" != "0" ]] ; then
time sudo yum install -y freetype freetype-devel || true
fi
if [[ "${USE_LIBRAW:-0}" != "0" ]] ; then
time sudo yum install -y LibRaw LibRaw-devel || true
fi
sudo yum install -y giflib giflib-devel && true
sudo yum install -y opencv opencv-devel && true
sudo yum install -y ffmpeg ffmpeg-devel && true
if [[ "${EXTRA_DEP_PACKAGES}" != "" ]] ; then
time sudo yum install -y ${EXTRA_DEP_PACKAGES} || true
fi
if [[ "${PIP_INSTALLS}" != "" ]] ; then
time pip3 install ${PIP_INSTALLS} || true
time sudo yum install -y ${EXTRA_DEP_PACKAGES}
fi
if [[ "$CXX" == "icpx" || "$CC" == "icx" || "$USE_ICX" != "" ]] ; then
if [[ "${CONAN_LLVM_VERSION}" != "" ]] ; then
mkdir conan
pushd conan
# Simple way to conan install just one package:
# conan install clang/${CONAN_LLVM_VERSION}@aswftesting/ci_common1 -g deploy -g virtualenv
# But the below method can accommodate multiple requirements:
echo "[imports]" >> conanfile.txt
echo "., * -> ." >> conanfile.txt
echo "[requires]" >> conanfile.txt
echo "clang/${CONAN_LLVM_VERSION}@aswftesting/ci_common1" >> conanfile.txt
time conan install .
echo "--ls--"
ls -R .
export PATH=$PWD/bin:$PATH
export LD_LIBRARY_PATH=$PWD/lib:$LD_LIBRARY_PATH
export LLVM_ROOT=$PWD
popd
fi
if [[ "$CXX" == "icpc" || "$CC" == "icc" || "$USE_ICC" != "" ]] ; then
# Lock down icc to 2022.1 because newer versions hosted on the Intel
# repo require a glibc too new for the ASWF CentOS7-based containers
# we run CI on.
sudo cp src/build-scripts/oneAPI.repo /etc/yum.repos.d
sudo yum install -y intel-oneapi-compiler-dpcpp-cpp-and-cpp-classic
# If we needed to lock down to a particular version, we could:
# sudo yum install -y intel-oneapi-compiler-dpcpp-cpp-and-cpp-classic-2023.1.0.x86_64
sudo /usr/bin/yum install -y intel-oneapi-compiler-dpcpp-cpp-and-cpp-classic-2022.1.0.x86_64
set +e; source /opt/intel/oneapi/setvars.sh --config oneapi_2022.1.0.cfg; set -e
elif [[ "$CXX" == "icpc" || "$CC" == "icc" || "$USE_ICC" != "" || "$CXX" == "icpx" || "$CC" == "icx" || "$USE_ICX" != "" ]] ; then
# Lock down icx to 2023.1 because newer versions hosted on the Intel
# repo require a libstd++ too new for the ASWF containers we run CI on
# because their default install of gcc 9 based toolchain.
sudo cp src/build-scripts/oneAPI.repo /etc/yum.repos.d
sudo yum install -y intel-oneapi-compiler-dpcpp-cpp-and-cpp-classic-2023.1.0.x86_64
# sudo yum install -y intel-oneapi-compiler-dpcpp-cpp-and-cpp-classic
set +e; source /opt/intel/oneapi/setvars.sh; set -e
echo "Verifying installation of Intel(r) oneAPI DPC++/C++ Compiler:"
icpx --version
@@ -82,28 +65,21 @@ if [[ "$ASWF_ORG" != "" ]] ; then
else
# Using native Ubuntu runner
if [[ "${SKIP_APT_GET_UPDATE}" != "1" ]] ; then
time sudo apt-get update
fi
time sudo apt-get update
if [[ "${SKIP_SYSTEM_DEPS_INSTALL}" != "1" ]] ; then
time sudo apt-get -q install -y --fix-missing \
git cmake ninja-build ccache g++ \
libtiff-dev libgif-dev libpng-dev libjpeg-dev \
libraw-dev libwebp-dev \
libavcodec-dev libavformat-dev libswscale-dev libavutil-dev \
dcmtk libopenvdb-dev \
libfreetype6-dev \
libopencolorio-dev \
libtbb-dev \
libdeflate-dev bzip2
# Iffy ones get the "|| true" treatment so failure is ok
time sudo apt-get -q install -y --fix-missing \
libjxl-dev || true
fi
if [[ "${USE_OPENCV}" != "0" ]] && [[ "${INSTALL_OPENCV}" != "0" ]] ; then
sudo apt-get -q install -y --fix-missing libopencv-dev || true
fi
time sudo apt-get -q install -y \
git cmake ninja-build ccache g++ \
libboost-dev libboost-thread-dev libboost-filesystem-dev \
libilmbase-dev libopenexr-dev \
libtbb-dev \
libtiff-dev libgif-dev libpng-dev libraw-dev libwebp-dev \
libavcodec-dev libavformat-dev libswscale-dev libavutil-dev \
dcmtk libopenvdb-dev \
libfreetype6-dev \
locales wget \
libopencolorio-dev \
libopencv-dev \
libhdf5-dev
if [[ "${QT_VERSION:-5}" == "5" ]] ; then
time sudo apt-get -q install -y \
qt5-default || /bin/true
@@ -114,12 +90,15 @@ else
time sudo apt-get -q install -y ${EXTRA_DEP_PACKAGES}
fi
if [[ "${USE_PYTHON}" != "0" ]] ; then
time sudo apt-get -q install -y python3-numpy
fi
: ${PIP_SUFFIX:=}
if [[ "${PIP_INSTALLS}" != "" ]] ; then
time pip3${PIP_SUFFIX} install ${PIP_INSTALLS}
# Nonstandard python versions
if [[ "${PYTHON_VERSION}" == "3.9" ]] ; then
time sudo apt-get -q install -y python3.9-dev python3-numpy
pip3 --version
pip3 install numpy
elif [[ "$PYTHON_VERSION" == "2.7" ]] ; then
time sudo apt-get -q install -y python-dev python-numpy
else
pip3 install numpy
fi
if [[ "$USE_LIBHEIF" != "0" ]] ; then
@@ -130,26 +109,35 @@ else
libheif-plugin-x265 libheif-dev || true
fi
if [[ "${USE_FFMPEG}" != "0" ]] ; then
time sudo apt-get -q install -y ffmpeg || true
fi
export CMAKE_PREFIX_PATH=/usr/lib/x86_64-linux-gnu:$CMAKE_PREFIX_PATH
if [[ "$CXX" == "g++-6" ]] ; then
time sudo apt-get install -y g++-6
elif [[ "$CXX" == "g++-7" ]] ; then
time sudo apt-get install -y g++-7
elif [[ "$CXX" == "g++-8" ]] ; then
time sudo apt-get install -y g++-8
elif [[ "$CXX" == "g++-9" ]] ; then
time sudo apt-get install -y g++-9
elif [[ "$CXX" == "g++-10" ]] ; then
time sudo apt-get install -y g++-10
elif [[ "$CXX" == "g++-11" ]] ; then
time sudo apt-get install -y g++-11
elif [[ "$CXX" == "g++-12" ]] ; then
time sudo apt-get install -y g++-12
fi
if [[ "$CXX" == "icpc" || "$CC" == "icc" || "$USE_ICC" != "" || "$USE_ICX" != "" ]] ; then
time sudo apt-get -q install -y wget
wget https://apt.repos.intel.com/intel-gpg-keys/GPG-PUB-KEY-INTEL-SW-PRODUCTS-2023.PUB
sudo apt-key add GPG-PUB-KEY-INTEL-SW-PRODUCTS-2023.PUB
echo "deb https://apt.repos.intel.com/oneapi all main" | sudo tee /etc/apt/sources.list.d/oneAPI.list
time sudo apt-get update
time sudo apt-get install -y intel-oneapi-compiler-dpcpp-cpp-and-cpp-classic
set +e; source /opt/intel/oneapi/setvars.sh; set -e
fi
fi
if [[ "$CMAKE_VERSION" != "" ]] ; then
source src/build-scripts/build_cmake.bash
fi
cmake --version
@@ -157,7 +145,7 @@ cmake --version
# If we're using clang to compile on native Ubuntu, we need to install it.
# If on an ASWF CentOS docker container, it already is installed.
#
if [[ "$LLVM_VERSION" != "" ]] ; then
if [[ "$CXX" == "clang++" && "$ASWF_ORG" == "" ]] ; then
source src/build-scripts/build_llvm.bash
fi
@@ -167,9 +155,7 @@ fi
# Packages we need to build from scratch.
#
if [[ "$PYBIND11_VERSION" != "0" ]] ; then
source src/build-scripts/build_pybind11.bash
fi
source src/build-scripts/build_pybind11.bash
if [[ "$OPENEXR_VERSION" != "" ]] ; then
source src/build-scripts/build_openexr.bash
@@ -187,10 +173,6 @@ if [[ "$LIBRAW_VERSION" != "" ]] ; then
source src/build-scripts/build_libraw.bash
fi
if [[ "$OPENJPH_VERSION" != "" ]] ; then
source src/build-scripts/build_openjph.bash
fi
if [[ "$OPENJPEG_VERSION" != "" ]] ; then
source src/build-scripts/build_OpenJPEG.bash
fi
@@ -208,22 +190,6 @@ if [[ "$PTEX_VERSION" != "" ]] ; then
source src/build-scripts/build_Ptex.bash
fi
if [[ "$ABI_CHECK" != "" ]] ; then
source src/build-scripts/build_abi_tools.bash
fi
if [[ "$LIBJPEGTURBO_VERSION" != "" ]] ; then
source src/build-scripts/build_libjpeg-turbo.bash
fi
if [[ "$FREETYPE_VERSION" != "" ]] ; then
source src/build-scripts/build_Freetype.bash
fi
if [[ "$LIBPNG_VERSION" != "" ]] ; then
source src/build-scripts/build_libpng.bash
fi
if [[ "$USE_ICC" != "" ]] ; then
# We used gcc for the prior dependency builds, but use icc for OIIO itself
echo "which icpc:" $(which icpc)
@@ -231,19 +197,5 @@ if [[ "$USE_ICC" != "" ]] ; then
export CC=icc
fi
df -h .
df -h /host/root || true
# nanobind's CMake config is discovered via `python -m nanobind --cmake_dir`.
# Version + wheel hash: src/build-scripts/ci-requirements-nanobind.txt (CodeQL / supply chain).
if [[ "${OIIO_PYTHON_BINDINGS_BACKEND:-}" == "both" || "${OIIO_PYTHON_BINDINGS_BACKEND:-}" == "nanobind" ]] ; then
_oiio_nanobind_requirements_file="$PWD/src/build-scripts/ci-requirements-nanobind.txt"
if [[ "$ASWF_ORG" != "" ]] ; then
time pip3 install -r "$_oiio_nanobind_requirements_file" --require-hashes || true
else
time pip3${PIP_SUFFIX} install -r "$_oiio_nanobind_requirements_file" --require-hashes
fi
fi
# Save the env for use by other stages
src/build-scripts/save-env.bash
+98 -52
View File
@@ -2,20 +2,21 @@
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# https://github.com/OpenImageIO/oiio
# DEP_DIR="$PWD/ext/dist"
DEP_DIR="$PWD/dist/$PLATFORM"
mkdir -p "$DEP_DIR"
mkdir -p ext
mkdir -p ext && true
INT_DIR="build/$PLATFORM"
VCPKG_INSTALLATION_ROOT=/c/vcpkg
export CMAKE_PREFIX_PATH=${CMAKE_PREFIX_PATH:=.}
export CMAKE_PREFIX_PATH="$CMAKE_PREFIX_PATH;$DEP_DIR"
export CMAKE_PREFIX_PATH="$CMAKE_PREFIX_PATH;$VCPKG_INSTALLATION_ROOT/installed/x64-windows-release"
export PATH="$PATH:$DEP_DIR/bin:$DEP_DIR/lib:$VCPKG_INSTALLATION_ROOT/installed/x64-windows-release/bin:/bin:$PWD/ext/dist/bin:$PWD/ext/dist/lib"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$DEP_DIR/bin:$VCPKG_INSTALLATION_ROOT/installed/x64-windows-release/bin"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$DEP_DIR/lib:$VCPKG_INSTALLATION_ROOT/installed/x64-windows-release/lib"
export CMAKE_PREFIX_PATH="$CMAKE_PREFIX_PATH;$VCPKG_INSTALLATION_ROOT/installed/x64-windows"
export PATH="$PATH:$DEP_DIR/bin:$DEP_DIR/lib:$VCPKG_INSTALLATION_ROOT/installed/x64-windows/bin:/bin:$PWD/ext/dist/bin:$PWD/ext/dist/lib"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$DEP_DIR/bin:$VCPKG_INSTALLATION_ROOT/installed/x64-windows/bin"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$DEP_DIR/lib:$VCPKG_INSTALLATION_ROOT/installed/x64-windows/lib"
# export MY_CMAKE_FLAGS="$MY_CMAKE_FLAGS -DCMAKE_TOOLCHAIN_FILE=$VCPKG_INSTALLATION_ROOT/scripts/buildsystems/vcpkg.cmake"
# export OPENEXR_CMAKE_FLAGS="$OPENEXR_CMAKE_FLAGS -DCMAKE_TOOLCHAIN_FILE=$VCPKG_INSTALLATION_ROOT/scripts/buildsystems/vcpkg.cmake"
@@ -24,46 +25,94 @@ export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$DEP_DIR/lib:$VCPKG_INSTALLATION_ROOT/i
#ls -l "C:/Program Files (x86)/Microsoft Visual Studio" && true
if [[ "$PYTHON_VERSION" == "3.9" ]] ; then
export CMAKE_PREFIX_PATH="$CMAKE_PREFIX_PATH;/c/hostedtoolcache/windows/Python/3.9.13/x64"
export Python_EXECUTABLE="/c/hostedtoolcache/windows/Python/3.9.13/x64/python3.exe"
if [[ "$PYTHON_VERSION" == "3.6" ]] ; then
export CMAKE_PREFIX_PATH="$CMAKE_PREFIX_PATH;/c/hostedtoolcache/windows/Python/3.6.8/x64"
elif [[ "$PYTHON_VERSION" == "3.7" ]] ; then
export CMAKE_PREFIX_PATH="$CMAKE_PREFIX_PATH;/c/hostedtoolcache/windows/Python/3.7.9/x64"
export Python_EXECUTABLE="/c/hostedtoolcache/windows/Python/3.7.9/x64/python.exe"
export PYTHONPATH=$OpenImageIO_ROOT/lib/python${PYTHON_VERSION}/site-packages
elif [[ "$PYTHON_VERSION" == "3.12" ]] ; then
export CMAKE_PREFIX_PATH="$CMAKE_PREFIX_PATH;/c/hostedtoolcache/windows/Python/3.12.10/x64"
export Python_EXECUTABLE="/c/hostedtoolcache/windows/Python/3.12.10/x64/python3.exe"
export PYTHONPATH=$OpenImageIO_ROOT/lib/python${PYTHON_VERSION}/site-packages
elif [[ "$PYTHON_VERSION" == "3.14" ]] ; then
export CMAKE_PREFIX_PATH="$CMAKE_PREFIX_PATH;/c/hostedtoolcache/windows/Python/3.14.3/x64"
export Python_EXECUTABLE="/c/hostedtoolcache/windows/Python/3.14.3/x64/python3.exe"
elif [[ "$PYTHON_VERSION" == "3.9" ]] ; then
export CMAKE_PREFIX_PATH="$CMAKE_PREFIX_PATH;/c/hostedtoolcache/windows/Python/3.9.10/x64"
export Python_EXECUTABLE="/c/hostedtoolcache/windows/Python/3.9.10/x64/python3.exe"
export PYTHONPATH=$OpenImageIO_ROOT/lib/python${PYTHON_VERSION}/site-packages
fi
pip install numpy
if [[ "${OIIO_PYTHON_BINDINGS_BACKEND:-}" == "both" || "${OIIO_PYTHON_BINDINGS_BACKEND:-}" == "nanobind" ]] ; then
_oiio_nanobind_requirements_file="$PWD/src/build-scripts/ci-requirements-nanobind.txt"
"${Python_EXECUTABLE:-python}" -m pip install -r "$_oiio_nanobind_requirements_file" --require-hashes
fi
# In case we need vcpkg, example:
# echo "All pre-installed VCPkg installs:"
# vcpkg list
# echo "---------------"
########################################################################
# Dependency method #1: Use vcpkg (disabled)
#
# Currently we are not using this, but here it is for reference:
#
echo "All pre-installed VCPkg installs:"
vcpkg list
echo "---------------"
# vcpkg update
# vcpkg install libdeflate:x64-windows-release
# export CMAKE_PREFIX_PATH="$CMAKE_PREFIX_PATH:$VCPKG_INSTALLATION_ROOT/installed/x64-windows-release"
#echo "All VCPkg installs:"
#vcpkg list
#
time vcpkg install boost-container:x64-windows
time vcpkg install boost-filesystem:x64-windows
time vcpkg install boost-math:x64-windows
time vcpkg install boost-stacktrace:x64-windows
time vcpkg install boost-system:x64-windows
time vcpkg install boost-thread:x64-windows
# # vcpkg install zlib:x64-windows
vcpkg install tiff:x64-windows
# vcpkg install libpng:x64-windows
# vcpkg install giflib:x64-windows
vcpkg install freetype:x64-windows
# # vcpkg install openexr:x64-windows
vcpkg install libjpeg-turbo:x64-windows
#
# vcpkg install libraw:x64-windows
# vcpkg install openjpeg:x64-windows
# # vcpkg install ffmpeg:x64-windows # takes FOREVER!
# # vcpkg install webp:x64-windows # No such vcpkg package?a
#
# #echo "$VCPKG_INSTALLATION_ROOT"
# #ls "$VCPKG_INSTALLATION_ROOT"
# #echo "$VCPKG_INSTALLATION_ROOT/installed/x64-windows"
# #ls "$VCPKG_INSTALLATION_ROOT/installed/x64-windows"
# #echo "$VCPKG_INSTALLATION_ROOT/installed/x64-windows/lib"
# #ls "$VCPKG_INSTALLATION_ROOT/installed/x64-windows/lib"
# #echo "$VCPKG_INSTALLATION_ROOT/installed/x64-windows/bin"
# #ls "$VCPKG_INSTALLATION_ROOT/installed/x64-windows/bin"
#
# # export PATH="$PATH:$DEP_DIR/bin:$VCPKG_INSTALLATION_ROOT/installed/x64-windows/bin"
# export PATH="$DEP_DIR/lib:$DEP_DIR/bin:$PATH:$VCPKG_INSTALLATION_ROOT/installed/x64-windows/lib"
export CMAKE_PREFIX_PATH="$CMAKE_PREFIX_PATH;$VCPKG_INSTALLATION_ROOT/installed/x64-windows/lib"
# export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$VCPKG_INSTALLATION_ROOT/installed/x64-windows/lib:$DEP_DIR/lib:$DEP_DIR/bin"
#
echo "All VCPkg installs:"
vcpkg list
#
########################################################################
########################################################################
# Dependency method #2: Build from source ourselves
#
#
if [[ "$LIBTIFF_VERSION" != "" ]] ; then
source src/build-scripts/build_libtiff.bash
fi
# src/build-scripts/build_zlib.bash
# export ZLIB_ROOT=$PWD/ext/dist
if [[ "$PYBIND11_VERSION" != "0" ]] ; then
source src/build-scripts/build_pybind11.bash
fi
# src/build-scripts/build_libpng.bash
# export PNG_ROOT=$PWD/ext/dist
# We're currently getting libtiff from vcpkg
#src/build-scripts/build_libtiff.bash
#export TIFF_ROOT=$PWD/ext/dist
# We're currently getting jpeg from vcpkg
# LIBJPEGTURBO_CONFIG_OPTS=-DWITH_SIMD=OFF
# # ^^ because we're too lazy to build nasm
# src/build-scripts/build_libjpeg-turbo.bash
# export JPEGTurbo_ROOT=$PWD/ext/dist
source src/build-scripts/build_pybind11.bash
#export pybind11_ROOT=$PWD/ext/dist
# curl --location https://ffmpeg.zeranoe.com/builds/win64/dev/ffmpeg-4.2.1-win64-dev.zip -o ffmpeg-dev.zip
@@ -73,27 +122,24 @@ fi
echo "CMAKE_PREFIX_PATH = $CMAKE_PREFIX_PATH"
if [[ "$OPENEXR_VERSION" != "" ]] ; then
OPENEXR_CXX_FLAGS=" /W1 /EHsc /DWIN32=1 "
OPENEXR_INSTALL_DIR=$DEP_DIR
source src/build-scripts/build_openexr.bash
export PATH="$OPENEXR_INSTALL_DIR/bin:$OPENEXR_INSTALL_DIR/lib:$PATH"
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$PATH
# the above line is admittedly sketchy
fi
OPENEXR_CXX_FLAGS=" /W1 /EHsc /DWIN32=1 "
#OPENEXR_BUILD_TYPE=$CMAKE_BUILD_TYPE
OPENEXR_INSTALL_DIR=$DEP_DIR
source src/build-scripts/build_openexr.bash
export PATH="$OPENEXR_INSTALL_DIR/bin:$OPENEXR_INSTALL_DIR/lib:$PATH"
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$PATH
# the above line is admittedly sketchy
echo "OPENCOLORIO_VERSION='${OPENCOLORIO_VERSION}'"
if [[ "$OPENCOLORIO_VERSION" != "" ]] ; then
OPENCOLORIO_INSTALL_DIR=$DEP_DIR
source src/build-scripts/build_opencolorio.bash
export PATH="$OPENCOLORIO_INSTALL_DIR/bin:$OPENCOLORIO_INSTALL_DIR/lib:$PATH"
fi
cp $DEP_DIR/lib/*.lib $DEP_DIR/bin || true
cp $DEP_DIR/bin/*.dll $DEP_DIR/lib || true
cp $DEP_DIR/lib/*.lib $DEP_DIR/bin
cp $DEP_DIR/bin/*.dll $DEP_DIR/lib
echo "DEP_DIR $DEP_DIR :"
ls -R -l "$DEP_DIR"
# source src/build-scripts/build_openexr.bash
# export CMAKE_PREFIX_PATH="$CMAKE_PREFIX_PATH;$ILMBASE_ROOT;$OPENEXR_ROOT"
# source src/build-scripts/build_opencolorio.bash
# Save the env for use by other stages
src/build-scripts/save-env.bash
+28 -42
View File
@@ -2,7 +2,7 @@
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# https://github.com/OpenImageIO/oiio
# This script, which assumes it is running on a Mac OSX with Homebrew
# installed, does a "brew install" in all packages reasonably needed by
@@ -19,59 +19,45 @@ if [[ `which brew` == "" ]] ; then
exit 1
fi
set -ex
if [[ "${DO_BREW_UPDATE:=0}" != "0" ]] ; then
brew update >/dev/null
fi
#brew update >/dev/null
echo ""
echo "Before my brew installs:"
brew list --versions
if [[ "$OIIO_BREW_INSTALL_PACKAGES" == "" ]] ; then
OIIO_BREW_INSTALL_PACKAGES=" \
ccache \
dcmtk \
expat \
ffmpeg \
imath \
jpeg-xl \
libheif \
libraw \
libultrahdr \
numpy \
opencolorio \
openexr \
openjpeg \
ptex \
pybind11 \
robin-map \
tbb \
"
if [[ "${USE_OPENCV:=}" != "0" ]] && [[ "${INSTALL_OPENCV:=1}" != "0" ]] ; then
OIIO_BREW_INSTALL_PACKAGES+=" opencv"
fi
if [[ "${USE_OPENVDB:=1}" != "0" ]] && [[ "${INSTALL_OPENVDB:=1}" != "0" ]] ; then
OIIO_BREW_INSTALL_PACKAGES+=" openvdb"
fi
if [[ "${USE_QT:=1}" != "0" ]] && [[ "${INSTALL_QT:=1}" != "0" ]] ; then
OIIO_BREW_INSTALL_PACKAGES+=" qt${QT_VERSION}"
fi
if [[ "${OIIO_PYTHON_BINDINGS_BACKEND:-}" == "both" || "${OIIO_PYTHON_BINDINGS_BACKEND:-}" == "nanobind" ]] ; then
OIIO_BREW_INSTALL_PACKAGES+=" nanobind"
fi
fi
brew install --display-times -q $OIIO_BREW_INSTALL_PACKAGES $OIIO_BREW_EXTRA_INSTALL_PACKAGES || true
# All cases except for clang-format target, we need the dependencies.
brew install --display-times -q gcc ccache cmake ninja boost || true
brew link --overwrite gcc
brew install --display-times -q python@${PYTHON_VERSION} || true
brew unlink python@3.8 || true
brew unlink python@3.9 || true
brew unlink python@3.10 || true
brew link --overwrite --force python@${PYTHON_VERSION} || true
#brew upgrade --display-times -q cmake || true
#brew install --display-times -q libtiff
brew install --display-times -q imath openexr opencolorio
#brew install --display-times -q libpng giflib webp
brew install --display-times -q jpeg-turbo openjpeg
brew install --display-times -q freetype libraw dcmtk pybind11 numpy || true
brew install --display-times -q ffmpeg libheif ptex || true
brew install --display-times -q tbb || true
brew install --display-times -q openvdb || true
brew install --display-times -q opencv || true
brew install --display-times -q qt${QT_VERSION}
echo ""
echo "After brew installs:"
brew list --versions
# Needed on some systems
pip${PYTHON_VERSION} install numpy
# Set up paths. These will only affect the caller if this script is
# run with 'source' rather than in a separate shell.
export PATH=${HOMEBREW_PREFIX}/opt/qt5/bin:$PATH
export PATH=${HOMEBREW_PREFIX}/opt/python/libexec/bin:$PATH
export PYTHONPATH=${HOMEBREW_PREFIX}/lib/python${PYTHON_VERSION}/site-packages:$PYTHONPATH
export PATH=/usr/local/opt/qt5/bin:$PATH
export PATH=/usr/local/opt/python/libexec/bin:$PATH
export PYTHONPATH=/usr/local/lib/python${PYTHON_VERSION}/site-packages:$PYTHONPATH
#export PATH=/usr/local/opt/llvm/bin:$PATH
# Save the env for use by other stages
src/build-scripts/save-env.bash
+22
View File
@@ -0,0 +1,22 @@
#!/usr/bin/env bash
if [[ ! -e ../oiio-images ]] ; then
git clone https://github.com/OpenImageIO/oiio-images.git -b RB-2.4 --depth 1 ../oiio-images
# NOTE: on release branches, this should include `-b RB-x.y`` so that
# updates to the master oiio-images don't break tests in release branches.
fi
# if [[ ! -e ../libtiffpic ]] ; then
# curl -o pics-3.8.0.tar.gz https://download.osgeo.org/libtiff/pics-3.8.0.tar.gz
# tar xf pics-3.8.0.tar.gz -C ..
# fi
if [[ ! -e ../openexr-images ]] ; then
git clone https://github.com/openexr/openexr-images.git --depth 1 ../openexr-images
fi
# if [[ ! -e ../bmpsuite ]] ; then
# mkdir ../bmpsuite
# curl -o bmpsuite.zip http://entropymine.com/jason/bmpsuite/bmpsuite.zip
# unzip bmpsuite.zip -d ../bmpsuite
# fi
-190
View File
@@ -1,190 +0,0 @@
#!/usr/bin/env python3
# Copyright 2018 Nico Weber
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
"""Converts one (or several) .ninja_log files into chrome's about:tracing format.
If clang -ftime-trace .json files are found adjacent to generated files they
are embedded.
Usage:
ninja -C $BUILDDIR
ninjatracing $BUILDDIR/.ninja_log > trace.json
"""
import json
import os
import optparse
import re
import sys
class Target:
"""Represents a single line read for a .ninja_log file. Start and end times
are milliseconds."""
def __init__(self, start, end):
self.start = int(start)
self.end = int(end)
self.targets = []
def read_targets(log, show_all):
"""Reads all targets from .ninja_log file |log_file|, sorted by start
time"""
header = log.readline()
m = re.search(r'^# ninja log v(\d+)\n$', header)
assert m, "unrecognized ninja log version %r" % header
version = int(m.group(1))
assert 5 <= version <= 6, "unsupported ninja log version %d" % version
if version == 6:
# Skip header line
next(log)
targets = {}
last_end_seen = 0
for line in log:
if line.startswith('#'):
continue
start, end, _, name, cmdhash = line.strip().split('\t') # Ignore restat.
if not show_all and int(end) < last_end_seen:
# An earlier time stamp means that this step is the first in a new
# build, possibly an incremental build. Throw away the previous data
# so that this new build will be displayed independently.
targets = {}
last_end_seen = int(end)
targets.setdefault(cmdhash, Target(start, end)).targets.append(name)
return sorted(targets.values(), key=lambda job: job.end, reverse=True)
class Threads:
"""Tries to reconstruct the parallelism from a .ninja_log"""
def __init__(self):
self.workers = [] # Maps thread id to time that thread is occupied for.
def alloc(self, target):
"""Places target in an available thread, or adds a new thread."""
for worker in range(len(self.workers)):
if self.workers[worker] >= target.end:
self.workers[worker] = target.start
return worker
self.workers.append(target.start)
return len(self.workers) - 1
def read_events(trace, options):
"""Reads all events from time-trace json file |trace|."""
trace_data = json.load(trace)
def include_event(event, options):
"""Only include events if they are complete events, are longer than
granularity, and are not totals."""
return ((event['ph'] == 'X') and
(event['dur'] >= options['granularity']) and
(not event['name'].startswith('Total')))
return [x for x in trace_data['traceEvents'] if include_event(x, options)]
def trace_to_dicts(target, trace, options, pid, tid):
"""Read a file-like object |trace| containing -ftime-trace data and yields
about:tracing dict per eligible event in that log."""
ninja_time = (target.end - target.start) * 1000
for event in read_events(trace, options):
# Check if any event duration is greater than the duration from ninja.
if event['dur'] > ninja_time:
print("Inconsistent timing found (clang time > ninja time). Please"
" ensure that timings are from consistent builds.")
sys.exit(1)
# Set tid and pid from ninja log.
event['pid'] = pid
event['tid'] = tid
# Offset trace time stamp by ninja start time.
event['ts'] += (target.start * 1000)
yield event
def embed_time_trace(ninja_log_dir, target, pid, tid, options):
"""Produce time trace output for the specified ninja target. Expects
time-trace file to be in .json file named based on .o file."""
for t in target.targets:
o_path = os.path.join(ninja_log_dir, t)
json_trace_path = os.path.splitext(o_path)[0] + '.json'
try:
with open(json_trace_path, 'r') as trace:
for time_trace_event in trace_to_dicts(target, trace, options,
pid, tid):
yield time_trace_event
except IOError:
pass
def log_to_dicts(log, pid, options):
"""Reads a file-like object |log| containing a .ninja_log, and yields one
about:tracing dict per command found in the log."""
threads = Threads()
for target in read_targets(log, options['showall']):
tid = threads.alloc(target)
yield {
'name': '%0s' % ', '.join(target.targets), 'cat': 'targets',
'ph': 'X', 'ts': (target.start * 1000),
'dur': ((target.end - target.start) * 1000),
'pid': pid, 'tid': tid, 'args': {},
}
if options.get('embed_time_trace', False):
# Add time-trace information into the ninja trace.
try:
ninja_log_dir = os.path.dirname(log.name)
except AttributeError:
continue
for time_trace in embed_time_trace(ninja_log_dir, target, pid,
tid, options):
yield time_trace
def main(argv):
usage = __doc__
parser = optparse.OptionParser(usage)
parser.add_option('-a', '--showall', action='store_true', dest='showall',
default=False,
help='report on last build step for all outputs. Default '
'is to report just on the last (possibly incremental) '
'build')
parser.add_option('-g', '--granularity', type='int', default=50000,
dest='granularity',
help='minimum length time-trace event to embed in '
'microseconds. Default: %default')
parser.add_option('-e', '--embed-time-trace', action='store_true',
default=False, dest='embed_time_trace',
help='embed clang -ftime-trace json file found adjacent '
'to a target file')
(options, args) = parser.parse_args()
if len(args) == 0:
print('Must specify at least one .ninja_log file')
parser.print_help()
return 1
entries = []
for pid, log_file in enumerate(args):
with open(log_file, 'r') as log:
entries += list(log_to_dicts(log, pid, vars(options)))
json.dump(entries, sys.stdout)
if __name__ == '__main__':
sys.exit(main(sys.argv[1:]))
-24
View File
@@ -1,24 +0,0 @@
#!/usr/bin/env bash
# Copyright Contributors to the OpenImageIO project.
# SPDX-License-Identifier: Apache-2.0
# https://github.com/AcademySoftwareFoundation/OpenImageIO
# Important: set -ex causes this whole script to terminate with error if
# any command in it fails. This is crucial for CI tests.
set -ex
CLANG_FORMAT_EXE=${CLANG_FORMAT_EXE:="clang-format"}
echo "Running " `which clang-format` " version " `${CLANG_FORMAT_EXE} --version`
files=`find ./{src,testsuite} \( -name '*.h' -o -name '*.cpp' \) -print \
| grep -Ev 'pugixml|SHA1|farmhash.cpp|libdpx|libcineon|bcdec.h|gif.h|stb_sprintf.h'`
${CLANG_FORMAT_EXE} -i -style=file $files
git diff --color
THEDIFF=`git diff`
if [[ "$THEDIFF" != "" ]] ; then
echo "git diff was not empty. Failing clang-format check."
exit 1
fi

Some files were not shown because too many files have changed in this diff Show More