Re: (*.hdr) environment shader questions

["Thomas Helzle" <xsi(at)screendream.de>]

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