Re: (*.hdr) environment shader questions

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

Hi Luc-Eric,

I checked your article in the wiki (and the spam added/removed:-),
of course helps a lot in getting an idea about linear colorspace,
gammacorrection and image interpretation rules neccessary.

DonÂt want to criticise any of that. ItÂs a great article.

WhatÂs puzzled me is the Clipping to 8bit the moment you enable
effects on an image (that has >8 bitdepth), if I understand you
correct, the image is then gammacorrected (according to prefs) and
passed to mR, resulting in a completely different rendering/backround.
As the gammacorrection doesnÂt happen for the native HDR file but
only for the clipped 8bit converted file.

I *would* have instead expected an *.hr with the Exposure=0
and the 8bit converted image to *look* identical, e.g. the clipping
being based on the exposure set in the slider for example.

Regarding the OGL display allways requiring a gammacorrection
for floating point images, no critique here either. ItÂs logic.

Yet, in terms fo working with fp images, IÂd think still think all
colorconcepts are still adaptable if you normalize all images
(not to be confused with a gammacorrection) to the 0-1 range.
Which is what you can do with Maya, the min input is declared
black, the max is pure white, for color operations. YouÂd need the
displaygamma to correctly set the exposurelevel if you want a
lowkey or highkey image (e.g. something without absolute black)
out of that. ItÂs true, you canÂt load such an image without having
an idea what it contains, the normalization always makes it a
*perfect, full range* image by default. IÂd need to check the specs
of the *.exr format, afaik they attach a certain exposure to the monitor
displaygamma via the header, but I never working/fiddled with *.exr yet.

I *think* itÂs like for exposure=0, thatÂs why I was puzzled initially.
Maybe IÂm wrong and there is not such thing in HDR/*.exr files.

Cheers

tim












----- Original Message ----- 
From: "Luc-Eric Rousseau" <lucer(at)Softimage.COM>
To: <XSI(at)Softimage.COM>
Sent: Tuesday, April 04, 2006 10:07 PM
Subject: RE: (*.hdr) environment shader questions


> I understand what you mean, Tim, but no one has solved the problems of using classic 
> color tools with HDR. They're not even sure what to do with anti-aliasing.
>
> HSV only exists to create user interface.  It maps the colors to a neat little Hue 
> circle, with the lowest value at 0 degrees, and the highest value to 360 degrees, 
> divided in 6 quadrants.  The saturation is the amount of gray the color does not 
> have, i.e. the purity.  In high dynamic range, there is no maximum value, and no 
> real "gray" value.  To do color correction on HDR, where a channel can possibly be 
> a thousands of time the value of the next, you can work with basic tools such as 
> multiply and additive.
>
> I think you might be misunderstanding the whole gamma correction controls; try to 
> catch my article on the wiki 
> http://softimage.wiki.avid.com/index.php/Gamma%2C_Linear_Color_Space_and_HDR.  XSI 
> has always uploaded 8-bit textures to OpenGL.  For HDR and EXR, you get to apply a 
> display gamma to these so you can see a better approximation of the textures you're 
> working with.  It's not possible to apply a gamma curve after display to OpenGL, at 
> least not in classic OpenGL, so that's the way to do it.  In any case, display 
> gamma is something to apply anytime a float image is converted to 8 or 16-bit
>
> ------------------
> Luc-Eric Rousseau
> Team Leader, User Interface
> Softimage|XSI
>
>
> > -----Original Message-----
> > From: Tim Leydecker
> >
> > Hi Luc-Eric,
> >
> > I donÂt want to be offensive or anything when I
> > still find it more failsafe to do image operations
> > and manipulations without clipping nowadays.
> >
> > >With an HDR or EXR images, the pixel buffer
> > >given to mental ray when the effects are on is an
> > >8-bit image gamma corrected and meant for
> > >OpenGL previewing, not a floating point HDR image.
> >
> > At least this gammacorrection is therfore wrong, imho.
> > Only the output from mR and the OGL display should
> > be gammacorrected but not clipped beforehead.
> >
> > I really donÂt want to stirr any mess or resentiments.
> >
> > ItÂs just that everything and everybody slowly transfers
> > over to lossless higher bitdepths for their work, even games
> > make use of HDR rendering (mostly blooming highlights),
> > it would be great to have XSI do itÂs operations accordingly.
> >
> > E.g. conceptually adapt working in an unclipped colorspace
> > that may even have room for Ultra-HDR or 128bitfull*.exr
> > or whatever the next killerformat will be called.
> >
> > I donÂt want to insist on the NTSC luminance concept either,
> > itÂs been an example to illustrate things. HSV imho still works,
> > itÂs just more V(alues). Same for H and S. Greyscale HDRÂs
> > are actually great for setting up materials well lit but colorproof.
> >
> > Cheers
>
> ---
> 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