Re: (*.hdr) environment shader questions

["Tim Leydecker" <BauerOink(at)gmx.de>]

Hi Thomas,

basically, you replace every *clip outside range* in your
code through a *normalize input to 0-1* and allow for
more than 256 steps for calculations, which may be
neccessary if you had optimized your code for speed
in the prior version. You can allow 16bit, 32bit, 64bit...
IÂd think it would be cool to work in the same bitdepth
mR uses internally (64bit or 128bit, I canÂt remember).

We had this discussion a while back at the maya(at)highend3d.com
listserver, the Alias guys reworked the CC nodes accordingly.
Their nodes (for the hypershade, similar to the rendertree)
hiddenly clipped things. Some people didnÂt like this,
the filmguys mostly.

ItÂs not generally a showstopper, itÂs more or less a
tradition that needs to be rethought when trying to
implement a fully functional highdynamicrange pipeline
with loads of room for grading nowadays.

Personally, my images wouldnÂt benefit from it yet, I still
lack the basic abilities of *lighting* accordingly.

I admit this because IÂve seen images that really benefit
from a highdynamic range...IÂm not capable to work at
that level...artistically :-)

Cheers

tim



----- Original Message ----- 
From: "Thomas Helzle" <xsi(at)screendream.de>
To: <XSI(at)Softimage.COM>
Sent: Tuesday, April 04, 2006 9:14 PM
Subject: Re: (*.hdr) environment shader questions


> Hi Tim,
>
> well, a lot of CC operations are hard to implement for HDRI. For instance, if you 
> invert a HDRI, what would you expect to get? If your colour values go up to 10.0, 
> but you invert around 1.0 ("1.0 - colour value"), you would get -9.0 as an 
> extreme - super black :-).
> Most image algorithms have been developed for those well defined ranges and are 
> hard to transfer to the unknown ranges of HDRI.
> But yes, it would be cool to have at least some options.
>
> Things like Hue and Saturation are often implemented by first converting RGB to 
> HSV, do your changes and then convert back. Now this conversion doesn't usually 
> account for outside-ranges, but I think it should be possible to "normalise" the 
> image to the standard range, save the normalisation amount (with what do you have 
> to multiply the values to make them fit into the 0.0-1.0 range), do the colour 
> correction and afterwards multiply with 1.0/normalisation amount.
> But this only works for the complete image (what is the highest R/G/B value in ALL 
> pixels?), you can't compute it on a per-pixel basis, so it isn't something a normal 
> custom node can do. You would need to create your own image node... ;-)
>
> Cheers,
>
> Thomas Helzle
>
>
>
> On Tue, 04 Apr 2006 20:34:22 +0200, Tim Leydecker <BauerOink(at)gmx.de> wrote:
>
> > O.k. Thomas,
> >
> > I missed that bit in Luc-EricÂs previous post:
> >
> > > > If you're using HDR, you can't enable the Image Clip effects
> >
> > I didnÂt realize Colorcorrection as implemented in an
> > Image>Adjust section is 8(16)bit only. Makes sense,
> > as the FXtree is *only* 16bit as well.
> >
> > I had asumed that the input, regardless of itÂs bitdepth,
> > would be normalized to the 0-1 range only for the
> > sliders, e.g. 0.1 would be a compareable lumavalue
> > in any 8,16,32bit b/w gradient but obviously the higher
> > the bitdepth, the more steps available for rendering and
> > the smoother the output.
> >
> > Thanks for making me aware of the clipping to 8/16bit.
> >
> > IÂll log a featurerequest to have this changed, e.g. have
> > CC-Operations work without prior clipping in a later
> > version of XSI. I guess they are looking into this allready, tho.
> >
> > Cheers
> >
> > tim
> >
> >
> >
> >
> > ----- Original Message -----
> > From: "Thomas Helzle" <xsi(at)screendream.de>
> > To: <XSI(at)Softimage.COM>
> > Sent: Tuesday, April 04, 2006 8:09 PM
> > Subject: Re: (*.hdr) environment shader questions
> >
> >
> > > No, the moment you activate the effects, everything outside the 0.0 to 1.0 range
> > > (that is what "normal" image formats use) is cut off (since it is converted to
> > > integer 8/16 bit), so you loose what makes a HDRI image different - values way
> > > outside of this range, "whiter than white" as the Persil commercial would call 
> > > it,
> > > giving those interesting effects of sunlight etc.
> > >
> > > In that regard, 8 and 16 Bit aren't different from each other as long as they are
> > > implemented as integers that are translated into the 0.0 to 1.0 range. 16 Bit can
> > > represent more in-between values, so it can look "smoother".
> > > Only floating point data can hold HDR information (at least this is how it is
> > > implemented, basically you could use integers too, but you would have to define
> > > what the range is).
> > >
> > > Hm - was that any clearer?
> > > Otherwise ask again :-)
> > >
> > > Cheers,
> > >
> > > Thomas Helzle
> > >
> > > On Tue, 04 Apr 2006 19:43:52 +0200, Tim Leydecker <BauerOink(at)gmx.de> wrote:
> > >
> > > > Hi Luc-Eric,
> > > >
> > > > thanks for pointing out the manual, will give it another go :-)
> > > >
> > > > So, as far as I get it, when my renderregion changes the
> > > > moment I "enable effects" on the environmentshader Âs
> > > > image "Adjust" page, this is due to the display gamma
> > > > setting of the renderregion. IÂll check my preferences
> > > > settings.
> > > >
> > > > When I asked about the 8-16bit conversion I expected
> > > > it to be a convenience hack for using lowdynamicrange
> > > > images as the input for lighting calculations of FG.
> > > > DidnÂt realize itÂs mostly meant for displacementmaps.
> > > >
> > > > What IÂd want is to load a *.hdr image, render using itÂs
> > > > linear float input, probably *see* the gammacorrected
> > > > input to correctly set the f-stop and have the renderregion
> > > > and OGLviews display things gammacorrected. Oh, my:-)
> > > >
> > > > Now IÂll check the wiki again.
> > > >
> > > > Cheers
> > > >
> > > > tim
> > >
> > > ---
> > > Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
> > > unsubscribe xsi
> >
> >
> > ---
> > Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
> > unsubscribe xsi
>
>
>
> ---
> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
> unsubscribe xsi


---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi