Acer Introduced a 799-Gram 14-Inch Laptop at IFA 2026

Acer introduced the Swift Blade 14 at IFA 2026 on September 2, 2026 as a new ultra-light Windows 11 laptop built around mobile productivity.

The headline number is 799 grams. That is the starting weight for a full 14-inch notebook with a conventional clamshell design, a built-in keyboard, a 50 Wh battery and display options reaching 3K OLED.

The launch gives Acer a new kind of Swift machine: one where portability is the central engineering idea rather than simply one feature among many.

The Chassis Is as Thin as 12.9 mm

Acer lists the Swift Blade 14 at as thin as 12.9 mm.

The dimensions are 312.5 mm wide and 216.8 mm deep, keeping the footprint compact while preserving a 14-inch display. That combination makes the laptop easy to imagine in a daily carry setup where every millimeter and every gram matters.

Acer has built the machine around mobility from the physical structure outward.

Carbon Fiber and Magnesium-Aluminum Keep the Structure Light

The Swift Blade 14 uses carbon fiber for the A and D covers and a magnesium-aluminum alloy for the C cover.

Those materials are central to the laptop’s low weight. Carbon fiber gives the outer shell a lightweight structural foundation, while magnesium-aluminum supports the keyboard deck and internal assembly.

The result is a design that makes material engineering part of the product identity.

Marshmallow White and Marshmallow Blue Give It a Distinct Look

Acer is offering the Swift Blade 14 in Marshmallow White and Marshmallow Blue.

The two finishes give the laptop a softer visual identity than the dark gray and black finishes commonly associated with business notebooks. That fits the broader Swift idea of combining work, portability and personal style in one everyday machine.

The color choices also make the ultra-light chassis feel like a deliberate design product rather than only a technical exercise.

The Display Can Reach 3K OLED

At the top of the display range, the Swift Blade 14 offers a 2880 × 1800 OLED panel.

Acer specifies 100% DCI-P3 color coverage and a 90 Hz refresh rate for that configuration. That brings a high-resolution, wide-color display into the same 799-gram portability story.

For creators, photographers, designers and anyone who works visually while traveling, the display gives the machine a premium creative dimension.

A 90% Screen-to-Body Ratio Keeps the Front Compact

Acer lists a 90% screen-to-body ratio and 4.3 mm ultra-slim bezels.

Those narrow borders help the 14-inch panel occupy more of the lid area, keeping the outer dimensions efficient. The 16:10 aspect ratio also provides extra vertical workspace for documents, web pages and application interfaces.

The design makes good use of the physical footprint by devoting more of the front surface to the screen.

Intel Core Series 3 Powers the Swift Blade 14

The Swift Blade 14 uses Intel Core Series 3 processors.

Acer lists configurations reaching the Intel Core 7 processor 350, with additional Core 5 and Core 3 options. That gives the laptop a range of performance choices inside the same lightweight chassis.

The processor family is paired with Intel graphics and Windows 11 Home, creating a familiar modern PC platform for work, browsing, media and creative tasks.

12GB of LPDDR5 Memory Is Built In

Acer specifies 12GB of onboard LPDDR5-6400 system memory for the Swift Blade 14.

The memory sits alongside the compact processor platform and contributes to the laptop’s thin integrated design. For everyday productivity, creative apps, communication and multitasking, the system is built around a streamlined mobile configuration.

The focus remains consistent: keep the computer light while preserving the core components needed for a complete Windows laptop experience.

Storage Reaches 1TB of PCIe Gen 4 NVMe

Swift Blade 14 supports up to 1TB of PCIe Gen 4 NVMe SSD storage.

That gives the ultra-light machine room for project files, media, applications and offline work without turning storage into an external-only workflow. Fast solid-state storage also supports the responsive feel expected from a modern portable PC.

For travelers and mobile workers, having substantial internal storage helps the notebook stay self-contained.

Three USB-C Ports Keep Connectivity Simple

Acer equips the Swift Blade 14 with three USB 3.2 Gen 1 Type-C ports.

Two are listed as full-function ports, while the third supports data transfer. The laptop also includes a 3.5 mm combination audio jack.

The all-USB-C approach matches the compact chassis and creates a clean modern connection layout for charging, displays, accessories and everyday peripherals.

A 50 Wh Battery Fits Into the 799-Gram Design

The Swift Blade 14 includes a 50 Wh battery and supports fast-charging technology.

Fitting that battery capacity into a machine starting at 799 grams is part of the product’s engineering story. The laptop is designed to remain useful as a complete mobile computer while keeping the carry weight exceptionally low.

That balance is what makes the Swift Blade 14 more interesting than a simple thin-shell design.

Wi-Fi 6 and Bluetooth 5.3 Handle Wireless Connectivity

Acer lists Wi-Fi 6 and Bluetooth 5.3 for wireless connectivity.

That gives the Swift Blade 14 the everyday connections needed for cloud apps, collaboration, wireless accessories and mobile work environments. Combined with the USB-C port layout, the notebook can move between desks, meeting spaces and travel setups with a minimal physical footprint.

Connectivity is kept straightforward and portable.

A Physical Camera Switch Adds a Direct Privacy Control

The Swift Blade 14 includes an FHD 2MP camera and a physical camera switch on the side of the chassis.

That gives users a direct hardware control for the webcam. Acer pairs it with dual digital microphones and dual 2W speakers for video calls and everyday communication.

For a laptop designed to travel between workspaces, built-in communication hardware is part of the complete mobile setup.

The 14-Inch Format Makes the Weight More Striking

Ultra-light notebooks often become more interesting when their screen size stays practical.

Swift Blade 14 keeps a full 14-inch panel while reaching the 799-gram starting weight. That gives users a familiar workspace for documents, browsers, creative tools and entertainment while significantly reducing the physical load in a bag.

The product is built around the idea that portability can improve without shrinking the everyday workspace.

The 16:10 Display Supports More Vertical Workspace

The Swift Blade 14 uses a 16:10 display ratio across its panel options.

That taller shape provides more vertical room than a traditional 16:9 layout, which can be useful for reading, writing, spreadsheets and editing interfaces. It also complements the narrow-bezel design by making more of the lid area function as usable screen space.

For a mobile productivity laptop, that extra vertical area contributes directly to how much work fits on screen.

OLED and IPS Options Give the Lineup Flexibility

Acer lists several display choices for the Swift Blade 14.

The range includes the 3K OLED panel, a 1920 × 1200 OLED option and a 1920 × 1200 IPS LCD option. That lets the same lightweight chassis support different display priorities while preserving the core portability concept.

The OLED options also bring 100% DCI-P3 coverage into the lineup for users who value richer color presentation.

The Design Is Built for Work Beyond One Desk

The strongest use case for the Swift Blade 14 is movement.

A 799-gram laptop is easy to carry between home, office, campus, client meetings and travel. The combination of a full keyboard, 14-inch display, internal battery and local storage means the machine remains a complete PC even as the physical load becomes much smaller.

That makes portability part of the daily workflow instead of a feature that is only noticed during travel.

EMEA Availability Starts in December 2026

Acer says the Swift Blade 14 will be available in EMEA in December 2026.

The IFA announcement therefore gives the product a clear path from launch to market later this year. For buyers who prioritize low carry weight and a premium display, the Swift Blade 14 adds a new option to Acer’s broader Swift family.

The December window also places the machine among the new generation of PCs arriving around the 2026 holiday period.

The Upgrade Feeling

Acer Swift Blade 14 is a reminder that a meaningful hardware upgrade can be physical as much as computational.

A 14-inch OLED-class laptop that starts at 799 grams changes how often a full PC can comfortably travel with you. Carbon fiber, magnesium-aluminum, narrow bezels and a compact 12.9 mm profile all work toward the same goal: make the computer easier to carry while keeping the experience recognizably complete.

That is the upgrade here. The laptop becomes lighter in the bag without feeling smaller when it is open in front of you.

RugOne’s Xsnap 7 Pro takes the phone-camera idea in a different direction: one rear camera module detaches from the rugged handset and keeps recording as a standalone action camera. The detachable unit can shoot up to 2.7K at 30 fps through a 133-degree ultrawide lens, run for about 40 minutes on its own, and reconnect to the phone for control, viewing, charging and file transfer. The phone itself combines a Dimensity 8400 platform, 12 GB of RAM, 512 GB of storage, a 6.67-inch 120 Hz AMOLED display and a 9,300 mAh battery. The interesting part is not simply that RugOne added another camera. It separated image capture from the phone body while keeping the phone as the screen, battery hub and control layer — a modular imaging idea that could matter beyond rugged phones if it proves useful in real-world shooting.

The Camera Is No Longer Trapped Inside the Phone

Smartphone cameras have improved for years by adding more sensors, larger sensors, better lenses and more computational photography.

RugOne is trying something different.

On the Xsnap 7 Pro, one rear camera module can physically leave the phone.

The user can detach the small magnetic camera, mount it away from the handset and keep recording while the phone becomes the viewfinder, controller, battery dock and storage hub.

That sounds like a novelty.

It is actually a different architecture for mobile imaging.

The phone is no longer only the object doing the recording.

It becomes the control center for a second camera that can move independently.

RugOne Is Launching the Xsnap 7 Pro at IFA 2026

RugOne is formally introducing the Xsnap 7 Pro during IFA 2026 in Berlin.

The official IFA program lists the company’s September 5 product event and describes the Xsnap 7 Pro as an outdoor smartphone with a detachable action camera.

RugOne had already shown the concept earlier in 2026, including at Mobile World Congress.

IFA is where the company is moving the product from an unusual prototype-style idea toward commercial launch.

The timing matters because RugOne is not only showing a design experiment.

The company says a Kickstarter campaign is planned for September 7, followed by broader availability later in the year.

The Detachable Camera Is the Product

The rest of the phone has solid specifications.

But the camera module is the reason the Xsnap 7 Pro exists.

The module is small enough to remove from the rear of the handset and use independently.

RugOne describes it as thumb-sized.

Recent hands-on reporting lists the module at roughly 39 grams.

That low weight matters.

A phone is too heavy for many point-of-view mounting positions.

A small camera can sit on clothing, a helmet, a bike, a vehicle or a narrow surface while the phone stays somewhere safer.

The Module Records Up to 2.7K at 30 Frames per Second

The removable camera is not trying to replace the highest-end action cameras on raw video specifications.

It records up to 2.7K at 30 frames per second.

That is lower than the 4K and higher-frame-rate modes available on many dedicated action cameras.

The trade-off is integration.

The camera is already part of the phone.

It docks to the handset.

It uses the phone as a control surface.

It can be recharged from the phone.

The appeal is less about beating GoPro or Insta360 on image quality and more about carrying one device instead of two.

The Lens Is a 133-Degree Ultrawide

The detachable camera uses a 133-degree ultrawide field of view.

That is appropriate for action-camera use because the user often cannot frame the shot precisely while moving.

A wider lens captures more of the scene and gives more margin for body movement, cycling, walking or other motion.

RugOne also describes distortion correction designed to reduce the exaggerated stretching that ultrawide lenses can produce near the edges of the frame.

Software stabilization is part of the system as well.

The company is therefore treating the detachable unit as a real action-camera module rather than simply moving an ordinary phone camera into a smaller box.

Forty Minutes of Standalone Recording Is the First Constraint

A tiny detachable camera has a tiny battery.

Recent reporting says the module can record for roughly 40 minutes on one charge.

That is enough for short activities, clips and point-of-view sequences.

It is not enough for an all-day recording session by itself.

This is where the phone becomes part of the camera system.

The camera can return to the handset to recharge.

RugOne is effectively using the much larger phone battery as the energy reserve for the smaller detachable camera.

The Phone’s 9,300 mAh Battery Becomes the Camera Dock

The Xsnap 7 Pro carries a 9,300 mAh battery.

That is much larger than the battery found in most mainstream flagship phones.

RugOne positions that capacity around outdoor use and the detachable-camera workflow.

A large phone battery can power the handset, recharge the action module and support long periods away from a wall charger.

The Verge reports that repeated docking can extend total camera use dramatically compared with the module’s single-charge runtime.

That does not mean the camera records continuously for that entire period.

It means the phone can repeatedly replenish the smaller module.

This Is More Like Earbuds and Their Charging Case

The architecture is easier to understand if we stop thinking about a normal phone camera.

Wireless earbuds have small batteries because the charging case carries the larger reserve.

The Xsnap 7 Pro applies a similar relationship to imaging.

The removable camera is small and light because the phone carries the larger screen, battery and storage capacity.

The module leaves the phone when physical freedom matters.

It returns when it needs power, management or a larger interface.

That separation is what makes the design interesting.

The Phone Can Act as a Wireless Viewfinder

Once the camera is detached, the handset can still act as a remote display and controller.

Recent coverage reports a wireless viewing/control range of roughly 50 meters under appropriate conditions.

That changes how the user can frame a shot.

The camera can be placed somewhere the user cannot comfortably hold a phone.

The phone can remain in the user’s hand.

The user can then preview the image and control recording remotely.

This is a workflow dedicated action cameras already support through phone apps.

RugOne is integrating that relationship into one device package from the start.

The Camera Carries Its Own Storage

The detachable unit includes its own local storage.

The Verge reports 64 GB inside the camera module.

That is important because the camera cannot depend on a constant high-bandwidth wireless connection to the phone while recording.

The module can capture footage locally and transfer files later.

RugOne’s design therefore gives the detached camera enough independence to behave like a real recording device rather than a wireless lens that becomes useless when the connection weakens.

Then the Phone Adds Another 512 GB

The handset itself includes 512 GB of internal storage.

That gives the two-part system a useful hierarchy.

Record on the detachable camera.

Move footage to the phone.

Review it on the larger display.

Edit or share from the handset.

Clear space on the camera.

Go back out and record again.

This is where modularity starts to become practical rather than decorative.

The phone is not only carrying the camera.

It is the media-management device behind the camera.

The Action Camera Is More Waterproof Than the Phone

One of the stranger details is that the detachable camera can tolerate deeper water than the phone itself.

Recent reporting says the camera module can be submerged to about 5 meters without an additional case.

The Xsnap 7 Pro phone carries IP68 and IP69K protection and is described as surviving immersion to around 2 meters for up to 30 minutes.

Those are different claims and should not be mixed.

The practical benefit is obvious.

The small camera can go into situations where taking the entire handset would be inconvenient or risky.

IP68 and IP69K Are Part of the Phone’s Core Identity

The Xsnap 7 Pro is still a rugged phone.

IP68 relates to dust protection and water immersion under specified test conditions.

IP69K is associated with resistance to high-pressure, high-temperature water jets under a defined test method.

Neither rating means the phone is indestructible.

Neither guarantees survival in every real-world water environment.

But the ratings reinforce RugOne’s target market.

The detachable camera is being built into a phone designed around outdoor use rather than into an ordinary glass flagship.

The Phone Is Built Around MediaTek Dimensity 8400

RugOne uses MediaTek’s Dimensity 8400 platform for the Xsnap 7 Pro.

That places the device well above entry-level rugged phones in compute capability.

The phone is paired with 12 GB of RAM and 512 GB of storage.

Those resources matter for camera workflows.

High-resolution media processing, stabilization, preview, file transfer and editing all put pressure on the system.

RugOne is trying to make the phone credible as both a rugged device and a media platform.

The Display Is a 6.67-Inch 120 Hz AMOLED

The Xsnap 7 Pro uses a 6.67-inch 1.5K AMOLED display with a 120 Hz refresh rate.

Recent coverage also lists high peak brightness intended to improve outdoor visibility.

That screen plays two roles.

It is the phone display.

It is also the control monitor for the detachable camera.

A modular camera becomes far more useful when the main device provides a large, responsive preview screen.

Instead of putting an expensive large display on the tiny camera, RugOne leaves the expensive interface on the phone.

The Main Rear Camera Is Still 50 Megapixels With OIS

Detaching the action camera does not leave the phone without normal photography hardware.

RugOne lists a 50 MP stabilized main camera on the handset.

That is the camera for ordinary phone photography.

The detachable module is a separate tool.

This distinction matters because the Xsnap 7 Pro is not trying to force one camera to perform every imaging task.

The phone keeps a conventional main camera for everyday photos.

The removable unit handles the shots where physical placement matters more.

There Is Also a 64 MP Infrared Night-Vision Camera

The phone also includes a 64 MP infrared night-vision camera with dedicated infrared illumination.

Night-vision cameras are already common in some rugged-phone categories because the products target outdoor and field use.

The sensor does not turn ordinary darkness into daylight in the same way a large professional low-light camera might.

It uses infrared illumination and an infrared-sensitive imaging path to capture scenes that may be difficult to see normally.

That adds another specialized camera to a phone already centered on unusual imaging modes.

The Front Camera Is 32 Megapixels

The Xsnap 7 Pro also includes a 32 MP front camera.

On another phone, that specification might be part of the headline.

Here it is almost background information.

That says something about the product.

RugOne is not marketing the phone primarily around a conventional three-camera flagship hierarchy.

The product identity comes from modular capture.

The detachable action camera changes what the camera system can physically do, not simply how many megapixels are available.

The Phone and Camera Solve Different Physical Problems

A smartphone is excellent when the user can hold it.

An action camera is excellent when the user cannot.

That difference is physical, not computational.

No amount of AI can make a 300-gram phone feel like a tiny wearable camera.

No software stabilization can make a full phone convenient on a helmet or chest mount.

RugOne’s design accepts that limitation.

Instead of asking software to compensate for the phone’s physical size, the system allows part of the camera hardware to leave the phone.

Modular Phones Usually Failed Because the Modules Were Extra

The phone industry has tried modularity before.

Many attempts required users to buy separate add-ons.

A camera grip.

A projector.

A speaker.

A second module that lived in a drawer until the right moment.

That creates friction.

The Xsnap approach is different because the module is part of the phone itself.

The user is already carrying it.

The camera has a default storage location on the handset.

The modular capability is available without remembering to pack another device.

That could make the idea more practical than earlier accessory-based modular-phone concepts.

The Risk Is That Two Devices Can Mean Two Failure Points

Modularity creates advantages.

It also creates complexity.

The magnetic attachment has to remain secure.

The module has its own battery.

Its own storage.

Its own wireless connection.

Its own charging behavior.

Its own software.

A conventional camera fixed inside the phone has fewer moving parts in the user experience.

RugOne now has to make detaching, reconnecting, syncing and transferring footage reliable enough that the extra flexibility feels worth the extra complexity.

Wireless Preview Is Not the Same as a Wired Camera Connection

A remote camera introduces latency and connection limits.

A 50-meter range is not a guarantee in every environment.

Walls, interference, terrain and nearby radios can reduce wireless performance.

The module’s local storage helps because recording does not have to stop when preview quality changes.

But users should still think of the phone connection as a control and preview link, not as a magical cable replacement with unlimited reliability.

Real-world reviews will matter here.

2.7K Is a Deliberate Compromise

A detachable camera this small has constraints.

Sensor size.

Thermals.

Battery.

Processing.

Storage.

RugOne caps the highlighted video mode at 2.7K/30 fps.

That may disappoint users comparing specification tables with premium action cameras.

The product should be judged by a different question.

Is the footage good enough that having the camera with you all the time is more valuable than carrying a separate higher-end action camera?

If the answer is yes for enough users, the lower ceiling may be acceptable.

The Phone Is Trying to Replace a Two-Device Kit

The normal outdoor-content kit can include a phone and a small action camera.

That means two devices.

Two charging systems.

Two sets of files.

Two pieces of hardware to remember.

The Xsnap 7 Pro tries to collapse that kit.

The phone provides the large battery, screen, connectivity and editing environment.

The detached module provides physical freedom.

The success of the idea will depend on whether that integration saves enough effort to compensate for the compromises of the smaller camera.

The Kickstarter Launch Adds Another Layer of Risk

RugOne plans to launch the Xsnap 7 Pro through Kickstarter on September 7.

That matters.

Crowdfunding is not the same thing as ordinary retail availability.

Production schedules can change.

Shipping dates can move.

Features can change between preproduction and final hardware.

Potential buyers should separate the product concept from the certainty of delivery timing.

RugOne is an established device brand under Ulefone’s broader ecosystem, but a Kickstarter launch still deserves the same caution applied to any crowdfunded hardware campaign.

The Early Price Is Expected Around €799

Recent reporting says the Kickstarter campaign will start with a limited early price around €799.

A later global retail release is expected around $999.

Those figures should be treated as announced launch pricing, not as permanent street prices.

Regional taxes, availability and retail channels can change the final cost.

The important competitive point is that RugOne is pricing the Xsnap 7 Pro like a premium rugged phone rather than like a cheap novelty device.

At $999, the Camera Has to Be More Than a Gimmick

A four-figure rugged phone has to justify itself.

The detachable camera is not enough if users stop detaching it after the first week.

The module has to be easy to mount.

Fast to connect.

Reliable to record.

Simple to recharge.

Easy to manage.

The phone has to be good even when the modular feature is ignored.

This is the central commercial test.

Interesting hardware can win awards and attention.

Only repeatable utility turns that hardware into a product category.

The Xsnap 7 Pro Already Won an IFA Innovation Award

RugOne says the Xsnap 7 Pro received an IFA 2026 Innovation Award ahead of its official IFA launch event.

That recognition reflects how unusual the form factor is.

It should not be treated as an independent long-term product-quality verdict.

Awards evaluate innovation under a particular process.

They do not tell us how the magnetic connection behaves after months of use, how good the camera looks in difficult lighting or how reliable the wireless workflow becomes outdoors.

Those questions require shipping hardware and sustained testing.

The Broader Idea Is a Camera System With Distributed Parts

Smartphone camera systems are normally centralized.

Sensors and lenses sit in the phone.

Compute sits in the phone.

Storage sits in the phone.

Display sits in the phone.

RugOne separates those layers.

Capture can move away.

Compute, storage, connectivity and the interface can remain on the handset.

That distributed architecture is the real innovation.

The camera becomes a sensor node attached to the phone ecosystem rather than a permanent part of the phone body.

This Could Be More Interesting for Creators Than Another Telephoto Lens

Mainstream smartphone camera competition often focuses on zoom range, portrait processing and sensor size.

Those upgrades improve image quality.

They do not create new camera positions.

A detachable module can.

Helmet view.

Chest view.

Pet-level view.

Bike frame.

Vehicle exterior.

Remote placement.

A strange angle inside a small space.

That flexibility can produce footage a better fixed phone camera simply cannot capture.

For some creators, physical perspective may be more valuable than another incremental increase in image quality.

The Idea Could Spread Beyond Rugged Phones

Rugged phones are a logical place to test this architecture because their users are more likely to care about action capture, outdoor durability and large batteries.

But the design is not inherently limited to rugged devices.

A mainstream phone could carry a smaller detachable camera.

A foldable could use one.

A tablet could control several.

A future device could support multiple remote camera pods.

Whether any of that happens depends on whether RugOne proves that users actually value the separation.

The Xsnap 7 Pro is a useful experiment even if the exact product remains niche.

It Also Raises a Better Question About Phone Modularity

Phone modularity has often been discussed as replacing parts.

Battery modules.

Camera upgrades.

Expansion accessories.

RugOne suggests another form.

Temporarily distribute the device.

The phone does not have to permanently change shape.

One subsystem simply leaves, performs a task and returns.

That is a more dynamic definition of modular hardware.

Instead of swapping the phone into a different configuration, the device briefly becomes two cooperating products.

What RugOne and IFA Have Actually Confirmed

RugOne is presenting the Xsnap 7 Pro at IFA 2026 and describes it as an outdoor rugged smartphone with a detachable magnetic action-camera module.

The official IFA program lists the product as part of RugOne’s September 5 launch event.

RugOne has previously confirmed a 6.67-inch 1.5K 120 Hz AMOLED display, Dimensity 8400 platform, a large battery, a 50 MP OIS main camera and a 64 MP night-vision camera.

Recent launch coverage adds the current production-target details for the detachable camera, including up to 2.7K/30 fps recording, a 133-degree field of view, roughly 40 minutes of standalone recording and independent storage.

The phone is expected to move to Kickstarter on September 7 before broader retail availability.

What We Should Not Claim

We should not say the Xsnap 7 Pro has already shipped globally.

It has not.

We should not describe Kickstarter availability as guaranteed retail delivery.

We should not say the detachable camera replaces high-end action cameras in image quality.

Its highlighted recording ceiling is 2.7K/30 fps.

We should not say IP68 or IP69K makes the phone indestructible.

Those are defined test ratings.

We should not say a wireless viewing range is guaranteed in every environment.

And we should not treat RugOne’s “world first” language as an independently established historical fact beyond the company and IFA’s current product positioning.

The Bigger Upgrade Is Giving the Camera Its Own Body

Phone cameras keep getting better.

But they remain attached to the phone.

RugOne is testing whether the next useful camera upgrade is not another sensor inside the same rectangle.

Maybe it is letting the camera leave.

The Xsnap 7 Pro turns the phone into the screen, battery, controller, storage and communications hub.

The small camera becomes the movable eye.

That division will not make sense for every user.

It does something most phone-camera upgrades cannot do.

It changes where the camera can physically exist.

That is why the Xsnap 7 Pro is more interesting than its specification sheet.

Shelly ThreadLink is a new opt-in firmware for eligible Gen4 smart-home devices that turns the built-in Thread radio into a full IP network connection. Shelly says the same Thread mesh can carry Matter, Shelly Cloud connectivity through a Thread Border Router, and direct device-to-device control. Local scenes, interlocks and automations can run peer-to-peer and continue even if the internet or the Wi-Fi network goes down, while cloud and app access still require a working path through a Thread Border Router.

Your Wi-Fi Goes Down — But Some Local Automations Can Keep Going

Your Wi-Fi goes down. The internet disappears. But a light switch can still tell another Shelly device what to do. That is the practical hook behind ThreadLink, a new firmware announced by Shelly at IFA 2026 for eligible Gen4 devices. Shelly says ThreadLink turns the built-in Thread radio into a full IP network connection. The same radio can carry Matter, connect the device to Shelly Cloud through a Thread Border Router, and let Shelly devices communicate directly with each other through Shelly’s API. The most useful consequence is local control. Scenes, interlocks and automations between ThreadLink devices can execute peer-to-peer inside the Thread mesh and, according to Shelly, continue running even if the internet — or the entire Wi-Fi network — goes down. That does not mean the whole smart home works without networking. It means the local Thread path can keep doing its job when that automation does not need the cloud or Wi-Fi. That distinction is what keeps the headline useful without turning it into a promise Shelly did not make.

First: What Exactly Keeps Working?

The answer needs to be precise. Shelly is not claiming that every smart-home function survives every outage. The company specifically says device-to-device scenes, interlocks and automations can run locally across the Thread mesh. That creates a local route: Shelly device → Thread mesh → another Shelly device. If that automation only depends on those devices, it does not need a cloud round trip. Remote access is different. Shelly Cloud still requires a path from the Thread network to the wider home network and the internet. App control outside the mesh also depends on that broader network path. So there are two separate ideas: local control can continue inside the mesh; cloud and remote access still need external connectivity. Keeping those two paths separate is the easiest way to understand ThreadLink.

ThreadLink Is Not a New Box You Have to Buy

ThreadLink is firmware, not a new proprietary hub. Shelly Gen4 hardware uses a multiprotocol radio platform that supports IEEE 802.15.4 alongside Wi-Fi and Bluetooth-class connectivity. Thread uses that IEEE 802.15.4 radio. Shelly’s change is to make the existing radio do more. Instead of treating Thread only as a transport for one smart-home application layer, ThreadLink gives the device a broader IP networking role. For eligible Gen4 hardware, the user will be able to choose a separate ThreadLink firmware path when Shelly releases it. That makes this an architectural update to devices people may already own rather than a completely separate product family. It also explains why the announcement is more interesting than a normal firmware changelog: Shelly is changing what the radio is allowed to be used for.

One Thread Radio, Three Jobs

Shelly describes ThreadLink around three simultaneous uses. First: Matter. The device can appear in compatible ecosystems such as Apple Home, Google Home, Amazon Alexa, SmartThings and Home Assistant through Matter. Second: Shelly Cloud. The device can reach Shelly’s cloud through a Thread Border Router even though the Shelly device itself is not joined to Wi-Fi. Third: direct Shelly-to-Shelly communication. Devices can talk across the Thread mesh using Shelly’s API for local logic. That produces a useful stack: Matter | Cloud | Direct Control, all sharing one Thread network connection. The interesting part is not any one of those functions alone. It is that Shelly is trying to make the Thread radio serve all three at the same time, instead of dedicating Thread only to Matter while using Wi-Fi for everything else.

Matter and Thread Are Not the Same Thing

Matter and Thread are often mentioned together, so it is easy to treat them as the same technology. They are not. Thread is an IPv6-based low-power mesh network. Matter is a smart-home application standard that can run over IP networks, including Thread. A simple way to think about it is: Thread = the network path. Matter = one application layer that can use that path. That distinction is central to ThreadLink. Shelly is not announcing Matter over Thread as a new idea. The company is asking what else the device can do over the same Thread network once it is treated as a normal IP connection. That is why Matter can coexist with Shelly’s own local API traffic and cloud connectivity instead of being the only thing traveling over the radio.

Shelly Is Treating Thread Like a Full IP Network

This is the technical center of the announcement. Shelly says ThreadLink runs IPv6 over Thread with 6LoWPAN, UDP and full TCP support. That means the Thread radio is not being reserved for one narrow smart-home protocol. The device can participate in a broader IP stack over the mesh. In plain language: the Shelly device is not treating Thread as a special lane used only by Matter. It is treating Thread as the device’s network connection. That is why Shelly can put Matter traffic, direct Shelly communication and cloud connectivity on the same radio. Thread was designed around IP from the beginning. ThreadLink is Shelly’s attempt to use more of that foundation and make the radio useful for the vendor’s own device logic as well as ecosystem interoperability.

A Shelly Device Can Reach the Cloud Without Joining Wi-Fi

One of the more unusual effects is cloud connectivity without Wi-Fi credentials on the Shelly device. The path becomes: Shelly ThreadLink device → Thread mesh → Thread Border Router → home network → internet → Shelly Cloud. Shelly says the border of the network uses standards-based NAT64 translation so an IPv6-only Thread device can reach IPv4 services on the internet. The device therefore does not need to associate directly with the home Wi-Fi access point. That does not remove the home network or internet from the equation. It changes which radio the end device uses to reach them. The cloud is still remote. The Wi-Fi radio simply stops being mandatory on the Shelly end device when ThreadLink is the chosen firmware path.

If the Device Is Not on Wi-Fi, Why Is a Border Router Still Needed?

Because Thread is its own network link. A Thread Border Router connects the Thread mesh to the rest of the IP network. Thread Group describes the role as bidirectional IPv6 connectivity between Thread and non-Thread networks such as Wi-Fi and Ethernet. So no Wi-Fi connection on the Shelly device does not mean no network infrastructure. For local Thread-to-Thread automation, the devices can communicate inside the mesh. For app control, LAN access or cloud connectivity beyond that mesh, the Thread network needs a path outward. That path is provided by a Thread Border Router. The Border Router is not translating a proprietary smart-home language into IP. It is routing between IP-based network links.

You May Already Have a Thread Border Router

A Border Router does not have to be a Shelly-branded box. Shelly says ThreadLink can work with suitable Thread Border Routers from ecosystems including Apple, Google, Amazon and Home Assistant. Thread Border Router functionality is often integrated into another device rather than sold as a separate proprietary bridge. The exact product still matters. Not every smart speaker, router or hub from those brands is automatically a Thread Border Router. A user still needs compatible hardware and a functioning Thread network. But the architecture means ThreadLink is designed to sit inside an existing standards-based Thread environment instead of requiring a mandatory Shelly-only gateway.

No Proprietary Shelly Hub Is Required

Shelly explicitly says no proprietary gateway, hub or bridge is required for ThreadLink. That is possible because the connection path stays within standard IP networking concepts. Inside the mesh, Thread carries IPv6 traffic. At the edge, a Thread Border Router connects that mesh to the home LAN. From there, ordinary IP routing can carry traffic toward local services or the internet. This is different from a proprietary-radio design where a vendor-specific hub has to translate a non-IP device protocol into something the rest of the network can understand. ThreadLink’s architecture keeps the device on an IP-based path from the start. That does not mean there is no infrastructure; it means the required infrastructure can be standards-based rather than vendor-exclusive.

The Most Interesting Part Happens Inside the Home

Cloud access is useful, but the local route is the part that changes the outage story. If one Shelly device needs to trigger another Shelly device, ThreadLink can let that instruction move directly across the mesh. The simplified route is: device → Thread mesh → device. There is no requirement for that local action to travel to a remote cloud and back. That matters for scenes and interlocks where two devices need to coordinate with each other. Shelly says those peer-to-peer automations can keep running even when the internet fails or the Wi-Fi network itself goes down. The key phrase is peer-to-peer. The automation survives because its required communication path still exists inside Thread. That is a much stronger consumer story than simply saying the firmware adds another protocol.

Losing the Internet Is Different From Losing the Automation

Smart-home outages can look similar from the user’s point of view even when different parts of the network have failed. If the internet is down but the local Thread mesh is healthy, a ThreadLink device-to-device automation can still have a valid local path. If the Wi-Fi network itself is unavailable, Thread devices can still communicate inside their separate Thread mesh. If an action requires Shelly Cloud, remote access or another service outside the mesh, that external path still has to be available. So the correct takeaway is not that ThreadLink makes the home independent of networking. It is that ThreadLink can separate local automation from Wi-Fi and cloud availability when the automation only needs devices inside the Thread mesh. That separation is the practical reliability benefit Shelly is highlighting.

Thread Is a Mesh, So the Network Is Not Built Around One Wi-Fi Access Point

Thread is a low-power wireless mesh protocol built on IPv6. Eligible Thread devices can participate in the mesh and route traffic according to their role in the network. That produces a topology different from conventional Wi-Fi clients that normally communicate through an access point. The practical benefit for ThreadLink is that local device communication can live on the Thread mesh itself. The Border Router becomes the connection between that mesh and other IP links such as Wi-Fi or Ethernet. It is a network of networks rather than every end device needing to join the same Wi-Fi radio environment. This is also why a Wi-Fi outage does not automatically erase the Thread mesh: they are separate wireless network links even when both ultimately belong to the same smart-home system.

Why 6LoWPAN Is Part of the Story

Thread runs IPv6 over low-power IEEE 802.15.4 radios, where packet sizes are much smaller than on ordinary Ethernet. 6LoWPAN is part of what makes that practical. It adapts IPv6 networking for constrained low-power wireless links, including header compression and other mechanisms that make IP traffic fit the environment more efficiently. The important point for this article is not the packet format. It is that Thread does not stop being an IP network because the radio is small and low-power. Shelly can therefore build ThreadLink around familiar IP transports and routing concepts while still using a mesh radio designed for smart-home devices. That is the bridge between a tiny relay behind a wall switch and a full IP participant on the home network.

Why Full TCP Support Matters

Shelly specifically calls out full TCP support as part of ThreadLink. UDP is useful for fast, compact communication. TCP adds a reliable transport option for larger data transfers where ordered delivery matters. Shelly gives examples including configuration data, diagnostics and updates. Thread Group documentation also describes TCP as part of modern Thread networking and notes larger-data use cases such as firmware transfer. This gives ThreadLink more room than a design focused only on small control messages. The same Thread network can carry quick device commands and larger management traffic using the transport that fits the job. That is part of Shelly’s argument that Thread should be treated as a general network connection rather than a single-purpose Matter transport.

Home Assistant Gets More Than the Matter View

Shelly is also building a dedicated Home Assistant integration for ThreadLink. The company says the module will expose the broader Shelly feature set instead of limiting Home Assistant to only the capabilities represented by the Matter data model. That distinction will matter most to advanced smart-home users. Matter is useful as a common interoperability layer. A vendor can still have device-specific features that extend beyond the standard model. Shelly’s plan is to keep Matter available while also giving Home Assistant a deeper path into ThreadLink devices. That makes ThreadLink interesting to both mainstream ecosystem users and people building more customized local automations. It also lets Shelly keep its own richer device controls without giving up Matter compatibility.

What Happens to Wi-Fi on the Device?

ThreadLink is being delivered as a separate opt-in firmware choice. Shelly says customers will choose per eligible Gen4 device whether it runs the standard Wi-Fi firmware or ThreadLink. That means the announcement should not be read as every Gen4 device now running full Wi-Fi and ThreadLink simultaneously. The user selects the firmware path for that device. This is an important boundary because the hardware may contain multiple radio capabilities, but the supported product behavior is defined by the firmware Shelly actually ships. The ThreadLink release is therefore a deliberate mode choice rather than an invisible automatic conversion. A user who prefers the existing Wi-Fi behavior can keep the standard firmware on that device.

The Update Is Free — But It Is Not Available Yet

ThreadLink was announced on September 3, 2026. Shelly says the firmware is planned for release in approximately three months. It will be free of charge for eligible Gen4 devices and available through the Shelly app and web interface. The company also describes it as opt-in. So the timeline is: announced at IFA → firmware still in the release pipeline → free opt-in update planned in about three months. That distinction matters because the feature is not something every Shelly Gen4 owner can install today. IFA visitors can see live demonstrations, but consumer availability follows later. The exact list of eligible Gen4 models should be taken from Shelly when the release arrives rather than guessed in advance.

Security Still Happens in Layers

ThreadLink does not replace the security models of the protocols running over it. Shelly says Thread mesh traffic is protected at the link layer with AES-CCM according to the Thread specification. Matter sessions add their own certificate-based end-to-end security through CASE. Cloud connections use TLS, as Shelly’s Wi-Fi products do. Those are separate layers serving different parts of the communication path. The announcement does not provide a basis to say ThreadLink is universally more secure than Wi-Fi. The useful point is narrower: moving the device onto Thread does not mean communication is being sent as unprotected plain traffic. Each layer continues to use the security mechanisms associated with that part of the stack.

What Happens When Wi-Fi Comes Back?

ThreadLink does not need to switch back to Wi-Fi simply because the Wi-Fi network is healthy again. If the device is running ThreadLink firmware, its intended network path remains Thread. A local automation can continue using the mesh. Cloud traffic can continue leaving through the Thread Border Router. Matter can continue operating over the same Thread link. The return of Wi-Fi mainly restores the wider home-network infrastructure that may sit on the other side of the Border Router or support other devices in the home. That is another reason the architecture should not be described as a Wi-Fi failover mode. ThreadLink is a separate networking choice, not a temporary emergency radio used only when Wi-Fi fails.

What ThreadLink Does — and What It Does Not Do

ThreadLink runs IP networking over the Thread radio of eligible Shelly Gen4 devices. It can expose devices through Matter. It can let Shelly devices communicate directly inside the Thread mesh. It can reach Shelly Cloud through a suitable Thread Border Router when external connectivity exists. Shelly says local device-to-device scenes, interlocks and automations can continue when the internet or Wi-Fi network is unavailable. It does not create internet access when the internet connection itself is down. It does not guarantee every device in a smart home will work during a Wi-Fi failure. It does not remove the need for a Thread Border Router when traffic needs to leave the mesh. It does not mean Matter and Thread are the same protocol. And the firmware is not generally available to customers yet.

Why This Matters Beyond Shelly

ThreadLink is a Shelly product decision, but the architectural idea is broader. Thread was built as an IP-based mesh, which means it can carry more than one application layer. Consumers usually encounter it through Matter because Matter has made Thread visible in mainstream smart-home products. Shelly is showing another way to use the same foundation. A vendor can keep Matter for interoperability while also running its own local device API and cloud path over the Thread network. That does not mean every Thread vendor will copy Shelly. It does show that the Thread radio can be treated as more than a hidden transport beneath Matter. For smart-home systems, that opens a design space where local control, ecosystem compatibility and cloud access share one low-power IP mesh.

The Bigger Change: Matter Is No Longer the Only Thing Using the Thread Radio

For many consumers, Thread has appeared mainly as the invisible network underneath Matter devices. ThreadLink pushes the radio into a broader role. Matter can use it. Shelly Cloud connectivity can use it through a Border Router. Shelly devices can use it to talk directly to one another. And when a local automation does not need Wi-Fi or the internet, the Thread mesh can keep carrying that automation on its own. That changes the question from: Does this smart-home device support Thread? to: What else can the device do over Thread? For Shelly, the answer is a full IP path that can serve standards-based smart-home control, cloud access and local peer-to-peer logic from the same radio. The headline feature is surviving a Wi-Fi outage. The deeper story is that ThreadLink treats Thread as the network itself.

ASUS is showcasing new ProArt P16 and P14 laptops at IFA 2026 powered by NVIDIA RTX Spark. The platform combines a Blackwell RTX GPU, Grace CPU, up to 128 GB of unified memory and up to 1 petaflop of FP4 AI performance. ASUS and NVIDIA say supported local workflows can run LLMs up to 120 billion parameters, work with up to 1 million tokens of context, generate 4K AI video and handle 90 GB+ 3D scenes. The ProArt P16 packages that architecture into a chassis just 12.9 mm thick.

A 120B Model Sounds Like Server Hardware — ASUS Is Putting That Class of Workload in a 12.9 mm Laptop

A 120-billion-parameter AI model sounds like something that belongs in a server rack.

ASUS is putting that class of local workload into a laptop only 12.9 mm thick.

The new ProArt P16 uses NVIDIA’s RTX Spark platform with up to 128 GB of unified memory and up to 1 petaflop of FP4 AI performance. ASUS and NVIDIA say the platform can run large language models with as many as 120 billion parameters locally, including supported agent workflows with context windows up to 1 million tokens.

The important part is not simply that the laptop has a fast GPU.

It is that the CPU and GPU are designed around one unusually large memory pool.

Large local models need compute, but before the accelerator can process a model, the weights and working state need somewhere to live.

That memory architecture is what makes the 120B figure interesting in a laptop this thin.

The 120B Number Needs One Important Phrase: “Up To”

The ProArt P16 does not ship with one specific 120-billion-parameter model installed by default.

The claim is about the class of workload the RTX Spark platform is designed to support.

ASUS says RTX Spark enables creators and developers to run LLMs with up to 120 billion parameters locally.

That means the chain is:

hardware platform → available compute and memory → compatible model and software → local inference.

The exact experience can vary substantially from one model to another.

Parameter count does not tell you model architecture, quantization, context length, runtime overhead or inference speed.

So “120B” is best treated as a supported upper workload class under compatible conditions, not as a promise that every 120B model will behave identically on the machine.

Why 128 GB of Unified Memory Changes the Equation

On a conventional PC, system memory and GPU memory are usually separate pools.

The CPU works primarily from system RAM.

A discrete GPU works primarily from its own VRAM.

That separation matters when a model becomes very large.

If the model or its active working set does not fit comfortably in the GPU’s available memory, the workflow can become more complicated and data movement becomes part of the problem.

RTX Spark changes that arrangement.

ASUS says the platform provides up to 128 GB of high-bandwidth unified memory shared across the integrated system.

The CPU and GPU can therefore work from a much larger common memory pool instead of treating a smaller discrete VRAM allocation as the only fast memory available to the accelerator.

For large local AI, that is one of the most important changes in the machine.

A 120B Model Is a Memory Problem Before It Becomes a Speed Problem

A useful way to understand the scale is to look at the model weights themselves.

A 120-billion-parameter model at FP16 would require roughly 240 GB for the weights alone if every parameter used two bytes.

At FP8, the same simple calculation is roughly 120 GB.

At FP4, four bits per parameter works out to roughly 60 GB for the raw weights.

Those are illustrative calculations, not the exact memory footprint of every model.

Real inference also needs room for runtime state, caches, context, temporary buffers and software overhead.

But the comparison explains why FP4 support and a 128 GB unified pool can matter together.

The accelerator does not only need to be fast enough.

The system needs enough usable memory to hold the model and the rest of the inference workload at the same time.

RTX Spark Combines a Blackwell GPU and Grace CPU

RTX Spark is a highly integrated NVIDIA platform rather than a conventional laptop pairing of an unrelated CPU and discrete graphics chip.

ASUS says the superchip combines an NVIDIA Blackwell RTX GPU with 6,144 CUDA cores, fifth-generation Tensor Cores with FP4 precision and an NVIDIA Grace CPU with up to 20 cores.

The two sides are connected through NVIDIA NVLink-C2C.

That matters because the architecture is being designed around shared AI and graphics workloads from the start.

The CPU handles general-purpose work and system orchestration.

The Blackwell GPU provides the parallel compute and Tensor Core acceleration used by many AI workloads.

The shared memory architecture connects those pieces into one system instead of forcing every large workload through the assumptions of a traditional discrete-GPU PC.

One Petaflop Does Not Mean Every AI Task Runs at One Petaflop

ASUS and NVIDIA advertise up to 1 petaflop of AI performance for RTX Spark.

That number needs context.

It refers to the platform’s peak FP4 AI compute capability under suitable workloads.

It does not mean every application receives one petaflop of real-world performance.

Actual throughput depends on the model, precision, quantization format, software stack, context length, batch size, memory behavior and how well the workload maps to the hardware.

The useful point is that RTX Spark combines very low-precision AI compute with a large unified memory pool.

Compute and memory solve different parts of the problem.

The petaflop figure describes how much mathematical work the accelerator can theoretically process.

The 128 GB figure describes how much working data the system can keep available.

Large local models need both.

The Bigger Shift Is Running the Agent on Your Own PC

ASUS is positioning RTX Spark around personal agents as much as traditional generative AI.

The workflow can move from:

prompt → remote service → cloud model → response

toward:

prompt → local model → local files and tools → local action.

That does not mean every agent should run locally.

It means the user has enough on-device compute to move more advanced workloads onto the PC when the model and software support it.

ASUS explicitly says RTX Spark is designed to let creators and developers explore advanced AI applications directly on their PCs without relying exclusively on cloud processing.

That phrase matters.

The local machine becomes a serious inference target rather than only a thin client for a remote model.

“Local” Does Not Mean the Cloud Disappears

The local-versus-cloud story should not be framed as an all-or-nothing choice.

ASUS describes a hybrid workflow.

Local RTX-powered AI can handle workloads on the PC.

Cloud services can still be used for burst capacity, frontier-scale models or services that are only offered remotely.

That gives the user another execution option.

A model that fits the machine and matches the task can run locally.

A larger or specialized service can still run in the cloud when that makes more sense.

The practical change is therefore not “no cloud required for everything.”

It is that the cloud no longer has to be the only place where a demanding AI workflow can happen.

Token-Free Local AI Does Not Mean AI Has No Cost

ASUS uses the phrase token-free local AI when describing workloads that run on the user’s own hardware.

The practical meaning is straightforward.

If the model is running locally, there is no remote API provider billing that local inference by generated or processed token.

That is different from saying the AI is free.

The hardware has a purchase cost.

The computer uses electricity.

Some software or models may have their own licensing terms.

Maintenance and storage still exist.

So the useful distinction is:

local inference → no per-token cloud inference charge for that local workload.

That can make repeated experimentation, local agents and iterative creative workflows easier to budget because usage is tied to owned compute capacity rather than a metered remote API.

RTX Spark Supports Agent Workflows With Up to One Million Tokens of Context

NVIDIA says RTX Spark can run 120-billion-parameter LLMs with up to 1 million tokens of context using local agents.

Context length matters because an agent often needs more than a short conversation.

A long-context workflow can include documents, source code, research material, project history, tool outputs and intermediate state.

The larger the active context becomes, the more memory the runtime may need.

That links the million-token claim back to the same architectural theme.

The 128 GB unified pool is not only useful for model weights.

It can also provide room for the working state around the model.

The “up to” still matters: the specific model and software stack must support the context length being used.

Local Agents Need More Than the Model Weights

Loading a model is only the beginning of an agent workflow.

The system may also need:

model weights,

context,

KV cache,

tool state,

application memory,

temporary inference buffers,

and sometimes multiple models or encoders.

That is why raw parameter count is not enough to predict whether a local workflow will fit comfortably.

A 120B model can consume a large amount of memory before the first response is generated.

Then the context and runtime add more.

Unified memory gives the system a larger shared workspace for that full chain.

The important question becomes less “how much VRAM does the GPU have?” and more “how much usable memory can the AI workload access across the system?”

RTX Spark Is Also Targeting Local 4K AI Video Generation

The platform is not designed only for text models.

ASUS and NVIDIA also highlight 4K AI video generation as an RTX Spark workload.

That broadens the meaning of local AI on the ProArt machines.

A language model primarily works with tokens and model state.

Generative video has to create and transform large sequences of image data.

3D workloads add geometry, textures, materials and rendering state.

Different applications stress the machine in different ways, but the same combination of large shared memory and GPU acceleration can support all of them.

That is why ASUS is positioning ProArt P16 as a creator system rather than a laptop built around one chatbot.

The Same Platform Can Work With 90 GB+ 3D Scenes

NVIDIA also says RTX Spark can render ultra-large 3D scenes larger than 90 GB.

Again, the number points back to memory capacity.

A large scene can contain geometry, textures, simulation data and rendering resources that would exceed the VRAM capacity of many conventional laptop GPUs.

A large unified memory pool changes the ceiling.

The graphics and AI accelerator can work with a much larger data set without treating a small discrete VRAM allocation as the only high-performance workspace.

That does not guarantee identical performance for every 90 GB scene.

Scene structure, application behavior and rendering settings still matter.

But it shows why memory architecture is central to RTX Spark’s pitch.

All of This Is Going Into a 12.9 mm Chassis

The ProArt P16 is where the architecture becomes visually surprising.

ASUS says the new model is 12.9 mm thick and weighs 1.77 kg.

It also carries a 99 Wh battery.

That puts a platform designed for large local AI, 4K AI video and heavy creator workflows into a chassis closer to an ultrathin creator notebook than a conventional mobile workstation.

ASUS describes it as the thinnest 16-inch RTX Spark laptop and the thinnest 16-inch ProArt it has produced.

The 120B figure attracts attention.

The physical packaging is what makes the story unusual.

Large local AI is moving into hardware that is designed to travel.

The Smaller ProArt P14 Is 13.9 mm Thick

ASUS is also putting RTX Spark into the ProArt P14.

The company lists the P14 at 13.9 mm thick and 1.48 kg, with a 90 Wh battery.

ASUS calls it the lightest ProArt laptop it has produced.

That matters because RTX Spark is not being limited to one 16-inch flagship chassis.

The platform is being packaged into a smaller portable form factor as well.

Both laptops support up to 128 GB of unified memory depending on configuration.

The result is a local-AI platform spanning more than one size class rather than one oversized demonstration machine.

The Display Still Targets Creator Work

The AI hardware is only one side of the ProArt P16.

ASUS also equips the system with a Lumina Pro OLED display aimed at creator workflows.

The P16 supports configurations up to 4K at 120 Hz with variable refresh rate and NVIDIA G-SYNC.

ASUS lists color accuracy below Delta E 1 and HDR peak brightness up to 1,600 nits.

The P14 reaches up to 3K resolution.

Those specifications matter because many of the workloads ASUS is describing — video generation, editing, 3D rendering and image creation — eventually become visual work.

The machine is being positioned as an AI-capable creator laptop rather than an inference appliance with a keyboard attached.

There Is Also a Desktop Version: ProArt GR1X

ASUS is extending the same RTX Spark platform into the ProArt GR1X Mini PC.

The compact system measures 150 × 150 × 51 mm.

ASUS describes it as an always-on agentic AI computer for creators.

The GR1X includes 10GbE wired networking, Wi-Fi 7, Bluetooth 5.4 and support for up to four 4K displays.

The form factor changes the role.

P16 and P14 are mobile systems.

GR1X can stay on a desk and act as a persistent local AI and creator machine.

That creates two ways to use the same architectural idea:

portable local AI → laptop.

always-on local AI → mini PC.

An Always-On Local Agent Is Different From a Chatbot Tab

An always-on local AI machine can support a different workflow from opening a browser tab whenever a task appears.

A local agent can remain available alongside the user’s files, applications and tools.

Architecturally, that can support workflows such as:

new input arrives → agent processes it locally → tool performs an action → result remains on the machine.

The specific automations still depend on the agent software and permissions.

The GR1X does not automatically perform every possible agent task out of the box.

But an always-on system with local inference capacity gives developers and creators a persistent place to run those workflows without depending on a remote model for every step.

The Real Story Is Memory Architecture, Not Just Another AI Performance Number

AI PCs have spent several years being marketed around accelerator-performance numbers.

RTX Spark makes another number unusually important:

128 GB of unified memory.

A large model has to fit somewhere before the GPU can accelerate it.

A long-context agent needs room for more than the model.

Large video and 3D workflows also consume substantial memory.

That creates a simple chain:

large workload → needs large working set → unified memory provides space → GPU accelerates the computation.

The 1-petaflop figure matters.

The Blackwell Tensor Cores matter.

But the memory architecture is what lets the system point that compute at workloads that would otherwise be difficult to fit inside a slim laptop.

What ASUS and NVIDIA Have Confirmed — and What They Have Not

ASUS and NVIDIA have confirmed the core specifications and workload claims behind RTX Spark.

The ProArt P16, P14 and GR1X use NVIDIA RTX Spark.

The platform combines a Blackwell RTX GPU with 6,144 CUDA cores, a Grace CPU with up to 20 cores and fifth-generation Tensor Cores with FP4 support.

It offers up to 1 petaflop of AI performance and up to 128 GB of unified memory.

NVIDIA says RTX Spark can run 120B-parameter LLMs with up to 1 million tokens of context in supported local-agent workflows, generate 4K AI video and work with 90 GB+ 3D scenes.

ASUS lists the P16 at 12.9 mm and 1.77 kg and the P14 at 13.9 mm and 1.48 kg.

What those sources do not establish is that every 120B model will run at the same speed, every model supports a million-token context, local inference is always faster than cloud inference, or every workload reaches 1 petaflop.

Those claims should not be added.

The Number That Makes 120B Local AI Plausible Is 128 GB

The attention-grabbing number is 120 billion parameters.

The number that makes that class of workload plausible is 128 gigabytes.

Large AI models need somewhere to live before the accelerator can run them.

RTX Spark gives the CPU and GPU access to a large unified memory pool, combines that with Blackwell Tensor Core acceleration and FP4 compute, then packages the system inside a laptop only 12.9 mm thick.

That changes the shape of local AI.

A demanding model no longer automatically implies a rack-mounted server or a remote API.

More of that work can move onto the machine sitting in front of the user.

model → unified memory → local inference → local agent.

The cloud does not disappear.

But it no longer has to be the only place where serious AI work happens.

Meta’s AI glasses use a white Capture LED to signal when photos or videos are being recorded. Beginning with the second generation, Meta says the camera can be disabled when the system detects that this LED is blocked, and the company is also updating the glasses to disable capture when physical tampering with or destruction of the LED is detected. The safeguard turns a visible indicator into part of the device-level rule that determines whether the camera can operate.

Meta AI Glasses Can Disable Their Camera When the Recording Light Is Tampered With — Here’s How the Safeguard Works

A recording light is usually just an indicator.

On Meta’s AI glasses, it is becoming part of the camera’s operating rules.

Every pair includes a white Capture LED on the front of the glasses. Meta says the light blinks when a photo is taken and continues blinking for as long as a video is being recorded.

Beginning with Meta’s second generation of glasses, the camera can also be disabled when the system detects that this Capture LED has been blocked.

Meta has extended that safeguard further.

The company says it is updating its glasses so the camera can also be disabled when the device detects that the Capture LED was physically tampered with or destroyed.

That turns a small light into something more than status feedback.

The indicator does not only report what the camera is doing.

Its availability can become one of the conditions that determines whether camera capture is allowed at all.

The Capture LED Is Part of the Camera System

Meta places the Capture LED on the front of its AI glasses so people nearby can see when the camera is capturing content.

The behavior changes with the type of capture.

For a photo, the white light blinks briefly.

For a video, it continues blinking during recording.

Meta also says the Capture LED has no normal off switch.

That distinction matters because wearable cameras are positioned differently from phones.

A phone is usually held in front of the person taking a photo or video. Glasses stay on the wearer’s face, so the camera can operate while the user is looking naturally at the scene.

The visible indicator therefore carries information for people around the wearer.

The light is not simply telling the person wearing the glasses that the camera is active.

It is also an external signal tied to capture.

Covering the Light Can Disable the Camera

The second-generation safeguard changes the relationship between the indicator and the camera.

Meta says that when supported glasses detect that the Capture LED has been blocked, the camera is automatically disabled.

No photos or videos can be taken until the system detects that the light is no longer blocked.

The basic behavior can be represented as a simple chain:

Capture LED blocked → camera disabled → capture unavailable.

Capture LED unblocked → camera can become available again.

That is stronger than an on-screen warning.

The glasses do not simply tell the wearer that the indicator is covered and continue recording normally.

According to Meta, the camera capability itself is tied to the detected state of the indicator.

The light has therefore become part of the capture path rather than a completely separate notification component.

Temporary Blocking and Physical Tampering Are Different Cases

There are two different conditions in Meta’s explanation.

The first is temporary obstruction.

A sticker, tape or another object may cover the Capture LED. On supported second-generation glasses, Meta says camera capture remains unavailable until the system detects that the light is unblocked.

The second condition is physical modification.

Meta says some people have gone beyond covering the LED and have attempted to modify or destroy the component itself.

The company says it is improving tamper detection and updating the glasses so the camera can be disabled when the device detects that the Capture LED was physically tampered with or destroyed.

Those cases are related, but they are not identical.

One can be reversible when the obstruction is removed.

The other concerns a detected change to the physical indicator itself.

Meta Has Not Published the Complete Detection Architecture

The confirmed behavior is useful.

The exact internal detection method is not fully public.

Meta says the glasses can detect when the Capture LED is blocked and that its newer safeguard can detect physical tampering or destruction of the indicator.

The company does not provide a complete public hardware schematic or firmware algorithm explaining every signal used to make that decision.

So it would be wrong to invent one.

We cannot assume from Meta’s public explanation alone that the system depends on a particular photodiode, electrical continuity measurement, resistance threshold, camera-based detector or one specific sensor architecture.

What is public is the behavior:

a blocked LED can disable capture,

and detected physical tampering can also lead to camera disablement.

The implementation details beyond that remain Meta’s internal engineering.

The Interesting Part Is the Enforcement Loop

The most useful way to understand the safeguard is as an enforcement loop.

Conceptually, the glasses need to know whether the recording indicator is in an acceptable state before camera capture continues.

That can be illustrated as:

Camera request

↓
Capture LED state or integrity check

↓
Safeguard condition satisfied?

YES → capture can proceed.

NO → camera capture is disabled.

This is not Meta’s published firmware diagram.

It is a simplified model of the behavior the company describes.

The important part is the dependency.

A normal indicator can be passive: the device records, and the light merely tells you that recording is happening.

Here, the indicator state can influence the camera’s permission to operate.

That is an architectural change in the role of the light.

A Recording Indicator Can Be More Than a Light

A small LED normally belongs to the interface layer.

Camera active → light on.

Camera inactive → light off.

Meta’s safeguard creates a stronger relationship.

Capture is not only expected to activate the light.

On supported glasses, the camera can also depend on the light remaining available to perform that visible signaling role.

This creates a two-way connection between the camera and the indicator.

The camera controls the light when capture begins.

The detected state of the light can, in turn, affect whether the camera remains available.

That is why the Capture LED is technically more interesting than it first appears.

It is still an indicator.

But it also participates in the operating rule around camera capture.

Meta’s Official Video Shows the Capture LED in Action

Meta published a short first-party video directly inside its AI-glasses privacy explainer.

The clip shows the Capture LED operating on the glasses and is useful here because it demonstrates the exact component this article is discussing.

It is not a general smart-glasses advertisement and it is not a third-party review.

The video does not reveal the internal tamper-detection architecture.

What it does show is the visible behavior of the white Capture LED during camera use.

That makes it a good visual reference for understanding why the indicator can function as an external camera-state signal before we move into the device-level enforcement behind it.

Why Meta Uses a Visible White Light

Meta says it considered different ways to communicate capture activity and chose a white light after evaluating visibility and user experience.

The company also says it tested brightness so the indicator could remain visible during daytime conditions and tested the blinking frequency used during video capture.

That is an engineering tradeoff rather than a universal rule for every wearable camera.

The indicator has to be noticeable enough to communicate camera activity without becoming the primary visual function of the glasses.

For still photos, a brief blink can mark the capture event.

For video, continuous blinking communicates that the recording state is still active.

The same hardware component therefore communicates two different temporal states depending on what the camera is doing.

Why the Light and the Shutter Sound Do Different Jobs

The glasses also provide audio feedback.

Meta says the wearer can hear a shutter sound.

But the company explains that sound is not practical as the only signal for people who may be standing farther away.

That gives the two indicators different audiences.

The shutter sound provides feedback to the person wearing the glasses.

The Capture LED provides a visible signal to nearby people.

Those functions can coexist because they solve different communication problems.

The audio cue confirms an action for the wearer.

The light exposes camera activity externally.

This distinction becomes important once the visible signal is tied to camera availability, because the external indicator is no longer treated as optional feedback.

The Safeguard Operates at the Device Level

The Capture LED safeguard is not a social-media setting.

It is not an Instagram posting preference.

It is not a cloud moderation rule.

Meta describes it as behavior of the glasses themselves.

That puts the control close to the hardware capability it governs.

The system detects a condition involving the physical Capture LED and changes whether the camera can capture photos or video.

This is a useful example of policy enforcement moving downward in the technology stack.

Instead of waiting until content is uploaded or shared, the device can make a decision before the image or video is captured.

The relevant chain is:

wearable hardware → detected indicator state → device software or firmware enforcement → camera availability.

That makes this primarily a hardware-and-camera story, even though software is essential to the rule.

The Rest of the Glasses Can Still Have Other Functions

Meta’s AI glasses are not only cameras.

The company describes them as wearable devices for listening to music and podcasts, taking hands-free photos and video, accessing Meta AI and using other connected features.

The Capture LED safeguard is specifically tied to camera capture.

That is an important boundary.

A detected problem with the recording indicator does not automatically mean every function of the wearable has to disappear.

The public description focuses on disabling the camera.

This distinction matters because “the glasses are disabled” and “the camera is disabled” are not the same statement.

The safeguard is targeted at the capability that depends on the visible recording signal.

Recent Enforcement Shows the Rule Is Operational

Recent reporting adds another useful piece of context.

Business Insider reported on September 2 that Meta had disabled camera functionality on AI glasses where tampering with the recording indicator was detected.

The same reporting distinguishes temporary obstruction from physical removal or modification.

That matters because the safeguard is not only a design description on a support page.

Camera availability can actually change when the device identifies a condition that activates the rule.

For this article, the technical point is narrow.

The indicator state is not merely informational.

It can participate in enforcement.

The exact consequences can differ depending on what the system detects, but the camera-disable behavior itself is now both publicly documented by Meta and visible in current deployment reporting.

This Is Different From a Software Camera Permission

Phones already have camera permissions.

An app asks the operating system for access.

The user grants or denies that request.

Meta’s Capture LED safeguard operates at a different layer.

The wearer may otherwise be allowed to use the camera, but the device can still make capture unavailable when the physical recording indicator fails a required condition.

So there are at least two different kinds of rules we can think about:

User or app permission → is this software allowed to access the camera?

Device safeguard → is the physical capture system in a state where the camera is permitted to operate?

Those are separate questions.

The first is mainly about software authority.

The second connects hardware state to camera availability.

Wearable devices create more opportunities for these layers to interact.

Hardware and Firmware Can Become Enforcement Points

Modern devices increasingly distribute operating rules across several layers.

A physical component can expose a state.

A sensor or monitoring circuit can detect that state.

Firmware can interpret it.

The operating system or device software can apply a rule.

The camera controller can then allow or deny a capture request.

Meta has not published enough detail to say precisely how every part of that chain is implemented in its glasses.

But the published behavior demonstrates the broader architecture.

A policy does not always need to be a checkbox or a warning dialog.

It can be expressed as a condition the device must satisfy before another hardware capability becomes available.

That is especially relevant for wearables because many of their sensors operate continuously around other people and environments.

From a systems perspective, the disclosed behavior resembles a fail-closed rule for camera capture: when a required indicator condition is not satisfied, the protected capability becomes unavailable. That is a useful engineering pattern because the device does not need to wait until a photo or video has been saved or shared before applying the rule.

That phrase is only a systems description, not Meta’s own published terminology. Meta has not released the full state machine behind the safeguard. What the company has confirmed is enough to establish the direction: the physical indicator is monitored, a condition can be detected, and camera availability can change as a result.

This creates a direct bridge between a visible hardware component and the software policy controlling another hardware component.

What Meta Has Confirmed — and What It Has Not

Meta has confirmed several important details.

Every pair of its AI glasses has a white Capture LED.

The light blinks briefly for a photo and continues blinking during video capture.

The Capture LED has no ordinary off switch.

Beginning with the second generation, the camera can automatically be disabled when the system detects that the LED is blocked.

Photos and videos remain unavailable until the system detects that the light is unblocked.

Meta also says it is updating the glasses to disable the camera when physical tampering with or destruction of the Capture LED is detected.

What Meta has not publicly detailed is just as important.

The company has not published the complete sensor architecture.

It has not published every tamper-detection threshold.

It has not published a complete classification algorithm for every possible modification.

Those implementation details should not be guessed.

The Bigger Shift Is Making the Indicator Part of the Camera Rule

The white light on a pair of AI glasses looks like a simple interface element.

Technically, it can be much more than that.

Meta has tied camera availability to whether the Capture LED can perform its signaling role on supported glasses.

Cover it and, when that state is detected, camera capture can stop.

Physically tamper with the component and, when that condition is detected, the camera can also be disabled.

The camera does not become less capable as imaging hardware.

The operating rule around when it is allowed to capture becomes more tightly connected to another physical component.

That is the larger engineering shift.

The indicator does not only tell people that the camera is recording.

The camera can depend on the indicator being there.

The same idea may become increasingly relevant as wearable devices add more cameras, microphones and environmental sensors. A visible or physical indicator can be designed not merely as feedback, but as part of the condition under which a sensitive capability is allowed to run.

That does not mean every future wearable will use the same mechanism. It shows one concrete architecture already described by a major device maker: a physical signal for people nearby can be connected to enforcement inside the device itself.

For camera hardware, that makes the indicator part of the operating contract rather than a decorative status light.

Your Camera Doesn’t Have to Follow the Subject Anymore — AI Can Reframe the Video After You Shoot It

For most of the history of video, framing happened while you were recording.

If a person moved left, you moved left. If they crossed the frame, you followed them. If you lost them behind someone else, the shot changed with them.

Samsung’s My FanCam on the Galaxy Z Fold8 series moves part of that job into editing.

The feature lets you open an existing video, choose a person and have the phone automatically track that person through the clip. It then reframes the footage around the selected subject and lets you choose an aspect ratio for the finished result.

Samsung explained the engineering behind My FanCam on September 1, 2026. The interesting part is not that AI can crop a video.

It is that the phone is separating two decisions that used to happen at the same time: capture the whole scene first, then decide who the camera should have been following.

That matters because a wide recording can preserve more than one possible story. A concert clip can become focused on one performer. A school event can be reframed around one child. A group video can be turned into several different subject-centered edits without recording the moment again.

The physical camera still points where you pointed it. The final moving frame no longer has to be decided there and then.

My FanCam Starts After the Video Already Exists

My FanCam is not primarily an automatic camera operator working during capture.

Samsung describes the workflow inside Gallery.

You select a video that already exists, launch My FanCam and choose the person you want to follow. The system analyzes the footage, tracks the selected person across frames and creates a reframed result centered on that subject.

That distinction matters.

The original recording can remain wide enough to contain several people. The decision about who becomes the focus is made later.

Samsung also says the feature works with older footage, including videos that were not recorded on a Galaxy device. That means My FanCam is not dependent on special tracking metadata captured only by the Fold8 camera. It can analyze ordinary video as input.

This makes the Fold8 behave as both a camera and an AI editing workstation. The source file is treated as visual evidence that can be reinterpreted after the event, rather than as a composition that became permanently fixed the moment the user stopped recording.

For users, the practical idea is simple: the raw footage preserves the scene, while the AI helps choose the final composition afterward.

The Camera Can Stop Chasing the Subject

A traditional fan-cam style video asks the person holding the phone to do several things at once.

Watch the event. Find the subject. Keep that person in frame. Adjust the phone when they move. Avoid sudden pans. Choose a crop that works for the final platform.

My FanCam moves several of those editing decisions to the phone after capture.

Samsung’s own advice is to shoot at high resolution and leave some extra space around the subject. That wider recording gives the software room to follow movement later.

This is an important inversion.

Instead of trying to create the final composition at the moment of capture, the user can preserve more of the scene and let the final framing happen afterward.

That can also change how a person behaves while recording. Rather than staring at the screen and constantly correcting the frame, they can leave more breathing room and concentrate on keeping the important action somewhere inside the source image.

The camera still records the pixels. The AI decides which part of those pixels should become the moving frame. It is less like replacing the camera operator and more like giving the editor a virtual camera that can move inside the footage later.

Tracking a Person Is More Than Tracking a Position

The central technical problem is identity.

A simple tracker could follow coordinates: the person is here in one frame, then slightly farther right in the next.

Real footage is harder. People cross in front of each other. They turn around. They move quickly. Several people can wear similar colors. A selected subject can disappear behind someone else and return later.

Samsung Research says My FanCam uses an AI model that recognizes both a person’s location and visual characteristics. The model is designed to remember the selected individual across the video so it can continue identifying the same person while the scene changes.

That means the system is solving two connected problems: Where is the person now? Is this still the same person?

The second question is what makes long-range tracking useful for reframing. If the tracker only followed the nearest body-shaped region, it could easily jump to someone else when two people crossed paths.

Identity-aware tracking is therefore the bridge between raw detection and an edit that feels intentional. The system needs continuity, not just repeated detections.

Occlusion Is Where Real Video Becomes Difficult

Tracking looks easy when one person walks across an empty background.

Concerts, school performances, sports days and group videos are not like that.

Bodies overlap. The subject may move behind someone else. They may leave the visible area. They may not even appear until halfway through the recording.

Samsung says these real-world situations were a major part of development. The teams found that models that behaved well in research conditions could respond differently when tested on footage with fast movement and overlapping people.

That led to repeated testing between Samsung Research and the mobile development team.

My FanCam also lets the user move through the video and select the subject at a moment when that person is clearly visible. So the system does not force the user to identify someone in the opening frame. The useful frame can be anywhere in the clip.

That small interface decision is technically meaningful. It lets the human provide a cleaner identity example when the beginning of the video is visually ambiguous. Instead of pretending the AI can infer everything from a difficult first frame, the workflow gives the user a practical way to help the tracker start from better evidence.

The Phone Analyzes More Than One Person at a Time

There is another design decision hidden behind the editing interface.

A group video may contain several people the user wants to try. One implementation could analyze the clip again every time the user selects someone new.

Samsung chose a different approach.

After the initial analysis, My FanCam can let the user switch between detected people without repeating the full wait each time. Samsung says the feature analyzes multiple people together so that changing the selected subject can show a result immediately after the first analysis completes.

This is a user-experience decision built on computation.

The system spends time understanding the clip once, then reuses that analysis for multiple editing choices. That matters in a real Gallery workflow because experimentation is part of editing. A user may not know which person produces the best result until they preview several options.

By doing more of the expensive analysis upfront, the feature turns later subject changes into interactive choices rather than repeated batch jobs.

The AI model becomes part of the editing timeline rather than a one-shot effect applied to a single person.

Samsung’s Official Camera Video Shows the Broader Editing Direction

Samsung published an official Galaxy Z Series video in July titled “AI-Powered Camera: Effortless Shooting and Editing.”

The video predates the September 1 engineering interview and is not a recording of that interview.

It is useful here because it shows the broader camera-and-editing direction Samsung introduced with the 2026 Galaxy Z lineup, including AI-assisted ways to turn captured footage into a more deliberate final result.

My FanCam fits directly into that direction.

The phone is not only trying to improve the image at the moment the shutter is pressed. It is becoming an editing system that can reinterpret what was already captured.

That distinction is important for the article because the September interview explains the engineering, while the official video provides visual product context. Together they show the same shift from two sides: one explains how the tracking pipeline was built, and the other shows how Samsung is packaging AI-assisted camera editing as part of the wider Galaxy Z experience.

All of the Person Tracking Runs On-Device

Samsung says the My FanCam AI workload runs entirely on the device without requiring a separate server for the tracking process.

That creates a very different engineering constraint from running a large video model in a data center.

Video is computationally expensive. A longer clip contains more frames. Each frame has to be decoded, analyzed and connected to what the model already knows about the people in previous frames.

Doing that locally also means working inside the phone’s limits for processing speed, power consumption and heat.

Samsung Research says it optimized the AI model to reduce the required computation. The mobile team also optimized the surrounding pipeline, including video decoding, data transfer and analysis.

On-device processing also changes the interaction model. The feature can work as a local editing function instead of requiring the user to send every source video to a remote processing service before seeing a result.

The model is only one part of the feature. The complete path from compressed video file to tracking result has to fit inside a phone and still feel reasonable enough for ordinary Gallery editing.

The Video Pipeline Matters as Much as the AI Model

AI features are often described as if the model receives perfect input instantly.

A real mobile video workflow has more stages.

The file has to be opened. Compressed frames have to be decoded. Image data has to move through memory. The tracking model has to process the frames. The selected crop has to be previewed. The final video has to be rendered.

Samsung specifically points to optimization across video decoding, data transfer and analysis because every stage can add compute, latency and energy use.

This is why My FanCam is an interesting mobile-AI example.

The user sees one button and one subject selection. Behind that interaction is a pipeline that has to keep the AI workload practical enough for a consumer phone.

A fast model can still feel slow if decoding or memory movement becomes the bottleneck. Likewise, efficient video handling cannot help if the tracker itself is too computationally heavy.

The feature only works as a product when all of those components are engineered together. My FanCam is not just a tracking model. It is a tracking model integrated into a complete video-processing system.

Reframing Is a Crop That Moves Through Time

A still-image crop chooses one rectangle.

Video reframing chooses a rectangle again and again as time moves forward.

If the subject walks across the original frame, the crop has to move with them. If the output is vertical, the available horizontal space changes. If the output is wide, the system has more room around the person.

My FanCam lets the user adjust the aspect ratio after the subject has been selected.

That means the same original video can support more than one final composition. The AI tracking provides the subject path. The aspect ratio defines the shape of the output window. The editing system combines the two.

This makes reframing a temporal problem rather than a single crop decision. The system has to preserve a usable composition across a sequence of changing positions instead of simply centering one frame.

It is especially useful for footage that may later be shared in different formats, because the capture does not have to commit to one social-video shape at the moment it is recorded. One wide source can become different subject-centered versions later.

Old Footage Becomes New Input

One of the most useful details in Samsung’s September interview is that My FanCam works with existing videos.

Samsung’s developers mention old concert clips, trips, children’s activities and other previously recorded footage. They also say the source video does not have to come from a Galaxy device.

That widens the feature beyond the camera hardware that ships with the Fold8 series.

The phone can act as an AI editing device for footage that already exists elsewhere.

This is a different kind of upgrade from improving the next photo you take. It can change how you use videos you already own.

A wide group recording from years ago can potentially become a subject-focused edit today, provided the footage contains enough usable visual information for the tracker.

That gives AI editing a backward-looking value. New hardware is often sold around the quality of future captures. My FanCam can also create a reason to revisit an archive, because the source footage becomes raw material for an editing capability that did not exist when the clip was recorded.

Wider Capture Gives the AI More Room to Work

Post-capture reframing still depends on what was captured in the first place.

Samsung recommends recording at a high resolution and framing a little wider when possible.

The reason is geometric.

If the subject reaches the edge of the original frame, there is no image outside that boundary for the software to recover. If the original video is already tightly cropped, a moving digital crop has less room to follow the person.

A wider source frame preserves more spatial margin. Higher resolution also gives the final crop more pixels to work with.

That creates a practical tradeoff. Shooting wider may look less finished as raw footage, but it can preserve more editing freedom. Shooting tighter can produce a stronger composition immediately, but it leaves less room for a virtual camera to move later.

This does not mean every wide video will produce the same result, and Samsung does not publish a universal quality threshold for all footage.

AI can move the frame inside the captured image. It cannot invent an unlimited camera view beyond it.

Capture and Composition Are Becoming Separate Stages

This is the larger camera shift.

Smartphone photography has already separated capture from many traditional camera decisions.

HDR can combine exposures after the shutter press. Portrait modes can estimate depth and change background rendering. Computational zoom can combine sensor data and processing.

My FanCam applies a similar separation to moving composition.

The original camera records a scene. The final virtual camera can be decided later.

That does not make physical camera movement irrelevant. Optical perspective, motion blur, exposure, focus and what actually enters the frame are still determined during capture.

But composition is becoming less final.

The recorded frame can become a larger canvas from which a second, moving frame is generated during editing. In that sense, mobile video is borrowing a workflow that is familiar in high-resolution production: capture more image area than the final output needs, then use the extra pixels to create movement and alternative framing in post.

What changes on the phone is accessibility. The tracking and crop path can be generated automatically instead of being built manually frame by frame.

This Is Not the Same as Generating Missing Video

It is useful to keep My FanCam separate from generative-video systems.

Samsung describes the feature as tracking and reframing a selected person in existing footage.

The core idea is not to generate a new performance or synthesize a person who was not present. The system is following visual information that already exists in the source video and selecting a moving region around it.

That distinction matters because “AI video” now covers several very different technologies.

One system may generate frames from text. Another may remove an object. Another may interpolate motion. Another may estimate depth or reconstruct detail.

My FanCam is primarily a person-tracking and reframing workflow.

Its value comes from changing the edit around existing footage rather than creating an entirely new scene.

Keeping those categories separate also makes the technical achievement easier to understand. The challenge here is persistent identity tracking, mobile computation and a usable moving crop. It is not open-ended scene synthesis.

What Samsung Has Confirmed — and What It Has Not

Samsung has confirmed several important details.

My FanCam can automatically track a selected person through a video. The underlying AI model uses location and visual characteristics to recognize individuals. Multiple people can be analyzed during the initial pass so the user can switch subjects afterward. The workload is processed on-device. The feature can work with existing videos, including footage not captured on a Galaxy phone. Users can adjust the output aspect ratio.

Samsung has also described the engineering challenges around occlusion, fast movement, processing speed, power and heat.

There are limits to what we should infer.

Samsung has not published a universal tracking-accuracy percentage for every scene. It has not said every person in every video can always be recovered after being fully obscured. It has not claimed that post-capture reframing replaces careful shooting. And it has not described the system as generating unseen parts of the scene outside the source frame.

The confirmed feature is narrower and more useful: the final subject can be chosen after the scene has already been recorded, with the phone building the crop path around that person.

The Bigger Upgrade Is a Camera You Can Aim After Recording

The most interesting thing about My FanCam is not the name or the fan-cam use case.

It is the timing of the creative decision.

A traditional camera asks you to decide where to point before the moment passes. Samsung’s feature lets the original recording hold a wider version of the moment, then uses on-device AI to decide which person the final frame should follow.

The camera still matters. The source resolution still matters. Where you stand still matters. What enters the original frame still matters.

But one part of directing the shot has moved into editing.

That gives smartphone video a new workflow: record the scene, select the subject, let the phone reconstruct the framing path, then choose the output shape.

It also suggests a broader direction for computational cameras. AI does not have to change what the sensor captured to change how the moment is presented. Sometimes the useful upgrade is simply being able to make a better decision later.

The camera does not literally move after recording.

The frame can.

And for everyday video, that may be the more useful change.

Global Shutter Is Scaling Into a 105-Megapixel Machine-Vision Sensor

Global shutter used to be discussed mainly through one camera behavior.

Capture the whole frame at the same instant.

That remains the foundation.

What is changing is scale.

Sony’s IMX927 pushes global-shutter imaging to approximately 105.51 effective megapixels while delivering about 100 frames per second at 10-bit output.

Sony announced the sensor in September 2025 and began sample shipment in November.

The device uses a 10,272 × 10,272 active-pixel array.

Its image diagonal is 39.7 millimeters.

Each pixel measures 2.74 micrometers.

The sensor belongs to Sony’s Pregius S family for industrial imaging.

This is not a smartphone camera and not a cinema sensor.

It is designed around machine vision.

Automated optical inspection.

Three-dimensional inspection.

Precision component recognition.

Large-object measurement.

The important shift is that global shutter is no longer only about preserving the geometry of fast motion.

It is now being combined with very high pixel count, high-speed readout and industrial interfaces so one sensor can capture large areas in detail without giving up fast acquisition.

Global Shutter Samples the Whole Image Plane at One Moment

A CMOS image sensor needs a defined exposure strategy.

With a global shutter, all pixels collect the relevant exposure during the same time interval.

Sony’s Pregius architecture uses a light-receiving photodiode section together with a memory section inside the pixel structure.

The light information is captured simultaneously across the image plane.

The stored signals can then be read out afterward.

That separation matters.

Exposure and readout do not have to be the same event.

The sensor can freeze the optical state first.

Then it can move the stored information through the downstream electronics.

For machine vision, this gives the processing system one geometrically consistent observation of the scene at the exposure instant.

A rotating component.

A moving conveyor.

A robot-carried part.

A projected structured-light pattern.

The complete image corresponds to one shared exposure window.

That is why global shutter is common in industrial measurement systems where pixel coordinates are used as geometry, not only as appearance.

Line-Sequential and Global Exposure Represent Time Differently

Rolling-shutter and global-shutter sensors use different temporal models.

A line-sequential sensor exposes different rows at slightly different moments.

A global-shutter sensor captures the complete frame during the same exposure interval and reads the stored signals afterward.

Both architectures are useful in different camera systems.

For machine vision, the global-shutter model has a specific advantage when image coordinates need to correspond to one known instant.

If a component moves while an image is being sampled line by line, different rows describe different points in that motion.

If the entire sensor samples together, the frame represents one shared temporal state.

That is especially useful when software will measure edges, hole locations, alignment marks or three-dimensional geometry.

The image becomes a measurement surface.

Timing is part of the measurement.

The IMX927 Captures More Than 105 Million Pixels in Every Frame

The IMX927 active array measures 10,272 pixels horizontally and 10,272 vertically.

That produces approximately 105.51 million effective pixels.

At around 100 full frames per second, the sensor is producing roughly 10.5 billion pixel samples every second before bit depth and protocol overhead are considered.

That is the engineering scale behind the headline number.

High resolution gives the inspection system more spatial samples across the object.

High frame rate gives it more complete observations per unit of time.

Combining both means the rest of the camera system has to handle a very large continuous data stream.

Sensor readout.

Analog-to-digital conversion.

Output lanes.

FPGA input.

Memory.

Processing.

Storage or inference.

The sensor therefore changes the machine-vision system around it.

A 105-megapixel frame is not useful at 100 FPS unless the downstream pipeline can keep moving the data.

Sony Uses Pregius S to Keep the Pixel Structure Compact

The IMX927 uses Sony’s Pregius S global-shutter technology.

Pregius S combines a back-illuminated pixel structure with stacked CMOS architecture.

Moving the wiring and much of the processing structure behind the light-receiving region gives the pixel more direct access to incoming light.

The stacked design also creates additional area for signal-processing circuitry.

Sony uses that architecture to combine global shutter with 2.74-micrometer pixels.

That pixel pitch is important because a 105-megapixel sensor would become physically much larger if each pixel required a wide conventional footprint.

The IMX927 still uses a large Type 2.5 sensor format, but the small pixel architecture lets Sony fit 10,272 × 10,272 pixels inside a 39.7-millimeter diagonal.

The result is a sensor designed for both spatial density and high-speed industrial capture.

High Pixel Count Changes How Much of an Object One Camera Can Inspect

Machine-vision resolution is usually tied to a field of view.

A camera may inspect one connector.

One semiconductor package.

One section of a display.

One mechanical assembly.

If the system needs more detail, it can use higher optical magnification, more cameras or a higher-resolution sensor.

A 105-megapixel global-shutter sensor changes that trade space.

The system can cover a larger physical area while retaining many pixels across small features.

Sony specifically positions IMX927 for inspections of precision components, semiconductors, flat-panel displays and larger objects.

That can reduce the need to divide one object into as many separate image regions.

The exact camera design still depends on optics, working distance and required measurement precision.

But the sensor gives system designers a much larger native sampling grid.

One exposure can contain both broad context and fine local detail.

100 FPS Changes the Inspection Takt-Time Equation

Resolution alone is not enough on a production line.

The camera also has to finish acquisition fast enough for the inspection cycle.

Sony specifies the IMX927 at 112 FPS in 8-bit mode, 102 FPS in 10-bit mode and 73 FPS in 12-bit mode for all-pixel readout.

Sony markets the 10-bit operating point as approximately 105 megapixels at 100 FPS.

That combination matters because inspection time includes image acquisition.

If a three-dimensional method needs several projected patterns, the camera must capture each pattern.

If automated optical inspection needs several lighting conditions, the camera may need several frames.

A higher full-resolution frame rate lets those image sets be collected in a shorter period.

Sony connects the IMX927 directly to shorter measurement and inspection times in advanced AOI and 3D inspection workflows.

The sensor is therefore increasing both the information per frame and the number of high-resolution frames available during the same machine cycle.

Three-Dimensional Inspection Can Use the Extra Frames as Measurement Inputs

Many industrial 3D systems do not create depth from one image.

They capture several images under controlled illumination.

Structured-light systems project patterns onto the object.

The camera records how those patterns deform across the surface.

Software then calculates three-dimensional shape from the image sequence.

Other systems use laser lines or multiple exposure conditions.

The IMX927 is designed for this type of multi-image workflow.

Sony lists 3D automated optical inspection, structured-light inspection and laser-based inspection among the intended applications.

The high pixel count gives each projected pattern a dense spatial measurement.

The high frame rate lets the system acquire several pattern states quickly.

Global shutter keeps each individual pattern capture tied to one exposure instant.

The three specifications therefore work together.

Resolution.

Speed.

Synchronized full-frame exposure.

That combination is what makes the sensor interesting for measurement, not simply the megapixel count by itself.

The Readout Electronics Had to Scale With the Pixel Array

Moving 105 megapixels at about 100 FPS requires a readout architecture designed for parallel work.

Sony says the IMX927 Series uses a new circuit structure derived from the earlier IMX925 generation.

The design increases internal signal-processing speed and parallelizes processing.

The pixel data is converted and moved through the sensor while keeping up with the full-array acquisition rate.

This is an important point.

A sensor can contain a very large pixel array without being able to read that array quickly.

It can also read quickly at a lower resolution.

The IMX927 is designed to do both at once.

The pixel architecture captures the image.

The stacked circuitry processes the signals.

The output interface carries the result into the camera.

The high-speed headline therefore belongs to the complete sensor architecture, not to the photodiode alone.

SLVS-EC Moves the Data Out at Up to 12.474 Gbps Per Lane

The IMX927 uses Sony’s SLVS-EC high-speed sensor interface.

The current specification lists lane rates of 4.752, 9.504 and 12.474 gigabits per second.

Several lane configurations are supported, including multi-lane arrangements designed for the sensor’s very high data volume.

Sony says the IMX927 Series can reach around 100 Gbps of image-data transfer.

That number explains why the interface matters.

The sensor is producing tens of megabytes in every uncompressed high-bit-depth frame.

At around 100 frames each second, camera electronics have to receive and process a continuous multi-gigabyte-per-second stream.

The interface is the bridge between the sensor and the next stage.

An FPGA or other processing device can then perform unpacking, correction, feature extraction, measurement or forwarding.

High-speed machine vision is therefore as much a data-movement problem as an imaging problem.

The FPGA Becomes Part of the Camera Architecture

Industrial cameras often place programmable logic close to the image sensor.

An FPGA can receive the high-speed sensor lanes.

It can synchronize triggers.

Reformat pixel data.

Apply corrections.

Crop regions.

Aggregate measurements.

Forward selected data into the host interface.

With a sensor like IMX927, that near-sensor processing becomes especially relevant because the raw stream is very large.

Not every application needs to store every full frame.

A camera can use local processing to turn images into measurements before the data travels farther.

That is one reason machine vision differs from consumer photography.

The desired output may not be a JPEG.

It may be a coordinate.

A defect map.

A pass/fail result.

A three-dimensional point cloud.

The 105-megapixel frame is the raw measurement surface.

The machine-vision pipeline decides what information needs to leave the camera.

The New Ceramic Package Is Designed Around Industrial Camera Integration

Sony also changed the package around the sensor.

The IMX927 Series uses a ceramic package with connectors.

The IMX927 package measures 45 × 52 millimeters and uses two 160-pin connectors.

Sony designed the package so the sensor can be attached to and removed from a camera module rather than requiring the same surface-mount approach used by many smaller image sensors.

The series also standardizes connector layouts across related sensor models.

That gives camera manufacturers more flexibility when building a family of systems around different resolutions and frame rates.

The package includes a heat-dissipation structure designed for stable long-term operation.

This is another sign that the IMX927 is a system component rather than only a silicon specification.

Mechanical mounting.

Electrical connection.

Thermal behavior.

Sensor replacement.

They all become part of the industrial camera design.

The IMX927 Series Scales the Same Architecture Across Several Sensor Sizes

Sony did not release the IMX927 as one isolated device.

The broader IMX927 Series includes sensors at several image sizes and resolutions.

The lineup spans approximately 12.69 megapixels through 105.51 megapixels.

The IMX928 provides about 68.16 megapixels.

The IMX929 provides about 50.79 megapixels.

Other variants trade resolution and frame rate differently.

That gives machine-vision designers a family rather than one fixed operating point.

A smaller inspection area may benefit from a lower-resolution sensor with a higher frame rate.

A large-area inspection may use the 105-megapixel model.

The common architecture and connector strategy can simplify camera-family design across those choices.

This is how a high-end sensor becomes a platform.

The top model demonstrates the maximum scale.

The series lets the camera system move along the resolution-speed spectrum.

Color and Monochrome Versions Support Different Measurement Tasks

The IMX927 is available in monochrome and Bayer-color versions.

That choice matters in machine vision.

A color sensor can separate visible color information and support applications where material or print color is part of the inspection.

A monochrome sensor does not use the same Bayer color-filter pattern and can dedicate its pixel response directly to luminance-related measurement.

The right version depends on the task.

A printed package may need color analysis.

A dimensional measurement may care mainly about edge position.

A semiconductor inspection system may use controlled illumination selected for contrast rather than natural appearance.

Sony therefore offers both versions inside the same sensor family.

The global-shutter timing and high-speed architecture remain shared.

The optical measurement layer can be selected around the application.

Sony Is Demonstrating the Sensor on Fine Mechanical Detail

Sony continued showing the IMX927 after its 2025 launch.

At the Advanced Packaging and Chiplet Summit held in December 2025, Sony demonstrated the 105-megapixel, 100-FPS global-shutter sensor by imaging the interior of a mechanical watch.

The example is useful because a watch contains many small structures inside one larger assembly.

A high-resolution sensor can capture a broad field while still resolving local mechanical detail.

The demonstration does not define every industrial use case.

It illustrates the type of inspection geometry the sensor is designed to address.

Electronics.

Precision assemblies.

Semiconductor manufacturing.

Flat-panel displays.

Large objects with small features.

The same imaging principle appears across all of them.

Capture a large amount of spatial information at one instant, then move the next high-resolution frame quickly enough for the machine cycle.

Global Shutter Is Becoming a High-Resolution Measurement Platform

The IMX927 shows how global shutter is scaling.

The exposure architecture still starts with one familiar principle.

All pixels sample the scene together.

But the surrounding system is much larger now.

10,272 × 10,272 effective pixels.

Approximately 105.51 megapixels.

Around 100 FPS at 10-bit output.

2.74-micrometer Pregius S pixels.

Back-illuminated stacked architecture.

High-speed parallel readout.

SLVS-EC lanes approaching a 100-Gbps image-data stream.

A removable ceramic package designed for industrial cameras.

Support for AOI and multi-frame 3D inspection.

That is no longer only a fast-motion camera feature.

It is a measurement platform.

The sensor can capture a large object in detail.

Freeze the full field at one exposure instant.

Repeat that capture rapidly.

Then feed the results into inspection software that turns images into geometry, defects and manufacturing decisions.

Global shutter is scaling from motion capture into high-resolution machine vision.

That is the upgrade.

LOFIC Changes What Happens When a Pixel Collects Too Much Light

A camera pixel has to collect light without losing detail at either end of the scene.

Dark areas produce small electrical signals.

Bright areas can produce much more charge.

The sensor has to preserve both.

LOFIC changes the way that charge is stored.

The name stands for Lateral Overflow Integration Capacitor.

When the photodiode reaches its normal charge capacity, additional charge can overflow into another storage region instead of ending the measurement at the photodiode alone.

Sony brought this structure into its LYTIA mobile lineup with the LYTIA L910 announced on June 17, 2026.

The sensor is designed for smartphones.

It has approximately 50 effective megapixels.

It uses a 1/1.28-type format with 1.22 micrometer pixels.

Sony says the combination of LOFIC, Triple Conversion Gain HDR and new low-noise circuitry produces 100 dB of dynamic range from a single exposure.

The important change is not a new camera app mode.

It happens inside the image sensor before the phone begins its later computational-photography pipeline.

Dynamic Range Starts With How Much Signal the Pixel Can Represent

Dynamic range describes the span between the darkest useful signal and the brightest signal the imaging system can record before saturation.

Both ends matter.

A pixel needs enough sensitivity and low enough noise to preserve weak signals in shadows.

It also needs enough charge capacity to preserve bright areas before the pixel saturates.

Those two requirements pull the sensor in different directions.

A high-gain readout is useful for small signals.

A large full-well capacity is useful for strong signals.

Modern image sensors therefore use several circuit techniques to read the same exposure in different ways.

LOFIC addresses the bright end by adding charge-storage capacity.

Sony then combines that extra capacity with multiple conversion gains so the same exposure can be read across different signal ranges.

The result is a wider electrical representation of the scene before image processing begins.

The Photodiode Is the First Charge Container

A CMOS image sensor pixel begins with photoelectric conversion.

Incoming photons generate electrons inside the photodiode.

During the exposure, the pixel accumulates that charge.

After the exposure, the sensor converts the stored charge into an electrical signal that can be measured and digitized.

The amount of charge the photodiode can store is finite.

That storage limit is one of the factors behind highlight saturation.

If a bright region creates more charge than the ordinary storage path can represent, the sensor needs another way to preserve that information.

LOFIC adds that second path.

The additional charge is not treated as unrelated data.

It belongs to the same exposure.

That is why the architecture can increase the bright-signal range without requiring the scene to be photographed again at another exposure time.

LOFIC Adds a Lateral Overflow Storage Path

Sony’s explanation of LOFIC is straightforward.

A conventional pixel stores photo-generated charge primarily in the photodiode and related floating-diffusion node used for readout.

A LOFIC pixel adds an additional capacitor connected to that charge path.

When the normal storage region approaches its capacity, overflow charge can be transferred laterally into the added capacitor.

The system therefore gains another charge reservoir.

Sony’s STARVIS 3 implementation in the IMX908 security sensor uses the same general LOFIC principle and gives a useful technical reference for how the structure works.

Sony says the added floating-diffusion capacitance greatly expands saturation charge in that design.

The exact pixel architecture differs by product, but the general idea is common.

Do not discard the strong signal when the first container fills.

Give the pixel another place to keep it.

That extra stored charge extends the measurable highlight range.

LYTIA L910 Is Sony's First Mobile LYTIA Sensor With LOFIC

Sony had already used LOFIC in other image-sensor categories before bringing it to LYTIA.

The L910 is the first LYTIA-branded mobile sensor to adopt the structure.

That matters because smartphone cameras have different constraints from larger industrial or security-camera systems.

The sensor has to fit inside a thin device.

Power matters because the camera shares the phone battery with the display, processor, modem and other components.

Video has to run continuously.

Autofocus has to remain available.

The imaging pipeline also has to support high-resolution stills and several video modes.

Sony designed L910 as a stacked CMOS image sensor with approximately 50 megapixels, a 12.49 mm diagonal and 1.22 micrometer unit cells.

Mass-production shipment was scheduled for summer 2026.

The LOFIC architecture therefore arrives inside a sensor designed specifically around the mobile-camera envelope.

Single-Exposure HDR Changes Where the Dynamic Range Comes From

Smartphone HDR can be created in several ways.

One common approach combines images captured at different exposure conditions.

Another approach reads different signal ranges from one exposure.

L910’s TCG-HDR with LOFIC belongs to the second category.

Sony says the sensor reaches 100 dB of dynamic range from a single exposure.

The scene is exposed once.

The sensor then reads the accumulated charge through several conversion-gain paths.

That means the wide dynamic range originates largely in sensor charge capacity and readout architecture before the phone combines later computational steps.

Sony also says single-exposure operation changes how moving subjects and light-source flicker are handled because the sensor does not need to synthesize several differently timed exposures for this HDR mode.

The distinction is architectural.

The HDR information is captured together in one exposure window.

Triple Conversion Gain Reads One Exposure at Three Signal Ranges

LOFIC is only one part of the L910 system.

Sony combines it with Triple Conversion Gain HDR, or TCG-HDR.

Conversion gain controls how efficiently stored charge is converted into a measurable voltage.

Different gain levels are useful for different signal strengths.

A high conversion gain can make a small amount of charge easier to distinguish.

A lower gain can represent a larger charge quantity before the readout reaches its own limit.

TCG-HDR reads the charge obtained from one exposure at three conversion gains.

That gives the sensor several electrical views of the same exposure.

The low-signal path can preserve detail in darker areas.

The larger-signal paths can represent progressively brighter regions.

The phone’s image pipeline can then combine those readings into one HDR result.

The key point is that the three gain readings originate from the same exposure, not three separately timed captures.

UHCG Targets the Dark End of the Same Range

The bright end of dynamic range gets more storage from LOFIC.

The dark end needs a clean readout of small signals.

Sony adds Ultra High Conversion Gain circuitry to L910 for that side of the problem.

UHCG increases charge-to-voltage conversion efficiency for weak signals.

Sony says the new circuit technology reduces random noise by approximately 30 percent compared with the LYTIA 828 under Sony’s stated comparison conditions.

That figure belongs to Sony’s product comparison.

The architectural role is clear.

LOFIC increases the range available for high signal levels.

UHCG improves the electrical treatment of low signal levels.

TCG-HDR connects multiple gain ranges across the exposure.

The 100 dB figure comes from the combined sensor architecture rather than from one capacitor acting alone.

A 100 dB Sensor Range Represents a Very Large Light Ratio

A decibel figure can feel abstract until it is translated into a ratio.

For an amplitude-like imaging signal, 100 dB represents a very large span between the smallest and largest usable levels.

Camera dynamic-range conventions and measurement methods matter, so a published dB number should always be read within the manufacturer’s stated test method.

Sony’s claim for L910 is 100 dB from its single-exposure TCG-HDR with LOFIC implementation.

The practical meaning is that the sensor is designed to preserve information across scenes containing very bright and much darker regions at the same time.

Sony uses night scenes with bright LED lighting as one example.

A phone may need to retain the illuminated sign while also preserving detail in surrounding buildings, streets or people.

The sensor gives the later image pipeline more captured signal to work with before tone mapping decides how that range will appear on the final display.

Sensor Dynamic Range and Display Dynamic Range Are Different Layers

Capturing 100 dB does not mean a phone screen simply shows the raw sensor values unchanged.

Capture and display are separate stages.

The sensor measures the scene.

The image signal processor converts and combines the readouts.

Color processing maps sensor values into an image space.

Tone mapping decides how a very wide scene range should fit into the output format and display capabilities.

An HDR display can present a wider range than a standard display, but it still receives a processed image.

This is why sensor dynamic range matters even when the final picture is heavily computational.

The processor can only work with information that reached it.

If the sensor preserved highlight and shadow signal during capture, the computational pipeline has more source data available when producing the final photograph or video.

LOFIC therefore sits underneath computational photography rather than replacing it.

The Architecture Is Designed for 4K 60 FPS HDR Video Too

Still photography is only one workload.

A smartphone sensor also has to maintain HDR while producing a continuous video stream.

Sony says L910 supports 4K2K video at 60 frames per second using 2×2 binning in TCG-HDR with LOFIC mode.

The sensor also supports 12.5 megapixel output at 60 FPS in the same HDR mode.

Video changes the engineering problem because the sensor repeats the readout continuously.

Analog-to-digital conversion has to complete on time.

The data interface has to move the result.

The image processor has to keep up.

The sensor has to remain within the phone’s thermal and power design.

Sony says it redesigned logic and analog-to-digital conversion circuitry to reduce conversion time and power consumption while maintaining the HDR mode.

That makes LOFIC part of a video architecture rather than only a still-image feature.

Circuit Design Matters Because HDR Has to Fit Inside a Phone Power Budget

Every additional sensor operation consumes time and electrical energy.

A high-resolution mobile camera may be active for minutes during video recording.

The camera subsystem therefore cannot be designed around image quality alone.

Sony says L910 uses optimized circuits and advanced processes to shorten the time needed for analog-to-digital conversion.

The company links that change to lower sensor power use during HDR operation.

The exact phone-level battery result depends on the rest of the device, so the relevant claim is at the sensor architecture level.

The important point is that LOFIC had to arrive with a readout system designed for mobile use.

More charge capacity is useful only if the sensor can read, convert and transmit the information within the required frame time and power envelope.

The storage architecture and the logic architecture therefore develop together.

Quad Bayer Keeps the Sensor Flexible Across Resolution and Sensitivity Modes

L910 uses Quad Bayer Coding.

Four neighboring pixels share the same color-filter arrangement in a repeated block.

That gives the sensor several output options.

At full resolution, L910 can output approximately 50 megapixels at up to 30 FPS with full-pixel autofocus according to Sony’s published specification.

In 2×2 binned modes, the sensor can produce approximately 12.5 megapixel output at higher frame rates.

Binning combines the signal from neighboring pixels into a lower-resolution output.

That can be useful for video and other modes where sensitivity, readout speed and manageable data volume matter more than the full 50-megapixel image.

LOFIC therefore does not exist in isolation from the rest of the mobile sensor design.

It operates inside a Quad Bayer, stacked CMOS architecture that has to support several capture modes.

Sony's IMX908 Shows LOFIC Is Becoming a Broader Sensor Architecture

The mobile L910 is part of a wider movement inside Sony’s sensor portfolio.

In March 2026, Sony announced the IMX908 for security cameras.

That sensor also uses LOFIC, under Sony’s STARVIS 3 technology.

The IMX908 is an 8.4-megapixel 1/2.8-type sensor with 1.45 micrometer LOFIC pixels.

Sony says it reaches 96 dB of dynamic range from a single exposure.

The application is different.

Security cameras emphasize continuous observation, low-light imaging and machine recognition.

Smartphones emphasize photography, video, compact design and battery operation.

The common architecture is charge handling inside the pixel.

That shows LOFIC is not merely one phone feature.

It is becoming one method Sony can adapt across sensor categories when the imaging system needs a wide single-exposure signal range.

The Camera Pipeline Now Starts With More Information Inside the Pixel

Modern phone photography is often described as computational photography.

That is accurate, but the computation begins with the electrical information delivered by the sensor.

LOFIC changes that starting material.

The pixel can retain more charge at the bright end.

Multiple conversion gains read different signal ranges.

UHCG improves low-signal conversion.

The stacked sensor digitizes the result.

The image signal processor then receives those measurements and performs the later computational work.

This creates a layered pipeline.

Photon capture.

Charge storage.

Gain conversion.

Analog-to-digital conversion.

HDR combination.

Demosaicing.

Noise processing.

Color.

Tone mapping.

Encoding.

The final image depends on all of them.

LOFIC moves one important part of HDR earlier in that chain.

The dynamic-range expansion begins while the pixel is still storing light-generated charge.

LOFIC Gives Phone Cameras a New Way to Capture Extreme Dynamic Range

LYTIA L910 shows why sensor architecture still matters in computational photography.

The phone does not begin with a finished image.

It begins with charge inside millions of pixels.

LOFIC gives bright-signal charge another storage path when the primary pixel capacity fills.

TCG-HDR reads one exposure through three conversion gains.

UHCG improves low-signal conversion.

Sony says the combined system reaches 100 dB of single-exposure dynamic range.

The same sensor supports approximately 50 megapixels, 4K60 HDR, Quad Bayer operation and all-pixel autofocus.

Circuit changes are designed to keep the HDR readout inside a mobile power budget.

The result is not the end of computational HDR.

It changes the information available before computational HDR begins.

More of the scene’s light range can be preserved at capture.

The processor then decides how to turn that captured range into the final photograph or video.

The phone camera remains computational.

But the pixel itself is becoming more capable.

That is the upgrade.

Event-Based Vision Changes What a Camera Sends

A conventional digital camera samples the scene in frames. Every exposure produces an image. The next exposure produces another image. Motion is reconstructed from the sequence.

Event-based vision uses a different measurement model.

Each pixel operates independently. When the brightness at that pixel changes beyond a configured threshold, the sensor emits an event. The event contains the pixel coordinates, a timestamp and the polarity of the brightness change.

If nothing changes at that pixel, it does not need to send a new visual value at that moment.

Sony Semiconductor Solutions uses this architecture in its Event-based Vision Sensor family developed with Prophesee. The IMX636 is the HD member of that family.

It has 1280 × 720 effective pixels. But resolution is only part of the story.

The important change is temporal.

The sensor does not wait for the next full frame before reporting movement. Motion itself creates the data.

That gives robotics and machine-vision systems another way to observe fast physical events.

Each Pixel Runs on Its Own Clock

The key word is asynchronous.

A frame camera has a shared image cadence. Thirty frames per second. Sixty. Two hundred. Whatever the system is configured to capture.

An event sensor does not require every pixel to report at the same instant.

One pixel can fire now. Another can fire microseconds later. A third can remain quiet because its local brightness did not change.

Sony describes the IMX636 as detecting luminance changes independently at each pixel and outputting events in the order they are detected.

That creates a continuous stream rather than a stack of complete images.

The time dimension becomes much finer than the nominal frame interval used in ordinary video.

For a robot tracking a fast object, that matters because the useful signal may be the change itself.

The machine does not always need a new copy of the static background. It needs to know that something moved, where it moved and when the change occurred.

An Event Contains Coordinates, Time and Polarity

The output is compact because each event carries a small set of information.

X coordinate.

Y coordinate.

Timestamp.

Polarity.

Polarity tells the processing system whether brightness increased or decreased relative to the sensor’s event threshold.

A moving edge can therefore produce a trail of positive and negative events as it crosses different pixels.

The result does not look like an ordinary photograph by default. It is a stream of changes.

Software can accumulate those events over a selected time window to create a visualization. It can also process the events directly without first turning them into a conventional frame.

That is where event-based vision becomes interesting for machine perception.

The sensor output already contains timing at the level of individual changes. The algorithm can decide how much time to accumulate depending on the task.

The IMX636 Brings Event Sensing to HD Resolution

Sony and Prophesee developed the IMX636 as a stacked event-based vision sensor.

The sensor has approximately 0.92 million effective pixels at 1280 × 720 resolution. Each pixel measures 4.86 micrometers.

Sony combines its stacked CMOS image-sensor architecture with Prophesee’s event-sensing technology.

The sensing layer and event-processing circuitry are integrated into a compact device intended for industrial vision.

Prophesee’s current IMX636 documentation lists pixel latency below 100 microseconds at 1,000 lux and a dynamic range above 120 dB under its specified measurement conditions.

Those are published sensor specifications, not universal application-level results.

The important point is what those specifications enable.

High spatial resolution identifies where the event occurred.

High temporal resolution identifies when it occurred.

Wide operating range helps the sensor continue producing event information across changing illumination.

The sensor becomes a motion-measurement device as much as an image sensor.

Temporal Resolution Is Different From Frame Rate

Frame rate and event timing describe two different things.

A 200 FPS camera produces one complete frame every five milliseconds.

An event sensor can report individual luminance changes between those frame boundaries.

That does not mean an event camera should be described as having an ordinary frame rate of thousands or millions of FPS. There may be no complete frames at all in the native output.

The better description is temporal resolution.

Each event receives a fine-grained timestamp.

The application can then decide how those events should be grouped.

A tracker may process them continuously.

A visualization may collect a few milliseconds of events.

Another algorithm may build time surfaces or other event representations.

This distinction matters because event-based vision is not simply a faster version of the same camera architecture.

It changes the unit of measurement from the complete image to the local brightness change.

Static Parts of the Scene Do Not Need Repeated Pixel Updates

A frame-based camera records the complete image at each frame interval. That includes areas that may not have changed since the previous frame.

Event-based vision concentrates its native output on local changes.

A stationary wall can remain mostly quiet.

A moving object creates events along the regions where its appearance changes over time.

Prophesee says its event-based sensors can produce substantially less data than conventional image streams in suitable dynamic scenes because unchanged pixels do not continuously report new samples.

The exact reduction depends on the scene and sensor configuration.

A busy environment can generate many events. A mostly static environment can generate fewer.

The architecture therefore adapts its data rate to visual activity.

For embedded robotics, that is useful because sensing, transport and computation are connected.

The amount of visual data affects memory bandwidth, processing load, latency and power.

Event-based sensing changes that relationship by making scene change one of the drivers of data production.

Motion Becomes Visible as a Continuous Event Stream

Imagine a table-tennis ball crossing the camera view.

With ordinary video, the ball appears at one position in one frame and another position in the next. The processing system estimates what happened between those samples.

With an event sensor, the moving ball continually changes the luminance measured by pixels along its path.

Those changes generate events as the motion occurs.

The software sees a dense temporal trail around the moving edges of the ball.

That makes event data especially useful when the object moves quickly relative to the required reaction time.

The sensor is not waiting to complete and transfer an entire image before reporting every local change.

It is streaming the change information as it is detected.

That is the sensing principle Sony AI used as one part of the perception system in Ace, its autonomous table-tennis robot.

Ace Shows Event Vision Inside a Real-Time Robot

Sony AI’s Ace system is a useful 2026 example because the robot has to react to a genuinely fast physical object.

The research was published in Nature in April 2026.

Ace plays table tennis against elite and professional-level human players under competition rules.

Its perception system combines conventional active-pixel cameras with event-based vision.

Nine cameras using Sony IMX273 global-shutter sensors cover the playing area and estimate the ball’s three-dimensional position.

Three separate gaze-control systems use Sony IMX636 event-based sensors to help estimate the ball’s angular velocity and spin.

That division of work is important.

The researchers did not treat event vision as a universal replacement for every camera.

They used different sensor architectures for different measurements.

The frame-based system provides full spatial observations.

The event-based systems focus on high-speed motion information.

The robot then combines those measurements inside one control pipeline.

Nine Global-Shutter Cameras Track Position at 200 Hz

Ace uses nine active-pixel-sensor cameras placed around the court.

These cameras use Sony IMX273 global-shutter image sensors.

According to the Nature paper, the system locates the ball in three-dimensional space at 200 Hz.

The researchers report an average position error of 3.0 millimeters and average latency of 10.2 milliseconds for that part of the perception system.

Those figures apply to the Ace research setup.

The full-frame cameras provide the geometric position needed by the controller.

Multiple views make triangulation possible.

Global-shutter capture helps keep fast motion geometrically consistent across each exposure.

This layer answers one main question.

Where is the ball?

Ace then uses another vision system to answer a more time-sensitive motion question.

How is the ball spinning while it travels?

Three IMX636 Systems Measure the Ball's Spin

Spin changes what happens after the ball contacts the table or racket.

A robot therefore needs more than position and linear velocity.

Ace uses three gaze-control systems for angular-velocity estimation.

Each system contains an IMX636 event-based camera.

Pan-and-tilt mirrors keep the sensing direction aligned with the ball. A tunable telephoto lens helps keep the target in focus.

The event stream captures the rapidly changing visual pattern on the moving ball.

The research team processes that stream in two ways.

One method uses a convolutional neural network on accumulated event data for low-latency estimation.

Another uses contrast maximization for a more accuracy-oriented estimate.

The system combines the estimates according to their uncertainty.

The Nature paper reports angular-velocity output at a variable rate of approximately 400 to 700 Hz.

That is a concrete example of event timing becoming part of robot state estimation.

Event Data Can Be Processed Without Becoming Ordinary Video

One useful property of event sensing is that the software does not have to reconstruct conventional video first.

The events can become algorithm input directly.

A tracker can operate on event coordinates and timestamps.

A neural network can consume accumulated event representations.

Optical-flow methods can estimate local motion.

Contrast-maximization algorithms can align events according to a motion hypothesis.

That gives developers several ways to use the same sensor stream.

The time window is part of the algorithm design.

A very short window preserves fine timing.

A longer window collects more spatial structure.

The application decides which representation matches the task.

This is different from a camera where the sensor has already decided that the primary output will be a sequence of complete rectangular images at a fixed cadence.

Event vision gives more of the temporal grouping decision to the perception software.

Wide Dynamic Range Helps When Lighting Changes Around Motion

Fast machines do not always operate under perfectly uniform lighting.

A robot can move between bright and dark regions.

Reflective material can cross a light source.

Outdoor systems can face strong highlights and shadows in the same scene.

Sony and Prophesee designed the IMX636 with a high dynamic range.

Prophesee lists more than 120 dB under its specified low-to-high-light measurement range.

The event-sensing architecture responds to relative luminance changes rather than producing a conventional intensity image at every frame.

That allows motion information to remain available across a wide range of illumination.

The specification belongs to the sensor and its measurement conditions.

Application performance still depends on optics, thresholds, algorithms and the physical environment.

But dynamic range becomes another reason event sensing fits machine vision.

The sensor is designed around detecting change across demanding temporal and lighting conditions.

Industrial Vision Can Use Events for More Than Robotics

Sony lists several industrial applications for event-based vision.

Fast-moving-object detection.

Equipment monitoring.

Movement analysis.

Image recognition.

The same event stream can also support vibration analysis, counting and motion tracking in industrial-camera products built around the Sony-Prophesee sensors.

The common requirement is temporal information.

A production line may need to detect a small change at high speed.

A rotating mechanism may generate a repeating event pattern.

A machine may need to track an object without continuously processing a full static background.

The sensor does not decide the industrial task.

It changes the raw observation available to the algorithm.

That gives machine-vision designers another sensing mode alongside global-shutter, rolling-shutter, line-scan, depth and other camera architectures.

Event Cameras and Frame Cameras Can Work as a Hybrid Pair

Ace also demonstrates a broader design pattern.

Event sensing and frame sensing can complement each other.

A frame contains dense appearance information.

Color.

Texture.

Absolute image intensity.

The complete scene at a defined moment.

An event stream contains precise information about local temporal change.

The two data types answer different questions.

A system can therefore use an RGB or monochrome frame sensor for recognition and scene context while using an event sensor for motion timing.

Prophesee has explored the same hybrid principle in imaging systems where event data is synchronized with conventional camera output.

For robotics, hybrid perception can be equally useful.

One sensor describes the world.

Another specializes in how the world is changing.

The perception stack fuses the results instead of forcing one sensor architecture to handle every measurement.

The Sensor Changes the Compute Pipeline After the Lens

A new sensor architecture changes more than the silicon behind the lens.

It changes the downstream software.

The interface receives events rather than only frames.

The driver has to preserve timestamps.

The processing system has to decide how events are filtered and accumulated.

Algorithms need data structures designed around asynchronous input.

Visualization tools need to convert the stream into something humans can inspect.

Prophesee provides its Metavision software stack for this part of the workflow.

The IMX636 can also be integrated into industrial cameras from several vendors.

That is how a sensing technology becomes an ecosystem.

The sensor provides the measurements.

Camera hardware packages the sensor.

Drivers move the stream.

Libraries process the events.

Robotics or machine-vision applications turn those events into state estimates and decisions.

Event-Based Vision Is Teaching Machines to See Motion Without Waiting for Frames

Event-based vision changes the starting point of machine perception.

A pixel does not have to wait for the whole image to be sampled.

It can report a brightness change when that change happens.

The event carries coordinates.

Time.

Polarity.

The software receives a continuous stream of local visual changes.

Sony’s IMX636 brings that architecture to 1280 × 720 resolution with fine temporal response and wide dynamic range.

Ace shows how the sensor can become part of a real robot.

Frame cameras estimate the ball’s three-dimensional position.

Event cameras help estimate angular velocity and spin at hundreds of updates per second.

The systems work together.

That is the bigger lesson.

Machine vision is no longer limited to asking how many frames a camera can capture.

It can also ask whether a frame is the right unit of measurement in the first place.

For some fast physical tasks, the event is the measurement.

That is the upgrade.