How to Make DS Adhere to Gamut Safe RGB Codes

ArtAngel

How to make DS adhere to gamut safe RGB codes seems impossble. If I insert a color in DS I am getting a differnt value back. I have tried Gamma adjustments, teliing DAZ do not Gamma correct, Crush Blacks, Burn Highlights but it seems that DAZ is erasing or miscalculating color data. Most likely there is a simple solution but so far I have found over 100 ways to fail. The gamut safe codes I insert simply as a base color result in out of gamut rendered versions. I understand lighting affects colors but even if I play with emissions and give the lighting the exact same y and x rotations it is still off. Enter any code in RGB fields and click ok and resulting decimals seem off. Any way to have a true color matches in DS?

crosswind

I think maybe you were thinking of the issue from printing / publishing perspective as I just realized I've almost never noticed this issue from rendering / post working perspective. It's an interesting topic indeed though I may not be able to give you a solid way that you truely wanted.

I agree with you that iray engine, iray shaders, lights, tone mappings, etc are all influencing the final RGB code. I'm not sure if you're creating a custom shader but without extra work I gave it some experiment with emmision which I thought it should be the only way with Iray Uber Shader to make an expected result. However, a conversion of RGB code seems always a must.

But anyway, I tested a case in DS 6 (should also work in DS 4) by using Daz Color Ball in Default Resources. Environment: Scene Only. No lights at all. With Tone Mapping enabled but zero ISO. Turn off all Weight (incl. hidden Diffuse Weight) on Color Ball's surfaces with Iray Uber Shader. Set Red, Green and Blue colors and custom color on Color Balls. Give Luminance 1 cm/m^2.

Now if I rendered, the result show the correct RGB code of pure Red(255,0,0), Green(0,255,0), Blue(0,0,255) as they have ultimate 8-bit values (sceenshot 1).
But if I wanted a dark green e.g. 55, 125, 75, I had to convert the RGB values to 90, 214, 125 (due to calculation with decimals + rounding, G channel got 126 finally). Conversion Rates are: R: 0.6094, G: 0.5859, B: 0.6016,  Formula: target RGB value / rate. Round the result, just keep the integer. (scrrenshot 2)

So in short: We may have to pre-compensate RGB code values to counteract Iray's built-in brightness scaling, channel offsets, Gamma curve etc. otherwise the rendered colors will always be darker and/or shifted from what we expected.

If with lights and other complex Render Settings, I believe the calulation still can be doable... only the rates may vary and more pre-tests have to be needed. Anyway, a bit headache lol ~~

Edit: I also attached the scene file. You may give it an experiment if interested.  But in practice, I also hope there could be a really solid way for various cases we may have.

ArtAngel

crosswind said:

I think maybe you were thinking of the issue from printing / publishing perspective as I just realized I've almost never noticed this issue from rendering / post working perspective. It's an interesting topic indeed though I may not be able to give you a solid way that you truely wanted.

I agree with you that iray engine, iray shaders, lights, tone mappings, etc are all influencing the final RGB code. I'm not sure if you're creating a custom shader but without extra work I gave it some experiment with emmision which I thought it should be the only way with Iray Uber Shader to make an expected result. However, a conversion of RGB code seems always a must.

But anyway, I tested a case in DS 6 (should also work in DS 4) by using Daz Color Ball in Default Resources. Environment: Scene Only. No lights at all. With Tone Mapping enabled but zero ISO. Turn off all Weight (incl. hidden Diffuse Weight) on Color Ball's surfaces with Iray Uber Shader. Set Red, Green and Blue colors and custom color on Color Balls. Give Luminance 1 cm/m^2.

Now if I rendered, the result show the correct RGB code of pure Red(255,0,0), Green(0,255,0), Blue(0,0,255) as they have ultimate 8-bit values (sceenshot 1).
But if I wanted a dark green e.g. 55, 125, 75, I had to convert the RGB values to 90, 214, 125 (due to calculation with decimals + rounding, G channel got 126 finally). Conversion Rates are: R: 0.6094, G: 0.5859, B: 0.6016,  Formula: target RGB value / rate. Round the result, just keep the integer. (scrrenshot 2)

So in short: We may have to pre-compensate RGB code values to counteract Iray's built-in brightness scaling, channel offsets, Gamma curve etc. otherwise the rendered colors will always be darker and/or shifted from what we expected.

If with lights and other complex Render Settings, I believe the calulation still can be doable... only the rates may vary and more pre-tests have to be needed. Anyway, a bit headache lol ~~

Edit: I also attached the scene file. You may give it an experiment if interested.  But in practice, I also hope there could be a really solid way for various cases we may have.

Thank you for responding. . I have spent a week on this. I tried a ton of colors. trying to determine what the math is. Anyone wanting to do a print product, be it a mug a book a comic a graphic novel or a that is sold in a printed format will not be able to adhere to branding colors, or any kind of cohesive palette without some very tedious post work intervention over and above typical post work. I am trying to find a pattern. There must be a common denominator these results have. EG: a certain percentage of desaturation or shifting of red green and blues. Something is hard coded into how those decimal divisions work. Did a programmer make a typo press a num-pad key near the five in 255 division factor? Will give your experiment a shot and if it fails, add it to my massive list lol.