Jump to content
Hash, Inc. Forums
Sign in to follow this  
Rodney

Open EXR 2.0

Recommended Posts

Larry Gritz posted this message today indicating that Open Image IO (OIIO) is pressing forward in their support for Open EXR 2.0:

 

I tagged the master branch immediately before the merge as: Release-1.1.0-beta2

 

I then merged the OpenEXR 2.0 (and deep data) extensions into the master branch and tagged as: Release-1.1.0-beta3

 

I would prefer that people use the new code, but if you have trouble, there is a specific tag you can revert to that has all the other goodness of the master, except for OpenEXR 2.x.

 

Note that although you get the new OIIO APIs, you won't actually be able to read OpenEXR 2.0 images unless you are *ALSO* compiling/linking against the OpenEXR 2.0 library. OIIO will successfully build against both OpenEXR 2.x and 1.x.

 

Presumably, any problem with the OpenEXR 2.0 support or deep data APIs will be identified quickly. Those of you who anticipate using deep data or multi-part EXR files, I encourage you to test this patch sooner rather than later. This one is a "beta", which means that the APIs are still subject to change if necessary, but very soon I'd like to lock down a stable OIIO 1.1 branch, and we will strive very hard to not break API or link compatibility once we've branched.

 

-- lg

Emphasis added.

 

I'd pay money to be able to program like these guys do that are developing Open EXR 2.0 support.

Heck, I'd pay money just to understand it a little more...

Share this post


Link to post
Share on other sites

It might as well be E I E I O

 

I have no idea what that is about.

Share this post


Link to post
Share on other sites

Open Image IO (OIIO) is a libary for use with image programming. The one I believe is used for importing and exporting images with A:M.

As the Open Image folks are updating their library to include the recently released Open EXR 2.0 spec that gives us an in to using it with A:M.

 

I'm not suggesting this is trivial implementation... I'm currenty trying to understand how we can use and exploit the new Depth and Multiple Image capabilities of EXR 2.0 in A:M.

 

There are two primary aspects of this:

 

1. A:M's ability to create the new data

 

2. A:M's ability to read and manipulate the new data

 

As I said, this is not a trivial consideration and I'm mostly just getting it on the map for a future release of A:M.

If a miracle were to happen and I learned how to program this would be fairly high on my agenda.

(That and further refining A:M Composite)

 

The Open Image IO Library is just the means to facilitate the use of EXR 2.0 (and other image formats). It doesn't do the hard work of actually creating the data nor does it provide an intuitive user interface for working with that data.

 

I've been following the EXR list since EXR 2.0 went into Beta and that's why Larry's note makes (a little) sense to me.

 

Added: It is my understanding that if the TIFF format were to be added to A:M it would do so through OIIO. I know that is a request that recently made its way into A:M Reports.

Share this post


Link to post
Share on other sites

Apologies for the length of this quote but there is good stuff here in this release.

There are some fixes that are noteworthy also.

 

From Larry Gritz:

I have tagged Release-1.1.0. Unless something is extremely, horribly broken, we will strive to not alter the public APIs (other than adding things, and then only if it doesn't break link compatibility). Mostly we'll only fix bugs, but new features or performance improvements could be added but only if they are extremely unlikely to break existing code.

 

New features or risky code will go in the master branch (which is the staging area for an eventual 1.2 release).

 

We'll continue to add critical bug fixes to 1.0 as long as people are depending on it, but from this point on, 1.1 is what we are recommending as the stable, production-ready release.

 

Enjoy.

 

----

 

Here are the release notes, comparing to 1.0:

 

Major new features and improvements:

* Support for reading and writing "deep" images (including OpenEXR 2.0).

* Big ImageCache/TextureSystem improvements:

- Improved accuracy of anisotropic texture filtering, especially when

combined with "blur."

- Improve performance in cases with high numbers of threads using the

TS simultaneously (mostly due to use of reader-writer locks on the

tile cache rather than unique locks).

* New ImageBufAlgo functions:

fromIplImage() : converts/copies an OpenCV image to an ImageBuf.

capture_image() : captures from a camera device (only if OpenCV is found)

over() : Porter/Duff "over" compositing operation

render_text() : render text into an image

histogram() : compute value histogram information for an image

histogram_draw() : compute an image containing a graph of the histogram

of another image

channels() : select, shuffle, truncate, or extend channels of an image.

* New oiiotool commands:

--capture : captures from a camera device (only if OpenCV is found)

--pattern constant : creates a constant-color image

--over : Porter/Duff "over" compositing operation

--text : render text into an image.

--histogram : computes an image containing a graph of the histogram of

the input image.

--fill : fills a region with a solid color

--ch : select, shuffle, truncate, or extend channels

 

API changes:

* A new static ImageInput::open(filename [,config]) combines the old

create-and-open idiom into a single call, which is also much more

efficient because it won't needlessly open and close the file multiple

times. This is now the preferred method for reading a file, though

the old-style create() and open() still work as always.

* Deep image support: ImageInput adds read_native_deep_scanlines,

read_native_deep_tiles, read_native_deep_image, and ImageOutput adds

write_deep_scanlines, write_deep_tiles, write_deep_image, as well as a

supports("deepdata") query. Also, a 'deep' field has been added to

ImageSpec, and some deep data access functions have been added to

ImageBuf.

* ImageInput plugins now may supply a valid_file(filename) method which

detects whether a given file is in the right format, less expensively

than doing a full open() and checking for errors. (It's probably the same

cost as before when the file is not the right time, but when it is, it's

less expensive because it can stop as soon as it knows it's the right

type, without needing to do a full header read and ImageSpec setup.)

* Removed various error_message() functions that had been deprecated for

a long time (in favor of newer getmessage() functions).

* Define a namespace alias 'OIIO' that gets you past all the custom

namespacesin a convenient way.

* TextureOpt now contains a 'subimagename' field that allows subimages

to be addressed by name as well as by index (only for multi-image textures,

of course).

* ImageBuf improvements:

- A new constructor allows an ImageBuf to "wrap" an existing buffer

memory owned by the calling application without allocating/copying.

- Renamed the old ImageBuf::copy_pixels -> get_pixels, and it now

works for 3D (volumetric) buffers.

- New ImageBuf::copy(), and eliminated operator= which was confusing.

- New ImageBuf methods: reres(), copy_metadata(), copy_pixels(),

get_pixel_channels().

- ImageBuf::specmod() allows writable access to the ImageSpec (caution!).

- Better error reporting mechanism.

- get_pixels and get_pixel_channels take optional strides.

* ImageBufAlgo changes:

- Many ImageBufAlgo functions now take a 'ROI' that restricts the

operation to a particular range of pixels within the image (usually

defaulting to the whole image), and for some operations a range of

channels.

- zero() and fill() take ROI arguments.

- ImageBufAlgo::CompareResults struct changed the failure and warning

counts to imagesize_t so they can't overflow int for large images.

* OIIO::getattribute("format_list") now can retrieve the comma-separated

list of all known image file formats.

 

Fixes, minor enhancements, and performance improvements:

* ImageCache/TextureSystem:

- Anisotropic texture lookups are more robust when the derivatives are tiny.

- Attribute "deduplicate" controls whether the identical-image

deduplication is enabled (on by default).

- Attribute "substitute_image" lets you force all texture references to a

single image (helpful for debugging).

- Texture files are no longer limited to having tile sizes that are

powers of 2.

- Much faster TIFF texture access (by speeding up switching of MIPmap levels).

- More graceful handling of the inability to free handles or tiles

under extreme conditions. Rather than assert when we can't free

enough to stay within limits, just issue an error and allow the

limits to be exceeded (hopefully only by a little, and temporarily).

- Detailed per-file stats now track the number of tile reads per

MIPmap level.

- Attribute "unassociatedalpha" (when nonzero) requests that

IC images not convert unassociated alpha image to associated alpha.

* iconvert handles the int32 and uint32 cases.

* Bug fix in to_native_rectangle, which could lead to errors in certain

data format conversions.

* iv improvements:

- better behavior after closing the last image of the sequence.

- file load/save dialogs can filter to show just certain image file types.

- remember last open dialog directory

- "About" dialog has a link to the OIIO home page

* Improve ::create to more robustly handle files whose extensions don't

match their actual formats.

* OpenImageIO::geterror() is now thread-specific, so separate threads will

no longer clobber each others' error messages.

* OpenEXR: support for building with OpenEXR 2.x, including use of

multi-part EXR and "deep" data.

* Fix reading bugs in DPX and Cineon.

* DPX: fix endianness problem for 15 bit DPX output.

* PNG: fix handling of gamma for sRGB images.

* oiiotool fixes: print MIP messages correctly (it was only printing for

the first MIP level); make sure stray "oiio:BitsPerSample" in an input

file doesn't mess up the -d flags.

* Field3D fixes: properly catch exceptions thrown by the Field3D open();

conform metadata to Field3D conventions; multi-layer f3d files will

present as a multi-image file with the "oiio:subimagename" giving a

unique name for each layer subimage;

* OpenEXR: suppress format-specific metadata from other formats.

* Targa: fix several bugs that were preventing certain metadata from being

written properly.

* TIFF: recognize the SAMPLEFORMAT_IEEEFP/bitspersample=16 as an image

composed of "half" pixels; enable PREDICTOR_FLOATINGPOINT to give slightly

better compression of float images.

* Handle UTF-8 paths properly on Windows.

* Removed the obsolete "iprocess" utility.

* Fix allocation and stride bugs when dealing with images having different data

formats per channel, and tiled images with partially filled border tiles.

* Field3D: Bug fix when reading vector f3d files.

* Significant performance improvements of our atomics and spin locks when

compiling with USE_TBB=0.

* Fix quantize() to properly round rather than truncate.

* ImageBufAlgo functions now by convention will save error messages into

the error state of their output ImageBuf parameter.

* Improve I/O error checking -- many file reads/writes did not previously

have their result status checked.

* Fixed missing OpenEXR open() error message.

* Clean up error reporting in iconvert.

* Fixes to handle Windows utf8 filenames properly.

* ImageBufAlgo::compare() gives a sensible error (rather than an assertion)

if the images being compared are not float.

* maketx:

- Better error messages for a variety of things that could go wrong when

reading or writing image files.

- Fixes for bug preventing certain ImageCache efficiencies.

- new option --ignore-unassoc leaves unassociated alpha data as it is

(no auto-conversion to associated alpha) and/or ignores the tags for

an input file that is associated but incorrectly tagged as

unassociated alpha.

- Option --monochrome-detect was buggy for images with alpha.

- Option --constant-color-detect didn't do anything; now it works.

- New option: --compression allows you to override the default compresion.

* oiiotool & info: the --hash command had a bug wherein when applied to

images there were MIP-mapped, would hash the lowest-res MIP level rather

than the highest-res. This could result in two different images, if

they happened to have the same average color, to incorrectly report

the same SHA-1 hash. Note that this did NOT affect non-MIPmapped images,

nor did it affect the SHA-1 hashing that occurred in maketx to allow

the TextureSystem to detect duplicate textures.

 

Build/test system improvements:

* Various Windows build fixes, including fixes for Windows 7, and

improvements to running the testsuite on Windows.

* Testsuite additions and improvements: png fmath_test

* Compilation fixes on FreeBSD.

* Compilation fixes on GNU Hurd platform.

* Compilation and warning fixes for Clang 3.1.

* Add FIELD3D_HOME build variable to allow explicit path to Field3D

implementation.

* Remove support for Boost

* Improved unit tests for atomics, spin locks, and rw locks.

* Avoid generating iv man pages when USE_QT=0

* New testtex options: --aniso, --stblur

* CMake option 'EXTRA_CPP_DEFINITIONS' lets custom builds inject

site-specific compiler flags.

* Make/cmake option: HIDE_SYMBOLS=1 will try to restrict symbol visibility

so that only symbols intended to be part of the public APIs will be

visible in the library when linked.

* The old DLLPUBLIC and LLEXPORT macros, which could clash with other

packages, have been renamed to OIIO_API and OIIO_EXPORT.

* Greatly reduced output when building with cmake; by default, most

non-error status messages only are printed when VERBOSE=1 compilation

is requested.

 

Developer goodies:

* Strutil new utilities: iequals, istarts_with, iends_with, to_lower,

to_upper, strip, join.

* Use Chris Foster's 'tinyformat' for type-safe printf-like formatting,

and this now forms the basis of Strutil::format, ustring::format, and

many of the classes' error() methods.

* TypeDesc::equivalent() tests for type equality but allows triples with

different' vector semantics to match.

* In timer.h, a new time_trial() template that makes multiple trial

benchmarks easy.

* Macros for memory and cache alignment (in sysutil.h).

* Extend Filesystem::searchpath_find() to be able to search recursively.

* Strutil::strip() strips whitespace (or other specified character sets) from

the beginning or ending of strings.

* Change threads.h to set USE_TBB=0 if undefined as a compiler flag; this

makes it easier to use threads.h in other applications without worrying

about TBB at all.

* Windows utf8 filename utilities path_to_windows_native and

path_from_windows_native.

Share this post


Link to post
Share on other sites

Apologies for the length of this quote but there is good stuff here in this release.

There are some fixes that are noteworthy also. For instance:

 

* PNG: fix handling of gamma for sRGB images.

 

That might be related to an issue we've seen previously with PNG files in A:M.

 

The Open CV movement of camera images into Image Buffers I perceive as also noteable as is the info related to Mipmaps.

 

 

 

From Larry Gritz:

I have tagged Release-1.1.0. Unless something is extremely, horribly broken, we will strive to not alter the public APIs (other than adding things, and then only if it doesn't break link compatibility). Mostly we'll only fix bugs, but new features or performance improvements could be added but only if they are extremely unlikely to break existing code.

 

New features or risky code will go in the master branch (which is the staging area for an eventual 1.2 release).

 

We'll continue to add critical bug fixes to 1.0 as long as people are depending on it, but from this point on, 1.1 is what we are recommending as the stable, production-ready release.

 

Enjoy.

 

----

 

Here are the release notes, comparing to 1.0:

 

Major new features and improvements:

* Support for reading and writing "deep" images (including OpenEXR 2.0).

* Big ImageCache/TextureSystem improvements:

- Improved accuracy of anisotropic texture filtering, especially when

combined with "blur."

- Improve performance in cases with high numbers of threads using the

TS simultaneously (mostly due to use of reader-writer locks on the

tile cache rather than unique locks).

* New ImageBufAlgo functions:

fromIplImage() : converts/copies an OpenCV image to an ImageBuf.

capture_image() : captures from a camera device (only if OpenCV is found)

over() : Porter/Duff "over" compositing operation

render_text() : render text into an image

histogram() : compute value histogram information for an image

histogram_draw() : compute an image containing a graph of the histogram

of another image

channels() : select, shuffle, truncate, or extend channels of an image.

* New oiiotool commands:

--capture : captures from a camera device (only if OpenCV is found)

--pattern constant : creates a constant-color image

--over : Porter/Duff "over" compositing operation

--text : render text into an image.

--histogram : computes an image containing a graph of the histogram of

the input image.

--fill : fills a region with a solid color

--ch : select, shuffle, truncate, or extend channels

 

API changes:

* A new static ImageInput::open(filename [,config]) combines the old

create-and-open idiom into a single call, which is also much more

efficient because it won't needlessly open and close the file multiple

times. This is now the preferred method for reading a file, though

the old-style create() and open() still work as always.

* Deep image support: ImageInput adds read_native_deep_scanlines,

read_native_deep_tiles, read_native_deep_image, and ImageOutput adds

write_deep_scanlines, write_deep_tiles, write_deep_image, as well as a

supports("deepdata") query. Also, a 'deep' field has been added to

ImageSpec, and some deep data access functions have been added to

ImageBuf.

* ImageInput plugins now may supply a valid_file(filename) method which

detects whether a given file is in the right format, less expensively

than doing a full open() and checking for errors. (It's probably the same

cost as before when the file is not the right time, but when it is, it's

less expensive because it can stop as soon as it knows it's the right

type, without needing to do a full header read and ImageSpec setup.)

* Removed various error_message() functions that had been deprecated for

a long time (in favor of newer getmessage() functions).

* Define a namespace alias 'OIIO' that gets you past all the custom

namespacesin a convenient way.

* TextureOpt now contains a 'subimagename' field that allows subimages

to be addressed by name as well as by index (only for multi-image textures,

of course).

* ImageBuf improvements:

- A new constructor allows an ImageBuf to "wrap" an existing buffer

memory owned by the calling application without allocating/copying.

- Renamed the old ImageBuf::copy_pixels -> get_pixels, and it now

works for 3D (volumetric) buffers.

- New ImageBuf::copy(), and eliminated operator= which was confusing.

- New ImageBuf methods: reres(), copy_metadata(), copy_pixels(),

get_pixel_channels().

- ImageBuf::specmod() allows writable access to the ImageSpec (caution!).

- Better error reporting mechanism.

- get_pixels and get_pixel_channels take optional strides.

* ImageBufAlgo changes:

- Many ImageBufAlgo functions now take a 'ROI' that restricts the

operation to a particular range of pixels within the image (usually

defaulting to the whole image), and for some operations a range of

channels.

- zero() and fill() take ROI arguments.

- ImageBufAlgo::CompareResults struct changed the failure and warning

counts to imagesize_t so they can't overflow int for large images.

* OIIO::getattribute("format_list") now can retrieve the comma-separated

list of all known image file formats.

 

Fixes, minor enhancements, and performance improvements:

* ImageCache/TextureSystem:

- Anisotropic texture lookups are more robust when the derivatives are tiny.

- Attribute "deduplicate" controls whether the identical-image

deduplication is enabled (on by default).

- Attribute "substitute_image" lets you force all texture references to a

single image (helpful for debugging).

- Texture files are no longer limited to having tile sizes that are

powers of 2.

- Much faster TIFF texture access (by speeding up switching of MIPmap levels).

- More graceful handling of the inability to free handles or tiles

under extreme conditions. Rather than assert when we can't free

enough to stay within limits, just issue an error and allow the

limits to be exceeded (hopefully only by a little, and temporarily).

- Detailed per-file stats now track the number of tile reads per

MIPmap level.

- Attribute "unassociatedalpha" (when nonzero) requests that

IC images not convert unassociated alpha image to associated alpha.

* iconvert handles the int32 and uint32 cases.

* Bug fix in to_native_rectangle, which could lead to errors in certain

data format conversions.

* iv improvements:

- better behavior after closing the last image of the sequence.

- file load/save dialogs can filter to show just certain image file types.

- remember last open dialog directory

- "About" dialog has a link to the OIIO home page

* Improve ::create to more robustly handle files whose extensions don't

match their actual formats.

* OpenImageIO::geterror() is now thread-specific, so separate threads will

no longer clobber each others' error messages.

* OpenEXR: support for building with OpenEXR 2.x, including use of

multi-part EXR and "deep" data.

* Fix reading bugs in DPX and Cineon.

* DPX: fix endianness problem for 15 bit DPX output.

* PNG: fix handling of gamma for sRGB images.

* oiiotool fixes: print MIP messages correctly (it was only printing for

the first MIP level); make sure stray "oiio:BitsPerSample" in an input

file doesn't mess up the -d flags.

* Field3D fixes: properly catch exceptions thrown by the Field3D open();

conform metadata to Field3D conventions; multi-layer f3d files will

present as a multi-image file with the "oiio:subimagename" giving a

unique name for each layer subimage;

* OpenEXR: suppress format-specific metadata from other formats.

* Targa: fix several bugs that were preventing certain metadata from being

written properly.

* TIFF: recognize the SAMPLEFORMAT_IEEEFP/bitspersample=16 as an image

composed of "half" pixels; enable PREDICTOR_FLOATINGPOINT to give slightly

better compression of float images.

* Handle UTF-8 paths properly on Windows.

* Removed the obsolete "iprocess" utility.

* Fix allocation and stride bugs when dealing with images having different data

formats per channel, and tiled images with partially filled border tiles.

* Field3D: Bug fix when reading vector f3d files.

* Significant performance improvements of our atomics and spin locks when

compiling with USE_TBB=0.

* Fix quantize() to properly round rather than truncate.

* ImageBufAlgo functions now by convention will save error messages into

the error state of their output ImageBuf parameter.

* Improve I/O error checking -- many file reads/writes did not previously

have their result status checked.

* Fixed missing OpenEXR open() error message.

* Clean up error reporting in iconvert.

* Fixes to handle Windows utf8 filenames properly.

* ImageBufAlgo::compare() gives a sensible error (rather than an assertion)

if the images being compared are not float.

* maketx:

- Better error messages for a variety of things that could go wrong when

reading or writing image files.

- Fixes for bug preventing certain ImageCache efficiencies.

- new option --ignore-unassoc leaves unassociated alpha data as it is

(no auto-conversion to associated alpha) and/or ignores the tags for

an input file that is associated but incorrectly tagged as

unassociated alpha.

- Option --monochrome-detect was buggy for images with alpha.

- Option --constant-color-detect didn't do anything; now it works.

- New option: --compression allows you to override the default compresion.

* oiiotool & info: the --hash command had a bug wherein when applied to

images there were MIP-mapped, would hash the lowest-res MIP level rather

than the highest-res. This could result in two different images, if

they happened to have the same average color, to incorrectly report

the same SHA-1 hash. Note that this did NOT affect non-MIPmapped images,

nor did it affect the SHA-1 hashing that occurred in maketx to allow

the TextureSystem to detect duplicate textures.

 

Build/test system improvements:

* Various Windows build fixes, including fixes for Windows 7, and

improvements to running the testsuite on Windows.

* Testsuite additions and improvements: png fmath_test

* Compilation fixes on FreeBSD.

* Compilation fixes on GNU Hurd platform.

* Compilation and warning fixes for Clang 3.1.

* Add FIELD3D_HOME build variable to allow explicit path to Field3D

implementation.

* Remove support for Boost

* Improved unit tests for atomics, spin locks, and rw locks.

* Avoid generating iv man pages when USE_QT=0

* New testtex options: --aniso, --stblur

* CMake option 'EXTRA_CPP_DEFINITIONS' lets custom builds inject

site-specific compiler flags.

* Make/cmake option: HIDE_SYMBOLS=1 will try to restrict symbol visibility

so that only symbols intended to be part of the public APIs will be

visible in the library when linked.

* The old DLLPUBLIC and LLEXPORT macros, which could clash with other

packages, have been renamed to OIIO_API and OIIO_EXPORT.

* Greatly reduced output when building with cmake; by default, most

non-error status messages only are printed when VERBOSE=1 compilation

is requested.

 

Developer goodies:

* Strutil new utilities: iequals, istarts_with, iends_with, to_lower,

to_upper, strip, join.

* Use Chris Foster's 'tinyformat' for type-safe printf-like formatting,

and this now forms the basis of Strutil::format, ustring::format, and

many of the classes' error() methods.

* TypeDesc::equivalent() tests for type equality but allows triples with

different' vector semantics to match.

* In timer.h, a new time_trial() template that makes multiple trial

benchmarks easy.

* Macros for memory and cache alignment (in sysutil.h).

* Extend Filesystem::searchpath_find() to be able to search recursively.

* Strutil::strip() strips whitespace (or other specified character sets) from

the beginning or ending of strings.

* Change threads.h to set USE_TBB=0 if undefined as a compiler flag; this

makes it easier to use threads.h in other applications without worrying

about TBB at all.

* Windows utf8 filename utilities path_to_windows_native and

path_from_windows_native.

Share this post


Link to post
Share on other sites

OpenIO documentation as of 8 Nov 2012 (Extract):

 

3.2.11 Writing “deep” data

 

NEW! Some image file formats (OpenEXR only, at this time) support the concept of “deep” pixels –

those containing multiple samples per pixel (and a potentially differing number of them in each

pixel). You can tell if a format supports deep images by checking supports("deepdata"),

and you can specify a deep data in an ImageSpec by setting its deep field will be true.

 

Deep files cannot be written with the usual write scanline, write scanlines, write -

tile, write tiles, write image functions, due to the nature of their variable number of

samples per pixel. Instead, ImageOutput has three special member functions used only for

writing deep data:

 

bool write_deep_scanlines (int ybegin, int yend, int z,

const DeepData &deepdata);

 

bool write_deep_tiles (int xbegin, int xend, int ybegin, int yend,

int zbegin, int zend, const DeepData &deepdata);

 

bool write_deep_image (const DeepData &deepdata);

 

It is only possible to write “native” data types to deep files; that is, there is no automatic

translation into arbitrary data types as there is for ordinary images. All three of these functions

are passed deep data in a special DeepData structure, defined in imageio.h as follows:

 

OpenImageIO Programmer’s Documentation

 

36 CHAPTER 3. IMAGEOUTPUT: WRITING IMAGES

 

struct DeepData {

int npixels, nchannels;

std::vector channeltypes; // for each channel [c]

std::vector nsamples;// for each pixel [z][y][x]

std::vector pointers; // for each channel per pixel [z][y][x][c]

std::vector data; // for each sample [z][y][x][c]

DeepData ();

 

// Set the size and allocate the nsamples[] vector.

void init (int npix, int nchan,

const TypeDesc *chbegin, const TypeDesc *chend);

 

// Allocate data[] and set up all the pointers[]

void alloc ();

};

 

Here is an example of using these methods to write a deep image:

 

// Prepare the spec for 'half' RGBA, 'float' z

int nchannels = 5;

ImageSpec spec (xres, yres, nchannels);

TypeDesc channeltypes[] = { TypeDesc::HALF, TypeDesc::HALF,

TypeDesc::HALF, TypeDesc::HALF, TypeDesc::FLOAT };

spec.z_channel = 4;

spec.channelnames[spec.z_channel] = "Z";

spec.channeltypes.assign (channeltypes+0, channeltypes+nchannels);

spec.deep = true;

 

// Prepare the data (sorry, complicated, but need to show the gist)

DeepData deepdata;

deepdata.init (xres*yres, 5, channeltypes+0, channeltypes+nchannels);

for (int y = 0; y

for (int x = 0; x

deepdata.nsamples[y*xres+x] = ...num samples for that pixel...;

deepdata.alloc (); // allocate pointers and data

int pixel = 0;

for (int y = 0; y

for (int x = 0; x

for (int chan = 0; chan

void *ptr = deepdata.pointers[pixel*nchannels + c];

if (chan

for (int samp = 0; samp

((half *)ptr)[samp] = ...value...;

} else {

 

// z channel -- FLOAT data

for (int samp = 0; samp

((float *)ptr)[samp] = ...value...;

}

}

}

}

OpenImageIO Programmer’s Documentation

 

3.2. ADVANCED IMAGE OUTPUT 37

 

// Create the output

ImageOutput *out = ImageOutput::create (filename);

if (! out)

return;

// Make sure the format can handle deep data and per-channel formats

if (! out->supports("deepdata") || ! out->supports("channelformats"))

return;

// Do the I/O (this is the easy part!)

out->open (filename, spec);

out->write_deep_image (deepdata);

out->close ();

delete out;

 

Full Documentation (with many undocumented areas) attached.

openimageio.pdf

Share this post


Link to post
Share on other sites

This just in from Larry Girtz on the latest OpenImageIO release.

(I've highlighted the area that looked interesting to me personally)

 

Release 1.1.4 (27 Jan 2013)

---------------------------

* ImageBufAlgo::make_texture() allows you to do the same thing that

maketx does, but from inside an application and without launching a

shell invocation of maketx.

* oiiotool now recognizes --metamatch and --nometamatch arguments which

cause metadata names matching (or only info NOT matching) the given

regular expression to be printed with --info.

* oiiotool --zover does z (depth) composites (it's like a regular "over",

but uses the z depth at each pixel to determine which of the two images

is the foreground and which is the background).

* ImageBufAlgo::fixNonFinite didn't work properly with 'half' image buffers.

* Performance improvements when reading and writing images.

* Fix error when writing tiled 'float' TIFF images, corrupted output.

(Could easily happen when using 'maketx' to convert float images into

TIFF textures.)

* Eliminate warnings when compiling with Clang 3.2.

* New CMake variable "USE_EXTERNAL_TBB" can optionally be set to force use

of an external TBB library rather than the embedded one.

* Additional testsuite tests (doesn't affect users, but makes bugs easier

to catch).

* Fix build problem with SHA1.cpp on some platforms.

 

 

Reminders:

 

1. The 'Release-1.1.4' tag is the latest tagged, stable production release. It will never change -- additional low-risk important improvements will be back-ported to the RB-1.1 branch, but the next official release tag there will be for 1.1.5. In any case, nothing added to RB-1.1 will ever (we believe) change existing API calls or break binary or link compatibility.

 

2. The "master" branch is where new development happens. This will eventually become the stable 1.2 branch, but for now, we make no guarantees about compatibility changes in "master" -- changes could happen at any time that alter the API or break linkage compatibility.

 

3. We're happy to back-port important fixes to earlier release branches (1.0 or even 0.10) if we can, but at this point, such back-ports to older branches only happen if people specifically request it.

Share this post


Link to post
Share on other sites

I'm relieved that "ImageBuffalo" has finally been implemented.

Share this post


Link to post
Share on other sites
I'm relieved that "ImageBuffalo" has finally been implemented.

 

That buffer algorithm actually does sound like a useful fix as it relates to 'half' image buffers.

Maybe that will help in A:M Composite somewhere down the line with all the various floats/buffers

Share this post


Link to post
Share on other sites

When I was a boy the planes were black with wild BufAlgo.

Share this post


Link to post
Share on other sites

The Buffalo has already been tweaked.

 

From Larry Girtz:

 

We don't usually do releases so quickly if we can help it, but coming just behind Release-1.1.4 is Release-1.1.5, which fixes two important bugs discovered right after 1.1.4 was tagged:

 

 

Release 1.1.5 (29 Jan 2013)

---------------------------

* Bug fix in ImageBufAlgo::parallel_image utility template -- care when

not enough work chunks to dole out to all the threads (was previously

sending work to threads with nonsensical ROI's, now we just stop when

all the regions have been doled out).

* Additional optional argument to IBA::zover that, when nonzero, will

treat z=0 pixels as infinitely far away, not super close. You can turn

this on from oiiotool with: oiiotool --zover:zeroisinf=1 ...

Share this post


Link to post
Share on other sites

More changes to the Buffalo:

 

From Larry Girtz:

 

I've tagged Release-1.1.6. This has several important bug fixes, plus a number of new features (though all seem extremely safe that they can't break existing behavior, and were requested by specific users who need them).

 

The release notes are as follows:

 

Release 1.1.6 (11 Feb 2013)

---------------------------

* Fix bug that could generate NaNs or other bad values near the poles of

very blurry environment lookups specifically from OpenEXR latlong env maps.

* Fix bug in oiiotool --crop where it could mis-parse the geometric parameter.

* Fix bug in ImageCache::invalidate() where it did not properly delete the

fingerprint of an invalidated file.

* Cleanup and fixes in the oiiotool command line help messages.

* New function ImageBufAlgo::paste() copies a region from one IB to another.

* oiiotool --fit resizes an image to fit into a given resolution (keeping the

original aspect ratio and padding with black if needed).

* ImageBufAlgo::channels() and "oiiotool --ch" have been extended to allow

new channels (specified to be filled with numeric constants) to also be

named.

* New function ImageBufAlgo::mul() and "oiiotool --cmul" let you multiply

an image by a scalar constant (or per-channel constant).

* Important maketx bug fix: when creating latlong environment maps as

OpenEXR files, it was adding energy near the poles, making low-res

MIP levels too bright near the poles.

* Fix to "oiiotool --text" and "oiiotool --fill" -- both were

incorrectly making the base image black rather than drawing overtop of

the previous image.

* Fix FreeBSD compile when not using TBB.

* New oiiotool --swap exchanges the top two items on the image stack.

Share this post


Link to post
Share on other sites

More interesting stuff about the Image Buffalo...

 

There are three easy ways to read a tiled image with OpenImageIO:

 

1. Read the whole image into your own buffer:

// Allocate and read into a big float buffer

ImageInput *in = ImageInput::open (filename);

std::vector buf (in->spec().image_pixels() * in->spec().nchannels);

in->read_image (&buf[0], TypeDesc::FLOAT);

in->close ();

delete in;

 

2. Use an ImageBuf:

ImageBuf ib (filename);

ib.read ();

// now you may access the pixels using ib.getpixel(x,y,&myfloatpixel)

// or ImageBuf::Iterator traversal

// or copy to your own buffer using ib.get_pixels(...)

 

3. Use ImageCache:

ImageCache *ic = ImageCache::create (); // just do this once

... set up your buffer to the right size ...

ic->get_pixels (ustring(filename), ..., &mybuffer);

 

 

All of these work identically for tiled and scanline files.

 

There's one more option: Like #1, but instead of read_image(), you could call read_tile() repeatedly to read individual tiles. But that ONLY works for tiled files, and there is no advantage to doing this versus #1 if you need the whole image at once -- reading individual tiles is only helpful if your application needs the individual tiles one-by-one.

Share this post


Link to post
Share on other sites

It is interesting to note that Nick Porcino... long ago user of A:M... and current Sr. R&D Engineer at ILM is an occasional contributor to EXR development. Makes sense as EXR is an ILM gift to the graphics community. Other interest include C++ programming and artificial intelligence.

 

I haven't seen him active in the EXR 2.0 arena recently but I'm sure it remains an area of interest to him.

Share this post


Link to post
Share on other sites

Open EXR 2.0 is officially released:

 

April 9, 2013 - Industrial Light & Magic (ILM) and Weta Digital announce the release of OpenEXR 2.0, the major version update of the open source high dynamic range file format first introduced by ILM and maintained and expanded by a number of key industry leaders including Weta Digital, Pixar Animation Studios, Autodesk and others.

 

The release includes a number of new features that align with the major version number increase. Amongst the major improvements are:

 

Deep Data support - Pixels can now store a variable-length list of samples. The main rationale behind deep images is to enable the storage of multiple values at different depths for each pixel. OpenEXR 2.0 supports both hard-surface and volumetric representations for Deep Compositing workflows.

Multi-part Image Files - With OpenEXR 2.0, files can now contain a number of separate, but related, data parts in one file. Access to any part is independent of the others, pixels from parts that are not required in the current operation don't need to be accessed, resulting in quicker read times when accessing only a subset of channels. The multipart interface also incorporates support for Stereo images where views are stored in separate parts. This makes stereo OpenEXR 2.0 files significantly faster to work with than the previous multiview support in OpenEXR.

Optimized pixel reading - decoding RGB(A) scanline images has been accelerated on SSE processors providing a significant speedup when reading both old and new format images, including multipart and multiview files.

Namespacing - The library introduces versioned namespaces to avoid conflicts between packages compiled with different versions of the library.

Although OpenEXR 2.0 is a major version update, files created by the new library that don't exercise the new feature set are completely backwards compatible with previous versions of the library. By using the OpenEXR 2.0 library, performance improvements, namespace versions and basic multi-part/deep reading support should be available to applications without code modifications.

 

This code is designed to support Deep Compositing - a revolutionary compositing workflow developed at Weta Digital that detached the rendering of different elements in scene. In particular, changes in one layer could be rendered separately without the need to re-render other layers that would be required to handle holdouts in a traditional comp workflow or sorting of layers in complex scenes with elements moving in depth. Deep Compositing became the primary compositing workflow on Avatar and has seen wide industry adoption. The technique allows depth and color value to be stored for every pixel in a scene allowing for much more efficient handling of large complex scenes and greater freedom for artists to iterate.

 

True to the open source ethos, a number of companies contributed to support the format and encourage adoption. Amongst others, Pixar Animation Studios has contributed its DtexToExr converter to the OpenEXR repository under a Microsoft Public License, which clears any concerns about existing patents in the area, and Autodesk provided performance optimizations geared towards real-time post-production workflows.

 

Extensive effort has been put in ensuring all requirements were met to help a wide adoption, staying true to the wide success of OpenEXR. Many software companies were involved in the beta cycle to insure support amongst a number of industry leading applications. Numerous packages like SideFX's Houdini, Autodesk's Maya, Solid Angle's Arnold renderer, Sony Pictures Imageworks' Open Image IO have already announced their support of the format.

 

Open EXR 2.0 is an important step in the adoption of deep compositing as it provides a consistent file format for deep data that is easy to read and work with throughout a visual effects pipeline. The Foundry has build OpenEXR 2.0 support into its Nuke Compositing application as the base for the Deep Compositing workflows.

 

OpenEXR 2.0 is already in use at both Weta Digital and Industrial Light & Magic. ILM took advantage of the new format on Marvel's The Avengers and two highly anticipated summer 2013 releases, Pacific Rim and The Lone Ranger. Recent examples of Weta Digital's use of the format also include Marvel's Avengers as well as Prometheus and The Hobbit. In addition, a large number of visual effects studios have already integrated a deep workflow into their compositing pipelines or are in the process of doing so including:, Sony Pictures Imageworks, Pixar Animation Studios, Rhythm & Hues, Fuel and MPC.

 

In addition to visual effects, the new additions to the format, means that depth data can also be assigned to two-dimensional data for a use in many design fields including, architecture, graphic design, automotive and product prototyping.

 

Source code for viewers etc.: http://www.openexr.com/downloads.html

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...