Announcement

Collapse
No announcement yet.

Wide Gamut RGB

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Wide Gamut RGB

    Spotted this on the corona render development blog...

    Internal Color Space is now WIDE RGB

    Why?

    Corona Renderer was previously using the XYZ color space, as opposed to the sRGB color space used by most renderers. There are several reasons why using wide-gamut color space improves rendering, even though the final rendered image is converted back to sRGB.

    The most important is that input material colors are interpreted differently, in much more plausible way. We all know using pure white (RGB 255 255 255) or pure black (RGB 0 0 0) colors is bad (one makes the render times skyrocket, other creates “black holes” in the image. No real object is totally white or black). An sRGB renderer actually faces these same problems every time a color with either 0 or 255 in red, green, or blue is used (for example, pure red, RGB 255 0 0). This means that using such materials will increase render times, and can also create entirely black objects when differently colored light is used.

    When using wide gamut color spaces, all color components are converted to not so extreme values internally. This “magic trick” causes the result to look identical under normal, white-ish lighting, but much more plausible when colored lighting is involved.

    A secondary effect is that certain phenomena, like low kelvin temperature emission, or physical sun/sky models at sunset, that are out of sRGB gamut, can be easily simulated with wide gamut spaces.

    Although the XYZ color space gave good results according to our empirical testing, using it was not theoretically correct, because the color space is not closed under multiplication (meaning it can produce non-existent colors). That’s why we have decided to switch to Wide gamut RGB, which does the job equally as well, is theoretically correct, and slightly more predictable.

    Look at the examples below:

    [img=http://corona-renderer.com/blog/wp-content/uploads/2014/03/colorspace-1024x184.jpg[/img]
    I just ran a test myself in VRay with the same setup, and got results like the sRGB image. In darker scenes that I've had to produce I've sometimes run into issues where certain materials/colours appear a lot darker than I'd have expected, so would it be possible/reasonable to impliment a wide gamut colour space for VRay's calculations behind the scenes? It would make lighting a scene that bit more intuitive and ultimately more realistic.
    Check out my (rarely updated) blog @ http://macviz.blogspot.co.uk/

    www.robertslimbrick.com

    Cache nothing. Brute force everything.

  • #2
    Yes I was wondering this myself. Even thought about posting it here. Guess you beat me to it.

    Comment


    • #3
      Heh, I was wondering when this will come up. But no, we will not do wide gamut RGB for the simple reason that It Is Wrong.

      Originally I wrote the article below to explain why rendering in XYZ space is wrong too, because people asked the same question about it:
      http://help.chaosgroup.com/vray/imag...yz_render.html

      I did not intend to put it here as I suppose the Corona guys realized too that XYZ is wrong and changed it. However, after doing some tests with the A6 release (I've attached the results - two of them are pretty much the same as before, just the colors are very slightly different, and the third still showed negative color components in the result), it still does not perform quite as expected. It is indeed closer to the real-world results in some cases, but still some way off in others. The mistake I guess is mixing up mathematical color spaces with physical ones. Both XYZ and Wide RGB are color spaces designed to transform color information between different devices, but they should not be used for physical calculations. The end result is that, unless you are only using gray materials in your scenes, the resulting image will never be quite correct.

      All in all, I think that a renderer should either implement proper spectral rendering, or stick to the universally accepted RGB. I don't think attempts to do some blend in between will work out.

      In any case, if you are not overly concerned with correctness, but just want nice images, I guess that's still perfectly ok. However, as I said, we will not be doing this with V-Ray.

      Best regards,
      Vlado
      Attached Files
      Last edited by vlado; 19-03-2014, 08:35 AM.
      I only act like I know everything, Rogers.

      Comment


      • #4
        So... any plans for spectral rendering?
        Rens Heeren
        Generalist
        WEBSITE - IMDB - LINKEDIN - OSL SHADERS

        Comment


        • #5
          Good points.

          Will you be introducing spectral rendering? Surely this is well suited to progressive/gpu rendering?
          Check out my (rarely updated) blog @ http://macviz.blogspot.co.uk/

          www.robertslimbrick.com

          Cache nothing. Brute force everything.

          Comment


          • #6
            Originally posted by Macker View Post
            Will you be introducing spectral rendering? Surely this is well suited to progressive/gpu rendering?
            Hehe, it would be a good bullet point on the feature list, but a) it will slow things down and b) for the vast majority of arch vis scenes where dispersion effects are not used, the results will be mostly identical to RGB.

            Best regards,
            Vlado
            I only act like I know everything, Rogers.

            Comment


            • #7
              Yeah, that's pretty understandable, plus we have dispersion for refraction.
              Check out my (rarely updated) blog @ http://macviz.blogspot.co.uk/

              www.robertslimbrick.com

              Cache nothing. Brute force everything.

              Comment

              Working...
              X