Another ultracool R8.5 tool

[danb]

woah that is a huge difference. then one wouldn't have to mess around with lighting settings. umm i think

[JIII]

hmm so does this mean I won't have to pump the lum channel all the way to 600?

just wondering.

[ThirdEye]

Originally posted by JIII
hmm so does this mean I won't have to pump the lum channel all the way to 600?

just wondering.


Actually it's exactly the opposite. Many hdr pic (especially the ones you find on Debevec's Site) have a really wide light range, using this technique the contrast isn't so harsh anymore. This just restores the original value, if you use it wihout this shader the values are just... Wrong.

[AdamT]

Yep, and in addition most-if-not-all of the SLA shaders are now capable of unclamped output.

[ThirdEye]

Another cool aspect of this process is the fact the restored values are much less harsh than the "false" one, so you don't need a so high stochastic samples value anymore = less splotches in a shorter time. :)

[Continuumx]

ThirdEye01, it would help if you could tell us the construction of this image, where are you using the filter shader?

Is this filter shader channel something new in 8.5?

Is it a shader texture, is a real channel?

My C4D 8.206 does not have this channel.

[ThirdEye]

Originally posted by Continuumx
ThirdEye01, it would help if you could tell us the construction of this image, where are you using the filter shader?

Is this filter shader channel something new in 8.5?

Is it a shader texture, is a real channel?

My C4D 8.206 does not have this channel.


Just read the title of the thread, obviously you don't have the filter into R8.206 ;) Anyway as i already said in my 1st post this is a new version of the old BhodiNut HUE channel shader, i'm using it in the luminance channel for this example with HDRI lighting.

[AdamT]

Originally posted by ThirdEye_01
Just read the title of the thread, obviously you don't have the filter into R8.206 ;) Anyway as i already said in my 1st post this is a new version of the old BhodiNut HUE channel shader, i'm using it in the luminance channel for this example with HDRI lighting.
To be precise it combines BT Hue and BT Brightness and Contrast.

[ThirdEye]

Originally posted by AdamT
To be precise it combines BT Hue and BT Brightness and Contrast.

Yep, you're right Adam, i forgot the 2nd one, maybe it's because i never used it :p

[brammelo]

I see tons of cool stuff in 8.5 here on CGTalk. I don't, however, see it on Maxon's website. Makes me wonder why ...

Anyway, glad we HAVE this much stuff in 8.5 :)

Cheers,
BaRa

[kiwi]

Originally posted by AdamT
To be precise it combines BT Hue and BT Brightness and Contrast.



Brilliant :thumbsup: I have so many custom materials which are so many fusions deep its not funny.The work around I came up with was to minimize what shaders use I could and then put the fusion in BN hue shader and adjust its lightness and darkness from the lightness slider,saved a lot of time,but these new additions sound excellent.Looks like I have an armload of shaders to re engineer soon :D

[astrofish]

Originally posted by ThirdEye_01
Generally HDRI maps are made with HDRShop, which has a gamma setting of 2.2 by default, C4D (and Lw and...) has a default gamma setting of 1, so you need to restore the original 2.2 value to get the right result.

Hmm, now I'm confused.
I thought that HDRI maps were supposed to contain floating point values which are directly proportional to light level (i.e. gamma doesn't come into it).

Gamma values are to do with monitor intensity response curves, so I can understand that to correctly _display_ an image you need to apply gamma correction, but I don't understand why it needs to be considered on a _per-material_ basis whilst rendering (you don't use different monitors for viewing different materials within the same image).

So, if you change the gamma setting in HDRShop, this will change the visible appearance of the image (because you are telling it that your monitor response has changed), but I wouldn't have expected it to change the map itself.

So, what's really going on here?
Is gamma information _really_ encoded into HDRI maps?

Cheers - Steve

[tjnyc]

Originally posted by AdamT
Yep, and in addition most-if-not-all of the SLA shaders are now capable of unclamped output.

Oh! Very nice, I am very glad to hear that. :)

[JIII]

yea I think gamma info is, there was a discussion about this a few days ago on IRC. http://www.cgtalk.com/showthread.php?s=&threadid=55726 there is some info about it in this thread.

[Continuumx]

ThirdEye01:

A tutorial of this should be sent to Maxon and included in their tutorial section on HDR so that these images take advantage of what is new in 8.5 for HDR image rendering!

[chris_b]

Fantastic news!!
C4D's current HDR handling (especially at default settings) has always
felt much to hot. This should really help smooth out the illumination curve
and reduce the need for insane sampling values.

A great extension of Cinema's HDR support would be to allow rendering
to 96 and 128 bit formats (.hdr, .exr, floating point TIFF... etc). Maxon could build in an exposure/gamma adjustment tool (perhaps in the Picture Viewer).
To allow the user to make post-render adjustments to the image before it is clamped down to 8 or 16 bit for export.

What do you think?

There is an interesting discussion on the subject of HDR gamma here:

http://hdri.cgtechniques.com/~blochi/show.php?id=326&PHPSESSID=b906e2a8135506416c4f547213f571ae (http://)

[MJV]

Originally posted by ThirdEye
The cool tool of the day is the filter channel shader: it's basically a new version of the old BN hue, and it works with .hdr pics too. Here's a screenshot of its settings, it'll show you how much important this shader is with HDRI lighting. Generally HDRI maps are made with HDRShop, which has a gamma setting of 2.2 by default, C4D (and Lw and...) has a default gamma setting of 1, so you need to restore the original 2.2 value to get the right result. Here's the default (gamma=1) result:

And here's the same render, i only changed the gamma value to 2.2, the difference is huge.



What is the reason that HDRShop uses a gamma value of 2.2? Why would it do that? Are you saying that all those images are more contrasty than they should be? How do you know? Changing the contrast of HDRImages should change the result for sure, possibly producing more pleasing images, but I don't understand where the claim that they are wrong comes from. By definition HDRImages have an enormous dynamic range. Not that I'm doubting you, but I just want to understand better. Thanks.

[chris_b]

Hi MV,

From what I have read, the problem is not so much that HDR shop uses a default display gamma of 2.2 (on PC), but that most 3D software packages
(Max, Lightwave, Cinema) interpret HDR images with a gamma of 1.0. As you say, HDR images have an extraordinary dynamic range and contrast ratio... why 3d software reads in the linear dataset the way it does is beyond me :shrug:

[ThirdEye]

Originally posted by MJV
What is the reason that HDRShop uses a gamma value of 2.2? Why would it do that? Are you saying that all those images are more contrasty than they should be? How do you know? Changing the contrast of HDRImages should change the result for sure, possibly producing more pleasing images, but I don't understand where the claim that they are wrong comes from. By definition HDRImages have an enormous dynamic range. Not that I'm doubting you, but I just want to understand better. Thanks.


check this old thread, there was an interesting discussion going on there, pay attention to TheRipper's post, i learnt it from his post and tested on 8.5, judging on the results he was right, to be sure do this: open a hdr pic in the material editor of C4D and open it in hdrshop as well, you'll immediately see the difference

http://www.cgtalk.com/showthread.php?s=&threadid=55726

[MJV]

Originally posted by ThirdEye
check this old thread, there was an interesting discussion going on there, pay attention to TheRipper's post, i learnt it from his post and tested on 8.5, judging on the results he was right, to be sure do this: open a hdr pic in the material editor of C4D and open it in hdrshop as well, you'll immediately see the difference

http://www.cgtalk.com/showthread.php?s=&threadid=55726

Ok, so you're just repeating what someone else said, but how do they know? And again, why would HDRShop do that? I can believe that changing the gamma of an illumination image will produce different results, but I'm not convinced that it's more right than the other.

[chris_b]

One place you might get a clear answer why HDR shop uses a default gamma of 2.2 is the HDR shop website forum:

http://athens.ict.usc.edu/HDRShop/ (http://)

... or maybe try e-mailling Paul Debevec or Greg Ward?

Does anybody on the beta team (ThirdEye/Kai) know whether HDRI output is
being considered as a feature?

[ThirdEye]

Originally posted by MJV
Ok, so you're just repeating what someone else said, but how do they know? And again, why would HDRShop do that? I can believe that changing the gamma of an illumination image will produce different results, but I'm not convinced that it's more right than the other.


Trust Stanford if you're not sure about what i say, let's hope Stanford is enough :D

http://www.stanford.edu/~pramodpk/HDR-Imaging/High_Dynamic_Imaging.html

[AdamT]

When you create an HDRI in HDRShop you have the option of choosing the gamma level, which depends in large part on the calibration of your camera lens. I don't know why it uses 2.2 as the default.

[LucentDreams]

Going along with michael I wouldn't say its right or wrong. However I do feel that the result as thirdeye has achieved is much more pleasing, whether its "right" or "wrong"

I hate right and wrong accurate and fake. To me what looks good is right because it looks good.

Using a few lights for SSS effects in a scene lit by HDR may be "wrong" but if it looks good who cares.

[MJV]

Originally posted by Kaiskai
Going along with michael I wouldn't say its right or wrong. However I do feel that the result as thirdeye has achieved is much more pleasing, whether its "right" or "wrong"

I hate right and wrong accurate and fake. To me what looks good is right because it looks good.

Using a few lights for SSS effects in a scene lit by HDR may be "wrong" but if it looks good who cares.

That's true, and I agree in principle, but I also like to know why something is. Curious that there would be this huge glaring error in HDRShop. The reflections seem accurate, and to me it seems that this solution is all about getting a less contrasty HDRI, which may produce more pleasing results largely because the radiosity can handle it better, but may not be the most accurate portrayal of the environment. Call it an academic interest.

[astrofish]

Ok, I think I've (partially, as least) got to the bottom of this.

All quotes from HDRShop hompage.

HDR images also have the important property that their pixel values are proportional to the amount of light in the world corresponding to that pixel, unlike most regular images whose pixel values are nonlinearly encoded.

and

If the image loaded is a high-dynamic range format, it loads up instantly. However, if you are loading a low-dynamic range format, HDR Shop pops up the "Specify Camera Response Curve" dialog:
The reason for this is that HDR Shop stores image pixels internally as numbers relative to the amount of light they represent. Unfortunately, the 8-bit pixel values in most traditional images don't have this property. For example, in a jpeg, a pixel of 200 is not twice as bright as a pixel at 100. In fact, in most formats, it is over four times as bright. The standard mapping (on PC's at least) is called a gamma 2.2 mapping. This means you take the pixel value and raise it to the 2.2 power to get a number proportional to the amount of light.


So, HDRs do store each pixel linearly in floating point format. I.e. if the HDR is properly created, then the values in it should be directly proportional to the amount of light energy.

However, when _creating_ a HDR from standard low-dynamic range (LDR) images, you have to tell HDRShop what the gamma of the LDR images is. LDR images often use gamma in order to make the limited number of values they can store represent a wider range of intensities. HDRShop needs to know what the gamma was so that it can calculate what the true intensities were, so that it can combine images properly.

Completely seperate to this is the display gamma. This is used by HDRShop (together with the exposure settings) to compensate for your monitor response, and shouldn't affect the hdr files it produces.

Now, if you attempt to make a HDR image using LDR images which are actually linear (or just less than 2.2 gamma), but you go with HDRShop's default assumption that they have gamma of 2.2 then HDRShop will wrongly interpret the LDR images as being much brighter than they should be, and after combining would end up with the HDR image itself effectively having something approximating gamma. Telling C4D to apply a gamma correction to this HDR file would then improve the results significantly, but the problem was that the HDR file itself was wrong.

If your HDR images have been put together correctly in the first place, then they should be linear already, as stated in the first quote from HDRShops's webpage, and no correction should be needed.

Regarding 'right or wrong', I agree that if you can come up with an image that you like, then it doesn't matter how you did it. However, if your images aren't looking like what you were expecting, then understanding what is happening is the first step to fixing it. In other words, there's nothing wrong with things being 'technically wrong', as long as they are deliberately wrong.

Cheers - Steve

[lllab]

"A great extension of Cinema's HDR support would be to allow rendering
to 96 and 128 bit formats (.hdr, .exr, floating point TIFF... etc). Maxon could build in an exposure/gamma adjustment tool (perhaps in the Picture Viewer).
To allow the user to make post-render adjustments to the image before it is clamped down to 8 or 16 bit for export."

chris B, that would be excellent!

i also already thought there shoud be an option to save unclamped images out of cinema, as far as i know, cinema uses internal 96bit per channel. imagine what superb controll for post adjustment we would have with that!

we should bring this as suggestion to maxon.

cheers

lllab

[astrofish]

Originally posted by lllab
"A great extension of Cinema's HDR support would be to allow rendering
to 96 and 128 bit formats (.hdr, .exr, floating point TIFF... etc). Maxon could build in an exposure/gamma adjustment tool (perhaps in the Picture Viewer).
To allow the user to make post-render adjustments to the image before it is clamped down to 8 or 16 bit for export."


That would certainly be very nice...

Cheers - Steve

[chris_b]

It would be even better if in addition to levels and gamma adjustments, you could apply specific film response curves and stock grain types (i.e. you could get the look of Kodak EK 35mm, or Fujicolour 16mm)... something like the similar features in Shake and Combustion. It would be like a virtual film lab. :drool:

Has anyone here tried working with Cinema's RLA and RPF export? I have noticed that there is an option in there to export "Non-Clamped Color". Is that just 16bit per channel or is it something else?

I wonder whether there is some technical reason why this option (HDR output or renderings) isn't available yet?

PS... Astrofish... thanks for GeomCheck, it is a really handy plug :)

[lllab]

"It would be even better if in addition to levels and gamma adjustments, you could apply specific film response curves and stock grain types (i.e. you could get the look of Kodak EK 35mm, or Fujicolour 16mm)... something like the similar features in Shake and Combustion. It would be like a virtual film lab. "

yeah, this is what i meant, it would be like a photolab or some highend video editing:-)

srek or somebody from maxon, what do you think about chris b's idea?

thanks

lllab
stefan

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.