Don't copy from memory using the stride, as this can get padded and read
past the end of the input pixel data. The 10 and 12 bit paths were
correct.
Test added, this only failed with address sanitizer.
Signed-off-by: Brecht Van Lommel <brecht@blender.org>
Implement support for reading and writing monochrome. Reading requires
libheif 1.17+ for heif_image_handle_get_preferred_decoding_colorspace.
Previously writing a single channel image would cause an exception due
to
wrong parameters, but close() would continue writing the image and
crash.
Destroy m_ctx on exception to prevent that for other potential errors.
Test added for monochrome read and write.
---------
Signed-off-by: Brecht Van Lommel <brecht@blender.org>
Like other file formats, the returned ImageSpec should indicate if the
image contains unassociated alpha.
This was an oversight in #4770.
Test added.
Signed-off-by: Brecht Van Lommel <brecht@blender.org>
Add IOProxy support similar to other file formats.
MyHeifWriter was renamed for consistency with other code.
All input and output now goes through the proxy, so this is covered by
existing tests.
Signed-off-by: Brecht Van Lommel <brecht@blender.org>
Initializing the encoder to `heif_compression_HEVC` by default throws an
exception when libheif was built without HEVC support, which prevents it
from being used entirely even if there is AVIF support.
So delay that initialization until we are sure which encoding we want.
Not really any practical way to automatically test this.
Signed-off-by: Brecht Van Lommel <brecht@blender.org>
The JPEG XL color encoding metadata only supports a subset of CICP. So
for
example `srgb_p3d65_display` and `pq_rec2020_display` are supported, but
`g26_xyzd65_display` is not.
Custom primaries, custom white point and arbitrary gamma could be used
to
support more, but I didn't implement that.
Tests for read and write were added.
Signed-off-by: Brecht Van Lommel <brecht@blender.org>
If the colorspace exists and has an interop ID in an OCIO 2.5 config,
use that.
Otherwise check if the colorspace is equivalent to a known color interop
ID.
Tests were added.
Signed-off-by: Brecht Van Lommel <brecht@blender.org>
When reading image files with CICP metadata, automatically set the
corresponding "oiio:ColorSpace". When writing files that support CICP
and no other colorspace metadata can represent "oiio:ColorSpace",
automatically write CICP metadata.
Setting "oiio:ColorSpace" on read prefers scene referred over display
referred color spaces, changing existing behavior as little as possible.
The alternative would have been to interpret the presence of CICP
metadata as an indication that the image is likely display referred,
which might be reasonable too. Either way it's a guess.
There is no automatic mapping from `g22_rec709_display` to CICP
currently to keep behavior unchanged, as this is often not what you want
and further discussion is needed to decided on the right behavior.
Also add new ColorConfig `get_cicp` and `get_color_interop_id` API
functions to share logic between file formats.
## Tests
Tests were updated, the auto detected color space name appears in the
output.
Commands like these should also do the right thing automatically.
```
oiiotool in.exr --ociodisplay "Rec.2100-PQ - Display" "ACES 2.0 - HDR 1000 nits (P3 D65)" -o out.avif
oiiotool out.avif --autocc -o out.exr
```
---------
Signed-off-by: Brecht Van Lommel <brecht@blender.org>
The EXR reading code was correct. These attribute names are case
sensitive in OpenEXR.
Test output was updated.
Signed-off-by: Brecht Van Lommel <brecht@blender.org>
Due to apparent limitations or bugs in swscale, there is a problem
reading the 16 bit green channel that is not 4 byte aligned like red and
blue. Reading each channel into its own plane solves the issue.
This also addresses an existing comment about 32 bit float being read as
16 bit. This needed the same mechanism of reading separate planes, so
the same code is reused to implement that.
Resolves#4901
I added a 10 bit test file encoded with VP9 and Matroska, same as the
existing 8 bit test file to maximize compatibility. I verified this now
converts correctly to a HDR PNG file.
Signed-off-by: Brecht Van Lommel <brecht@blender.org>
Many codecs don't provide `bits_per_raw_sample`. The bit depth of the
luma channel is the closest equivalent to a single bit depth then, while
the chroma channels may be subsampled.
Tested on basically all the video files on my computer, they all give a
non-zero bit depth that looks correct now.
Signed-off-by: Brecht Van Lommel <brecht@blender.org>
* Read and write 10 and 12 bit images
* Read and write CICP
This makes it possible to write HDR images that are much smaller than
PNGs, in a file format that is supported in all modern web browsers.
By setting the matrix coefficients, the library will perform RGB to YUV
conversion on write. The YUV to RBG conversion was already happening on
read automatically.
A future improvement would be a better default choice of matrix
coefficients for writing. When no CICP is specified or when CICP is read
from PNG, then no conversion to YUV will be performed and compression
will not work as well. This is the same behavior as before. When there
is support for conversion between CICP and display interop ID, a good
default choice for matrix coefficients could be made as part of that.
Tests for CICP and 10 bit were added.
---------
Signed-off-by: Brecht Van Lommel <brecht@blender.org>
The actual CICP reading code is trivial.
Also recognize mkv (Matroska) extension for the test.
Add test using Matroska + VP9, to maximize the chance of an ffmpeg build
supporting them. They are royalty free, built into ffmpeg and relatively
old.
Signed-off-by: Brecht Van Lommel <brecht@blender.org>
This got lost with the 2-level namespace changes in #4567, but is used
by e.g. OpenUSD. Might as well not break the API here.
Signed-off-by: Brecht Van Lommel <brecht@blender.org>
Only use the OIIO_LIBRARY_PATH environment variable by default.
Searching through such system paths has some risk loading plugins
installed for another purpose or that may be incompatible.
If the previous behavior is desired, applications can add these
environment variables to the plugin search path manually.
Signed-off-by: Brecht Van Lommel <brecht@blender.org>
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.
When the texture cache reads scanlines in random order, the same pixels could
be read many times over. Now the file offset for scanlines is cached for quick
random access.
* PNG, TIFF and TGA input still had oiio:UnassociatedAlpha set to 1 after they
convert the alpha to associated.
* PNG output did not take oiio:UnassociatedAlpha into account to determine if
conversion should be done, while TIFF did.
For most other fileformats this was already fixed, and I thought this wasn't
possible with the current OpenEXR API, but it turns out it is by implementing
a custom input/output stream class.
The code for these is copied from ImfStdIO.h/cpp which are the classes that
would be used otherwise, so exception handling etc should work identical.
passing the file descriptor. This moves platform specific code into the tiff
plugin code, but it should be safer than trying to obtain the right file handle
with fopen.
* New Filesystem utility functions wrap fopen, open, and last_write_time
but do so in a way that is safe for UTF-8 filenames on Windows (for example,
we need to call _wfopen rather than fopen on Windows).
* The various plugins that called fopen/etc directly have been changed to
use these Filesystems wrappers.
* Add Filesystem::convert_native_arguments which modifies an argv[] in
place to convert Windows native to UTF-8 (does nothing for non-Windows).
* Create a wrapper for last_write_time that, like many other Filesystem
wrappers, catches the exceptions that can happen
* Fix file handle leak with failed read of tiff/z gzipped files.
Brecht Van Lommel