It still seems we're talking about completely different things, or maybe you're trying to derail the conversation... Both ML-based processing and tonemapping t

It still seems we're talking about completely different things, or maybe you're trying to derail the conversation... Both ML-based processing and tonemapping take place after demosaicing to produce the final JPEG. RAW capture is just your typical laplacian pyramid stacking/exposure fusion with motion compensation and sensor-specific calibration. That's the main contributing factor that somewhat compensates for the sensor size, not some kind of ML processing. If you think that ML is somehow involved here, I have zero idea where you are getting it from. The entire point of pre-demosaicing pipeline is to robustly converge the captured stack into a neutral scene-referred baseline with provably better SNR and precise photometric parameters. And that's what you get in a resulting DNG, not some neural tonemapped RGB image (which is not even created at this point). Perhaps you should look at the pipeline yourself, here's the source code for a typical "computational imaging" camera app that produces stacked RAWs, for example. [1] And here's what Google Camera does [2] [3] (you can ignore everything that comes after demosaicing). Google's particular method is also partially implemented for arbitrary RAWs as third-party software, so you can stack any burst capture from your camera with the same method smartphones do. [4] (there's much less benefit for normal sized sensors, for obvious reasons) [1] https://github.com/mirsadm/motioncam/ https://github.com/mirsadm/motioncam/ [2] https://static.googleusercontent.com/media/hdrplusdata.org/en//hdrplus.pdf https://static.googleusercontent.com/media/hdrplusdata.org/e... (PDF) [3] https://static.googleusercontent.com/media/hdrplusdata.org/en//hdrplus_supp.pdf https://static.googleusercontent.com/media/hdrplusdata.org/e... (PDF) [4] https://github.com/martin-marek/hdr-plus-swift https://github.com/martin-marek/hdr-plus-swift