Re: Canon EOS R3 Baked in Raw Noise Reduction Revisited
1
Mika Y. wrote:
Lost99999 wrote:
Hi Claff,
between the lines you seem to imply this ‘baking’ is not a good thing. But could it not be that Canon understand the sensor and processing and desired end result to such perfection that this so called ‘baking’ leads to a better rather than worse result ?
While I'm not him, from my point of view, the problem with baking processing in is that it's optimal if you assume the current processing is the best there can ever be. But in real world, both the available algorithms and processing power tend to improve over the time. And unlike in-camera processing, doing conversion from raw does not have to be done almost instantly while processing files on a computer.
In fact this is, in many ways, the whole point of raw, and always has been: To be able to apply more computationally hungry algorithms to the sensor data. In fact most of the initial reasons to shoot raw were because in-camera demosaicing algorithms were easy to outperform. While this gap has closed a bit, in-camera NR algorithms still are easy to outperform, and usually in-camera color management is too. 90%+ of cameras out there still do per-channel tone curve lookups which causes hue twisting, for example.
I think the only scenarios in which in-camera "cooking" is acceptable are:
1) If it can be turned off
2) If it is being done to work around a significant storage/throughput bottleneck - for example, see modern smartphone burst stacking. While it would be nice to have access to the original burst of sensor images, 90% of the time, it isn't worth the 10-20x increase in data that must be saved to storage. Rule 1 still applies here though.
-- hide signature --
Context is key. If I have quoted someone else's post when replying, please do not reply to something I say without reading text that I have quoted, and understanding the reason the quote function exists.