Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

It's started failing on GHA and is old enough that it's not worth trying
to track down what's broken. We still have MacOS 12 and 13 tests in the
matrix.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…Foundation#4056)

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Switch "bleeding edge" test to gcc13, "latest releases" test to gcc12

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…ainst (AcademySoftwareFoundation#4058)

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…n#4057)

Used to be no problem, but after a recent VSCode update, this seems to
have been causing errors when asking VSCode to format. No idea why this
recently became problematic.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…ademySoftwareFoundation#4060)

The important bug fix is in oiiotool image input when autocc is used,
where we reversed the sense of a test and did the autocc-upon-input if
the file's color space was equivalent to the scene_linear space
(pointlessly), and skipped the conversion if they were different (oh no,
big bug!).

Along the way:

* Add missing try/catch around OCIO call that should have had it.

* Some very ugly SPI-specific recognize-by-name color space heuristics.
I hate this, sorry, but it solves a really important problem for me.

* A bunch of additional debugging messages during color space inventory,
enabled only when debugging, so nobody should see these but me.

* A couple places where we canonicalize the spelling of
"oiio:ColorSpace".

Note that there is still an issue with the color space classification
using OCIO 2.3+'s identification of built-in equivalents by name. These
are shockingly expensive. I will return to this later.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…areFoundation#4062)

A recent change (PR 4026) tried to include Imath.h in cases where there
was no SSE support (to provide a fallback implementation of matrix
invert, because simd.h's native one requires SSE), but it had a mistake
-- it used `#if !OIIO_SIMD_SSE` prior to that symbol being defined! This
caused the header to always be included, which is not what we wanted, as
we desired for that header to not be exposed in the public headers.

This patch offers a temporary/partial fix by simply moving that guarded
include later in the file to after OIIO_SIMD_SSE is defined. For
architectures that support SSE, at least, this achieves our goal of not
exposing Imath.h in public headers.

I need this patch right away to solve a particular problem I'm running
into.

Longer term, we note that this isn't a full solution -- on non-SSE
architectures (like ARM), it still ends up exposing Imath.h against our
desire.

For today, so be it. A better fix would be to rewrite our current
SSE-requiring invert to change the SSE intrinsics therein to the wrapped
kind we use with our simd classes, which will let it work fine with ARM.
But I feel like that needs to be done carefully and with more testing
than I can afford at this minute when I need this fix. I will return to
it shortly, but need this patch now.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…oundation#4061)

- Fix perceptual test false positive by removing the initialization of
`cr` to avoid losing the information when leaving block scope

Included additional test with parameter `-fail 1`, which was giving a
false positive pass for a perceptual difference.
This was due to the fact that the result variable `cr` was getting out
of scope for the perceptual calculation and the first `if (cr.nfail <=
imagesize_t(allowfailures)) {` was testing for the result of the
absolute difference instead of the perceptual difference.

Before:
```
Comparing "img1.exr" and "img2.exr"
PASS
```
After:
```
Comparing "img1.exr" and "img2.exr"
64 x 64, 3 channels
  Mean error = 0
  RMS error = 0
  Peak SNR = 0
  Max error  = 1 @ (5, 17, R)  values are 0.1, 0.1, 0.1 vs 0.1, 0.6, 0.1
  0 pixels (0%) over 0.008
  121 pixels (2.95%) over 1
  121 pixels (2.9541%) failed the perceptual test
FAILURE
```

Signed-off-by: Aura Munoz <aura.munoz@autodesk.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…wareFoundation#4063)

Add a few more assertion checks and error messages in imagebufalgo_test.

I observe that if somebody runs the testsuite with `$OCIO` set to a
config that doesn't contain the required color space names for this
test, it will fail. As a backstop, use the default built-in config if
the initial request fails. That will always give a working processor
between these spaces if OCIO >= 2.2 is being used.

Also one more tiny SPI-specific enhancement to hacky identification of
nonconforming color space names in our old configs.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…twareFoundation#4065)

Slightly different output to match for the combo of OCIO >= 2.2, but
simultaneously Python 2.7 -- which was not in our CI test matrix, so I
missed it, but ran into it at work.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Don't want that included for Cuda compilation, either.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…ademySoftwareFoundation#4071)

## simd.h improvements:

vint4::load from unsigned char pointer got pre-SSE4 code path. Testing
on Ryzen 5950X / VS2022 (with only SSE2 enabled in the build):
- vint4 load from unsigned char[]: 946.1 -> 4232.8 Mvals/sec

vint4::store to unsigned char pointer got simpler/faster SSE code path,
and a NEON code path. Additionally, it got test correctness coverage,
including what happens to values outside of unsigned char range (current
behavior just masks lowest byte, i.e. does not clamp the integer lanes).

- vint4 store to unsigned char[]: 3489.8 -> 3979.3 Mvals/sec
- vint8 store to unsigned char[]: 5516.9 -> 7325.3 Mvals/sec

NEON code path as tested on Mac M1 Max (clang 15):
- vint4 store to unsigned char[]: 4137.2 -> 6074.8 Mvals/sec

## Tests

vint4 store to unsigned char pointer got actual correctness checking
test, which seemingly was lacking before (only had a benchmark test).

Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

In some environments, only one kind of the library could be available.
Choose proper fallback in such cases. Prefer static library, if
LINKSTATIC is ON and dynamic otherwise.

Signed-off-by: Dominik Wójt <domin144@o2.pl>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…ySoftwareFoundation#4073)

Without getting the version properly, we weren't disabling use of a
deprecated field for OpenJpeg >= 2.5, as we thought we were.

This fixes recently broken CI when building against the current openjpeg
master.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…eFoundation#4074)

There was a flaw in PNGOutput::write_scanlines when the y range of
scanlines to write consisted of less than the whole image, and alpha
de-association was needed -- we used the whole-image size instead of the
y range of scanlines size.

Fixes AcademySoftwareFoundation#4044

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

I didn't have the condition right -- the `if` isn't respected in the
`pull_request` section, so this job was running on every PR instead of
just the ones with "macarm" in the branch name. Refactor to get the
conditional on the job instead.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

This change adds OCIO functionality to iv.

To enable OCIO, first set the $OCIO environment variable to point with a
path to the OCIO config. "ocio://default" should work as well.

If a valid config provided, a new menu gets added under "View/OCIO" with
an on/off toggle and submenus to select the image color space and
display/view and optional look.

If an image color space, display and view are provided as command line
parameters ("image-color-space", "display", "view"), then the OCIO mode
is switched on automatically.

If no image color space is provided as command line parameters, the top
most color space of the config get pre-selected in the menus.

If no display or view is provided as command line parameters, the
default values get pre-selected in the menus.

In OCIO mode the exposure and gamma adjustments are done by OCIO. The
exposure is done in scene linear, gamma is still in display space. The
exposure adjustments don't match between the OCIO and non-OCIO modes.

When OCIO fails to initialise the pipeline for any reason, an error
message is shown in the status bar, and the non-OCIO path gets used.

TODO:
- All channel shuffling is done by the existing shader and happens
before the OCIO step. We may want to discuss/change that?
- The initial image color space gets selected from the command line
parameter, or the first color space in the config. There is no attempt
being made to use the image metadata.
- The exposure/gamma values get baked into the shader, which gets
recompiled on every change. We may want to use uniforms instead. - DONE

---------

Signed-off-by: Anton Dukhovnikov <antond@wetafx.co.nz>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…le (AcademySoftwareFoundation#4033)

Historically, ImageBuf has provided Iterator for writing to mutable IB's
and ConstIterator for reading into IBs. If you initialized an Iterator
to an IB that was ImageCache-backed (and therefore by definition not
mutable), it would convert the IB to the mutable kind (basically by
allocating the memory and reading the file through the IC, thus freeing
the IB of its dependence on the cache.

An important bug was fixed by PR 3997, which kinda proved that people
were not depending on this behavior, since it would tend to fail. But it
also got me thinking about to what degree the whole Iterator vs
ConstIterator was really necessary, or did it just make things harder
for users.

In this proposed patch, we change the Iterator behavior so that instead
of immediately making the IB writable as soon as the Iterator was
instantiated and associated with the IB, we instead treat it as a
ConstIterator UNTIL it actually tries to write a value, at which point
we ensure that the IB is writable.

The bottom line is that this seems to work. If you don't want to have to
think about Iterator vs ConstIterator, you don't have to. Iterator is
fine. If you don't actually write into any of the pixels, it behaves
just like a ConstIterator, including being perfectly happy with an
IC-backed IB. Performance metrics indicate that there is NO penalty for
doing so -- if you are only reading pixel values, traversing an IB with
Iterator is the same speed as doing it with ConstIterator.

I had one sleepless night after implementing this when suddenly I
realized that this was totally not thread-safe, that somehow multiple
iterators traversing the same IB would screw each other up if one of
them wrote to a pixel and converted the image. So I put in a test to
have many threads concurrently traversing the same IB, some with
ConstIterator, some with Iterator but only reading, and some with
Iterator and writing. I have not been able to trigger any failures or
crashes. It seems fine. (I did use the mutex a little more aggressively
than before.)

Why is this not as dangerous as I thought? Mainly because once an
iterator (of either variety) thinks it's dealing with an IC-backed
ImageBuf, basically, it will just happily keep using the IC all on its
own, even if the IB that it's supposedly traversing has, because another
thread's iterator has written to a pixel, "localized" the image and
severed the IC dependence. Then if it also needs to write, it will
(safely, because of a mutex) see that the image is already
localized/writable, and start using that representation.

So herein lies a very important caveat about using IB iterators: If you
have multiple iterators traversing the same IB and any of them are
*writing* to the image, the iterators may not see a globally temporally
consistent version of the image. Put in plain English: iterators that
are strictly reading may see an IC-backed disk image as it was on disk,
and not as it has since been modified by a different active iterator. So
if you are modifying an image in place, beware of using multiple
iterators, because a reading iterator may or may not see the changes
that a writing iterator made to a pixel value.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…oundation#4075)

Please look this over. If you are one of the duplicated names and I
haven't chosen your preferred canonical email (I made my best guess),
please comment here with corrections.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…twareFoundation#4085)

Fix for AcademySoftwareFoundation#4084. Will now check if the given filename exists before
checking for REST parameters.

Before:
```
bin % ./oiiotool \?.png -o \?-output.png
oiiotool ERROR: read : "?.png": ImageInput::create() called with malformed filename
Full command line was:
> oiiotool ?.png -o ?-output.png
```

After:
```
bin % ./oiiotool \?.png -o \?-output.png
```
No output, `?-output.png` created.

Signed-off-by: AdamMainsTL <adam.mains@topazlabs.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

## Description

Minimal change to update link to OpenEXR's new Test Images page. I poked
around a bit to find a "friendlier" variant of the link but could find
none.

Note that the section containing this link implies that folks need to
download these files themselves and should be "placed in a sibling
directory to oiio-testimages". The problem is that not even OpenEXR
lists the repository for the test images nor does the page linked above
offer a download.

Should we list out the openexr-images repo address too and say to just
clone that?

Fixes AcademySoftwareFoundation#4042

---------

Signed-off-by: Jesse Yurkovich <jesse.y@gmail.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…twareFoundation#4092)

Unity builds (which we do for CI to speed it up) combine source files,
sometimes in ways that are a bit non-deterministic, and can run into
violations of the ODR that were not a problem when separate definitions
of the same thing (a macro in this case) were in different compilation
units but are in the same one as a unity build.

In this case, a private OIIO_DISPATCH_TYPES macro in printinfo.cpp
conflicted with a different macro of the same name in
imagebufalgo_util.h.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…reFoundation#4088)

For the in-place case (where src and dst refer to the same IB), we were
doing an unnecessary full-image copy.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…twareFoundation#4086)

It's a little involved to explain why, but at work a combination of
libraries and some trickery with static linkage led me to really need a
way to inject another library into the mix, just for iv linkage.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…areFoundation#4087)

For image with more than 4 channels, we were misallocating the OpenGL
buffer by using the total channels instead of the 4 we wanted to create
the texture out of. Also, make sure the calculation usees wide types to
avoid possible integer overflow.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

This broke some time back, probably partly related to our change in
repository home. This seems to get it mostly working? The reports are
still not showing up, but I think the solution might be to make sure
this is checked into master, so we need to merge this before assessing
whether there is more work to be done in this area.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…on#4091)

Move a bunch of specific tests from testsuite/oiiotool to
testsuite/oiiotool-copy to group similar tests together, and also to
load balance better between the tests.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…AcademySoftwareFoundation#4099)

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…n#4098)

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…reFoundation#4076)

We had an awkward situation of the simd matrix44::inverse() only being
defined for Intel SSE, and in all other cases falling back on
Imath::M44f::inverse. The problem with that is that it made simd.h
depend either directly on ImathMatrix.h, or assume that it would be
included prior to inclusion of simd.h. This was not good.

This patch rewrites inverse() to eliminate all of the direct SSE
intrinsics in terms of other simd wrapper functions, which means that
they will be defined one way or another on all architectures.

Along the way I added a new vfloat4 shuffle that combines two vectors
(corresponding to `_mm_shuffle_ps` in SSE land), and a vfloat4
constructor from 2 float*', where the first two elements come from the
first ptr and the second two elements come from the second ptr.
Ultimately, the final implementation I settled on for the new inverse
didn't use these (an earlier version did), but I want to keep them
around anyway in case they are useful in the future. I did add a test
for them.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…4090)

We did `import OpenImageIO as oiio` then instead of using `oiio`, we
used `OpenImageIO`.

This was failing sometimes. Frankly, I'm not sure why it ever worked.
Maybe it works on some versions of Python but not others?
I dunno. But this fixes it everywhere and is clearly correct.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…ion#4093)

This patch adds a new oiiotool command: `--cryptomatte-colors`, which
takes the name of a cryptomatte set of channels, and produces a
color-coded matte in which each ID gets a distinct color in the image.
This can be useful for visualizing the matte, among other things.

Maybe this is the first cryptomatte related functionality of many?

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

fmt provides cmake config files since at least version 7.0.0, which is
the minimum version supported.
Fixed some variable names, so the provided config can be used.
The previous variable names were missing, if the library was installed
in a custom location,
like in case of manual build or provided by conan.

---------

Signed-off-by: Dominik Wójt <domin144@o2.pl>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Verified that the memcpy trick works fine (even when used in vectorized
loops) for gcc, clang, MSVS, icx. So change the specialized versions using
intrinsics so they are only used for icc, which fails to vectorize loops when
the memcpy trick is used.

Also get rid of unused double specializations.

---------

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…on#4103)

Remove duplicate dependecy for OpenImageIO_Util to fmt.
OpenImageIO target already depends on fmt through OpenImangeIO_Util
library.

Signed-off-by: Dominik Wójt <domin144@o2.pl>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…cademySoftwareFoundation#4096)

Bump our clang-format standard from llvm 12 to llvm 17, and our
C++ standard (for formatting) to 17.

Fixes/improvements along the way:

* Moved the clang-format CI test from an aswf container to bare Ubuntu
  to make it run faster -- it doesn't need most of the dependencies,
  so there's no point wasting 2 minutes or so downloading a container.

* build_llvm.bash: Make sure llvm installs when needed, even if not
  using clang.

* gh-installdeps.bash: Setting SKIP_SYSTEM_DEPS_INSTALL=1 skips
  installation of many non-essential dependencies.

There is some reformatting here and there as 12->17 changed some formatting
choices somewhat, but it's fairly minor. Most changes are improvements,
some are neutral, a few are inexplicable but not less readable than before.
We've long since accepted the tradeoff that using clang-format makes some
things formatted differently/worse than we would have preferred, but we deem
it worthy of the benefit of having it all 10% automatic and never fighting
over formatting in PRs.

---------

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…areFoundation#4100)

If you are looping i over range [0,width), and want index to go the
other direction, you need `index = width - 1 - i`, not `index = width - i`.

Identified by Sonar static analysis.

---------

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…dation#4079)

The one we were using is broken. John's is surely the GOAT notifier.

---------

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: John Mertic <jmertic@linuxfoundation.org>
Co-authored-by: John Mertic <jmertic@linuxfoundation.org>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…SoftwareFoundation#4109)

Fixes a CI breakage

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…oundation#4104)

The function signatures in the header didn't match those in the docs,
after some previous changes. It's probably been broken in the docs for
some time. Nobody noticed?

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…reFoundation#4113)

* pngoutput.cpp: Catch possible exceptions.
* printinfo.cpp: assertions to assure we don't dereference a null
pointer.
* testtex.cpp: make sure allocated chunk is initialized
* WriterInternal.h: Catch condition that could lead to buffer underflow.
* imagebufalgo_mad.cpp: Simplify pointless clause. The prior test was
redundant. Since a few lines above, if B was an image but A was not, we
swapped to ensure that A was always an image. So here, we can just test
A to know for sure that at least one of them is an image. That makes the
test here simpler, but it also makes it more clear to static analysis
that from this point forward, A can't be nullptr.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…yable (AcademySoftwareFoundation#4110)

*  Use default implementations of copy ctr, destructor, and assignment
    from ustring. This allows ustring & ustringhash to be recognized as
    being a variety of flavors of trivially constructible, copyable, and
    destructible.

*   It seems that the assignment operators were returning const &
    whereas it's more typical to return &, so now we do.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…ion#4114)

Bleeding edge CI test failures due to more changes in fmt's trunk.
Solutions:

* Accommodate some recent header refactoring in fmt.

* Straighten up some const issues that worked before, but break under
the latest fmt. Making the custom formatter's 'format' method be const
fixes the latest, but breaks some of the oldest versions of fmt we
support, so we add the const only from fmt 9.0 on.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…#4105)

Some of the ways we were using unions for type punning in the vbool16
class were unnecessary, as both union members were basically the same
type. Simplify by getting rid of the unnecessary m_bits union member.

This also makes Sonar static analysis happier about these dubious uses
of unions for type punning.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Thanks to Matteo Vescovi for pointing these out.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

This PR fixes vfloat16 round function. Intrinsic `_mm512_roundscale_ps`
was used incorrectly, and caused failure on Zen4 CPU.

```
/var/tmp/portage/media-libs/openimageio-2.5.5.0-r1/work/OpenImageIO-2.5.5.0/src/libutil/simd_test.cpp:1579:
FAILED: round(F) == mkvec<VEC>(std::round(F[0]), std::round(F[1]), std::round(F[2]), std::round(F[3]))
	values were '-1.5 0 1.5 4 -1.5 0 1.5 4 -1.5 0 1.5 4 -1.5 0 1.5 4' and '-2 0 2 4 -2 0 2 4 -2 0 2 4 -2 0 2 4'
```

In old code `_mm512_roundscale_ps (a, (1<<4) | 3)` meant the following:
```
[0001] - Number of fixed points to preserve
[0] - Use MSCSR exception mask
[0] - Select mode from imm
[11] - Truncate mode
```
Effectively enabling rounding to nearest 0.5, not to integer.

References:
* https://www.felixcloutier.com/x86/vrndscalepd#fig-5-29
*
https://stackoverflow.com/questions/50854991/instrinsic-mm512-round-ps-is-missing-for-avx512

Signed-off-by: Sv. Lockal <lockalsash@gmail.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…emySoftwareFoundation#4108)

There are two different IBA::fit() entry points -- one that takes a
Filter2D* and one that takes a name of the filter. In both cases, if the
supplied filter is empty, fit will make its best guess (which, roughly
speaking, is supposed to be lanczos3 when shrinking and
blackman-harris when zooming).

You might expect that both, for the "pick my filter" case, would end up
with the same filters, but they did not! And the "wrong" one was -- ick
-- using an awful triangle filter. So when they were unified to both use
the same logic, it was easy to see that the one being used by oiiotool
was using the triangle and definitely over-blurring! So I think the
images look much nicer now that it's using the lanczos3 in appropriate
circumstances.

Sometimes lanczos3 can over-sharpen and you see some ringing. That was
easy to see at the edges of images that were being letterboxed, so I
also put a little extra guard in filtered_sample() so that when it's
asked to do edge clamping, it doesn't try to apply the filter too far
off the edge of the image boundary.

You *still* may see a little over-ringing in some cases, and if you do,
that's a sign that maybe you should be selecting a different, slightly
less harsh, filter rather than use its default. Or, does anybody want to
argue that we should switch the default resizing filter to be
blackman-harris, which is a lot less likely to have unsightly ringing,
and if you want something even sharper, you should have to ask for
lanczos3?

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…AcademySoftwareFoundation#4106)

These things were scattered around fmath.h. This grouping corresponds to
things in C++20 <bit> (but of course works for older C++ and for Cuda)
and lets modules use those without needing the full fmath.h.

Switch our swap_endian implementation to the "byteswap" name and
semantics to match C++20. The old swap_endian just calls those. Also add
a version of byteswap (in fmath) that takes an OIIO::span, since we
generally are leaning toward preferring spans rather than raw pointers
and lengths as separate parameters.

None of this should break source or binary compatibility for
applications.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…wareFoundation#4122)

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…emySoftwareFoundation#4070)

Upon reading, the subsampled Y/BY/RY(/A) channels of luminance-chroma
images are automatically converted to RGB(A) channels. These images will
set a metadata "openexr::luminancechroma" to 1 in the ImageSpec, to indicate
that the original image was luminance/chroma.

Subsampled channels are not supported with the exception of reading
luminance-chroma images with vertical and horizontal sampling rates of 2.
This limited support does not work when OpenEXR's C Core API in used, only
when OpenEXR's C++ API is used. Furthermore, it does not work in
combination with tiles, multiple subimages, mipmapping, or deep pixels.

The test images from the OpenEXR testsuite have been added and work with
the C++ variant of the test.

Fixes AcademySoftwareFoundation#4051.

---------

Signed-off-by: Joachim Reichel <43646584+jreichel-nvidia@users.noreply.github.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…wareFoundation#4115)

With GitHub runners with more cores becoming available, adjust our CI
scripts to do parallel builds with nprocs+2 instead of hard-coding. We
use slightly more than the number of available cores because these
builds and tests tend to be I/O bound, so they can be a little
over-threaded to get maximum utilization.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…areFoundation#4120)

OpenVDB >= 10.1 is incompatible with building OIIO using C++14. We had
tried to disable this disallowed combination, but a typo prevented it
from working properly.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

A better default for users is probably to assume a 2.2 value if the
GAMMA env variable is not set. If you want something different, set
GAMMA proactively or use a real color managed workflow.

Fixes AcademySoftwareFoundation#318

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

New OIIO global attributes (read only):

- "build:platform" retrieves the OS and CPU type that this build of OIIO
is fof (e.g., "Linux/x86_64").
- "build:compiler" retrieves the compiler name and version used to build
OIIO itself (e.g. "gcc 9.3").
- "build:dependencies" retrieves a semicolon-separated list of library
dependencies -- both for image format support (like libtiff) but also
general (boost, TBB, Python, fmt, OCIO).
- "build:simd" is a new (preferred) synonym for the SIMD and other
hardware capabilities selected at build time. The old name, "oiio:simd"
is hereby softly deprecated as confusing.

`oiiotool --buildinfo` is a new command that prints this information.

Example output:

```
$ oiiotool --buildinfo

OIIO 2.6.0.2spi | MacOS/x86_64
    Build compiler: Apple clang 15.0 | C++17/201703
    HW features enabled at build: sse2,sse3,ssse3,sse41,sse42
Dependencies: OpenEXR 3.2.1, LIBTIFF Version 4.6.0, jpeg-turbo
    3.0.1/jp80, dcmtk 3.6.8, FFMpeg 6.0 (Lavf60.16.100), gif_lib 5.2.1,
    libheif 1.17.6, OpenJpeg 2.5.0, null 1.0, OpenVDB 11.0.0abi11, libpng
    1.6.40, Ptex 2.4, libraw 0.21.2-Release, Webp 1.3.2, Boost 1.83,
    OpenColorIO 2.3.1, Python 3.11.7, TBB 2021.11.0, fmt 10.2.1
```

This is all a convenience utility to make it easy to ask users to run a
simple command that will tell us a lot of information relevant to
resolving their issues in cases where it's related to some of their
build-time compiler or dependencies.

Also cleaned up the "bug report issue template" to clarify the
instructions and specifically ask people to run this command and include
the information with any bug report.

---------

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…ble (AcademySoftwareFoundation#4129)

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…reFoundation#4130)

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…cademySoftwareFoundation#4132)

We had all along omitted an important 'int' conversion case for an
internal to_floats() helper function that's used by the
TypeDesc::convert_type utility. Which is in turn used by
ParamValue::get_float() and ParamValueList::get_float().

All of these would fail to return the proper float if the underlying
data was an int, despite these functions saying that they would have no
trouble returning the float equivalent of int data when asked.

I added a test that verifies that it's wrking.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…4125)

* New header span_util.h with span-related helpers:
  - make_span/make_cspan helps for converting vectors & arrays to spans
when passing to templated functions.
  - spancpy, spanset, spanzero are memory-safe, range-checking
substitutions for memcpy, memset when working with spans.
* Add range check DASSERT to span access in debug mode. There were a
couple spots where we were taking the address of an out-of-range value
that needed to be adjusted to use a better idiom.
* ParamValue: extra OIIO_DASSERT range check for get() method.
* Simplify constructors by replacing `&x[0]` with using `data()`, which
is always well-defined.
* Fix typos in span.h comments

The range checking imposes no extra cost for release/optimized builds.
But it might help us for CI analysis and any time we're debugging.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…areFoundation#4136)

Fixes AcademySoftwareFoundation#4135

Thanks to @OgreTransporter for the suggestion.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…ndation#4138)

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Co-authored-by: Thiago Ize <ThiagoIze@users.noreply.github.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…wareFoundation#4137)

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…reFoundation#4134)

No more need for the paid macos13-arm-py311 runner and only use it on
the ASWF repo selectively. An ARM-based MacOS-14 runner is now available
for open source projects, so can run free on every PR and on user forks.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…complaints (AcademySoftwareFoundation#4128)

* jpeg output: Extra memory check
* TS: batch texture call fixed to handle any number of channels
* TS: assert to guard against possible null pointer dereference
* oiiotool printinfo: clarify assertion for the sake of static analysis
* jpeg2000 reader: assertion to ensure we don't dereference a null
pointer

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

typos

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…Foundation#4141)

Eliminates some GHA warnings.

---------

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Primarily, recent changes (PR AcademySoftwareFoundation#4071) to vint4::store for the NEON case
appear to have some type mismatches, which apple clang on ARM-based Mac
(including our CI) seems ok with, but which is generating type errors on
other ARM Linux platforms.

I think the types were weird here, so I tightened it up to get the types
right for temporary variables in that function. That's the primary fix
here.

Secondarily, I modified simd.h and the CMake setup so that build option
USE_SIMD=0 will disable NEON in the same way that it disables SSE. (I
realized that USE_SIMD=0 was not disabling NEON, so there was no way for
a NEON platform to completely disable SIMD if they needed to.)

Fixes AcademySoftwareFoundation#4111

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…ademySoftwareFoundation#4127)

Remember that ImageBuf only stores one pixel data type per buffer, but
of course they may have differing-per-channel types in image files. So
how does oiiotool know what to write? There is a series of heuristics:
-d is for explicit user control, if not, then try to deduce it from the
input files.

A bedrock precept is that `oiiotool in.exr -o out.exr` ought to write
the same channel types that it read in.

The logic to implement this with the various image operations and
possible overrides can be hard to get right. Indeed, I did not get it
right. It made mistakes even in simple cases like the above. And the
code was complicated and hard to understand, as well.

This PR rewrites a couple functions that implement this chunk of this
logic, both correcting several errors as well as (I hope) being clearer
and better commented so that we can more easily reason about it and
modify it in the future.

I also added some additional tests to testsuite/perchannel to verify
some of the cases that were previously failing.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…mySoftwareFoundation#4121)

We did this separately each place we needed it. Do it just once, in a
public header, and give it a name that won't clash with other packages.

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

…emySoftwareFoundation#4140)

Add testsuite/filters that verifies that the filter shapes are correct
and don't change if we make future changes to the filter code.

Along the way, add a new global getattribute query 'filter_list', that
returns a semicolon-separated list of all the 2D filters it knows about.

---------

Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>

Signed-off-by: Peter Kovář <peter.kovar@reflexion.tv>