In robotics systems, vast amounts of visual data are easily captured at high resolution using low-cost, low-power hardware. Yet, limited bandwidth and on-device compute resources prevent full utilization when transmitted via conventional codecs like JPEG/MPEG. Newer codecs, like AV1/AVIF, improve the rate-distortion trade-off, but demand far more resources for encoding, impractical without custom ASICs. Recent asymmetric autoencoders deliver high quality under extreme power and bandwidth constraints, but add prohibitive decoding cost and use bespoke formats that ignore decades of infrastructure built around standards like JPEG. To address these limitations, we introduce a compression framework for cloud robotics based on a Sensor Embedded Autoencoder paired with a One-Time Transcode for Efficient Reconstruction (SEAOTTER). Because the sensor, cloud, and consumer stages face very different power and bandwidth budgets, SEAOTTER combines the compactness of a learned latent with the broad usability of a standard JPEG file. Since naive transcoding degrades performance, we propose a learnable JPEG color and quantization transform that enables increased accuracy for global, dense, and vision-language-based perception. Using SEAOTTER, we train both general-purpose and task-aware transcoding pipelines for a pre-trained, frozen encoder. At a compression ratio of 200:1 and compared to AVIF, we observe 7 times faster encoding, 3.5 times faster decoding, and +8% ImageNet top-1 accuracy, while retaining compatibility with JPEG infrastructure. Our code is available at https://github.com/UT-SysML/seaotter .
Alex: Welcome to another episode of ResearchPod. Today we're looking at a challenge in robotics: how to get high-quality video from a small, battery-powered drone to the cloud without stalling the connection or draining the battery.
Sam: That is the central puzzle. We are discussing a new framework called SEAOTTER, which aims to bridge the gap between extreme compression on a tiny device and the need for standard, usable video files in the cloud.
Alex: So this paper is basically asking how we can have our cake and eat it too—getting massive compression on the robot while keeping the output compatible with the software we already use?
Sam: Exactly. Modern robots capture vast amounts of visual data, but they lack the power to run complex compression software. If you use standard tools like JPEG, you lose too much detail. If you use newer, smarter tools, they are too heavy for the robot to run, or they produce file formats that nothing else can read.
Alex: Right. And if the robot has to do all the heavy lifting to make a file "standard," it's going to run out of battery or slow to a crawl.
Sam: Precisely. The researchers propose an "asymmetric" approach—and the word asymmetric is key here. Think of it like a relay race where one runner does almost nothing and hands the baton to a much stronger runner waiting at the finish line. On the robot, a very simple, lightweight piece of software turns raw video into a highly compressed shorthand. The researchers call this compact representation a "latent."
Alex: Okay, so the robot does the bare minimum to get the data off the device. But if that shorthand is unreadable to a normal computer, how does the cloud make sense of it?
Sam: That is where the "one-time transcode" comes in. Once that shorthand reaches the cloud—where power is cheap and plentiful—a much more powerful computer acts as a translator. It rewrites that cryptic shorthand into a standard, universally understood JPEG file. The kind any browser or app can open.
Alex: Oh—so the cloud does the heavy lifting of reconstruction, and the robot just sends the shorthand. That's a clean division of labor.
Sam: Exactly. The researchers call the overall system an "Encoding-Efficient Asymmetric Autoencoder." The name is a mouthful, but the idea is simple: deliberately shift the hard computational work away from the battery-constrained robot and onto the cloud server, which has no such limits.
Alex: But doesn't that conversion process lose information? If you're turning a specialized shorthand into a standard JPEG, aren't you just adding another layer of blurriness?
Sam: That is a valid concern, and it is the central technical challenge the paper addresses. To prevent that loss, the team uses what they call a "learnable" transform. During training, they teach the system how to color and package the data in a very specific way—so that when the cloud converts it to JPEG, the result stays as accurate as possible for an AI to analyze. They call this technique the "JPEG Sandwich."
Alex: The JPEG Sandwich—I like that name. So it's like pre-packaging the data in a way that survives the translation step without losing the details that matter?
Sam: That is exactly right. And the training process is clever. The system learns to predict how a standard JPEG encoder would handle the data, and it adjusts the shorthand accordingly—essentially learning the exact packaging that results in the smallest file size while keeping the image clear enough for machine vision to work reliably.
Alex: Does it actually perform better than what we have now?
Sam: The evidence suggests it is a meaningful improvement. Compared to modern standards like AVIF, this approach achieved much faster encoding on the device while maintaining higher accuracy for machine vision tasks—and it outputs a file that any standard software can open without modification.
Alex: So it's faster for the robot, better for the AI, and compatible with everything else. That's a significant combination of benefits.
Sam: It is. But the researchers are careful to note it is not a "set it and forget it" system. The cloud-side translator needs to be calibrated to the specific AI task you are running. If the AI model changes, that cloud-side component may need fine-tuning. So you are making a deliberate trade-off: you gain enormous efficiency on the robot, but you accept some additional work on the cloud side when things change.
Alex: So you're essentially locking in the robot's behavior to keep it lightweight, and accepting that the cloud has to adapt when needed.
Sam: Correct. And for many real-world deployments—where the robot's task is fixed but battery life is critical—that is a very practical trade-off to make. The robot stays simple and efficient, and the cloud handles the complexity. That division of responsibility is, in many ways, the core insight of the whole paper.
Alex: It's a useful reminder that good engineering is often about choosing where to put the burden, not eliminating it entirely. Thanks for listening to ResearchPod.