I do know a wee bit of both physics and visual perception, but i fail to see where the color theory above has any visual impact, Gavin: show me a control image, one with and one without invisible colors (Like IR contamination, or UV spectrum bits), on a standard RGB display device, then we can maybe confront what the variance is, mathematically, and with a control group of humans, study the perceptual difference and likeable-ness of the three.
For right now, in plain RGB, without UV-Ray (this year’s april’s fool, btw), the matching is (and has been for a while) good enough for technical professionals to rely on when moving towards the physical realm (or in and out of it, with the scanned materials).
There’s a serious amount of help coming from Post, but that is also where ALL of the color conversion away from LWF takes place, and where a non-linear human or camera response curve can be countered efficiently to normal conditions first, and to the desired tonal range then.
Is it perfect a method? Of course not: it’s much more discrete and limited, compared to Nature.
Is it a dependable assumption to make in most situations? Yes it is. Compared to Nature (there is quite the literature on the subject: rendering approaches weren’t chosen on a whim.).
Photons do not change their energy based on your perception of them, rather, they have a precise amount of energy based on their wavelength, and it’s the atomical structure of materials getting excited by the different wavelengths and emitting a photon back of just the right one which we call colour (and Albedo).
That is what a renderer should calculate, within the bounds of the visible spectrum (how many channels ought to represent a visible spectrum well enough for human consumption is quite debatable, outside of a few specific cases. We also dither quite a lot, perceptually.).
If a renderer had to (or pretended to.) cater for the variance in visual perception in humans, wow, that would make for fun times.
This wasn’t a debate on color perception, anyways.
This was a debate which was set on a course driven by two running rumors:
A) octane is doing it better in terms of light transport models and physical accuracy, and
B) VRay will get close enough if we add those “corrective” camera response curves to make it behave like Octane.
I rebated with a set of Octane renders which aren’t in LWF, or which are in the CM section, but then are clipped, in response to point A), and renders which ought to be white by the standards of not just VRay, but everyone else which isn’t a niche product (rMan, Arnold, iRay, Corona), and instead show all sorts of (perhaps correct?) non-user initiated, nor user-changeable, skews and deviations from the norm (namely, the light intensity and colour) for point B)
All I care for is objective, and measurable data.
Even speculars can be measured against each other.
“Pretty” isn’t something that can be measured, but the lobe to tail ratio and the intensities can, even on very complex scenes.
Even with the best match Grant could get, the specular models look quite different in a number of places, and matching two different models may well be impossible.
Once we establish that everyone else is doing the expectable, and what’s been proven right enough to fool millions of perceptual machines in humans over many a year, we can still CHOOSE to go with the odd one doing things its way.
Just my maths and historical results will not change despite what anyone else chooses.
I was never in the debate from stopping the use of Octane, i entered it to set a few records straight.
We can take the nitty gritty of what’s supposed to be in a render engine core these days to a private place and debate it to exhaustion, but i think i demonstrated the two points i wanted to make, in here, with simple enough, and reproducible enough, data.
I’d love to be treated in kind, rather than with hypoteticals, so the debate can stay on course.
And most of all, i still see no case for the camera curves being provided by ChaosGroup (it’s a 1d lut in plain text format. vray has a LUT input already. Get converting, says I.) nor that those could or should be used with HDR renders (the curves are in the 0-1 range. so clipping may be a feature, not a bug, also in Octane.).
But everyone will get them anyways, very likely.
With good peace of the people asking for fewer controls throughout the VRay UI, and a streamlined workflow.
Baking colormappings in LDR images doesn’t sound like much of a workflow to *me*, so no, *I* shall stay on record flatly stating they’re not going to be of any help, but rather hindrance.
I guess time will prove me wrong once again: it wouldn’t be the first time, it won’t be the last.
Regardless, my renders will never be clipped to 1.0.
As for hat VRay needs to match competitors after all the testing, i’d say it would have to add a few useless loops and slow down a wee bit, lest those amazing articles on hundreds of hours of rendering per VFX frame turn out way shorter. 
Jokes aside, Chaos is pursuing a few avenues which are quite interesting.
Nightly builds are provided to the beta group, under NDA.
Feel free to apply!
P.s.: i did a short test too. Can anyone tell me how to enable importance sampling for IBL lighting in Octane for Max? I don’t seem to be able to have it work (there’s no dome light object, and no option in the bitmap loader when the HDR is used as a background. so i get the results you see below. Manuals are quite opaque, and i’d have thought something like that would be quite visible without trawling forums…). In the renders below the background HDRI providing light is a render of a VRay sky, and it matches for position and intensity. Octane’s simply missing the very intense and very small sun disk. Notice that also means a (potentially a LOT) faster convergence, due to the fewer high-intensity samples bouncing around, but until i get it to correctly sample the Bg I’ll never know.
All renders achieved the same sampling level (1024RPP) and were rendered on a GTX 980.
P.P.S.: the tests i am doing are on gray shaders not because i haven’t found colours yet, but because they make retrieving what is happening simpler to read (R,G, and B become V, 0-255 ranges are 0-1, so the maths simplifies.), and further shows precisely the lighting colour (times the intensity of the shader’s diffuse, 0.75 in the renders above) when a surface is hit (ie. the picked color is the light’s not the shader’s.). If the basics are set right (ie. LWF) then i can move to more complex scene and shading models conversion. Doing it backwards would make the job of figuring things out very complex indeed.
