It is a sleek, gold smartphone engineered for performance and proudly designed and built in the United States for customers who expect the best from their mobile carrier.

I'm displeased to announce it's not fake.

Say what you want, but local tonemapping be like this.

(But if you read my earlier posts, you'll know that buying a dedicated phone for that goal isn't necessary. You may even process raws in bulk if you really want to)

No, it's not running Snapdragon 6g1. Laugh hard at me if it actually happens to be qcom. It being the same thing as REVVL 7 Pro 5G is impossible. The ODM behind it wouldn't allow it to look so stupid.

Do you have a device abandoned by official LOS? Back in February, LineageOS for microG released LOS 18.1 builds for devices like LG G2 and Redmi Note 5 Pro. Whatever you do with them, that's pretty cool.

https://download.lineage.microg.org/

(real)

Boring, more readable now

Camera2 API is great. It can easily be the biggest thing to exist in software part of smartphone photography. Despite a degree of OEM and chipset vendor disobedience and voices of complexity coming from app developers, the versatility it started with on Nexus 5 with Android 5.0 was already years ahead of what app developers would think of using at the time.

But it has an unaddressed weakness. The way camera sensors operate causes their characteristics to drastically differ depending on configuration currently set by the driver.
As a simplest example, the exposure time of most smartphone camera sensors gets controlled in the unit of linetime. The unit of linetime is directly derived from sensor clock, usable part of line length and line length blanking. As much as line length blanking can theoretically be controlled on the fly, it becomes much more complicated to do that with internal pixel clock, while expecting stability.
In short, if our priority lies in stability (expected behavior), then each sensor mode that utilizes a unique pixel clock must declare its exposure time range separately. For the simple purpose: to not limit the maximum nor minimum exposure time of exposed sensor modes.

Then comes the ISO. Your sensor's ability to provide a given value of analog gain depends on how fast you want your rolling shutter to be (not just through pixel clock, but also the difference in required line length blanking between various configurations). This means that as a device implementator, you have to either limit the exposed ISO range to the lowest value between the utilized sensor modes or again arbitrarily decide which one(s) will be most versatile. This means you'll be unable to trigger a higher dynamic range mode or a mode with higher frame rate while exposing the highest possible ISO range and staying compliant with API design.

I'm sure it's not all of it, while it's already major. Currently, there's even no way to declare a separate ISO range for SENSOR_PIXEL_MODE_MAXIMUM_RESOLUTION, while I'm yet to see a sensor that wouldn't support a higher ISO range in binned mode, meaning you must technically expose a usually 4 times lower max analog gain value to third party apps.

What's the current solution?
1. Be uncompliant – expose as much as possible as long as it doesn't impact the CTS and hope that advanced app vendors will excuse you for a dose of unexpected behavior for a greater goal.
2. Expose every sensor mode as separate camera ID – highly unintuitive to simple users, but gets things done.

If you happen to design a new camera API, don't make the same mistake as Google. The same single camera can be as different as a few, depending on the way it's driven. An API should inform the app whether it's operating on the same physical module, but it should also let the app select a suitable sensor mode by its characteristics. Whenever any information is declared by your API, think twice before declaring it as persistent on the camera as a whole.

Very fine 4x ISZ of Honor 400...

... and the 200MP mode that is nowhere near 🥴

Why, why does it look like a format that isn't even 1/2.55"? If it isn't at least IMX882, it'll be among the worst price-per-spec devices to exist from an established company.