Why "Up to 95%" Needs Its Median

We say "up to 95%" neural compression savings on photographic sources. It is a true number, and on its own it is close to useless for planning. A best-case figure tells you what the technology can reach on its friendliest input. It does not tell you what your library will do next Tuesday.

That gap between the headline and the typical result is where most compression claims quietly mislead. Not by lying. By reporting the peak and letting you assume it is the average.

This piece is about how to read a savings claim, including ours. If a number does not travel with its distribution, you cannot plan with it.

Key Takeaways

• A "up to" figure is a ceiling, not an expectation. It describes the best input, not the median one.
• Compression savings vary enormously by source. A flat photograph and a fine-detail texture do not behave alike.
• The median is the honest planning number. It tells you what half your assets beat and half fall short of.
• The U.S. FTC advises that "up to" claims should be achievable by an appreciable number of users, not a lucky few (FTC, 2013).
• Inverity reports best-case with "up to" and always distinguishes it from typical, because a claim you cannot plan against is not a claim worth making.

What does "up to 95%" actually mean?

It means at least one realistic class of input reached 95% savings under our perceptual quality floor, and nothing more. "Up to" is a ceiling. It marks the best result the method produced on its most compressible sources, photographs with smooth gradients and redundant detail, while holding structural similarity at or above 0.975 against the original.

The word doing the quiet work is "up." It caps the claim without describing the shape underneath it. A method that hits 95% on one image in a thousand and 40% on the rest can honestly print "up to 95%," and so can a method that averages 90%. The headline cannot tell them apart. That is exactly why a ceiling needs a middle. We make the full argument in why file size is the wrong metric.

Why does the median tell the real story?

The median is the value half your assets beat and half fall below, so it survives outliers that wreck an average. One enormous, highly compressible hero can drag a mean upward and make a codec look better than it will feel across a real library. The median resists that. It answers the planning question directly: what should a typical asset do?

Means and medians diverge whenever a distribution is skewed, and compression results are almost always skewed. A handful of soft, redundant images compress spectacularly. Most images sit in a broad middle. A few, dense textures, noise, fine text, barely move at all. Report the mean and those spectacular few flatter the whole set. Report the median and you describe the center of gravity.

Here is the part vendors rarely say out loud. A higher "up to" number and a lower median often come from the same aggressive setting. Push quality down and your best case climbs while your typical result gets worse and your failure rate rises. The ceiling and the center can move in opposite directions, which is why a single number, either one, is never enough.

How do savings claims get inflated?

Mostly through selection, not fabrication. The common move is to benchmark on a friendly corpus: large, lightly compressed source images that leave enormous headroom, then report the average as if it represented all content. Nothing in that number is false. It just answers a question you did not ask.

We have watched the same dataset produce a 70% headline or a 35% headline depending only on which images went into it. Swap studio photographs for a mix that includes screenshots, logos, and already-optimized JPEGs and the number halves, because those inputs have little left to give. A claim without its corpus is a claim you cannot check.

Three tells give away an inflated number. First, no median, only a peak or an average. Second, no description of the test set, so you cannot tell if it resembles your content. Third, no mention of quality, because savings measured without a perceptual floor are meaningless: you can hit any file size if you are willing to ship a worse image. We describe how to run this honestly in how we benchmark, and why the quality axis matters in PSNR vs SSIM vs looks good to humans.

What should you ask about any savings number?

Ask four questions, and a good vendor will have all four answers ready. Regulators reach for the same logic: the FTC's guidance on "up to" advertising warns that a peak claim implies a result an appreciable share of users will actually see, not a number only the best case touches (FTC, 2013).

The four questions are simple. What is the median, not just the peak? What was the test set, and does it look like my content? At what quality was the saving measured, and was there a floor? And what happens to the assets that do not compress well, do they ship degraded or fall back? A claim that answers all four is a claim you can plan against. One that answers none is marketing.

Why quality has to be part of the claim

A savings number without a quality bar is unfalsifiable. Any codec can reach 95% or 99% if you let it destroy the image, so the byte figure alone rewards exactly the wrong behavior. The honest version pins quality first, then reports whatever savings clear that bar. We hold structural similarity at or above 0.975 against the original, and anything that cannot clear the floor falls back rather than shipping degraded. That verify-and-fallback discipline is covered in when neural compression fails.

How does Inverity report savings honestly?

We frame the best case with "up to" and never let it stand in for the typical case. "Up to 95%" is our ceiling on photographic sources under the 0.975 floor. The median is lower, it varies by library, and we would rather quote it against your actual assets than print a single flattering average that fails to survive contact with your content.

The reporting discipline follows from how the system works. Our Neural Media Orchestrator evaluates each asset and selects the optimal path from 352 possibilities, so savings are decided per asset, not applied as one global setting. That produces a distribution, not a point, which is precisely why we report a range and a middle rather than a hero number. The routing detail sits in neural compression vs adaptive codecs.

The Pareto-safe guarantee is what lets us be relaxed about a modest median. Because the Orchestrator never delivers a result larger than the strongest adaptive baseline, the downside of a hard-to-compress asset is bounded: worst case, you match the best conventional codec, you do not regress. So the honest median is not "sometimes it saves nothing and sometimes it hurts." It is "sometimes it saves a little, often a lot, and never worse than your current best." The mechanism is in rollback and Pareto-safe routing.

Why does this honesty discipline matter for you?

Because you cannot budget against a ceiling. If you plan storage, bandwidth, or Core Web Vitals gains around "up to 95%" and your median is 55%, every forecast you build is wrong in the same direction. A median lets you size the win, staff the project, and set expectations with your own stakeholders without getting caught short.

There is a trust dividend too. A vendor who volunteers the median before you ask is telling you they expect to be measured after you deploy. That is the whole posture behind our tagline, the truth in every pixel, and it is why the honest number, not the impressive one, is the one we lead with. The same principle governs image weight and page speed, which we cover in Core Web Vitals and image weight.

Frequently Asked Questions

Is "up to 95%" a real result or marketing?

It is a real, measured ceiling on photographic sources under a structural similarity floor at or above 0.975. It is also, by design, the best case. The typical result is lower and varies by library, which is why we always report the median alongside it rather than letting the peak stand alone.

What is the difference between mean and median savings?

The mean is the average, easily pulled upward by a few highly compressible images. The median is the middle value, where half your assets do better and half do worse. Because compression results are skewed, the median is the more honest planning number and usually sits below the mean.

Why can't a vendor just give one savings number?

Because compression varies enormously by source. A smooth photograph and a dense texture behave nothing alike, so any single number hides a wide distribution. A responsible claim gives you at least a ceiling and a median, plus the test set and the quality bar the number was measured against.

How do I sanity check a compression claim?

Ask four things: the median not just the peak, the test corpus, the quality bar, and what happens to assets that compress poorly. If a vendor can answer all four, the claim is plannable. If they only offer a headline percentage, treat it as the best case and nothing more.

Does a lower median mean the technology is worse?

Not necessarily. A modest median with a hard quality floor and Pareto-safe routing can be more valuable than a flashy average that ships degraded images. What matters is that savings are real at quality, bounded on the downside, and reported against content that resembles yours.

The point

"Up to 95%" is true, and truth is not the same as usefulness. A ceiling tells you what is possible on the best input. A median tells you what to expect across the library you actually run. Plan against the second, not the first.

The test for any vendor, including us, is whether the median arrives before you ask for it, and whether the number came with its corpus and its quality bar. If it did, you can build a forecast. If it did not, you have a headline, not a plan. Start with how we benchmark, then read why file size is the wrong metric.