A preview pipeline offers a lossy encoder for every stored artifact; which payload classes must refuse it, and why?
answer
- ask who reads the output
- a sense organ, or an exact comparison
- one flipped bit breaks a digest
- master copy or delivery copy
- discarded bits never come back
basics
~20 sAnything whose value is its exact bits must stay lossless: executables, archives, source, ledgers, and anything later checked by a digest or signature. Lossy fits terminal media a human tolerates approximately, never the master copy everything else is derived from.
solid answer
~40 sA lossy encoder throws information away permanently: the decoder reconstructs something close to the input under some distortion measure, not the input. So the test is who consumes the bytes. If the consumer is a human sense with a tolerance and the artifact is terminal — a thumbnail, a delivered preview, a played stream — approximate is fine and the discarded bits were never worth their cost. If the consumer compares bytes exactly, a single changed bit is fatal: executables, archives, source, ledgers and anything verified by a digest or a signature. The third class is the sneaky one: the master an artifact is re-derived from. It may look like media, but every future variant is computed from it, so it must be lossless even when everything shipped from it is lossy.
go deeper
Remember the one-line test: lossy is for output a person looks at once; anything compared byte for byte, executed, parsed or re-derived from must stay lossless.
Be able to explain why the loss is permanent — the encoder's output is all any later stage sees — and why a digest taken before an encode can never match the bytes after it.
Show the operational consequence: a pipeline that keeps only lossy copies has silently promoted damaged output to master, and every later variant inherits and compounds that damage.
The judgment is a tiering policy: what the archive tier keeps, what the delivery tier may discard, and who owns the fidelity floor when storage cost pushes back on it.
## What a lossy encoder actually promises A **lossless** coder promises that decoding reproduces the input **bit for bit**; its only freedom is how compactly it describes the same information. A **lossy** coder makes a weaker promise: the reconstruction is *close* to the input, where "close" means an agreed **distortion measure** — commonly **mean squared error**, the average of the squared per-sample differences — stays inside a budget. The extra compression is not cleverness; it is paid for with information that is **gone**. No later pass, no higher quality setting and no better encoder brings it back, because nothing downstream ever sees it. That single property — irreversibility — is the whole of the decision. ## The decision test: who consumes the bits Ask what the consumer does with the output: - **A human sense with a tolerance.** Eyes and ears already discard far more than any encoder does. An error below the threshold of notice costs nothing, so paying bits for it is waste. - **An exact comparison.** A digest, a signature, a diff, a checksum, an equality test, a decompressor's own integrity check. These are defined over exact bytes; any change is a failure, and the failure is total rather than gradual. - **A parser or an execution engine.** Machine code, archive framing and structured records are not "mostly" valid. A flipped byte is not a slightly worse program; it is a crash or a corrupt record. - **Another encoder.** If the output is an input to further processing, its errors become the next stage's signal, and they accumulate. | Payload class | Who consumes it | Lossy? | |---|---|---| | Delivered preview, thumbnail, played stream | A viewer or listener, once | Yes — this is what lossy is for | | Executable, archive, structured record, source text | A parser or an execution engine | Never | | Ledger, audit log, legal or clinical original | An exact reconciliation or a regulator | Never | | Artifact verified by digest or signature | A byte-exact comparison | Never after the digest is taken | | The master every variant is derived from | The pipeline itself | Never, even when the outputs are lossy | ## Why "high quality setting" is not an escape A quality setting moves the operating point along a trade-off; it does not change its nature. At every setting above the lossless endpoint, information is discarded. Two consequences engineers get wrong: 1. **Re-encoding at maximum quality does not restore anything.** The encoder faithfully preserves what it was given, and what it was given is already damaged. The usual result is a larger file that is no better — sometimes worse, because the encoder now spends bits describing the previous pass's artifacts as if they were real detail. 2. **A digest taken before the encode will never match after it.** This is not a bug in the tooling. Decide which representation is authoritative and take the digest over that one's exact bytes. ## Where the boundary genuinely sits The honest line is not "media versus data". It is **terminal versus load-bearing**: - A preview shipped to a browser is terminal: nothing is derived from it, nobody compares it to anything, and its only reader is an eye. - The same image as the library's stored original is load-bearing: crops, alternative sizes and future formats all come out of it. A pipeline that keeps only lossy copies has quietly made its damaged output the master. Every later variant then inherits that damage and adds its own. The cheap insurance is to retain one lossless (or highest-fidelity) copy and derive every delivered artifact from it in a single encode. ## Where lossy earns its place When the consumer really is a sense organ, the saving is not marginal. The information a viewer cannot resolve is a large fraction of what a sensor captured, and the bit rate needed to preserve a signal *exactly* is set by its entropy, which is dominated by noise-like detail nobody perceives. That is why the delivered tier of almost every media system is lossy and its archive tier is not — the two answer different questions, and the mistake is to run one policy for both. One last framing that keeps the argument straight: lossless is not a separate technology from lossy. It is the **zero-distortion endpoint** of the same trade-off. Choosing lossy is choosing to move off that endpoint in exchange for bits, and the only question is whether anything downstream will notice.
- Where does lossless compression sit relative to this trade-off — is it a different mechanism?No. It is the zero-distortion endpoint of the same curve. For a discrete source, the minimum rate at zero distortion is the source's entropy — the floor no lossless coder beats. For a continuous-valued source there is no finite endpoint: exact reproduction of a real-valued sample needs unbounded precision, so the required rate grows without limit as the distortion budget approaches zero.
- Is it safe to sign or checksum a lossy artifact?Yes, as long as you sign the exact bytes you deliver and treat those bytes as authoritative. What fails is taking a digest of the input and expecting it to survive the encode, or re-encoding a signed artifact anywhere in transit. Pin one representation, digest that, and do not re-encode downstream of the signature.
- A team wants to store only lossy previews and re-derive crops from them. What do you say?That makes the preview the master. Every crop is then a second encode over already-damaged input, so distortion compounds and the library's worst copy becomes the source of truth. Keep one high-fidelity master, derive each variant from it in a single encode, and treat the previews as disposable output you can always regenerate.
It is the difference between summarising a meeting and photocopying the minutes. The summary is fine for someone who just needs the gist, and useless to anyone who has to quote a line exactly.
saying these in an interview costs you the question
- Thinks a high quality setting makes a lossy encode reversible.
- Keeps only lossy copies and calls them the library's masters.
- Expects a re-encode at maximum quality to restore discarded detail.
- Treats a digest mismatch after re-encoding as a tooling bug.
- Runs archive and delivery tiers under one fidelity policy.
- Assumes lossy just means slightly lower quality, not lost information.