Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.Daz 3D is part of
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
select the object in the Scene pane.
In the Parameters pane, set the x y and z to 0.
There may be another way.
>8eos8
I can confirm it too.:)
the gamma in image editor of DS 4.8 beta can work about 3delight render with shaders.
But about Iray and iray uber shader, I can not find any difference , between two rendered images when I tweak
specular and cut-off opacity texture gamma in ds image editor.
it seems not work which supposed to be.
I had tested with 3delgit to check which value seems best for hair opacity texture, with gamma correction render.
today I test same hair for I-ray shader and render, then compare in render editor,
(gamma 0, gamma 1.0 gamma 0.7 etc)
about 3delgiht render, I could easy find diffrerence .
but about i-ray render (with I-ray base shader) it cause no differende.
if subtract and compare two images in render editor, simply keep all black.
After DAZ cleaned up old mantis bug report ,
I do not know how to add coments and check if there is already same bag report or not.:roll:
can I see other guys report still ?:roll: (before I could check othere reports and add coments easy)
=================
I know about non color data , we may set gamma 1.0 (it means not add reverse gamma correction)
but it simply circulate each texture correctly in linea space.
it does not mean, it can show the vendor supposed effect about opacity or splecular map
which made for non gamma correction render.
I believe vendor should adjust contrast etc with their test render image to achieve what they hope .
most of products textures have not been made for gamma correction render.
The iray development team give what they consider the ideal tonemapping settings for working with LPE at their blog. I won't lecture anyone on what I consider to be a major clue.
http://blog.irayrender.com/post/76948894710/compositing-with-light-path-expressions
added: To clarify, this is what I see as best practise for non-destructive rendering that will undergo postwork in the likes of Photoshop or Fusion (now available for free), where we can tonemap and regrade the render to death.
https://www.google.co.uk/#q=fusion+tonemapper
https://www.blackmagicdesign.com/uk/products/fusion/compare
Could you define "working as intended"?
Because as far as I know, we don't know what's intended.
The gamma switch in the image editor is intended for 3Delight, and it basically has three positions: 0,1 and 2.2. And that is used in conjunction with the Gamma Correction On/Off switch in the 3Delight render settings.
Nowhere have I seen anyone say that these settings are at all relevant for rendering in Iray or how to apply them.
What are the odds that settings specific to one render engine are going to be at all relevant for another? Don't we have completely separate render settings for each?
Or course, I could be utterly wrong and the DAZ devs may very well be using those switches in exactly the same way... which, for completeness' sake we'll define here: 0 means GUESS if this texture ought to have anti-gamma applied, 1 means don't do anything with this texture and 2.2 (or some other number might be here on rare occasions I guess) which means this texture has a gamma value of 2.2 please anti-gamma it.
Also, we have no idea if Iray has a method of applying anti-gamma. I've not been able to find anything that states this with any certainty.
Jimbow makes a solid point referencing the Iray devs, but its an inference. not a conclusive point. We can infer from this post that the ideal is to render in linear space with multiple passes (canvases) and then post process/composite our work. And for true, high-end, production level rendering... well, hell, that's what we ought to do (Hey, I read Jeremy Birn too). Please note, that nowhere in this blog post is the actual issue of gamma correction specifically raised. The post primarily talks about a linear output. It never once discusses how we are achieving a linear INPUT. We can infer that we have somehow gotten one... but we have no idea how.
We are primarily a community of hobbyists, and we are not taking it to the level of this post most of the time. Most of us just want to create something that pleases us and maybe makes our friend and families go: "wow".
I realize this is still a beta, but... tell us, please. How the hell does this work? Its important.
He he... I filed a crash/bug report about a week ago and detailed everything I did up to the point where it crashed. I got a response, and the tech wanted me to detail what I did up to the point where it crashed. :D
Well I got my automated response back for the new bug report, so I guess that's a good sign, heh. (And I used to work in tech support, and I'd always have the opposite problem, I'd get a caller saying "it doesn't work! Fix it!!" and then it was like pulling teeth trying to get any details outta them. :))
Could you define "working as intended"?
Because as far as I know, we don't know what's intended.
The gamma switch in the image editor is intended for 3Delight, and it basically has three positions: 0,1 and 2.2. And that is used in conjunction with the Gamma Correction On/Off switch in the 3Delight render settings.
Nowhere have I seen anyone say that these settings are at all relevant for rendering in Iray or how to apply them.
What are the odds that settings specific to one render engine are going to be at all relevant for another? Don't we have completely separate render settings for each?
Or course, I could be utterly wrong and the DAZ devs may very well be using those switches in exactly the same way... which, for completeness' sake we'll define here: 0 means GUESS if this texture ought to have anti-gamma applied, 1 means don't do anything with this texture and 2.2 (or some other number might be here on rare occasions I guess) which means this texture has a gamma value of 2.2 please anti-gamma it.
Also, we have no idea if Iray has a method of applying anti-gamma. I've not been able to find anything that states this with any certainty.
Jimbow makes a solid point referencing the Iray devs, but its an inference. not a conclusive point. We can infer from this post that the ideal is to render in linear space with multiple passes (canvases) and then post process/composite our work. And for true, high-end, production level rendering... well, hell, that's what we ought to do (Hey, I read Jeremy Birn too). Please note, that nowhere in this blog post is the actual issue of gamma correction specifically raised. The post primarily talks about a linear output. It never once discusses how we are achieving a linear INPUT. We can infer that we have somehow gotten one... but we have no idea how.
We are primarily a community of hobbyists, and we are not taking it to the level of this post most of the time. Most of us just want to create something that pleases us and maybe makes our friend and families go: "wow".
I realize this is still a beta, but... tell us, please. How the hell does this work? Its important.
It works as it should. All renderers should be feed the same. There is no difference on that. The goal is to send pictures at gamma 1
The slider is used to tell DS the gamma of the input image in order to apply correct degamma. You can enter other values than 0;1 or 2.2
If the value is 0, the DS will try to guess
Below are simple test with the Genesis Jeremy texture on a diffuse ball. Renders with input image gamma = 0, 1, 2.2 and 4. Final render output gamma = 2.2
With Gamma = 0 DS guessed right.
With Gamma = 1 DS doesn't linearize the input resulting in a lighter skin color
With Gamma = 2.2 we give the correct gamma so the output is correct
With Gamma = 4 we give an incorrect information thus having a (wrong) darker skin
The only unkown is how DS guess the input gamma when you set it to 0. My opinion on that is that there is no way that it could be 100% correct. So if you know the input gamma, set the value
The only bug I've found is that changing parameters in the image editor doesn't trigger a new Iray render in the Viewport. That may be the problem 8eos8 is having
The iray development team give what they consider the ideal tonemapping settings for working with LPE at their blog. I won't lecture anyone on what I consider to be a major clue.
http://blog.irayrender.com/post/76948894710/compositing-with-light-path-expressions
added: To clarify, this is what I see as best practise for non-destructive rendering that will undergo postwork in the likes of Photoshop or Fusion (now available for free), where we can tonemap and regrade the render to death.
https://www.google.co.uk/#q=fusion+tonemapper
https://www.blackmagicdesign.com/uk/products/fusion/compare
Should I mention that there is now a free version of Nuke?
Takeo, thanks for posting that.
We still don't have any sort of confirmation from DAZ that the same mechanism is used, but your example seems to suggest that for color textures it is at least working the way we expect it to (the same as 3Delight, which is awesome).
Others are suggesting that control maps, that ought not to be changed, are not working as intended.
My take on that is that we are not feeidng a proper input.... sending rgb images instead of grayscale. GIGO.
Very interesting and informative comments, folks. Thanks. I'm so inexperienced with DS itself I didn't even think of the image editor for texture gamma correction.
I saw the post you're talking about.
I don't see a problem if sending a rgb map instead of a grayscale as long as what is sent is linearized. On the other hand, there may be a problem if the texture has a specified gamma of 0, which means DS has to guess the correct value, and that the "guessing algorithm" assumes a gamma of 2.2 if it detects a RGB map and then process a de-gamma with value 2.2. That would explain why some users had better result by adjusting the texture gamma to 2.2 with a 2D app, as it would be then processed by DS with a degamma of 2.2 and you'd get the correct texture linearized at gamma 1
It would be easier and quicker to specify Gamma=1 to correct the problem if I guessed right
You just did.
You just did.
Was a rhetorical question lol
I wouldn't know. I don't do rhetorical, only lots of questions.
Have you guys tried converting a control map to at least 16-bit floating point? Maybe then the guess algorithm will work correctly?
I just tested Takeo.Kensei's suggestions on the BBC test card scene I did yesterday. Both test cards now match by changing the gamma value for the right hand card from 1 to 0.4545 (a bit of difference in the blues and Carole's skin tones, probably due to only four decimal places). I still prefer the lighting on the spheres and the background saturation and range of luminance at render gamma 1, but that's possibly job influenced as I often work to a working grade and hand over to compositors or graders who implement the final look.
Many thanks for the nugget.
I used EXRs yesterday and it guessed wrong.
I used EXRs yesterday and it guessed wrong.
I think we need one of the devs to step in and say how Studio reads and decides what to do with the files. Because there seems to be no real logic to it. It's not a pure location based guess, because if it was, the control map slots wouldn't have wrong guesses. It's also not based on file type...because it doesn't really matter what the file is...I've had wrong guesses on hdr, exr, tif, png, jpg (haven't tried any bmp or or other supported formats). And bit count doesn't seem to matter.
Whether or not the file is 'color' or b/w...and set somewhere in the file itself (like file header or other internal file data), is what seems to matter most.
If image editor (in ds 4.8) gamma setting with iray lender (and iray uber shader)
only work with nvida GPU?
how I tweaked it about base color map, or non linea color etc,
the rendered image cause no diffrence. I just keep tone mapping gamma 2.2. (it is my monitor seting, simple)
If I find a bug, how should I report it?
For bug reporting. That said you may want to check the change log first to see if it is one they have already sorted. We have version .09 and they are on .32. You will need to scroll way down to see the newer logs. http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log
..whoops...wrong thread...
Well I got my automated response back for the new bug report, so I guess that's a good sign, heh. (And I used to work in tech support, and I'd always have the opposite problem, I'd get a caller saying "it doesn't work! Fix it!!" and then it was like pulling teeth trying to get any details outta them. :))
Yeah. Been there, done that... One of the reasons I try to be as detailed as possible. lol And I really do appreciate the help we get from tech support. It's not an easy job.
Will the "pin" tool be improved with this new version? Will we be able to better animate characters in situations where we want the feet to remain planted in one place?
Is it me, or does Iray seem to struggle a bit with subdivision of meshes. It seems to take a long time to calculate them before starting to render, regardless of whether that subdivision is set up in an objects parameters Mesh Resolution settings or the Iray shader subdivision settings. That is where I have seen the most 'bogging down' when I click render. I've seen it take hours to calculate the subdivision, taking up more and more ram until it finally can process what it need, before finally starting the convergence process. The more detailed objects, with displacement maps take a long time to deal with, and because of this its hard to test shader presets.
For bug reporting. That said you may want to check the change log first to see if it is one they have already sorted. We have version .09 and they are on .32. You will need to scroll way down to see the newer logs. http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log
Thanks!
How does one go about makinging an Ambient light that works in Iray? I have noticed that only photometric lights seem to work so things like Age of Armor's Ambient lighting don't seem to work, on the same note dtying to make a photometric point light room filling seems to be a pain. However, there is a chance I am missing something
There are no ambient lights as such, but you can make any object emit light (like mesh lights, but, IMO, easier), and set various environment lights (sun, or put in an environment map that will glow from all over depending on the image).
If there's going to be light on the scene, it generally has to come from something.
It takes some adjustment, but after having played with it for a month, I find it way easier to manage than 3Delight style lighting
Increase the luminous flux and intensity as needed. You can exceed the max parameters by clicking on the gear for the settings and entering new maximums. Of course, that's still not an ambient light. :)
...sounds like they need something to fill that void. I usually just create a large off camera softbox using a plane primitive.
They don't work, because they're made to work in 3Delight, not Iray.
It's a major difference in the way lighting works — 3Delight has to fake real-world lighting, with workarounds like the AoA Advanced lights. Iray, on the other hand, doesn't have to fake anything, it just does real-world lighting. It's a completely different way of lighting your scene, so we'll all have to re-learn how to do it if we want to use Iray.
Don't forget, though, Iray is only the new default render setting; you can still change back to 3Delight, and all the lighting sets in your content and techniques you've learned will still work.