The leaks were right. This is a real phone.
https://fdn.gsmarena.com/imgroot/reviews/22/tecno-phantom-x2-pro/lifestyle/gsmarena_021.jpg
https://fdn.gsmarena.com/imgroot/reviews/22/tecno-phantom-x2-pro/lifestyle/gsmarena_021.jpg
👍3
Tadi Channel
Dear Tecno, you're now on my pantheon right after Mate X2 and S20, S21 high res modes, congrats! You may be even unaware that your results beat so many biggest OEMs around. https://fdn.gsmarena.com/imgroot/reviews/22/tecno-camon-19-pro/camera/gsmarena_013.jpg
And despite the ridiculously (and unnecessarily) huge camera island, they regressed
😁2
Tadi Channel
And despite the ridiculously (and unnecessarily) huge camera island, they regressed
It's worth noting that they forgot to regress on the full res processing of tele camera, which probably isn't the best in the optical area (despite the impressive aperture diameter), but still not as bad to not benefit from less destruction. Sharpening of the binned mode functions as a censorship of not so great demosaicing, but in result ruins the natural micro contrast, adds a few artifacts and clearly makes thin lines thicker.
👍3
Tadi Channel
Looks like devices with support for SCALER_STREAM_CONFIGURATION_MAP_MAXIMUM_RESOLUTION are finally starting to pop up. The device in the screenshot is Axon 40 Ultra.
Also there on Vivo X90 Pro+. The frame duration visible here correctly translates to 15 fps, as the only high-res sensor mode at 30 fps they implemented is direct 8k which they didn't expose, at least as a raw stream.
A big part of why these tables finally start being populated is because Qualcomm already implemented them in camera HAL for the recent SoCs. It's likely that their reference designs offer high res streams out of the box now with 0 code changes.
A big part of why these tables finally start being populated is because Qualcomm already implemented them in camera HAL for the recent SoCs. It's likely that their reference designs offer high res streams out of the box now with 0 code changes.
👍5
In 2016, XDA came with the idea of a brightness flashlight API dependant on a blob. Well, in 2022, "thanks" to GRF, this is exactly a thing that won't come to most of existing Android devices running their stock vendor image. If you're on Android 13, just try this app:
Forwarded from Google News | En
Flashlight Tiramisu.apk
2.4 MB
Android 13 flashlight brightness adjustment app for Pixel 6, 6 Pro and 6a. (and Galaxy S22 on One UI 5 beta)
Features:
• You can add a "Brightness control" tile to the quick settings for easy access;
• Support for dynamic colors and themed icon;
• Support for predictive back gesture;
• Demo;
You can't install this app on earlier Android versions.
Thanks to @polodarb for the build.
Google News | En
Features:
• You can add a "Brightness control" tile to the quick settings for easy access;
• Support for dynamic colors and themed icon;
• Support for predictive back gesture;
• Demo;
You can't install this app on earlier Android versions.
Thanks to @polodarb for the build.
Google News | En
❤2👍1
As media directly copied the imprecise claims of my friend on what staggered HDR actually is, let me correct it:
Typical sensor capture process works in a way that as long as your exposures are short, the integration (exposure start) of next frame won't happen any sooner than than the cycle of next frame, which basically starts when each of the sensor lines start integration, top to bottom. So for a sensor in 30 fps mode, it won't matter if your exposure time is 1/800s or 1/40s, you won't be able to capture more frames just because their exposure time is short.
Staggered HDR changes that. A sensor in such mode is able to have more than one ongoing integration start at a time, as long as a given line already stopped integration for the previous frame. This is better than bracketing typically is, as it lets the frames represent a narrower range of time. But it's really not a perfect timing match, the frames won't represent the same exact moment in time. To achieve that, you still need to rely on either dual...
Typical sensor capture process works in a way that as long as your exposures are short, the integration (exposure start) of next frame won't happen any sooner than than the cycle of next frame, which basically starts when each of the sensor lines start integration, top to bottom. So for a sensor in 30 fps mode, it won't matter if your exposure time is 1/800s or 1/40s, you won't be able to capture more frames just because their exposure time is short.
Staggered HDR changes that. A sensor in such mode is able to have more than one ongoing integration start at a time, as long as a given line already stopped integration for the previous frame. This is better than bracketing typically is, as it lets the frames represent a narrower range of time. But it's really not a perfect timing match, the frames won't represent the same exact moment in time. To achieve that, you still need to rely on either dual...
👍4
Tadi Channel
As media directly copied the imprecise claims of my friend on what staggered HDR actually is, let me correct it: Typical sensor capture process works in a way that as long as your exposures are short, the integration (exposure start) of next frame won't happen…
/triple conversion gain merge or gain-based QHDR (or Nona, Hexa etc. equivalent of it). It's a good moment to remind of the Samsung presentation I linked here: https://news.1rj.ru/str/TadiBlog/111
Telegram
Tadi Channel
https://hc33.hotchips.org/assets/program/conference/day2/(Final)Hotchips2021_CIS_Samsung_ISOCELL_GN2.pdf
👍2
A graph I made representing the non-staggered (typical) operation of a sensor. It's a bit idealized, as it skips the blanking time and other margins.
👍2
Tadi Channel
As media directly copied the imprecise claims of my friend on what staggered HDR actually is, let me correct it: Typical sensor capture process works in a way that as long as your exposures are short, the integration (exposure start) of next frame won't happen…
You may want to say "hey, but the sensor has limited clocks and same definitely goes for the output!". And well, you'll be correct. Staggered HDR isn't an on-sensor merge, meaning that it somehow has to output at basically the same rate as it captures. And that leads me to one simple guess: staggered operation is achieved by slowing down the scan to the levels comparable with slower frame rate modes, exchanging the minimal rolling shutter distortion for smaller "temporal gap", which is how Samsung calls the time not covered by any exposure.
And make no mistake, a sensor outputting 90 frames per second in staggered mode is able to do the same in normal operation mode.
And make no mistake, a sensor outputting 90 frames per second in staggered mode is able to do the same in normal operation mode.
👍4
Forwarded from Telegram Info English (Sominemo)
SafetyNet attestation in Telegram for Android
Beta version of Telegram for Android has begun performing a SafetyNet check before sending out the SMS authorization code. This was discovered by developers of the unofficial Nekogram modification.
Telegram Info found out custom ROM users don't need to worry.
SafetyNet API, developed by Google, is a tool that app developers can use to detect unofficial modifications within the app and on the system, such as mods, root access, and custom ROMs. This technology is used to protect against piracy and improve security by blocking the app or certain features on devices deemed unreliable by the developer.
Some users have expressed concern that Telegram's implementation of SafetyNet may indicate that the app will no longer allow SMS codes to be received from devices with unofficial ROMs or that the app will cease to function on these devices altogether.
However, a deeper analysis of the app's code reveals that Telegram is using SafetyNet to test a new method of delivering SMS authorization codes via Google's Firebase service, which requires the device attestation. The old method of sending codes will still be used in other cases, leading to the conclusion that Telegram does not intend to impose any sanctions on users of unofficial apps or mods.
The use of Firebase may be related to the high cost of sending SMS messages and calls for authentication. The delivery of codes accounts for a quarter of the messenger's expenses.
#Android
Beta version of Telegram for Android has begun performing a SafetyNet check before sending out the SMS authorization code. This was discovered by developers of the unofficial Nekogram modification.
Telegram Info found out custom ROM users don't need to worry.
SafetyNet API, developed by Google, is a tool that app developers can use to detect unofficial modifications within the app and on the system, such as mods, root access, and custom ROMs. This technology is used to protect against piracy and improve security by blocking the app or certain features on devices deemed unreliable by the developer.
Some users have expressed concern that Telegram's implementation of SafetyNet may indicate that the app will no longer allow SMS codes to be received from devices with unofficial ROMs or that the app will cease to function on these devices altogether.
However, a deeper analysis of the app's code reveals that Telegram is using SafetyNet to test a new method of delivering SMS authorization codes via Google's Firebase service, which requires the device attestation. The old method of sending codes will still be used in other cases, leading to the conclusion that Telegram does not intend to impose any sanctions on users of unofficial apps or mods.
The use of Firebase may be related to the high cost of sending SMS messages and calls for authentication. The delivery of codes accounts for a quarter of the messenger's expenses.
#Android
😁4🎉2❤1
Still waiting for samples of my favorite GSMArena building with dotted balconies, but I can already see one thing:
The 200 MP mode is how the 50 MP one should look like. The latter is bad. The first can really be useful once you downscale it.
The 200 MP mode is how the 50 MP one should look like. The latter is bad. The first can really be useful once you downscale it.
👍3