Adding to Cart…

Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.You currently have no notifications.
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
Looks that I am the kid here being that I turn 43 next month. While I was very good with math as teenager, completing my first two years of college math credits while still in high school (algebra, trig, and calculus), I have certainly waned in the years since, mostly from being lazy and allowing computers to do the math for me.
What I get a kick out of is that if you had asked my school art teachers if I would ever be doing anything in art other than photography, they would laughed uncontrollably and needed an asylum themselves.
Did you guys happen to see this fix mentioned in the changelog for the new public beta (4.9.0.54)?
Wonder what was it being measured in before?
Looks like some lighting fixes are in there as well.
http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log
Umm... parsec.

I guess they might still were set on the MDL standard, meters.
Gonna be 55 Jan 13th, hated math as a kid, hate it as an adult. Plus I deal with ADHD and a slight issue with dyslexia. I'm amazed I funtion at all sometimes! lol
lol
do you see a theme building with our ages...interesting
You guys have done some brilliant work here. I can't say I understand it all, but I can put enough pieces together to employ some of it; and for me, at least, it really is filling in some of the missings pieces.
Now if I could just understand why it is that some textures sets just render so much better using settings like this...the majority of textures just don't seem to cut it. Why is that? And is there something that can be done about it.
Well...one key area where the image maps can 'look' good on screen but fall apart when fed to a renderer is the fact that most of them are jpgs. The JPEG format is not very PBR friendly (not an ideal format for any kind of renderer, really). Between the compression (lossy) and included gamma information there is much more that can go wrong, once fed to a renderer that makes faults stick out like a sore thumb.
While I can certainly understand that, both the good and the bad are delivered in that format.
Would there be any benefit, do you think, to resaving them in a different format? Or is that just spitting into the wind?
Many diffuse textures in JPG are to much compressed.(i use maximum quality and my textures are always larger in filesize then the ones i buy )..to save ram... some will use wrong ICC Profiles (20% dot is right).. and many Authors will open and save the images many times in different softwares and that adds to compression loss massiv!
When you paint in a 3d softare - save as JPG .. open in Photoshop - save again... the loss can be seen allready by eyes if you use not the maximum quality .....
Next for best quality the colors should only use 0.9 for fresh snow to about 0.04 darkest possible material).... no full blacks.no full whites in RGB = .. (natural Albedo)...
For Skin the color range (contrast) is usally way to much - the texture should look relative FLAT.) if there is only skin dosent matter which color, spots or scares... albedo differences are very narrow !.
Here is a REAL albedo (diffuse) - a PHOTO...(ignore the black spots)
EDIT: colorprofile missmatch... R 210-230, G 160 - 170, B 140 -150....
if i measure the color values .... EVERYTHING is in the range of R 200 - 220, G 140 - 155, B 120 - 133...
the color range (contrast is only about 18%)
DAZ texures use 50 - 80 % easy
In addition to what Andy and mjc said above, I find that the bump maps, almost as a standard rule, are horrible. 95+% of the time, all the artist did was convert the diffuse map to grey scale and then maybe invert it, causing it to not resemble anything close to the actual micro details of human skin. When normal maps are provided, to me they generally look like a bump map that was run through an automatic conversion instead of a normal map that was created from actual high subdivision sculpting.
That's absolutly correct... normal maps for very small details - can NOT get created from Bumps for microdetails - while they LOOK better for wrinkles and large pores - very small details can not be there (beause of not enough pixel (missing) geometry infos in the bump..
i tested my bump raster grids (experiment) - they dont convert usable to a normal map!..
ok, that's all good information. But is there something that can be done to help these textures along? Not all of us are capable of making our own textures or have the time to spend learning how and then doing it. I've sworn off buying from certain vendors, but the best vendors don't produce as often and rarely do they make textures for the models I want them too :(
Converting to another format is a waste of time...because the loss of quality has already happened and can't be regained. Same with overly compressed files...lossy compression basically means it's gone forever. Correcting the colorspace problems is doable, but that's about it.
Adopting a new image format from start to download...tif, png, exr...even the newer jpg2000. But that won't fix old image maps. Just ensure the new ones don't have the same problems.
Adjust/play with surface settings and render settings to get them looking the best you can and hope it's enough...while not a very satisfying answer, is about the only one there is, if you aren't going to be making your own.
The problems with the textures aren't limited to Iray (or Octane or Luxrender), but also show up in 3Delight...especially now that raytracing is the 'expected' way to render.
And that's not even counting, especially on textures more than a couple of years old, things like baked in highlights.
you can not compensate the detail loss because of to much compression and other mistakes....
But you can correct the Albedo.....
Levels in Photoshop - here is a good texture.. but even this one dosent match the real tone of a caucasian albedo...
So - what you can do is bringing for each color channel contrast and range to the values i posted above
Thanks gentlemen.
Andy, I'll take a whack at that. But let me make sure I understand you properly.
You're suggestion is to take the texture into PS (or what-have-you), and for each color channel, adjust the Levels range to match this scale: R 200 - 220, G 140 - 155, B 120 - 133.
Do I have that correct?
One of the weird things I have noticed, when you look at some of the..less realisitcly renderable textures, shall we say, there is a dramatic color peak that you do not see in the easier ones. What the hell causes that? I'll have to show an example later on because I know I have not described that accurately.
Quite possibly a wrong colorspace/ICC profile applied somewhere along the line...
I don't really always see this as a problem. I hear lots of complaints about it... but, really...most of that actually lends credence to things; as long as its not glaring (like painted highlights or obviously painted hair).
@mjc1016
possible - (calibration even in my case) ... are you on a calibrated workflow?
Can you measure and post color space profile and values ?
I just want make sure myself too - that the values posted are correct...(they are close to values i know from real measusred skin - but differ slightly)..
One problem comes in when there are bright highlights from the lighting, or shadows that are way to strong. Ideally, the diffuse map should have very little lighting information baked in to it since we want the effects of lighting to come from our scene and not the texture. Some of the baked in lighting can be removed via Photoshop or Gimp, depending on how strong it is, but if you run in to highlights that are blown out (close to white), then detail has been lost.
yes....
Skin has a measured minimum and maximum albedo value .... as posted this is in a very flat range...
If you correct each channel to a similar range you will come close to a real fully albeo face skin (the reference image)..
Others posted allready - desaturate, or devibrance.diffuse textures for better results. But the correct way is matching each RGB channel with reference datas.
This is one of the mainproblems in a PBR workflow: "Quite possibly a wrong colorspace/ICC profile applied somewhere along the line...

We dont know what the author of a texture did... many many mistakes are possible.. we can just open the file and measure and then correct the values ourself to a correct sRGB workflow..
Example - Glossiness Texures are complete wrong for PBR iray.... they must be corrected and converted into LINEAR color space..
Diffuse textures should be corrected to match Albedo Values.. and if you want smaller files using JPG the ICC Profile 61966-2.1 should be ON when saving a image to JPG... ) but here i must do some research - I dont known what IRAY actually expect .....other render engines use this profile - so i hope Iray too
example - a texture i just try which should be made for IRAY.. i just had to make a 2.2 gamma correction....
Looks as the author worked in linear space.. but just saved it as sRGB...
the above postings just lead me to a open question
...
A normal workflow is:
Diffuse Textures in sRGB... everything else in linear (specular, glossiness and so on,,,,
I automaticly assumed Iray does the same.... Is this somewhere documented or confirmed? Does Iray expect sRGB gama 2.2 in base color? what if i want 16 bit or even 32 bit which is linear? .. can we set a flag somewhere ... or does Iray a decision depending on the file type?
That's very unfortunal true. I remember throwing a darker and darker getting grey on the roughness map I made for the Victoria 6 "Belle" face texture for the eyelid and gap between upper lip and nose areas to tune down the highlights there. The texture itself comes with a very bright highlight already baked in. Now I know how computer keyboards taste...
Ideally, an Albedo Texture shall not include any baked-in lighting and ambient occlusion information. If you take a closer look on the diffuse maps for the new iconic figures of DAZ''s 7th Generation, most of their maps did at first include baked in lighting, too, which then has been supressed by the artist who set them up.
For Photoshop, there's a recommended Color Setting for creating/working on Texture Maps for a PBR environment.
Interesting... so should one save using that color profile?
Yep.
@evilded777
Yes.. see my postings above... you must check when you save a JPG that the same profile is checked when saving..
IEC61966-2-1.. includes also the needed dot 20% allready... so all you must do when saving is check on the box for this profile!
ok.. i answer myself here....


the image is (was) a generic RGB token from the web.....
So sorry...
The values converted to sRGB are: R 210-230, G 160 - 170, B 140 -150....
Here is the converted image 1 sRGB against web RGB... small difference but that's exactly how mistakes adding up in the PBR workflow