Valley of the Shadow of Death or Size does matter at least for Iray

jag11

Because if we are using a physically based rendering technology we want to take advantage of the full capabilities, don't we?

It is relevant because I'll help you understand how does the Iray black box works, unless that is not relevant.

 

agent unawares

We were discussing this point:

jag11 said:

DS is applying gamma correction in the other direction, I know, this is disturbing.

DS appears to be applying gamma correction correctly based on what gamma you tell it textures have, there's no "other direction" happening. A straight flat color discussion isn't relevant as DS does not handle those the same as textures, like most renderers you need to use the linear values from the start, it will not linearize them for you if you enter sRGB float.

jag11

agent unawares said:

. A straight flat color discussion isn't relevant as DS does not handle those the same as textures, like most renderers you need to use the linear values from the start, it will not linearize them for you if you enter sRGB float.

Wrong, DS does handles colors in textures the same as colors you select in the Select Color Dialog. So, back to the relevant question, what color values should you provide if I want to render a Sphere the same orange color provided earlier. 

 

 

jag11

Come on, guys, don't leave agent unawares alone...

prixat

On your original post you mention 800 Lumens but don't say the size of the light?

jag11

prixat said:

On your original post you mention 800 Lumens but don't say the size of the light?

100 centimeters, when you specify lumens they get evenly distributed on the size of the geometry...

 

Richard Haseltine

jag11 said:

When Using consistent measure units, lights, distances and exposure values give better images almost naturally, very low effort. I noticed that if I adjusted an EV and later added another light to the scene I had to re adjust EV. Now I add more lights and I can keep my EV the same, no need to readjust.

Try creating a 800 lumens light placed at 240 centimeters from the ground, also place a ground, add a camera and set your EV at 13 and ISO as 100.

in real world you would get a nice clear image of the ground, but Iran gives a black image, Now if you do the same and only change the units to 1%! You get a nice clear image. The proper way to test this is create a group node to wrap the objects and the camera. Now, selecting the group node, apply change scale from 100% to 1%. Render. You should see the clear image, the inverse square law is working as expected.

Try adding more 800 lumens lights separated by say 200 centimeters, your EV should still be valid.

By the way, I advice googling some light equivalence charts to use real world lumens values in your scenes.

I just did this - 800 Lumens should be about the light level in my desklamp, so I switched the room light off and took a photo at shutter 1/125, f 8.0, ISO 100. It was almost fully dark (even though my monitor was stil on so the light level was probably a bit higher).

nonesuch00

I use 800 Lumen LED bulbs in every light fixture in my house and they are good for general lighting but not really great for reading. Also, although they are rated for many, many hours that winds up being years, the lumen output does degrade on them overy time although they don't burn out like an old fashioned incandescent bulb. They aren't 800 lumen for 20 years and then on the 1st day of the 21st year they burn out.

The FHD monitor I'm using is LED and I've had it for 12 years now, although I think it's backlit with some sort of CFL bulbs or something.

barbult

I enjoy the back and forth discussion and hope it leads to understanding and agreement eventually. Keep on keeping it civil so mods don't get annoyed. 

Richard Haseltine

jag11 said:

When Using consistent measure units, lights, distances and exposure values give better images almost naturally, very low effort. I noticed that if I adjusted an EV and later added another light to the scene I had to re adjust EV. Now I add more lights and I can keep my EV the same, no need to readjust.

Sorry to be doing this piecemeal - you should need to adjust the EV to keep the overall tone if you add or remove lights, EV is a summary of ISO, shutter speed, and f-stop all of which admit a certain amount of light. I wonder if you are being confused by the exposure adjustment setting on cameras, which is not an absolute value but an offset from the automatically generated value - so if you take a shot in a dim room or a bright garden an adjustment of -1 will make the shot darker and an adjustment of +1 will make it lighter; however, the absolute exposure value (if it's given, or if you get shutter speed, ISO, and f-stop and feed them into the EV formula) will be radically different between the two situations.

agent unawares

jag11 said:

agent unawares said:

. A straight flat color discussion isn't relevant as DS does not handle those the same as textures, like most renderers you need to use the linear values from the start, it will not linearize them for you if you enter sRGB float.

Wrong, DS does handles colors in textures the same as colors you select in the Select Color Dialog.

Weird hill to die on since you're dead wrong, buddy. ;)

On the left is a plane colored by a texture flood filled in photoshop with RGB 108,138,70

On the right is a plane filled with the same color in DS, entered as an sRGB float (theoretically exactly the same as the texture, since the texture is in sRGB).

As you can see, DS is not treating the color fill the same as the texture fill, because DS does not know how to linearize it. DS does not know how to handle a color space for one color. It only knows how to handle this for textures.

And again.

On the left is a plane colored by a texture flood filled in photoshop with RGB 108,138,70

On the right is a plane filled with the same color in DS, except I linearized it, by hand, and entered it as linear float.

And what do you know, it's suddenly correct!

DS does not handle colors the same as textures. This is normal behavior for a renderer since a color cannot store gamma information. Questions?

jag11

Guys, I'm back.

I'm a providing two test scenes, one with the nice orange color mentioned before, the second with the color provided by agent unawares. Each correspond with the images below.

Reference colors:

Orange: 245, 146, 5

Green:  108,138,70

The scene setup correspond to the recommended setup to calibrate any given camera using one of the devices for that purpose.

Please open any of the scenes, the lighter spheres(the ones of the left of each image) correspond to the original colors both agent unawares and I reference. Also, I am providing image tiles corresponding to the colors, one for orange, one for green.

Notice the spheres surfaces specify RGB color values only, no textures. The left spheres on each scene use the unmodified RGB color referenced, the right spheres use an adjusted RGB version of the color.

Now, if we are in linear space, only one sphere should resiste color burn, so, in the tone mapping settings, set Burn Hightlights to the max (1.0), which sphere performed better to the burning?

agent unawares claims:

DS does not handle colors the same as textures.

I claim: DS treats both color and textures the same, so, the adjusted RGB colors I provide prevents this correction so colors render faithfully.

Here is the link to the test scene.

Please comment your observations.

 

jag11

Forgot to ask, Which sphere ressembles the referenced RGB colors?

agent unawares

Jag, if you have to adjust RGB colors to make them match corresponding textures, DS is not treating colors the same as textures.

nonesuch00

Well I just added the RGB colors for the orange & the green in Gimp & it matches the orange & green sphere over the while ceramic tiles on the viewer's right in your render above. 

agent unawares

jag11 said:

Now, if we are in linear space, only one sphere should resiste color burn

??? The colors in sRGB are going to get more messed up highlights because they're literally lighter colors. They don't actually correspond to the spheres on the right, they're much much lighter colors because they're meant to be entered as linear, and you entered sRGB colors. If I take a photo of a white thing and a black thing, the white thing is going to blow out first. This is what you are doing here. This has absolutely nothing to do with whether DS is handling gamma correction correctly.

agent unawares

Bonus question, if DS is not handling gamma correction on textures properly, why is my textured plane accurate?

agent unawares

Bonus bonus question, if DS is not handling gamma correction properly, when you flood fill a texture with one of those RGB colors and add it to the sphere in your test scene, why is the sphere accurate?

agent unawares

Okay, I finally got the scene to download.

You're...not actually using the correct linear and sRGB colors. You're using darker ones. You can't enter RGB into the picker, DS will assume you want it converted to linear float and do that for you, so your sRGB float never actually gets entered. You have to actually enter them into the color by right clicking the color bar.

This is the actual sRGB float for the green: 0.4235 0.5412 0.2745

This is the actual linear float for the green: 0.1510 0.2591 0.0582

This is the actual sRGB float for the orange: 0.9608 0.5725 0.0196

This is the actual linear float for the orange: 0.9158 0.2932 0.0002

 

Rounded of course so there are tiny errors.

agent unawares

So here's your scene featuring the green spheres, using the correct values.

What's that? None of them match? That's because the scene is in really bright sunlight and the correct exposure for shooting in bright sunlight is actually about 15 EV.

But we already knew that lighting affects the ultimate color of an object, and I already demonstrated that you have to use the linear float to get a color that matches a texture properly, so now I'm really just questioning what all this has to do with DS supposedly correcting gamma wrong. This still looks completely accurate to me.

Oh, here's the last scene but the ball on the left has the matching texture.

Doesn't look incorrect, looks in fact exactly like DS is taking the image and linearizing it just like we did to the straight color, only automatically.

agent unawares

And one more. This is the same image as my last, but the texture has Image Gamma 4.4.

I'd like to state for the record that using Image Gamma 4.4 clearly overcorrects and does not match the linear color next to it.

agent unawares

I lied, one more.

This is the same as my recent images, but the Image Gamma is set to 1 to tell DS the texture is already linear. This way DS doesn't linearize it.

And of course it matches the earlier image with the color that hasn't been linearized next to the color that has been correctly linearized.

All this clearly indicates that DS correctly linearizes textures, since its results correcting the texture match our hand-calculated color values.

barbult

agent unawares said:

Okay, I finally got the scene to download.

You're...not actually using the correct linear and sRGB colors. You're using darker ones. You can't enter RGB into the picker, DS will assume you want it converted to linear float and do that for you, so your sRGB float never actually gets entered. You have to actually enter them into the color by right clicking the color bar.

This is the actual sRGB float for the green: 0.4235 0.5412 0.2745

This is the actual linear float for the green: 0.1510 0.2591 0.0582

This is the actual sRGB float for the orange: 0.9608 0.5725 0.0196

This is the actual linear float for the orange: 0.9158 0.2932 0.0002

 

Rounded of course so there are tiny errors.

I've been trying to follow this, but you lost me here. If DS converts the entered sRGB values to "linear float", why are the DS-converted values not the same as what you describe as the "actual linear float" values? Can you please explain a little bit more for those of us struggling to comprehend?

jag11

When the texture is read by hardware it is in gamma space, to convert to linear space you apply the Math.pow(x, 2.2). When you provide a sRGB color it is in gamma space, it has to be converted to linear space, same formula. Now that you have your input textures(or colors) converted to linear space that does not mean that it is valid linear data to the renderer. Why? because it is pre-corrected.

From the GPU Gems 3:

24.3.1 Nonlinear Input Textures

The average user doesn't have a calibrated monitor and has never heard of gamma correction; therefore, many visual materials are precorrected for them. For example, by convention, all JPEG files are precorrected for a gamma of 2.2. That's not exact for any monitor, but it's in the ballpark, so the image will probably look acceptable on most monitors. This means that JPEG images (including scans and photos taken with a digital camera) are not linear, so they should not be used as texture maps by shaders that assume linear input.

This precorrected format is convenient for directly displaying images on the average LCD or CRT display. And for storage of 8-bit images, it affords more "color resolution" in the darks, where the eye is more sensitive to small gradations of intensity. However, this format requires that these images be processed before they are used in any kind of rendering or compositing operation.

Here is the link for those interested in learn from the big dogs.

This was the book that opened my eyes.

agent unawares

barbult said:

agent unawares said:

Okay, I finally got the scene to download.

You're...not actually using the correct linear and sRGB colors. You're using darker ones. You can't enter RGB into the picker, DS will assume you want it converted to linear float and do that for you, so your sRGB float never actually gets entered. You have to actually enter them into the color by right clicking the color bar.

This is the actual sRGB float for the green: 0.4235 0.5412 0.2745

This is the actual linear float for the green: 0.1510 0.2591 0.0582

This is the actual sRGB float for the orange: 0.9608 0.5725 0.0196

This is the actual linear float for the orange: 0.9158 0.2932 0.0002

 

Rounded of course so there are tiny errors.

I've been trying to follow this, but you lost me here. If DS converts the entered sRGB values to "linear float", why are the DS-converted values not the same as what you describe as the "actual linear float" values? Can you please explain a little bit more for those of us struggling to comprehend?

The DS converted values are the actual linear float values. Problem is Jag used those converted values as sRGB float values and then calculated "new" linear float values from that, which is not correct.

You get the sRGB float values just by dividing RGB values by 255. Then you can convert those yourself to linear by doing value^2.2, or you can just enter the RGB into the DS color picker for linear.

agent unawares

jag11 said:

When the texture is read by hardware it is in gamma space, to convert to linear space you apply the Math.pow(x, 2.2). When you provide a sRGB color it is in gamma space, it has to be converted to linear space, same formula. Now that you have your input textures(or colors) converted to linear space that does not mean that it is valid linear data to the renderer. Why? because it is pre-corrected.

Sure, textures in theory might be better if they were linear from the start, but this has nothing to do with DS handling gamma wrong, and none of this implies we should be telling DS our Image Gammas are all 4.4.

This means that JPEG images (including scans and photos taken with a digital camera) are not linear, so they should not be used as texture maps by shaders that assume linear input.

The important part of that is not what you highlighted but this bit: "they should not be used as texture maps by shaders that assume linear input." DS does not assume linear input, it does gamma corrections based on Image Gamma which is pretty standard for modern renderers, exactly what this a bit later is talking about:" "this format requires that these images be processed before they are used in any kind of rendering or compositing operation."

Sincerely, I think you should read even more on this since your float values weren't even converted correctly. In retrospect that isn't fair, it's easy to assume DS actually used straight numbers from the color picker if you don't check, but advocating that Image Gamma should be 4.4 and that Image Gamma corrects "backwards" is just so very divorced from how this actually works.

jag11

agent unawares said:

Sincerely, I think you should read even more on this since your float values weren't even converted correctly. In retrospect that isn't fair, it's easy to assume DS actually used straight numbers from the color picker if you don't check, but advocating that Image Gamma should be 4.4 and that Image Gamma corrects "backwards" is just so very divorced from how this actually works.

With all due respect, I don't think I should be reading more, check that list of books I bought recently, I also attend to courses, every month or so, so I think a might have learn a thing or two.

agent unawares

jag11 said:

agent unawares said:

Sincerely, I think you should read even more on this since your float values weren't even converted correctly. In retrospect that isn't fair, it's easy to assume DS actually used straight numbers from the color picker if you don't check, but advocating that Image Gamma should be 4.4 and that Image Gamma corrects "backwards" is just so very divorced from how this actually works.

With all due respect, I don't think I should be reading more, check that list of books I bought recently, I also attend to courses, every month or so, so I think a might have learn a thing or two.

Look. Here's a quote from that same exact page of the GPU Gems book you quoted to me earlier.

Texture lookups can apply inverse gamma correction so that the rest of your shader is working with linear values.

This is exactly what DS is doing, and you are arguing for some reason that this is wrong based on the same book. So, frankly, read it again.

Also, wow, absolutely nothing on that book list is about texture math. Wait a minute while I photo all my chemistry and math books, surely those are as relevant. :P

Richard Haseltine

I'm going to make an official request to correct the thread please, things are getting a bit of an angry red hue.

nonesuch00

Sorry, I've been reading along and although I don't have the source code from DS and reference books to say with 100% certainy, I think the agent unawares is correct in how they say DS is treating gamma based on their examples and explanations.