Author Topic: Color accuracy  (Read 921 times)

2025-03-14, 10:48:02

Max Knol

  • Users
  • *
  • Posts: 4
    • View Profile
I can't wrap my head around this.

I've always wanted to create realistic materials in 3D. My approach is simple: if I reproduce every real-world value—light intensity, camera settings, and material colors—as accurately as possible using measured data instead of "eyeballing," then theoretically, the render should look as realistic as possible.

I can manually tweak values to make something look good—that’s not the issue. The real problem arises when working with clients. I want to establish a workflow where I can rely on measured, objective data instead of subjective adjustments.

If I’m not mistaken, not every Pantone or RAL color fits within the sRGB color space. This would mean that some real-world colors cannot be accurately represented in 3D since the base color input for most physically based rendering (PBR) workflows assumes an sRGB format. Additionally, there are many websites that claim to convert RAL to rgb (what i assume is gamma corrected srgb, even though it doesnt say ANYWHERE?) but they dont list how this is measured at all. Is this done scientifically by the makers of ral or pantone? or is it a kid in his bedroom guessing the rgb values by eye on a decently calibrated monitor? I guess we'll never know.... Please give me reliable sources someone...

This leads to my main question:
How do you accurately measure and input real-world colors into a 3D material?

If I have a plastic sample or a painted surface with a specific color, can I use a color meter to measure its sRGB value? And if the measured color falls outside the sRGB gamut, does it simply get clipped? If so, how do professionals handle this issue?

I'm not overly concerned about color clipping itself. My bigger frustration is the lack of reliable, standardized guidance on achieving accurate, repeatable results. I want to build materials using real-world values and then control my renders in the same way a photographer would—by adjusting lighting, exposure, and composition.

I do have an X-Rite ColorChecker at work, but it seems to correct colors relative to white balance rather than providing absolute brightness measurements. What I really need is a way to measure a real-world color, input it into a shader, and trust 100% that the result is scientifically correct. If the render looks bad, it should be because of poor lighting, exposure, or composition—not because the material itself was guessed.

I’m tired of pulling values randomly until someone arbitrarily decides "this looks good." That’s not accuracy—that’s just subjective tweaking.

Are there any experts in this field? Where can I find proper guidance on this?

2025-03-14, 11:19:44
Reply #1

piotrus3333

  • Active Users
  • **
  • Posts: 295
    • View Profile
start with some theory: Pointer's gamut - real surface colours, measured.
https://tftcentral.co.uk/articles/pointers_gamut

Corona can process only the ones in the triangle (attached):

edit: no longer true. Corona is now capable of acescg inputs and outputs.

« Last Edit: 2025-03-14, 18:38:31 by piotrus3333 »
Marcin Piotrowski
youtube
CGI OCIO config 04

2025-03-14, 11:52:06
Reply #2

maru

  • Corona Team
  • Active Users
  • ****
  • Posts: 13468
  • Marcin
    • View Profile
start with some theory: Pointer's gamut - real surface colours, measured.
https://tftcentral.co.uk/articles/pointers_gamut

Corona can process only the ones in the triangle (attached):

Could you please explain what exactly you mean here, and where you got that information from? Corona can, and does, "process" in wider gamut. In newest versions it's ACEScg (when using the 3ds Max OCIO mode). In older versions and when using the gamma 2.2 workflow, it used to be Adobe Wide RGB (for many, many, years). You can find the setting for this in "development/experimental stuff".
Max - https://support.chaos.com/hc/en-us/articles/4528523195537
C4D - https://support.chaos.com/hc/en-us/articles/4528469959953
Marcin Miodek | chaos-corona.com
3D Support Team Lead - Corona | contact us

2025-03-14, 11:54:04
Reply #3

pokoy

  • Active Users
  • **
  • Posts: 1975
    • View Profile
This post warms my heart - really, good to read it drives others mad, too.

Two in-depth articles from a longtime Max user about PBR and some of its assumptions and pitfalls, and practical solutions:
https://www.racoon-artworks.de/blog_PBRfromrulestomeasurements.php
https://www.racoon-artworks.de/blog_PBRshootingandcalibrating.php

Getting the right material properties is hard without a proper device. A colorimeter will only give you a reflected color value without any other info about reflectance and its behavior. The there's the materials surface which will affect all incoming/outgoing light and will produce different results for lighting and viewing angles.

Then there's the renderer - you can't really be sure how realistic it'll model the reflectance behavior when it comes to surface structure, how bump maps work in renderers is generally very simplified and will not reproduce real life accurately, and with texture filtering you can not really tell what it'll do). Rough diffuse materials are really a topic on its own with hardly any renderer caring about it.

As for sRGB, it's only getting worse from here. I'd say the range of colors in RAL and Pantone that can't be reproduced in sRGB may even be about 50%, maybe even more. I have not once come across a site that will tell you which space of RGB they assume for the values, and I'm pretty sure it's because they know it's impossible and just tell you a number close enough. Some vendors will give you LAB colors which is another can of worms because the scientific LAB space is not the LAB you'll find in Photoshop.

Broad topic, and then there are clients who will view your results on an uncalibrated display one day and tell you it's too dark, and the next they'll look at it on their mobile and tell you it's too bright and could be less saturated :D

I have worked in pre-press for some years and looking back I wish people in all places of the production chain (software vendors, too) would care about this today as people did 20 years ago when they printed stuff on paper.

2025-03-14, 18:52:06
Reply #4

piotrus3333

  • Active Users
  • **
  • Posts: 295
    • View Profile
start with some theory: Pointer's gamut - real surface colours, measured.
https://tftcentral.co.uk/articles/pointers_gamut

Corona can process only the ones in the triangle (attached):

Could you please explain what exactly you mean here, and where you got that information from? Corona can, and does, "process" in wider gamut. In newest versions it's ACEScg (when using the 3ds Max OCIO mode). In older versions and when using the gamma 2.2 workflow, it used to be Adobe Wide RGB (for many, many, years). You can find the setting for this in "development/experimental stuff".
Max - https://support.chaos.com/hc/en-us/articles/4528523195537

C4D - https://support.chaos.com/hc/en-us/articles/4528469959953

I was rather referring to ability to input and output acescg colour information to and from Corona. Not long ago it was still restricted to lin rec709. Everything seems to be working as expected now.

my mistake. apologies. well done Corona.

I might be wrong again but this passed quite unnoticed, right? considering the amount of "Corona needs aces" whining back in a day.

Marcin Piotrowski
youtube
CGI OCIO config 04

2025-03-14, 21:34:18
Reply #5

Aram Avetisyan

  • Corona Team
  • Active Users
  • ****
  • Posts: 855
    • View Profile
Corona did as best as it could to support ACES (whatever users had in mind saying it) in the meantime, on the go.

First it was the limitation of the host app (no proper color management), then it was its half baked state.

Corona had wide gamut for rendering since the very early days. Even with 3ds Max being just gamma managed, we added ACEScg as internal rendering space some time ago (maybe Corona 10 or older, cannot quite remember). This would give slight differences in color, the most significant being in colored medium. See this comparison. Overall, the differences between Wide RGB and ACEScg are very subtle, and this shows that Corona's internal rendering color space was very robust even before ACES was "cool".

Then we also implemented ACES OT operator. This specifically brought better highlight (including colored) handling. See this comparison.

It might have left unnoticed because, in my opinion, archviz is not a branch that would had seen significant boost from it. It just became a better standard, and render engines tried to adopt it as good as possible.



Aram Avetisyan | chaos-corona.com
Chaos Corona QA Specialist | contact us

2025-03-14, 22:45:12
Reply #6

pokoy

  • Active Users
  • **
  • Posts: 1975
    • View Profile
Corona did as best as it could to support ACES (whatever users had in mind saying it) in the meantime, on the go.

First it was the limitation of the host app (no proper color management), then it was its half baked state.

Corona had wide gamut for rendering since the very early days. Even with 3ds Max being just gamma managed, we added ACEScg as internal rendering space some time ago (maybe Corona 10 or older, cannot quite remember). This would give slight differences in color, the most significant being in colored medium. See this comparison. Overall, the differences between Wide RGB and ACEScg are very subtle, and this shows that Corona's internal rendering color space was very robust even before ACES was "cool".

Then we also implemented ACES OT operator. This specifically brought better highlight (including colored) handling. See this comparison.

It might have left unnoticed because, in my opinion, archviz is not a branch that would had seen significant boost from it. It just became a better standard, and render engines tried to adopt it as good as possible.
If you want to help archviz, Corona should finally support ICC profiles in the VFB as final color transform. For all the PS guys, Aces might be nice for it tonemapping, but as far as color management is concerned, it's not helping much.

We went slightly off topic though, OP asked for shortcomings of sRGB and workflows for proper material/surface capturing.

2025-03-15, 03:05:37
Reply #7

burnin

  • Active Users
  • **
  • Posts: 1638
    • View Profile
few sources:

&
ScanBox by Dave Riganelli (works w/ Substance suite)

BTW
no one is ever absolutely fully correct, art is in balance

2025-03-18, 14:11:47
Reply #8

Max Knol

  • Users
  • *
  • Posts: 4
    • View Profile
This post warms my heart - really, good to read it drives others mad, too.

Two in-depth articles from a longtime Max user about PBR and some of its assumptions and pitfalls, and practical solutions:
https://www.racoon-artworks.de/blog_PBRfromrulestomeasurements.php
https://www.racoon-artworks.de/blog_PBRshootingandcalibrating.php

Getting the right material properties is hard without a proper device. A colorimeter will only give you a reflected color value without any other info about reflectance and its behavior. The there's the materials surface which will affect all incoming/outgoing light and will produce different results for lighting and viewing angles.

Then there's the renderer - you can't really be sure how realistic it'll model the reflectance behavior when it comes to surface structure, how bump maps work in renderers is generally very simplified and will not reproduce real life accurately, and with texture filtering you can not really tell what it'll do). Rough diffuse materials are really a topic on its own with hardly any renderer caring about it.

As for sRGB, it's only getting worse from here. I'd say the range of colors in RAL and Pantone that can't be reproduced in sRGB may even be about 50%, maybe even more. I have not once come across a site that will tell you which space of RGB they assume for the values, and I'm pretty sure it's because they know it's impossible and just tell you a number close enough. Some vendors will give you LAB colors which is another can of worms because the scientific LAB space is not the LAB you'll find in Photoshop.

Broad topic, and then there are clients who will view your results on an uncalibrated display one day and tell you it's too dark, and the next they'll look at it on their mobile and tell you it's too bright and could be less saturated :D

I have worked in pre-press for some years and looking back I wish people in all places of the production chain (software vendors, too) would care about this today as people did 20 years ago when they printed stuff on paper.

Great information! Ive gone searching myself a little more and found this page on polyhaven saying similar things. Awesome stuff! Aparently lightroom is garbage for this type of work because it's geared towards non-technical people and a lot of stuff that significantly influences the final output is hidden away or automated.

https://docs.polyhaven.com/en/technical-standards/texture-color-calibration