Differential D1973
Cycles: Use proper XYZ <-> Scene Linear conversion instead of assuming sRGB Authored by Lukas Stockner (lukasstockner97) on May 8 2016, 1:18 AM.
Details
This is the first part of the Cycles color management implementation. It still has some ToDos More details on this patch can be found in T46860, this diff contains a cleaned-up version of
Diff Detail
Event Timeline
Comment Actions While we are at this patch, the default config should be chucked out. The ACES bits are entirely wrong, the legacy copied transforms from the SPI pack is completely wrong in this context, and a hundred other errors. Lukas has a cleaned OCIO configuration in his GitHub branch, and it would at least be a beginning of fixing this abomination.
Comment Actions Let's not tie a revised OCIO config into this code review, one thing at a time.
Comment Actions It seems I screwed up the splitting into different patches a bit, some stuff that was in here Regarding the new Blackbody code: The new approximation comes from Wikipedia (article "Planckian locus"), Comment Actions The color output from the blackbody node looks quite different with this patch, even at the default temperature of 1500 K. Maybe the RGB values in the tables in the original code can be normalized, converted from Rec.709 to XYZ, and unnormalized again? With some luck the fit is still close in XYZ space. Another option would be to add a Rec.709 to working space matrix, but would prefer not to. Other than that it looks good to me.
Comment Actions Okay, I just decided to kick the curve fitting approximation approach completely and use lookup tables. To clean up the lookup table handling, I generalized the Beckmann lookup code a bit to make adding new tables easier. Also, the nodes now request the tables they need, Comment Actions Weused ot have lookup table to blackbody which then we replaced with an approximation by @lockalas in D1280, which gives quite reasonable speedup (up to 30% in a fire scene). Before going back to lookup table speed is to be investigated again and if we'll have penalty there then it's something to concern about (having slowdown due to support of a case which normal blender being almost never uses is mwua). Do you have plot of your lookup table? Did you try to curve-fit it? Comment Actions Hi, any update here? @Sergey Sharybin (sergey) the LUT comes from http://cvrl.ioo.ucl.ac.uk/cmfs.htm which has a graph view if you really want a graph. As for curve fitting, @Lukas Stockner (lukasstockner97) have you seen this paper from NVIDIA? http://jcgt.org/published/0002/02/01/paper.pdf The paper develops a multi-Lobe, piecewise gaussian fit with:
It even gives some example c code for formulas to calculate the individual XYZ values: // Inputs: Wavelength in nanometers
float xFit_1931( float wave ) {
float t1 = (wave-442.0f)*((wave<442.0f)?0.0624f:0.0374f);
float t2 = (wave-599.8f)*((wave<599.8f)?0.0264f:0.0323f);
float t3 = (wave-501.1f)*((wave<501.1f)?0.0490f:0.0382f);
return 0.362f*expf(-0.5f*t1*t1) + 1.056f*expf(-0.5f*t2*t2)
- 0.065f*expf(-0.5f*t3*t3);
}
float yFit_1931( float wave ) {
float t1 = (wave-568.8f)*((wave<568.8f)?0.0213f:0.0247f);
float t2 = (wave-530.9f)*((wave<530.9f)?0.0613f:0.0322f);
return 0.821f*exp(-0.5f*t1*t1) + 0.286f*expf(-0.5f*t2*t2);
}
float zFit_1931( float wave ) {
float t1 = (wave-437.0f)*((wave<437.0f)?0.0845f:0.0278f);
float t2 = (wave-459.0f)*((wave<459.0f)?0.0385f:0.0725f);
return 1.217f*exp(-0.5f*t1*t1) + 0.681f*expf(-0.5f*t2*t2);
}@Lukas Stockner (lukasstockner97) are you able to update the patch with this and master? Comment Actions If someone wants to easily test these values generated by these equations I created a quick LUT that can be used instead of the one that is in this patch to test if there is a difference in color. This comment was removed by Troy Sobotka (sobotka). | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||