Rick Burnett
Well-known member
- Joined
- Jan 20, 2009
- Messages
- 896
- Reaction score
- 0
- Points
- 0
Actually, it's not just the postponing of the choice of white balance. Consider that the order of operations has the white balance followed by a colour correction matrix. These two operations concatenate nicely. If you separate them by an integer representation, like in recording (even uncompressed) you will have the matrix magnifying rounding errors in the integer conversion. This is undesirable.
Graeme
I see this in the audio world a lot and it is hard to explain to some people what is going on. Audio is stored as either a 16-bit or 24-bit value. When you read that audio in, it is used as 32-bit float. What I show people is this:
Let's say you have the value 123456 and you read that in, then you apply a gain reduction to the value so it becomes 12.3456 and write out the file back at 24-bit. You read that file back in, and you have 12. Now, you decide to gain that value back up to the range it was before (let's assume in this example, you want to remove the operation you did before). Now the value us 120000. Clearly you can see that data precision has been lost.
However, if you had done those two operations in the same session and didn't write out an intermediate file, no precession would have been lost.
I believe this is what is trying to be explained as the reasoning for not baking in the white balance. Because if the color correction and white balance work in opposition to each other, like the gain down/gain up above, then ultimately you CAN introduce quite a bit of error into the result.