You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Snogray's current handling of color is trivial -- R,G,B are just uninterpreted values, which are read/written without modification from/to image textures, result images, user color specs, etc.
The current representation is mostly fine for rendering purpose, treating the color components as samples in an SPD (spectral power distribution), as most rendering operations act independently on spectral samples, but color I/O should really pay attention to the color representation of the input/output format, as different image formats are not all the same in this respect (they're similar enough that things "mostly look OK" without interpretation, but for instance textures loaded from TGA files in snogray look subtly wrong when the result is written to a jpeg file).
It'd be nice to have a nicely general framework that allows, for instance, the user to specify colors as arbitrary spectral distributions, blackbody temperatures, etc, and then approximate these with an appropriate SPD.
This isn't all that hard, but there are lots of details to handle.
Most existing color-management libraries are not actually very useful as they typically seem to represent the problem as only one of conversion between fixed endpoints, whereas we'd like something that allows arbitrary endpoint specifications, and calculates the necessary conversion matrices.
Idea: The basic representation of a color space can be the number of components in that space, and a pair of matrices for converting a vector of components to/from an SPD of some fixed resolution (the intermediate SPD resolution can be fairly high, because operations using them are fairly rare). A color-space conversion matrix between color-spaces A and B can then be calculated by multiplying A.TO_SPD and B.FROM_SPD.
The text was updated successfully, but these errors were encountered:
Snogray's current handling of color is trivial -- R,G,B are just uninterpreted values, which are read/written without modification from/to image textures, result images, user color specs, etc.
The current representation is mostly fine for rendering purpose, treating the color components as samples in an SPD (spectral power distribution), as most rendering operations act independently on spectral samples, but color I/O should really pay attention to the color representation of the input/output format, as different image formats are not all the same in this respect (they're similar enough that things "mostly look OK" without interpretation, but for instance textures loaded from TGA files in snogray look subtly wrong when the result is written to a jpeg file).
It'd be nice to have a nicely general framework that allows, for instance, the user to specify colors as arbitrary spectral distributions, blackbody temperatures, etc, and then approximate these with an appropriate SPD.
This isn't all that hard, but there are lots of details to handle.
Most existing color-management libraries are not actually very useful as they typically seem to represent the problem as only one of conversion between fixed endpoints, whereas we'd like something that allows arbitrary endpoint specifications, and calculates the necessary conversion matrices.
The text was updated successfully, but these errors were encountered: