That's a good point and a good example, Thiago.
Now that this release is on its way out the door, let me see where I left that
in-progress Cuda code. I think I can set up the basic infrastructure and
prototype a couple IBA functions, and then it'll be open to people making PRs
to add Cuda implementations of any other individual IBA functionality that
seems like it would benefit.
-- lg
> On Aug 18, 2021, at 10:16 AM, Thiago Ize <thi...@solidangle.com> wrote:
>
> OIIO::ImageBufAlgo::convolve is currently used in Arnold's bloom filter, and
> bloom is applied every time the image is updated during IPR, so that's at
> least one example where CUDA would likely help out.
>
> On Wed, Aug 18, 2021 at 10:21 AM Larry Gritz <l...@larrygritz.com
> <mailto:l...@larrygritz.com>> wrote:
> Currently, OIIO doesn't use Cuda in any way. I have a private branch in which
> I prototyped using Cuda for some of the image math when available. It's in an
> incomplete state, but I'd like to revive it and turn it into a PR at some
> point. The reason it hasn't been a priority to finish that work is that when
> I analyze how OIIO is used (in particular, oiiotool), the fact is that even
> now, the typical usage pattern is
>
> 1. read input images from disk
> 2. do some image processing on those images
> 3. write the output to disk
>
> #1 and #3 -- the disk or network I/O -- typically dominate any oiiotool or
> scripted OIIO operation. This makes it surprisingly hard to get a substantial
> speedup by using the GPU for #2 (which would also involve having to add steps
> #1.5 copy the inputs from main memory to the GPU, and #2.5 copy the outputs
> from GPU back to main memory).
>
> The case where GPU might speed things up substantially would be if you needed
> to read inputs from disk once, do a WHOLE LOT of steps of image math on those
> in-memory images -- in other words, a complex pipeline of image operations
> where the data can stay on the GPU the whole time -- and then write the final
> result to disk once. But as far as I can tell, that's not the pattern for the
> most common ways that people use OIIO, which are typically simple things like
> remapping value ranges, cropping an image, doing a color space
> transformation, or simply converting from one data or file type to another.
> I/O still dominates.
>
> It's been a few years since I gave this a serious look, so maybe I can do
> better if I put some more time into it? Or maybe there are use cases where
> people are doing a whole lot of processing for each I/O operation?
>
>
>> On Aug 18, 2021, at 4:56 AM, Reverator <i...@reverator.com
>> <mailto:i...@reverator.com>> wrote:
>>
>> Hi Larry,
>>
>> Just wanted to thank you for all the extremely valuable work you’re doing
>> for me, and of course for the developer community at large.
>>
>> I have not had a need for OIIO for the past 2 years or so, but I’m really
>> hoping there’s going to be a demand for a CLI version of Reverator at some
>> point. I will then be back relying heavily on you.
>>
>> Reading through the list, CUDA is mentioned once or twice. Do some parts of
>> your lib use CUDA, if available?
>>
>> Thank you,
>>
>> Chris Spence
>> Reverator
>> 6815 Biscayne Blvd, Suite 103-191
>> Miami, FL 33138
>>
>> Tel: 305 757 1330
>>
>> i...@reverator.com <mailto:i...@reverator.com>
>> www.reverator.com <http://www.reverator.com/>
>>
>>
>>
>>
>>
>>> On Aug 18, 2021, at 2:09 AM, Larry Gritz <l...@larrygritz.com
>>> <mailto:l...@larrygritz.com>> wrote:
>>>
>>> At long last, I have branched for this year's big release, OpenImageIO 2.3.
>>> The new branch is "dev-2.3" (a change from the old convention of RB-x.y; I
>>> think it's clearer since many people didn't know what RB stood for), and
>>> the first beta is tagged "v2.3.7.0-beta". Why 2.3.7.0? Because we had 6
>>> "developer preview" snapshots along the way.
>>>
>>> I'm aiming for September 1, 2021 to tag a release. It might get delayed if
>>> serious problems are discovered. But considering that SPI and probably lots
>>> of other places use master branch or developer preview snapshots for real
>>> production, for anything other changes made in the last couple weeks, I'm
>>> pretty confident that everything is solid and has already been through the
>>> heat of battle in production. In general, the only difference between our
>>> release branches and master is that release branches make a strict promise
>>> about not breaking compatibility; there is little practical difference in
>>> stability or production worthiness.
>>>
>>> We will strive to make no breaking changes to the API or ABI between now
>>> and the release. After final release, when the beta designation disappears,
>>> we will be 100% strict about this promise.
>>>
>>> We will keep releasing 2.2.x patches as needed, but they will slow down and
>>> be restricted to only critical bug fixes, as we transition to 2.3 being the
>>> current supported release. Meanwhile, master -- which is now the staging
>>> area for what will become 2.4 next year -- is where big new, and possibly
>>> compatibility-breaking, changes will be made.
>>>
>>>
>>>
>>> Release 2.3 (1 Sept 2021?) -- compared to 2.2
>>> ----------------------------------------------
>>> New minimum dependencies and compatibility changes:
>>> * C++ standard: **C++14 is now the minimum (gcc 6.1 - 11.2, clang 3.4 - 12,
>>> MSVS 2017 - 2019, icc 17+).** The default C++ standard mode, if none is
>>> explicitly specified, is now C++14. #2918 (2.3.4) #2955 #2977 (2.3.5)
>>> * FFMmpeg (optional) dependency minimum is now 3.0 (raised from 2.6). #2994
>>> * OpenCV (optional) dependency minimum is now 3.0 (raised from 2.0). #3015
>>>
>>> New major features and public API changes:
>>> * Changes and clarifications to `geterror()` in all classes that have one:
>>> - `geterror()` now takes an optional `clear` parameter controls if the
>>> pending error is cleared as well as retrieved (default `true`).
>>> - All classes with `geterror()` are ensured to have `has_error()`.
>>> - `geterror()` appends to the pending error message, if one is already
>>> present but not retrieved. Appending errors will be automatically
>>> separated by newlines, also any newline at the end of a geterror
>>> call will be stripped. #2740 (2.3.0.1)
>>> * ImageInput error messages are now thread-specific. This prevents multiple
>>> threads simultaneously reading from the same ImageInput from getting the
>>> other thread's error messages. But it means you must always retrieve an
>>> error with `getmessage()` from the same thread that made the read call
>>> that generated the error. #2752 (2.3.0.1)
>>> * ImageInput and ImageOutput have removed several fields (like the m_mutex)
>>> and instead now use a PIMPL idiom that hides internals better from the
>>> ABI. If you had a custom ImageInput/Output class that directly accessed
>>> the m_mutex, replace it instead with calls to ImageInput::lock() and
>>> unlock() (and ImageOutput). #2752 (2.3.1.0)
>>> * Clarify that ImageBuf methods `subimage()`, `nsubimages()`, `miplevel()`,
>>> `nmipevels()`, and `file_format_name()` refer to the file that an ImageBuf
>>> was read from, and are thus only meaningful for ImageBuf's that directly
>>> read from files. "Computed" or copied ImageBuf's are solo images in memory
>>> that no longer correspond to a file even if the input to the computation
>>> was from a file. #2759 (2.3.0.1/2.2.9 <http://2.3.0.1/2.2.9>)
>>> * New `get_extension_map()` returns a map that list all image file formats
>>> and their presumed file extensions. #2904 (2.3.4)
>>> * Overhaul of how we handle "thumbnails" (small preview images embedded in
>>> the headers of some image file formats) #3021 (2.3.7):
>>> - Thumbnails no longer embedded in the ImageSpec as "thumbnail_image"
>>> metadata of a big character array blob.
>>> - ImageInput, ImageBuf, and ImageCache have varieties of
>>> `get_thumbnail()`
>>> method that returns the thumbnail as an ImageBuf. If this is not
>>> called, ideally the reader will not undergo the expense of reading and
>>> storing thumbnail data.
>>> - ImageOutput and ImageBuf have `set_thumbnail()` to communicate a
>>> thumbnail image as an ImageBuf.
>>> - The net effect is that reading files and retrieving ImageSpec's should
>>> be more efficient for apps that don't have a use for thumbnails.
>>> * Significant improvements to UDIM handling in ImageCache/TextureSystem:
>>> - New UDIM texture name patterns recognized: `%(UDIM)d` is the Houdini
>>> convention, and `_u##v##` is for Animal Logic's internal renderer.
>>> #3006 (2.2.16/2.3.6)
>>> - It is now permissible for `get_texture_info()/get_image_info()` to
>>> retrieve metadata for UDIM patterns -- previously it failed, but now
>>> it will succeed in retrieving any metadata as long as it is present
>>> and has the same value in all the matching "UDIM tile" panels. #3049
>>> (2.3.7)
>>> - TextureSystem now exposes methods `is_udim()`, `resolve_udim()`,
>>> `inventory_udim()` that should be helpful for apps dealing with UDIM
>>> textures. See the documentation for details. #3054 (2.3.7)
>>> - Performance improvements when using UDIM textures. #3049 (2.3.7)
>>> * ImageBuf, when "wrapping" an app-owned buffer, now allows explicit
>>> specification of stride lengths. This allows you to wrap a buffer that
>>> has internal padding or other non-contiguous spacing of pixels, scanlines,
>>> or image planes. #3022 (2.3.6)
>>> * oiiotool new commands and options:
>>> - `--pastemeta` takes two images as arguments, and appends all the
>>> metadata (only) from the first image onto the second image's pixels
>>> and metadata, producing a combined image. #2708 (2.3.0.0)
>>> - `--chappend` and `--siappend` both allow an optional modifier `:n=`
>>> to specify the number of images from the stack to be combined
>>> (default n=2). #2709 (2.3.0.0)
>>> - `--fit` now takes an additional optional modifier: `fillmode=` with
>>> choices of `letterbox` (default), `width`, and `height`. #2784
>>> (2.3.2.0)
>>> - `--autocc` now has an optional modifier `:unpremult=1` that causes
>>> any color transformations related to autocc to unpremultiply by alpha
>>> before the transformation and then re-premultiply afterwards, exactly
>>> the same control that exists for individual `--colorconvert` but never
>>> existed for autocc. #2890 (2.3.3)
>>> - `--list-formats` lists all the image file formats that OIIO knows
>>> about, and for each, the associated file extensions. #2904 (2.3.4)
>>> - `--skip-bad-frames` causes an error (such as an input file not being
>>> found) to simply skip to the next frame in the frame range loop, rather
>>> that immediately exiting. #2905 (2.3.4)
>>> - When doing expression substitution, `{getattribute(name)}` will be
>>> replaced by the value that `OIIO::getattribute(name, ...)` would
>>> retrieve. #2932 (2.3.4)
>>> - `--missingfile` (which takes a subsequent argument of `error`, `black`,
>>> or `checker`) determines the behavior when an input image file is
>>> missing (the file does not exist at all, does not include cases where
>>> the file exists but there are read errors). The default value of
>>> `error` matches the old behavior: report an error and terminate all
>>> command processing. Other choices of `black` or `checker` will continue
>>> processing but substitute either a black or checkerboard image for the
>>> missing file. #2949 (2.3.4)
>>> - `--printinfo` prints verbose metadata info about the current top
>>> image on the stack. #3056 (2.3.7)
>>> - `--printstats` prints statistics about the current top image on the
>>> stack, and optionally can limit the statistics to a rectangular
>>> subregion of the image. #3056 (2.3.7)
>>> - Expanded expression now support the following new metadata notations:
>>> `META`, `METABRIEF`, and `STATS`. #3025 (2.3.6)
>>> - `--mosaic` now takes optional `fit=WxH` modifier that lets you set the
>>> "cell" size, with all constituent images resized as needed (similarly
>>> to if you used `--fit` on each individually). This is helpful for
>>> creating contact sheets without having to resize separately or to know
>>> the resolution of the original images. #3026 (2.3.6)
>>> - REMOVED `--histogram` which had been deprecated and undocumented since
>>> before OIIO 2.0. #3029 (2.3.6)
>>> * Python bindings:
>>> - When transferring blocks of pixels (e.g., `ImageInput.read_image()`
>>> or `ImageOutput.write_scanline()`), "half" pixels ended up mangled
>>> into uint16, but now they use the correct `numpy.float16` type. #2694
>>> (2.3.0.0)
>>> - The value passed to `attribute(name, typedesc, value)` can now be a
>>> tuple, list, numpy array, or scalar value. #2695 (2.3.0.0)
>>> - Added Python bindings for the TextureSystem. #2842
>>> - Add the previously (inadvertently) omitted enum value for
>>> `ImageBufAlgo.MakeTxBumpWithSlopes`. #2951 (2.3.4)
>>> * Environment variables:
>>> - `CUE_THREADS` env variable, if set, is now honored to set the default
>>> size of the OIIO thread pool. This helps to make OIIO-based apps be
>>> good citizens when run as OpenCue jobs. #3038 (2.3.7)
>>> * Library organization:
>>> - All the utility classes are now in libOpenImageIO_Util *only* and
>>> libOpenImageIO depends on and links to libOpenImageIO_Util, rather
>>> than the utility classes being defined separately in both libraries.
>>> #2906 (2.3.4)
>>> - Include file change: `imagebuf.h` no longer includes `imagecache.h`.
>>> It should never have needed to, since it didn't need any of its
>>> declarations. Other code that should always have included both headers,
>>> but inadvertently only included `imagebuf.h`, may now need to add an
>>> explicit `#include <OpenImageIO/imagecache.h>`. #3036 (2.3.7)
>>> * Important change to `Makefile` wrapper: We have a 'Makefile' that just
>>> wraps
>>> cmake for ease of use. This has changed its practice of putting builds in
>>> `build/ARCH` to just `build` (and local installs from `dist/ARCH` to
>>> `dist`)
>>> to better match common cmake practice. So where your local builds end up
>>> may
>>> shift a bit. #3057 (2.3.7)
>>> * Deprecations: A number of long-deprecated functions and methods have been
>>> given deprecation attributes that will cause warnings if you use them. They
>>> will eventually be removed entirely at the next "breaking" release (3.0,
>>> whenever that is). #3032 (2.3.7)
>>>
>>> Performance improvements:
>>> * Speed up BMP reading by eliminating wasteful allocation and copying
>>> done on each scanline read. #2934 (2.3.4)
>>> * For `IBA::to_OpenCV()`, improve efficiency for certain image copies. #2944
>>> (2.3.4)
>>> * Fix runaway parsing time for pathological XMP metadata. #2968
>>> (2.3.5/2.2.15)
>>> * TextureSystem reduction in overhead when using UDIM textures. #3049
>>> (2.3.7)
>>>
>>> Fixes and feature enhancements:
>>> * Fix a situation where if an ImageBuf backed by an ImageCache reads an
>>> image, then the image changes on disk, then another ImageBuf or ImageCache
>>> tries to read it, it could end up with the old version. This involved some
>>> strategic cache invalidation when ImageBuf's write images to disk. #2696
>>> (2.3.0.0)
>>> * Improve parsing of XMP records in metadata: more correct handling of
>>> lists/sequences, better inference of types that look like int or float
>>> (rather than forcing unknown fields into strings), fixed bugs in parsing
>>> rational values. #2865 (2.2.12/2.3.3)
>>> * ImageBuf/ImageBufAlgo:
>>> - `IBA::contrast_remap()` fixes bug that could crash for very large
>>> images #2704 (2.3.0.0)
>>> - Fix stack overflow crash in IBA::colorconvert of unusually wide images.
>>> #2716 (2.3.0.1/2.2.8 <http://2.3.0.1/2.2.8>)
>>> - Fix `IBA::make_texture()` incorrectly setting tile sizes. #2737
>>> (2.3.0.1/2.2.8 <http://2.3.0.1/2.2.8>)
>>> - `IBA::make_texture()` now correctly propagates error messages, which
>>> can be retrieved via the global OIIO::geterror() call. #2747 (2.3.0.1)
>>> - `IBA::fit()` now takes a `fillmode` parameter that controls exactly
>>> how the resize will occur in cases where the aspect ratio of the new
>>> frame doesn't exactly match that of the source image. The old way (and
>>> the default value now) is "letterbox", but now also "width" and
>>> "height" modes are allowed. See `fit()` documentation for details.
>>> #2784 (2.3.2.0)
>>> - `IBA::fit()` fixes some slight ringing at image edges when using a
>>> combination of black wrap mode and a filter with negative lobes.
>>> #2787 (2.3.2.0)
>>> - Fix: `ociolook()` and `ociofiletransform()` internally reversed the
>>> order of their `inverse` and `unpremult` arguments, making it hard to
>>> select the inverse transformation. #2844 (2.3.3/2.2.11)
>>> - Fix crash for certain calls to `ImageBuf::set_write_format()` when
>>> writing files that support per-channel data types. #2885 (2.3.3)
>>> - Fix: `IBA::fillholes_pushpull` did not correctly understand which
>>> channel was alpha when generating subimages. #2939 (2.3.4)
>>> - Fix: `IBA::render_text` did not properly account for non-1 alpha of
>>> the text color. #2981 (2.3.5/2.2.15)
>>> - `IBA::colorconvert`, `colormatrixtransform`, `ociolook`, `ociodisplay`,
>>> and `ociofiletransform` have been fixed so that if input is more than
>>> 4 channels, the additional channels will be copied unchanged, rather
>>> than inadvertently set to 0. #2987 (2.3.5/2.2.16)
>>> - Thread safety has been improved for `ImageBuf::init_spec()` and
>>> `read()`
>>> (though no problem was ever reported in the wild). #3018 (2.3.6)
>>> - `render_text()` now accepts text strings with embedded linefeeds and
>>> will turn them into multiple lines of rendered text. #3024 (2.3.6)
>>> * ImageCache/TextureSystem/maketx:
>>> - Fix ImageCache bug: add_tile/get_tile not properly honoring when
>>> `chend < chbegin` it should get all channels. #2742 (2.3.0.1/2.2.8
>>> <http://2.3.0.1/2.2.8>)
>>> - `ImageBufAlgo::make_texture()` (as well as `maketx` and `oiiotool
>>> -otex`)
>>> clamp `half` values to their maximum finite range to prevent very large
>>> float inputs turning into `Inf` when saved as half values. #2891
>>> (2.3.3)
>>> - Fix crash when sampling non-zero-base channels. #2962 (2.3.5/2.2.15)
>>> - `IBA::make_texture()` rejects "deep" input images, since they cannot
>>> be made into textures. Doing this could previously crash. #2991
>>> (2.3.5/2.2.16)
>>> - maketx and `oiiotool -otex` have fixed double printing of error
>>> messages #2992 (2.3.5).
>>> - Making bumpslopes textures now allows scaled slopes UV normalization.
>>> This is exposed as new maketx argument `--uvsopes_scale`, or passing
>>> the attribute `uvslopes_scale` (int) to make_texture(). #3012 (2.3.6)
>>> - There is a new variety of ImageCache::invalidate() that takes an
>>> `ImageHandle*` argument instead of a filename. #3035 (2.3.7)
>>> * oiiotool:
>>> - `--resize` of images with multi-subimages could crash. #2711 (2.3.0.0)
>>> - Improve oiiotool's guessing about the desired output format based on
>>> inputs (in the absence of `-d` to specify the format). #2717
>>> (2.3.0.1/2.2.8 <http://2.3.0.1/2.2.8>)
>>> - `--text` now accepts text strings with embedded linefeeds and
>>> will turn them into multiple lines of rendered text. #3024 (2.3.6)
>>> * BMP
>>> - Fix reading BMP images with bottom-to-top row order. #2776
>>> (2.3.1.1/2.2.9 <http://2.3.1.1/2.2.9>)
>>> - Correctly read BMP images of the older V1 variety without crashing.
>>> #2899 (2.3.3/2.2.13)
>>> - Fix error in the rightmost pixel column when reading 4 bpp images with
>>> odd horizontal resolution. #2899 (2.3.3/2.2.13)
>>> - BMP reads now return metadata "bmp:bitsperpixel" (only when not 24
>>> or 32) to indicate non-whole-byte channels sizes in the file, and
>>> "bmp:version" to indicate the version of the BMP format. #2899
>>> (2.3.3/2.2.13)
>>> - Speed up BMP reading by eliminating wasteful allocation and copying
>>> done on each scanline read. #2934 (2.3.4)
>>> - For BMP files that are 8 bits per pixel and all palette entries have
>>> R == G == B values, read the file as an 8-bit grayscale image instead
>>> of needlessly promoting to a full RGB 3-channel image. #2943 (2.3.4)
>>> - Full support for reading RLE-compressed BMP images. #2976
>>> (2.3.5/2.2.15)
>>> - Write single channel BMP as 8 bit palette images. #2976 (2.3.5/2.2.15)
>>> * DPX
>>> - Output to DPX files now supports IOProxy. (Input already did.) #3013
>>> (2.2.17/2.3.6)
>>> * FFMpeg/movies:
>>> - Avoid potential crash when a frame can't be read. #2693 (2.3.0.0)
>>> - Several varieties of encoded videos with 12 bits per channel and
>>> having alpha were incorrectly reported as 8 bits and without alpha.
>>> #2989 (2.3.5/2.2.16)
>>> * GIF
>>> - Support UTF-8 filenames on Windows for GIF files. #2777 (2.3.2.0)
>>> - Fix error checking for non-existant GIF files. #2886 (2.3.3)
>>> * HEIC
>>> - Fix error decoding Apple HEIF files. #2794/#2809 (2.3.2.0)
>>> - Better valid_file() check for HEIF. #2810 (2.3.2.0)
>>> - Enabled AVIF decoding of heic files (requires libheif >= 1.7 and for
>>> it to have been built with an AV1 encoder/decoder). #2811 #2812 #2814
>>> #2818 (2.3.3.0)
>>> * IFF
>>> - Fix broken reads of 16 bit iff files. #2736 (2.3.0.1/2.2.8
>>> <http://2.3.0.1/2.2.8>)
>>> * JPEG
>>> - Allow reading of JPEG files with mildly corrupted headers. #2927
>>> (2.3.4)
>>> * OpenEXR:
>>> - Fix rare crash that was possible when multithreaded writing openexr
>>> files. #2781 (2.3.2.0)
>>> - Improved error reporting when errors are encountered writing OpenEXR
>>> files. #2783 (2.3.2.0)
>>> - Fix potential crash parsing OpenEXR header that contains Rational
>>> attributes with certain values. #2791 (2.2.10/2.3.2)
>>> - EXPERIMENTAL: When building against OpenEXR 3.1, the OIIO CMake option
>>> `-DOIIO_USE_EXR_C_API=ON` will use a new OpenEXR API that we think
>>> will allow higher performance texture reads in a multithreaded app.
>>> This has not yet been benchmarked or tested thoroughly. #3009 #3027
>>> (2.3.6)
>>> - The reader no longer renames file metadata "version" into the special
>>> "openexr:version" that would indicate the OpenEXR file format version
>>> of the file. That's never what it meant! It really was just arbitrary
>>> metadata. #3044 (2.3.7)
>>> * PNG
>>> - Read Exif data from PNG files. #2767 (2.3.1.1/2.2.9
>>> <http://2.3.1.1/2.2.9>)
>>> * PSD
>>> - Add support for reading ISD profiles for PSD input. #2788 (2.3.2.0)
>>> - Fix loading PSB files with cinf tags. #2877 (2.2.12/2.3.2)
>>> * RAW:
>>> - Additional input configuration hints to control options in the
>>> underlying LibRaw: `"raw:user_flip"` #2769 (2.3.1.0)
>>> `"raw:balance_clamped"`, `"raw:apply_scene_linear_scale"`,
>>> `"raw:camera_to_scene_linear_scale"` #3045 (2.3.7)
>>> - Correctly handle RAW files with Unicode filenames on Windows. #2888
>>> (2.3.3)
>>> - Fix garbled output when `raw:Demosaic` hint is `"none"`. #3045 (2.3.7)
>>> * Targa
>>> - Fix potential crash when reading files with no thumbnail. #2903
>>> (2.3.3/2.2.13)
>>> - Fix alpha handling for some files. #3019 (2.3.6)
>>> * TIFF:
>>> - Fix broken reads of multi-subimage non-spectral files (such as
>>> photometric YCbCr mode). #2692 (2.3.0.0)
>>> - Fix spec() and spec_dimensions() for MIPmapped TIFF files, they did
>>> not recognize being asked to return the specs for invalid subimage
>>> indices. #2723 (2.3.0.1/2.2.7 <http://2.3.0.1/2.2.7>)
>>> - Add ability to output 1bpp TIFF files. #2722 (2.3.0.1/2.2.7
>>> <http://2.3.0.1/2.2.7>)
>>> - Fix reading TIFF files with "separate" planarconfig and rowsperstrip
>>> more than 1. #2757 (2.3.0.1/2.2.9 <http://2.3.0.1/2.2.9>)
>>> - Fix incorrect reading of tiled TIFF files using certain rare TIFF
>>> features that also have a vertical resolution that is not a whole
>>> multiple of the tile size. #2895 (2.3.3/2.2.13)
>>> - Support IOProxy for reading TIFF files. #2921 (2.3.4)
>>> - TIFF plugin now properly honors caller request for single-threaded
>>> operation. #3016 (2.3.6)
>>> * WebP:
>>> - Add support for requesting compression "lossless". #2726
>>> (2.3.0.1/2.2.8 <http://2.3.0.1/2.2.8>)
>>> - Input improvements including: RGB images are kept as RGB instead of
>>> always adding alpha; more efficient by skipping alpha premultiplication
>>> when it's unnecessary; now can read animated WebP images as
>>> multi-subimage files. #2730 (2.3.0.1/2.2.8 <http://2.3.0.1/2.2.8>)
>>> * Fix memory leak during decoding of some invalid Exif blocks. #2824
>>> * Fix possible divide-by-zero error in read_image/read_scanlines for invalid
>>> image sizes (usually from corrupt files). #2983 (2.3.5/2.2.16)
>>>
>>> Developer goodies / internals:
>>> * Internals now use C++11 `final` keywords wherever applicable. #2734
>>> (2.3.0.1)
>>> * More internals conversion of old Strutil::sprintf to Strutil::fmt::format
>>> and related changes. #2889 (2.3.3)
>>> * Redundant format conversion code removed from imageio.cpp #2907 (2.3.4)
>>> * Eliminate direct output to std::cerr and std::cout by library calls.
>>> #2923 (2.3.4)
>>> * argparse.h:
>>> - ArgParse::abort() lets the response to a command line argument signal
>>> that no further arguments should be parsed. #2820 (2.3.3/2.2.11)
>>> * color.h:
>>> - New `ColorConfig::OpenColorIO_version_hex()` returns the hex code for
>>> the version of OCIO we are using (0 for no OCIO support). #2849 (2.3.3)
>>> * farmhash.h:
>>> - Clean up all non-namespaced preprocessor symbols that are set
>>> by this header and may pollute the caller's symbols. #3002
>>> (2.2.16/2.3.6)
>>> * filesystem.h:
>>> - New Filesystem::generic_filepath() returnss a filepath in generic
>>> format (not OS specific). #2819 (2.3.3/2.2.11)
>>> - Improve exception safety in Filesystem directory iteration. #2998
>>> (2.2.16/2.3.6)
>>> - New `filename_to_regex()` makes a filename "safe" to use as a
>>> regex pattern (for example, properly backslashing any `.` characters).
>>> #3046 (2.3.7)
>>> - Some methods that used to take a `const std::string&` now take a
>>> `string_view`. #3047 (2.3.7)
>>> * fmath.h:
>>> - Use CPU intrinsics to speed up swap_ending (by 8-15x when swapping
>>> bytes of large arrays). #2763 (2.3.1.0)
>>> * hash.h:
>>> - `farmhash::inlined::Hash` now is constexpr and works for Cuda.
>>> #2843 (2.3.3) #2914 #2930 (2.3.4)
>>> * oiioversion.h:
>>> - New macros `OIIO_VERSION_GREATER_EQUAL` and `OIIO_VERSION_LESS`.
>>> #2831 (2.3.3/2.2.11)
>>> * platform.h:
>>> - New macro OIIO_INLINE_CONSTEXPR, equivalent to `inline constexpr` for
>>> C++17, but just constexpr for C++ <= 14. #2832 (2.3.3/2.2.11)
>>> * simd.h:
>>> - Fix incorrect ARM NEON code in simd.h. #2739 (2.3.0.1/2.2.8
>>> <http://2.3.0.1/2.2.8>)
>>> * span.h:
>>> - `std::size()` and `std::ssize()` should work with OIIO::span now.
>>> #2827 (2.3.3/2.2.11)
>>> * string_view.h:
>>> - `std::size()` and `std::ssize()` should work with OIIO::string_view
>>> now. #2827 (2.3.3/2.2.11)
>>> - More thorough constexr of string_view methods. #2841 (2.3.3)
>>> * strongparam.h:
>>> - New StrongParam helper for disambiguating parameters. #2735 (2.3.2)
>>> * strutil.h:
>>> - Strutil `splits()` and `splitsv()` should return no pieces when passed
>>> an empty string. (It previously erroneously returned one piece
>>> consisting of an empty string.) #2712 (2.3.0.0)
>>> - Fix build break when strutil.h was included in Cuda 10.1 code. #2743
>>> (2.3.0.1/2.2.8 <http://2.3.0.1/2.2.8>)
>>> - `strhash()` is now constexpr for C++14 and higher. #2843 (2.3.3)
>>> - New Strutil functions: find, rfind, ifind, irfind #2960 (2.3.4/2.2.14)
>>> contains_any_char #3034 (2.3.7) rcontains, ircontains #3053 (2.3.7)
>>> * sysutil.h:
>>> - Extend `getenv()` to take a default if the environment variable is not
>>> found. #3037 #3040 (2.3.7)
>>> * typedesc.h:
>>> - `TypeDesc::basetype_merge(a,b)` returns a BASETYPE having the
>>> precision and range to hold the basetypes of either `a` or `b`.
>>> #2715 (2.3.0.0)
>>> - TypeDesc can now describe 2D and 3D bounding boxes, as arrays of 2
>>> VEC2 aggregates (for 2D) or VEC3 aggregates (for 3D) with "BOX"
>>> semantic. The shorthand for these are `TypeBox2`, `TypeBox3` (for
>>> float), and `TypeBox2i` and `TypeBox3i` for integer or pixel coordinte
>>> boxes. #3008 (2.2.17/2.3.6)
>>> * unordered_map_concurrent.h:
>>> - New methods find_or_insert, nobin_mask(). #2867 (2.2.12/2.3.3)
>>> * ustring.h:
>>> - ustring internals now have a way to ask for the list of ustrings whose
>>> hashses collided. #2786 (2.2.11/2.3.2.0 <http://2.3.2.0/>)
>>> - ustring now guarantees that no two ustrings will return the exact same
>>> value for `hash()`. #2870 (2.3.3)
>>>
>>> Build/test system improvements and platform ports:
>>> * CMake build system and scripts:
>>> - Instead of defaulting to looking for Python 2.7, the OIIO build now
>>> defaults to whatever Python is found (though a specific one can still
>>> be requested via the PYTHON_VERSION variable). #2705 (2.3.0.0/2.2.8
>>> <http://2.3.0.0/2.2.8>)
>>> #2764 (2.3.0.1/2.2.8 <http://2.3.0.1/2.2.8>)
>>> - Make the OIIO CMake files work properly if OIIO is a subproject. Also
>>> various other CMake script refactoring. #2770 (2.3.1.1/2.2.9
>>> <http://2.3.1.1/2.2.9>)
>>> - Extend checked_find_package with VERSION_MIN and VERSION_MAX #2773
>>> (2.3.1.1/2.2.9 <http://2.3.1.1/2.2.9>), DEFINITIONS and SETVARIABLES
>>> #3061 (2.3.7)
>>> - No longer directly link against python libraries when unnecessary.
>>> #2807 (2.2.11/2.3.3)
>>> - On Windows, fix some linkage problems by changing the pybind11
>>> bindings to make a CMake "shared" library rather than "module". Sounds
>>> wrong, but seems to work. We will reverse if this causes problems.
>>> #2830 (2.3.3/2.2.11)
>>> - Improvements to building or linking static libraries. #2854
>>> (2.2.12/2.3.3)
>>> - Change default STOP_ON_WARNING to OFF for release branches (including
>>> this one) so that small change in compiler warnings after our release
>>> don't break anybody's builds. (Though we still stop on warnings for CI
>>> builds). #2861 (2.2.12/2.3.3)
>>> - The pkgconfig OpenImageIO.pc was specifying the include path
>>> incorrectly. #2869 (2.2.12/2.3.3)
>>> - Support for CMake 3.20. #2913 #2931 (2.3.4)
>>> - Be sure to have the namespace include the patch number for pre-release
>>> builds from the master branch. #2948 (2.3.4)
>>> - Use modern style cmake targets for PNG and ZLIB dependencies. #2957
>>> (2.3.4)
>>> - Propagate C++14 minimum requirement to downstream projects via our
>>> cmake config exports. #2965 (2.3.5)
>>> - Fix exported cmake config files, which could fail if Imath and OpenEXR
>>> weren't the at the same version number. #2975 (2.3.5/2.2.15)
>>> - Change default postfix for debug libraries to `_d`. (2.3.5)
>>> - Our CMake `checked_find_package` is now able to be requested to favor
>>> an exported config file, if present, on a package-by-package basis.
>>> #2984 (2.3.5/2.2.15)
>>> - If a package is requested to be disabled, skip its related tests rather
>>> than reporting them as broken. #2988 (2.3.5/2.2.16)
>>> - Finding boost is more flexible when desiring static libraries. #3031
>>> (2.3.7/2.2.17)
>>> - FindTBB.cmake module updated to create proper targets. #3060 (2.3.7)
>>> * Dependency version support:
>>> - C++20 is now supported. #2891 (2.3.3)
>>> - Fix deprecation warnings when building with very new PugiXML versions.
>>> #2733 (2.3.0.1/2.2.8 <http://2.3.0.1/2.2.8>)
>>> - Fixes to build against OpenColorIO 2.0. #2765 (2.3.0.1/2.2.8
>>> <http://2.3.0.1/2.2.8>) #2817
>>> #2849 (2.3.3/2.2.11) #2911 (2.3.4)
>>> - Fix to accommodate upcoming OpenColorIO 2.1 deprecation of
>>> parseColorSpaceFromString. #2961 (2.3.5/2.2.15)
>>> - Work to ensure that OIIO will build correctly against Imath 3.0 and
>>> OpenEXR 3.0, as well as Imath 3.1 / OpenEXR 3.1. #2771 (2.3.1.1/2.2.9
>>> <http://2.3.1.1/2.2.9>)
>>> #2876 #2678 #2883 #2894 (2.3.3/2.2.12) #2935 #2941 #2942 #2947 (2.3.4)
>>> - Better finding of OpenJpeg 2.4. #2829 (2.3.3/2.2.11)
>>> - On Mac, libheif 1.10 is very broken. Don't use that version. #2847
>>> (2.3.3/2.2.11)
>>> - Fix build break against changes coming in future libtiff, where it
>>> is changing from some libtiff-defined integer types to the equivalent
>>> stdint.h types. #2848 (2.3.3/2.2.11)
>>> - Fixes to support the libraw 202101 snapshot (their in-progress 0.21.0).
>>> #2850 (2.3.3/2.2.11)
>>> - More clear warnings about using OpenVDB 8+ when building for C++11,
>>> because OpenVDB 8 requires C++14 or higher. #2860 (2.2.12/2.3.3)
>>> - More gracefully handle building against a custom Imath/OpenEXR even
>>> when another exists in the system area. #2876 (2.2.12/2.3.3)
>>> - Minor fixes to build cleanly against the upcoming Imath 3.0. #2878
>>> (2.2.12/2.3.3)
>>> - Remove obsolete dependency on Boost random (now use std::random).
>>> #2896 (2.3.3)
>>> - libtiff 4.3 is supported. #2953 (2.3.4)
>>> - We now include a `build_OpenJPEG.bash` script that can conveniently
>>> build a missing OpenJPEG dependency. (2.3.5/2.2.16)
>>> - Changes to make it build against TBB 2021. #2985 (2.3.5/2.2.15)
>>> - Support for building OIIO with gcc 11. #2995 (2.2.16/2.3.6)
>>> - Fixes to accommodate Imath 3.1 upcoming changes. #2996 (2.2.16/2.3.6)
>>> - Finding FFMpeg now correctly detects the version. #2994 (2.2.16/2.3.6)
>>> - FFMpeg minimum version is now >= 3.0. #2999 (2.3.6)
>>> - Fixes for detecting and using Ptex, among other things got the version
>>> wrong. #3001 (2.2.16/2.3.6)
>>> - Fixes for building against fmt 8.0. #3007 (2.3.6)
>>> - The OpenCV minimum version is now >= 3.0. #3015 (2.3.6)
>>> - Fixes to build properly against the upcoming OpenColorIO 2.1. #3050
>>> (2.3.7)
>>> - All the `src/build_scripts/build_*.bash` scripts now honor an env
>>> variable called `DOWNLOAD_ONLY`, which if set will only do the
>>> downloads
>>> but not the builds. #3058 (2.3.7)
>>> * Testing and Continuous integration (CI) systems:
>>> - Completely get rid of the old appveyor CI. #2782 (2.3.2.0)
>>> - Test against libtiff 4.2 in the "latest releases" test. #2792 (2.3.2.0)
>>> - Got Windows CI fully working, bit by bit. #2796 #2798 #2805 #2821 #2826
>>> #2834 #2835 #2836 #2838 #2839 #2840 (2.3.3)
>>> - Reduce redundant verbosty in CI output logs during dependency building.
>>> - Modify hash_test to verify correctness and stability of the hashes.
>>> #2853 (2.3.3)
>>> - When building custom OpenEXR with build_openexr.bash, don't have it
>>> build the examples. #2857 (2.2.12/2.3.3)
>>> - Speed up CI by using GitHub 'cache' actions + ccache. #2859
>>> (2.2.12/2.3.3)
>>> - Separate stages (setup, deps, build, test) into separate GHA "steps"
>>> for better logging and understanding of the timing and performance.
>>> #2862 (2.2.12/2.3.3)
>>> - Now actively testing libheif in Linux CI. #2866 (2.2.12/2.3.3)
>>> - Remove the last vestiges of Travis-CI, which we no longer use. #2871
>>> (2.2.12/2.3.3)
>>> - For failed tests, add CMake cache and log part of the saved artifacts.
>>> (2.2.12/2.3.3)
>>> - CI now tests build in C++20 mode. #2891 (2.3.3)
>>> - Our CI clang-format test now uses LLVM/clang-format 11. #2966
>>> - Test the clang11 + C++17 combo. #3004 (2.3.6)
>>> * Platform support:
>>> - Fixes for mingw. #2698 (2.3.0.0)
>>> - Windows fix: correct OIIO_API declaration on aligned_malloc,
>>> aligned_free of platform.h. #2701 (2.3.0.0)
>>> - Fix boost linkage problem on Windows. #2727 (2.3.0.1/2.2.8
>>> <http://2.3.0.1/2.2.8>)
>>> - Fix warnings when compiling webpinput.cpp on 32 bit systems. #2783
>>> (2.3.2.0)
>>> - Fix problems with `copysign` sometimes defined as a preprocessor symbol
>>> on Windows. #2800 (2.3.2)
>>> - Fixes related to Mac M1-based systems: Fix crash in ustring internals
>>> #2990 (2.3.5/2.2.15.1 <http://2.2.15.1/>)
>>>
>>> Notable documentation changes:
>>> * Make Readthedocs generate downloadable HTML as well as PDF. #2746
>>> * Explain how to read image data into separate per-channel buffers. #2756
>>> (2.3.0.1/2.2.8 <http://2.3.0.1/2.2.8>)
>>> * Improve use of breathe and formatting. #2762 (2.3.1.0)
>>> * Remove documentation of deprecated ImageBufAlgo functions. #2762 (2.3.1.0)
>>> * Document missing texture option fields. #2762 (2.3.1.0)
>>> * Starting to use "sphinx_tabs" as a clear way to present how things should
>>> be done for different language bindings. #2768 (2.3.1.0)
>>>
>>> --
>>> Larry Gritz
>>> l...@larrygritz.com <mailto:l...@larrygritz.com>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-dev@lists.openimageio.org <mailto:Oiio-dev@lists.openimageio.org>
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-dev@lists.openimageio.org <mailto:Oiio-dev@lists.openimageio.org>
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>
> --
> Larry Gritz
> l...@larrygritz.com <mailto:l...@larrygritz.com>
>
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-dev@lists.openimageio.org <mailto:Oiio-dev@lists.openimageio.org>
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-dev@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
l...@larrygritz.com
_______________________________________________
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
