8. Darker photos often look better.
Yes, you should ETTR, but ETTR is your input, not your output. By lowering exposure in post, it's easier to show the real contrast, without dynamic range compression.

9. No root, no fun.
Even while your device happens to be quite obscure and there's no one to mod any camera binaries or source, a way to set flags to allow extra access to third party apps or force a useful sensor mode system-wide tends to exist. In current reality, this tends to be mandatory to access in-sensor zoom. On sufficiently blessed devices, the feature set of stock camera will feel like a demo.

10. Camera isn't everything, even while you prioritize it.
In the end, we're about smartphones. What's the use of a phone that you can't hold comfortably, that gets its lens cover constantly smudged with fingers due to its position, what if you sacrificed everything for the sake of camera? You'll be less willing to take it out of pocket, as the similar roadblocks that prevent you from keeping a big, real cam on yourself will now also affect your phone. Perhaps it'll make these shots count? Not me to judge. :)

Experience is mine, the photos from Unsplash.com, mirrored in full resolution at this channel.


I reserve the right to expand on each topic at random intervals. ☺️

Let's expand on this one a bit:
A typical way to figure out the sensor modes configured by your OEM in the sensor driver is to utilize dumpsys media.camera, which is a command for root-less shell, hence we're keeping a few exotic device camera dumps at @cam2caps despite their not-so-rootable state.

On a qcom phone, you get to CTRL+F for the sensormodetable and count each x×y×fps combination from 0, where 0 is most of the time a mode with highest resolution.
On an mtk phone, the sensor drivers are in kernel space, meaning you can actually look at them. It's quite easy to figure out their structure, so let's go for actual forcing.

For qcom:
setprop vendor.debug.camera.overrideForceSensorMode YOURMODEID
For mtk:
setprop vendor.debug.cameng.force_sensormode YOURMODEID

Then narrow down the parts of camera stack that you may want to kill, by ps -A |grep cam, proceed to kill them with killall -9.

Of course, if you mismatch the raw resolution selected by the app and your sensor mode, things may break, but that doesn't make these modes useless, you can still go for a good JPEG. On a modern device, your chance to access an in-sensor zoom mode with same exact resolution as default is really high, and they really tend to work just fine. And heck, that's the minimum, many devices will offer a bit more.

So... Apple pokes holes in anti-fingerprinting measures by design, as a feature.
https://www.finnvoorhees.com/words/banned-iphone

The original Nougat wallpaper had stars, see you later.

It's quite different from the most recognizable version.

The starry one is at:
https://github.com/aosp-mirror/platform_frameworks_base/blob/d9f91827a9c6b0537b18d6e29873ae70b2d0bba6/core/res/res/drawable-sw720dp-nodpi/default_wallpaper.png?raw=true

Removal commit:
https://github.com/aosp-mirror/platform_frameworks_base/commit/38fdd605c83addeb9d52e1ab01958dbf7ee5742b

A not so far fetched conspiracy theory:
It may be be a fingerprint sensor, just not acting as one.
(iPhone 16)

They actually made it look jumpy, this suggests against a granular sensor (if true irl)

Meanwhile in comments of a channel actually distributing a Spotify mod with malware...

https://securelist.com/necro-trojan-is-back-on-google-play/113881/

No lie detected 😆

Chinese RN14P+:
OV50E main, IMX355 ultrawide, S5KJN1 tele

Global RN14P+:
S5KHP3 main, IMX355 ultrawide, OV02B10 macro, no tele

Sorry for few edits, had to consult about the naming. Not surprised that there's a catch with HP3 comeback, it's too good.