Split out some private utilities into effect_util.cpp, so we do not need to include...

[movit] / white_balance_effect.cpp

diff --git a/white_balance_effect.cpp b/white_balance_effect.cpp
index 8a495fb6f3616b45fb8c78b9988d028b1c8cfa1e..56cd8c96b853306a776e878b0f6e481092053fd0 100644 (file)
--- a/white_balance_effect.cpp
+++ b/white_balance_effect.cpp
@@ -1,12 +1,12 @@
-#include <math.h>
-#include <assert.h>
-
+#include <Eigen/Core>
 #include <Eigen/LU>
+#include <GL/glew.h>
+#include <assert.h>
 
-#include "white_balance_effect.h"
-#include "util.h"
-#include "opengl.h"
 #include "d65.h"
+#include "effect_util.h"
+#include "util.h"
+#include "white_balance_effect.h"
 
 using namespace Eigen;
 
@@ -39,7 +39,7 @@ Vector3d convert_color_temperature_to_xyz(float T)
 }
 
 // Assuming sRGB primaries, from Wikipedia.
-double rgb_to_xyz_matrix[9] = {
+const double rgb_to_xyz_matrix[9] = {
        0.4124, 0.2126, 0.0193, 
        0.3576, 0.7152, 0.1192,
        0.1805, 0.0722, 0.9505,
@@ -53,9 +53,9 @@ double rgb_to_xyz_matrix[9] = {
  * (Hunt-Pointer-Estevez, or HPE) for the actual perception post-adaptation. 
  *
  * CIECAM02 chromatic adaptation, while related to the transformation we want,
- * is a more complex phenomenon that depends on factors like the total luminance
- * (in cd/m²) of the illuminant, and can no longer be implemented by just scaling
- * each component in LMS space linearly. The simpler way out is to use the HPE matrix,
+ * is a more complex phenomenon that depends on factors like the viewing conditions
+ * (e.g. amount of surrounding light), and can no longer be implemented by just scaling
+ * each component in LMS space. The simpler way out is to use the HPE matrix,
  * which is intended to be close to the actual cone response; this results in
  * the “von Kries transformation” when we couple it with normalization in LMS space.
  *