Unfortunately the iPhone (and Mac's built-in FaceTime) cameras have no option to manually set the white balance. You need to use third-party apps/webcams to handle it.
I think the new iPhones ship with native ProRAW support, which might mean that the built-in Photos app would be able to access the same amount of imaging data that a specialised RAW editor could in prior versions.
https://www.techradar.com/news/what-is-apple-proraw-the-new-...
Things like low-light photography has always been available on DSLR's, like SLR's long before it, since you've always been able to control shutter speed, aperture, and ISO.
And all the extra software magic can already be done on your laptop on RAW files, where you've got enough space on your screen for all the sliders -- and a large enough screen to see the difference it makes in the details.
These days, pretty much the only people shooting with DSLR's are the people who want/need that fine-grained manual control anyways.
When that becomes available, then yes the possible processing on a computer will match and exceed what can be done on a phone.
If any camera would be able to do it, I'd bet on the Sony A9iii or A7iv.
It does seem like it's high time for there to be some kind of RAW-over-time standard, e.g. a single file with 2 hours of exposure that Photoshop would have built-in tools to manage -- and even the ability to handle matrix transformation movement over time, e.g. to photograph stars over 5 minutes.
I wonder how useful it would be to embed gyroscope/accelerometer data with it though? Everything I imagine having to do with long/stacked exposures involves a tripod.
Motion data actually seems like it would be more useful to embed in regular-exposure RAWs, since it could help build a deconvolution kernel to undo motion blur.
Of course, this would need a camera with much faster sensor readouts, which should be possible with Sony's next generation of stacked sensors.
Of course, storing 100 or 10,000 stills would up storage requirements dramatically -- but then lossless compression should bring that back down to entirely reasonable levels.
Because all you really have to do is compute the "average" image across the entire exposure (or at various "keyframes" if there's significant motion) and then encode the differences from those, which is trivial to compress.
I really hope this is something we see in the next 5 years, as opposed to 20 years.
Or people who shoot journalism, sports, conferences or other live events.
I don't care how damn good smartphones are (or will become). DSLRs will forever rule the roost in fast paced environments, smartphones are just too fiddly and there's nothing the manufacturers can do, the hinderance is not software, its form-factor.
That was the original question, and I'm not seeing it.
Obviously they're using DSLR's for the manual controls and lenses. But my point stands: if they need advanced image processing for something they're going to publish... they need to adjust it on a large screen. Not on-camera.
Not entirely true: DSLRs wouldn't be able to capture depth data like the dual/triple-camera phones can, for "computational photography" magic (or simple masking).
Now, there's some good use cases for it but I guess the tradeoff hasn't been worth it so far. E.g. having some processing options in camera can speed up your workflow (but then again all the "toys" like this are removed from pro cameras because most people didn't use them). Also, the same magic Apple or Google use doesn't really exist outside of their phones (yet at least, I assume Adobe is working on this).
There's also some obstacles that I know of:
- bigger sensor, slower readout, slower sensor processing
- much bigger raw, needs big expensive CPU, heating problems
- hiring engineers that can do this (it took a long time for Apple to catch up to Google f.e.)
One constraint around this is the sheer bandwidth required to do any sort of live processing (either for viewfinding purposes or autofocus) — the latency (and even bandwidth) of anything less than a direct raw feed into the processor isn't gonna be good enough.