2 ms·
Since there are plenty of knowledgeable folks here (you included) I'll pitch a naive question in hopes of learning some more: Beyond efficiency, is there any r
by zamadatix 2y ago
Since there are plenty of knowledgeable folks here (you included) I'll pitch a naive question in hopes of learning some more:
Beyond efficiency, is there any reason to avoid bringing everything into "some wide gamut linear space using doubles to represent each channel" for the computations and then converting back to the desired color space for any final output or export? Are there other things or alternative things you can do to meaningfully increase the final quality too/instead of?
- adgjlsfhk1 2y agoNope! the easiest way to do this is to always load images as linearized Float32 color.
- jiggawatts 2y agoDoubles are way overkill. Using something like 16 bit integers per channel is adequate even for HDR.
- nullc 2y agoIn doing so you may introduce banding artifacts by destroying the existing dithering in smooth areas of images. You could re-dither the output, but the required amount of dither to eliminate banding artifacts is great enough to be obvious and often annoying.
- dahart 2y agoMost film production already does close to what you describe, they convert to linear in order to do editing/rendering/grading/compositing, and then convert to the desired output color space. One place to start learning about film color handling is ACES: https://en.wikipedia.org/wiki/Academy_Color_Encoding_System https://en.wikipedia.org/wiki/Academy_Color_Encoding_System Outside of stylistic choices, I think the only technical reasons to use fewer bits are space & bandwidth efficiency, meeting the requirements of a given output device or file format. There are reasons to avoid doubles, just because they’re so big. 64 bits is unnecessary and wasteful for almost all color handling. Doubles are slow on most GPUs, where a lot of image processing has moved. 16 bits per channel is usually way more than enough for basic capture & display, especially if the output color range matches the input color range, i.e. little to no editing needed. (That ACES page says “Most ACES compliant image files are encoded in 16-bit half-floats, thus allowing ACES OpenEXR files to encode 30 stops of scene information.”) Even 32 bit floats is vast overkill for most things, but offers a much wider safety net in terms of using very small or very large ranges, and reduces the possibility of clipping error or visible degradation from quantization and rounding error when converting multiple times. Note while a lot of cameras offer things like HDR outputs and high bit rate RAW, even the best photo cameras in the world are getting around 8 effective bits per channel signal-to-noise ratio. (I’m getting this from the SNR measurements on dxomark.com) 8 bits per channel also happens to be close to the limits of human perception, when handled carefully, i.e., not linear but a more perceptually uniform color space.