What do you think about the future of rendering (and color manipulation in general) when considering the aspect of wide gamut color spaces and the problems associated with it?
It is a pretty mindbending topic, so I haven’t quite wrapped my head around it. The main points of problem are something like that:
RGB color values are used for encoding albedo and when converted from one gamut to another, surface reflectance (and absorbtion etc) amount changes because the RGB values are different;
renders done in different gamuts are different (due to previous problem) even when all inputs are properly converted and resulting image is converted back to whatever gamut we are comparing it with;
sRGB and similar gamuts seem to give the most “realistic” results at the moment (due to pure coincidence I believe), but they are quite narrow when compared to rec2020, ACEScg etc.
this generates great headaches when all other source material is in wider gamut but renders must be done on sRGB or similar. It is the lowest common denominator and gamut will be clipped.
As I understand, the problem rises from the RGB tristimulus model itself, spectral rendering should be immune to this if more detailed reflection etc spectra are used instead and resulting image is converted to RGB after rendering. This rises many interesting topics like how to efficiently describe and store spectral data, how to present it to user (texture artist, lighting TD etc) and how to optimize spectral rendering to be fast enough for production.
Rendering in high gamut aka true 32bit workflows with exr and hdr has many practical applications indeed and few limitations from a software perspective.
However currently without a profesional nvidia or AMD ( read quadro or firepro GPU) and a minimum of 10bit (8bit+2FRC minimum) LED IPS monitor there can’t be a reason to do wide gamut rendering(in Blender at least). Currently consumer grade GPUs (geforce and radeon) and monitors with pannels (<=8bit) are not viable options for this kind of workflow.
I would like to see the 10bit display ability for geforce/radeon GPUs first then some nice afordable 8bit+2FRC panels that don’t break the bank.
This is just the starting point from a hardware perspective as adequate hardware is unfortunately the minimum that you need in order to start a conversation about something as cool as this.
Wide gamut is a bit different topic than high dynamic range that you are mostly describing. They are not directly connected, a HDR display can work on sRGB gamut also. Almost all compositing applications work on 32bit float values, which is enough for all practical purposes. The fact that a GPU and monitor work on 8 or 10 bits does not remove the reason to work with HDR images, you just can’t directly map a HDR image to a LDR device as it looks ugly. The highlights are compressed with different transforms to show a pleasing image on LDR display, this was achieved with the interplay of negative and positive analog films in the analog film days, with transfer functions and LUTs until now and with rendering transforms (like RRT in ACES) in the future.
What I mean by wide gamut (either HDR or LDR, does not matter) is the aspect of maximum achievable color saturation and the effects it has on color rendering and compositing operations. The read on wikipedia is somewhat confusing but can maybe clarify the difference: Color gamut
You can do wide gamut and high dynamic range rendering in Blender, the question is, if you should try to do wide gamut rendering. There is no question whether you should do high dynamic range rendering, it is a must if you want to achieve any kind of realism at all, whatever your monitor is capable of.
There is already a patch in the pipeline to support alternate colour spaces. More vocal folks might push the priority up.
It is a pretty simple mathematical concept to grasp in that each primary pushes out towards maximum saturation in every coloured indirect bounce. Given that the basis vectors are non-orthogonal in XYZ, every set of RGB lights generates different results.
Regarding 10 bit HDR, it is required for the specification as the transfer function is inherently log-like, and the perceptual quantizer needs the extra steps to render the image properly.
Cosmos Laundromat is most certainly incorrectly generated, and sadly due to the nature of the pipeline, it would likely be very tricky to generate a proper HDR display transfer curve. It is also with absolute certainty REC.709 lights based due to limitations in Cycles and Blender proper, hence not wider gamut.
If you wish to insulate yourself from this, simply embrace a fully scene referred pipeline and you get HDR rendering “for free.” Coupled with Lukas Stockner Cycles patch, it would be easy to render REC.2020 compliant HDR material.
Thank you for the link to patch and related conversation!
I understand the problem (to some extent), but the question I’m interested more is the solution. Making it easier to convert everything to ACEScg for Cycles rendering gives you better control over working space but does not solve the problems.
You are well versed in color science issues, maybe you can give your opinion about these little bits of thought:
Will an ACEScg gamut RGB render theoretically only look correct on a (non-existing) ACEScg display device?
Would a compensating matrix multiplication in render engine allow for rendering in one gamut with results being pleasible in some other gamut?
Would conversion from working space to SPD (using for example the XYZ standard observer curves), doing calculations on SPDs in render engine and then sampling the resulting curves first to XYZ, then to working space and then to display space give a different or more accurate result? Would a spectral rendering that is still based on RGB inputs help solve the saturation and hue shift problems or probably not?
It will look different, yes. Correctly transformed, any wider gamut rendered on a smaller gamut will look as close to the source as possible, within the limits of the smaller gamuts.
This is where rendering intents usually come into play, with the two standardized methods, absolute colorimetric and relative colorimetric, being reliable. Perceptual and saturation tend to be secret sauce on a per application basis.
TL; DR: Yes, but the more obvious results will be clear even on the smaller gamut.
Gamuts are defined by basis lights. That is, at the core, the difference in gamuts is because the low level RGB lights are different. sRGB has unique lights as does ACEScg, but you can transform ACEScg lights into sRGB lights and see the results. Some colours may be out of sRGB’s reach of lights, but the results will be very close to 1:1, out of gamuts notwithstanding.
Spectral rendering would be agnostic, but would likely bring other aspects and problems into play; everything is a model and frequently our models disconnect from what they are attempting to model. Working in XYZ however, cannot solve the issue.
That thread actually motivated my original question
There Whorfin mentions the matrix multiplication that my second question referred to. That is, if we know what the intended resulting space will be, is it actually possible to not only scale but also shift and rotate so that when multiplied values are in gamut x, the result does not turn GI light funky in gamut y. Or would it not really work, which would mean that there is no real workaround for wide gamut render problems in three-component color model?
In the last question I didn’t mean working in XYZ but going through XYZ back to 10nm (or whatever the precision is) SPD curves, doing all the calculations using SPDs and then sample the resulting curve back to XYZ values using the standard observer curves again. And then doing transform to wherever we actually want to go.
