Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
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.
We were discussing this point:
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.
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.
Come on, guys, don't leave agent unawares alone...
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...
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).
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.
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.
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.
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?
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:
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.
Forgot to ask, Which sphere ressembles the referenced RGB colors?
Jag, if you have to adjust RGB colors to make them match corresponding textures, DS is not treating colors the same as textures.
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.
??? 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.
Bonus question, if DS is not handling gamma correction on textures properly, why is my textured plane accurate?
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?
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.
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.
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.
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.
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?
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:
Here is the link for those interested in learn from the big dogs.
This was the book that opened my eyes.
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.
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.
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.
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.
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
I'm going to make an official request to correct the thread please, things are getting a bit of an angry red hue.
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.