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.

FYI to any Android app dev:
This toggle in Play console doesn't effectively secure your app against tampering. Instead, it'll prevent sideloading the app even while it's a completely untouched original binary. This means that if Google Play is the sole distributor of your app, people won't be able to obtain it through an open source Google Play client like Aurora Store or through APKMirror, which is a site that verifies developer signatures before hosting the app mirrors. This forces your users to be constantly logged into their Google account, which is more privacy invasive than simply using a device with GMS. And yes, this toggle also excludes devices without GMS.

The irony is that a malware version of your free/IAP app will in result install just fine, while the purest original binary will reject the device. In other words, the only mirrors of your app that work will instantly be suspect, putting your users at risk from sites that get their popularity thanks to "apps that work". "Piracy" of free apps is a concept that goes a little too far from reason, it's not worth to forcefully materialize it.

Bb-but, Google knows how to code! They couldn't do it any other way!


Really? Imagine less anticompetitive Google for a minute. Even if you intend to retroactively cover the situation of a free app becoming paid (so that old sideloaded apk stops working), an uncracked binary could still ask Google Play to check if it's legitimate and currently free during the first run. Heck, you could even have the check in the app itself in case Google Play is missing from device. Google could provide all this info without a forced login or presence of GMS. Why would anyone ever need a license for an actually free app?