Re: [Openexr-devel] siggraph course

[Rod Bogart]

On Fri, 08 Aug 2003, Luc-Eric Rousseau wrote:

> Is there some place we can get more information about some of the paint and 
> compositing issues (and solutions) mentioned during the Monday, July 28th 
> siggraph course on HDRI?
> 
> For example, Rod Bogart mentioned problems with compositing when alpha is 
> slightly less than 1.0, and compositing HDR anti-aliased images.
> Was there a discussion of the implementation techniques and problems for 
> artist tools to paint HDR images? Unfortunately there was again this year too 
> many things happening at the same time to see and hear everything.
> 

I wanted to raise a few issues for people to be aware of when doing
floating point compositing (and also painting).  The most obvious
difference is image display.  If you take an opaque (alpha==1.0) object
with a nice antialiased edge, and comp it over a HDR background, it
will work fine.  But it might look wrong.  The bright pixels of the
bg will be reduce by the correct factor according to the alpha.  But
it is possible that all of those edge pixels still have very bright
values, and thus look blown out, causing an edge that isn't antialiased
looking.  So you need to do tone mapping, or output simulation or something
to see how the bright pixels will be handled by the downstream devices
(such as film output).

Another problem I demonstrated is when your "opaque" object has an
alpha of .999 rather than 1.0.  In a floating point compositing
system, bright background values will leak thru.  So, the problem
for users is verifying that they have opaque alpha where they want
it, and the problem for software developers is to provide tools
that don't round off the numbers when users are examining values.

When painting on HDR images, the soft edge of a brush has similar
issues to the antialiased edges.  So, cloning dark pixels onto
bright pixels can look wrong if the display is simply zero to one.
But the pixels are actually "right".

The last issue I mentioned was the use of implicit "1.0" values in
compositing operators.  The most obvious is "invert", which takes
a 0-255 image and makes it 255-0.  But in floating point, you want
to specify a pivot (.5 in this case).  Another example is the "screen"
operator which sort of accumulates towards 1.0, and should have a
pivot/limit value.  Another significant problem is negative lobed
filters during resize etc, so extreme differences between neighboring
pixels need to be handled in the filter, or as a preprocess to the
filter.

That's the rough summary of the areas I touched on in the course.
Other folks indicated similar problems in the questions afterwards.

RGB