Re: (*.hdr) environment shader questions

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

Hi Luc-Eric,

someone spammed your article with porn/casino links:
(mind wordwrap)
http://softimage.wiki.avid.com/index.php?title=Gamma%2C_Linear_Color_Space_and_HDR&diff=0&oldid=3062

> > You're not suposed to use the Image Clips Effects when you
> > work with HDR or OpenEXR image.
> > If you Enable them, you will get the gamma corrected image
> > sent to mental ray and that's the wrong result, because the
> > gamma correction is implemented in the image source loader.
> > (It's also terrribly memory intensive as images buffers are
> > copied over the Mental Ray.) So don't enable the image clip
> > effects with HDR...

ThatÂs what had puzzled me, they are there but arenÂt meant to
be used (this is probably documented), will produce clipping
and defeat the correct use of a HDR/*.exr. ThatÂwhy I asked.

> > If it was just up to me we wouldn't have image clip fx.., at
> > least for color correction I mean why would have color tools
> > there, then other kinds of tools in the RenderTree.  A shader
> > to do this in the RenderTree is totally reasonable, whereas
> > I'm less keen on adding more feature creep to the Image Clip PPG

Yepp. IÂd also prefer to have everything available via the rendertree
instead of having to search for a setting in the properties pages.
Coming from a Maya Hypershade and Attribute Editor I expected
everything to be accessible via the rendertree actually,from multiple
selections, too. Makes sharing images and rewiring things a snap.

> > If Maya does have a shader that does HSV correction on HDR
> > images, and uses a min and max value, it probably doesn't
> > normalize the entier image, but rather apply the LUT on a
> > region of values and leaves the other values outside of it
> > untouched, which is the proper thing to do.

Maya (6) doesnÂt have a (default) shader for this, itÂs just that
the clipping has been removed from the coloroperations, contrast
and gammacurve nodes (compareable to the stuff in the rendertree).

IÂd really welcome if some of the guys actually using *.exr and *.hdr
in their pipelines together with Compositing (AE, DF, Nuke, Shake)
would chime in on this here. All I can contribute is not more than an
academic trail of thoughts - e.g. not really derrived from a production
pipeline and itÂs demands.

Cheers


tim




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


> btw, what does that mean?
> > I checked your article in the wiki (and the spam added/removed:-),
>
> ------------------
> Luc-Eric Rousseau
> Team Leader, User Interface
> Softimage|XSI
>
>
> > -----Original Message-----
> > From: owner-xsi(at)Softimage.COM
> > [mailto:owner-xsi(at)Softimage.COM]On Behalf
> > Of Luc-Eric Rousseau
> > Posted At: Wednesday, April 05, 2006 12:35 PM
> > Posted To: xsi
> > Conversation: (*.hdr) environment shader questions
> > Subject: RE: (*.hdr) environment shader questions
> >
> >
> > I think you may have misunderstood the gamma correction bit.
> > Of perhaps you did understand it, I'm not sure anymore.
> >
> > In XSI, there are settings for Exposure and Display Gamma for
> > HDR and OpenEXR images.  This is for OpenGL and other preview.
> >
> > You're not suposed to use the Image Clips Effects when you
> > work with HDR or OpenEXR image.
> > If you Enable them, you will get the gamma corrected image
> > sent to mental ray and that's the wrong result, because the
> > gamma correction is implemented in the image source loader.
> > (It's also terrribly memory intensive as images buffers are
> > copied over the Mental Ray.) So don't enable the image clip
> > effects with HDR...
> >
> > With regards to running HSV correction on a 'normalized'
> > version of HDR images, that doesn't work.  It would only work
> > reasonably if all the color channels in the image had the
> > same scale and the image is pretty uniform, but then it
> > wouldn't be a useful HDR image.   If there are large
> > differences between red, green and blue channels, you can't
> > really say what's really "red", "green" or "blue" because it
> > depends of where you're looking and what's the exposure.
> >
> > If Maya does have a shader that does HSV correction on HDR
> > images, and uses a min and max value, it probably doesn't
> > normalize the entier image, but rather apply the LUT on a
> > region of values and leaves the other values outside of it
> > untouched, which is the proper thing to do.
> >
> > If it was just up to me we wouldn't have image clip fx.., at
> > least for color correction I mean why would have color tools
> > there, then other kinds of tools in the RenderTree.  A shader
> > to do this in the RenderTree is totally reasonable, whereas
> > I'm less keen on adding more feature creep to the Image Clip PPG
> >
> > ------------------
> > Luc-Eric Rousseau
> > Team Leader, User Interface
> > Softimage|XSI
> >
> >
> > > -----Original Message-----
> > > From: owner-xsi(at)Softimage.COM
> > > [mailto:owner-xsi(at)Softimage.COM]On Behalf
> > > Of Tim Leydecker
> > > Posted At: Wednesday, April 05, 2006 10:28 AM
> > > Posted To: xsi
> > > Conversation: (*.hdr) environment shader questions
> > > Subject: Re: (*.hdr) environment shader questions
> > >
> > >
> > > 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
> > >
> >
> > ---
> > 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