Hi Larry, What you say & surmise I agree with entirely, especially considering you’re already harnessing CPU threads for the image processing.
I was just wondering if there was something in there I may have missed, CUDA wise. Chris Spence Digital Devoid, Inc. 7300 Biscayne Blvd, Suite 405 Miami, FL 33138 Tel: 305 757 1330 ch...@digitaldevoid.com www.digitaldevoid.com > On Aug 18, 2021, at 1:16 PM, 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
_______________________________________________ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
