/oiio

OpenImageIO
  1. C++ 81.4%
  2. TeX 12.5%
  3. Python 2.8%
  4. CMake 2.1%
  5. C 0.8%
  6. Makefile 0.3%
  7. Shell 0.1%
C++ TeX Python CMake C Makefile Shell
Find file
Latest commit 0b76e3b Dec 22, 2016 @lgritz lgritz committed on GitHub Improvements to thread_pool and 2D parallelism (#1581) 
* Improvements to thread_pool and 2D parallelism

2D parallelism loops:

* Add parallel_for_2D varieties for easy thread_pool parallelization over
  2D domains.
* Refactor ImageBufAlgo::parallel_image:
  - Use thread pool rather than spawning new threads.
  - Options struct includes max number of threads to use, domain
    subdivision hints, minimum number of pixels per thread task, and
    custom pool. Users should almost never need to adjust any of these.
* Refactor all the places using parallel_image to use the new style,
  and to use lambdas in a pleasing way rather than the prior idiom of
  recursing and handling the 1-thread and many-thread cases separately.
* More miscellaneous refactor of places where we used thread_group launch
  into use of parallel_for with pool.
* The resulting refactor of the IBA functions is pleasing to me, and the
  whole thing is much more idiomatic C++11.

thread pool improvements:

* New thread_pool method, this_thread_is_in_pool(), lets a caller find
  out if it (the calling thread) is a pool thread, so it may avoid
  submitting more jobs to the pool and clogging it up. A pool thread
  (which presumably is a task in a larger parallel work group) is
  probably better off doing any further subtasks itself rather than
  enqueuing them.  That also helps naive users from writing tasks that
  accidentally deadlock. This is implemented with a thread-specific
  pointer that lets the pool keep track of which threads participate.
* The various parallel_for functions employ this to avoid recursively
  splitting parallel tasks into more enqueued parallel tasks.
* Change the thread_pool to be able to switch (via #if) between a
  traditional mutexed queue and the boost::lockfree::queue.
  Interestingly, in my benchmarks on both OSX and Linux, the
  mutexted queue is slightly faster! So it remains the default for
  now.
* Allow environment variable OPENIMAGEIO_THREADS, if set, to override
  the hardware_concurrency (number of cores) as the default pool size
  and default OIIO threading count. This is primarily for debugging,
  so it's easy to force an artificially high or low thread count.
* Improved logic for wanting no extra worker threads: Allow you to set
  pool size to 0, meaning no extra worker threads, all work will be done by
  the calling thread. Setting the pool size to -1 means to figure out the
  number of hardware cores, and set pool size to one less than that (again,
  still considering that the calling thread will help run the tasks).
Permalink
Failed to load latest commit information.
.github Docs updates Mar 17, 2016
site/spi SPI: fix typo from last commit Dec 8, 2016
src Improvements to thread_pool and 2D parallelism (#1581) Dec 22, 2016
testsuite Debugging and testsuite improvements: (1580) Dec 10, 2016
.gitignore Adjust .gitignore Feb 16, 2016
.travis.yml DICOM reader. DICOM is the main format used for medical imaging. (1534) Dec 10, 2016
CHANGES.md DICOM reader. DICOM is the main format used for medical imaging. (1534) Dec 10, 2016
CMakeLists.txt DICOM reader. DICOM is the main format used for medical imaging. (1534) Dec 10, 2016
CONTRIBUTING.md Docs updates Mar 17, 2016
CREDITS.md Nuke txWriter: Exposed texture mode parameter Sep 14, 2016
INSTALL.md Update install notes about minimum boost version Nov 16, 2016
LICENSE Revert LICENSE.md back to LICENSE. Jul 7, 2016
Makefile More boost -> std C++11 conversion (#1586) Dec 15, 2016
README.md DICOM reader. DICOM is the main format used for medical imaging. (1534) Dec 10, 2016
appveyor.yml Prep for C++11 as new minimum language standard. No turning back. (1513) Oct 10, 2016

README.md

README for OpenImageIO

License Build Status Windows Build Status

Introduction

The primary target audience for OIIO is VFX studios and developers of tools such as renderers, compositors, viewers, and other image-related software you'd find in a production pipeline.

OpenImageIO consists of:

  • Simple but powerful ImageInput and ImageOutput APIs that provide an abstraction for reading and writing image files of nearly any format, without the calling application needing to know any of the details of these file formats, and indeed without the calling application needing to be aware of which formats are available.

  • A library that manages subclasses of ImageInput and ImageOutput that implement I/O from specific file formats, with each file format's implementation stored as a plug-in. Therefore, an application using OpenImageIO's APIs can read and write any image file for which a plugin can be found at runtime.

  • Plugins implementing I/O for several popular image file formats, including TIFF, JPEG/JFIF, OpenEXR, PNG, HDR/RGBE, ICO, BMP, Targa, JPEG-2000, RMan Zfile, FITS, DDS, Softimage PIC, PNM, DPX, Cineon, IFF, Field3D, Ptex, Photoshop PSD, Wavefront RLA, SGI, WebP, GIF, DICOM, many "RAW" digital camera formats, and a variety of movie formats (readable as individual frames). More are being developed all the time.

  • Several command line image tools based on these classes, including oiiotool (command-line format conversion and image processing), iinfo (print detailed info about images), iconvert (convert among formats, data types, or modify metadata), idiff (compare images), igrep (search images for matching metadata), and iv (an image viewer). Because these tools are based on ImageInput/ImageOutput, they work with any image formats for which ImageIO plugins are available.

  • An ImageCache class that transparently manages a cache so that it can access truly vast amounts of image data (tens of thousands of image files totaling multiple TB) very efficiently using only a tiny amount (tens of megabytes at most) of runtime memory.

  • A TextureSystem class that provides filtered MIP-map texture lookups, atop the nice caching behavior of ImageCache. This is used in commercial renderers and has been used on many large VFX and animated films.

  • ImageBuf and ImageBufAlgo functions -- a simple class for storing and manipulating whole images in memory, and a collection of the most useful computations you might want to do involving those images, including many image processing operations.

  • Python bindings for all of the major APIs.

Licensing

OpenImageIO is (c) Copyright 2008-2016 by Larry Gritz et al. All Rights Reserved.

OpenImageIO is distributed using the modified BSD license (also known as the "new BSD" or "3-clause BSD" license). Please read the "LICENSE" file for the legal wording. The documentation is licensed under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/).

The plain English bottom line is that OpenImageIO is free, as well as freely modifiable and redistributable (in both source and binary form). You may use part or all of it in your own applications, whether proprietary or open, free or commercial. Using it in a commercial or proprietary application DOES NOT obligate you to pay us, or to use any particular licensing terms in your own application.

Some code and resources are distributed along with OIIO that have highly compatible, though slightly different, licenses (generally MIT or Apache). See the PDF documentation Acknowledgements section for details.

Web Resources

Main web page: http://www.openimageio.org

GitHub page: http://github.com/OpenImageIO/oiio

Mail list subscriptions and archives:

Contact

[email protected]

Building and Installation

Please read the "INSTALL" file for detailed instructions on how to build and install OpenImageIO.

If you build with EMBEDPLUGINS=0, remember that you need to set the environment variable OIIO_LIBRARY_PATH to point to the 'lib' directory where OpenImageIO is installed, or else it will not be able to find the plugins.

Documentation

The primary user and programmer documentation can be found in src/doc/openimageio.pdf (in a source distribution) or in the doc/openimageio.pdf file of an installed binary distribution.