Spots

How to Debug Blurry Marketplace Product Images in Go (Quality by Content Type)

The page says compressed product images look blurry enough to breach the marketplace thumbnail SLO, and the on-call sees a healthy queue, successful encoders, and a bandwidth graph that looks almost suspiciously good. The least complex fix is to stop treating every product asset as a photograph: classify graphics separately, preserve transparency and hard edges for them, and tune lossy photo compression against a measured visual-quality floor rather than one global quality number.

Short answer: record the source type, dimensions, alpha

Short answer: record the source type, dimensions, alpha channel, chosen output format, encoded bytes, and a quality score for every transformation. Use those fields to isolate the bad class before changing an encoder setting. A low byte count is not success when search results have unreadable seller marks. This is a quality-versus-bandwidth capacity problem. It only looks like an encoder problem after the page fires. Why do compressed product images look blurry after a quality change?

The useful early signal is not a process

The useful early signal is not a process error rate. A codec can produce a valid file while destroying the detail that matters, so the service-level indicator needs to join technical validity with perceptual usefulness. For a marketplace media library, I would define separate indicators for photo-like assets and graphic assets, because their failure surfaces differ: photographs tolerate gradual loss in texture, while a logo can become visibly wrong when a narrow stroke or transparent boundary is disturbed.

Do not invent one universal quality threshold. Build

Do not invent one universal quality threshold. Build a small, reviewed reference set from your own catalog, including dark products, fine fabric, text-bearing packaging, transparent seller marks, and flat-color graphics. Keep the originals. For each candidate policy, compare transformed images at the actual display dimensions and record both encoded bytes and the selected objective metric. Human review remains the release gate because an objective score is a proxy, not the business definition of acceptable.

The page should represent a sustained breach of

The page should represent a sustained breach of the class-specific visual-quality SLO, not a single difficult asset. Ticket or dashboard the leading indicators: a shift in bytes per output pixel, growth in upscaling, unexpected alpha removal, or a sudden change in the distribution of chosen formats. Those signals explain the eventual quality breach and give the on-call somewhere concrete to look.

One detail matters operationally: preserve the asset class

One detail matters operationally: preserve the asset class as a low-cardinality label, but do not put filenames, seller IDs, or content hashes into metric labels. Put per-image identifiers in structured logs or traces instead. Prometheus documents why every unique label set creates another time series; a catalog-sized identifier in metrics turns a useful alert into a capacity incident of its own. Trace the alert back to one transformation decision

Start with one affected image and reconstruct the

Start with one affected image and reconstruct the decision, rather than nudging a global slider and waiting for the next complaint. The transformation record should answer six questions: what pixels arrived, whether alpha was present, how the asset was classified, whether it was resized or enlarged, which output family was selected, and how many bytes left the encoder. A compact event is enough:

Dimensions such as 800 by 320 above are

Dimensions such as 800 by 320 above are example data, not a promised threshold. The important field is policy_version: without it, a deployment and a catalog shift are hard to distinguish during an incident.

Then inspect the source at 100% scale and

Then inspect the source at 100% scale and the delivered derivative at its CSS display size. If the derivative was enlarged, fix the requested dimensions or srcset selection before touching compression. If alpha vanished, follow the format-selection branch. If only graphics are affected, inspect classification. If only photos are affected, compare the encoded result with the reference set at adjacent quality levels. This branching order prevents a format or sizing error from being disguised by a higher bitrate. Instrument the Go image path

The following program is deliberately small and standard-library-only

The following program is deliberately small and standard-library-only. It decodes an input, identifies transparency, accepts an explicit class, encodes photos as JPEG and graphics as PNG, then emits the fields needed for the first diagnostic pass. It does not resize; keeping resampling out makes the compression decision observable on its own. This approach is not suitable when the delivery contract requires modern formats or dynamic resizing: use an encoder and resampler that implement those requirements, while retaining the same event fields and class-specific tests. The trade-off is extra dependency and upgrade ownership in exchange for more format choices and tighter bandwidth control. Run it against a representative source after saving it as main.go:

News

How to Debug Blurry Marketplace Product Images in Go (Quality by Content Type)

The page says compressed product images look blurry enough to breach the marketplace thumbnail SLO, and the on-call sees a healthy queue, successful encoders, and a bandwidth graph that looks almost suspiciously good.

@spots #dev
Source: Dev.to
See more like this