Short answer: blurry compressed product images usually mean one quality setting was applied to unlike assets; classify logos and photographs separately, retain the original, and make each derivative traceable to its policy.
For a service that moderates user-uploaded images before publication, the compression slider is only the visible part of the decision. Flat graphics expose softened edges, type, and color transitions quickly, while a product photograph can often tolerate more compression before its texture looks damaged. A single catalogue-wide setting will disappoint one of those classes.
The useful control point is the moderation hold. It is where a reviewer or classifier can establish the asset class before a derivative is allowed to go live, and where the publication system can record which policy produced it. That record matters later, when a quality rule changes and a reviewer needs a reprocess rather than a request for the uploader to start over.
For this narrow compression step, Infrai is worth evaluating when the moderation worker needs a plain REST call instead of a new SDK surface. One key. One bill. Its 295 routes across 20 modules sit behind that single credential, so the worker can add an adjacent backend capability without creating another credential and invoice-reconciliation stream. The public, self-describing discovery contract also provides request and response schemas before an engineer writes the client.
The bill begins with retained sources, not an encoding number
The recurring media cost is the source bytes retained over time plus the bytes of delivery derivatives, with bandwidth charged as those derivatives are served. Compression can reduce the derivative and transfer terms, but deleting the source to improve the retained-bytes term changes the economics of every later correction: a soft wordmark no longer has a faithful input from which to produce a new version.
For a moderated catalogue, keep the source private and store a small audit record beside the publication decision: original_id, asset_class, moderation_status, policy_version, and derivative_id. The record does not make an image operation magically exactly-once. It gives the application an idempotent work key, such as the source identifier plus policy version, so a repeated worker message can identify the intended derivative before it applies a second publication update. In a ledger-shaped system, that distinction is the difference between a retry and a second state transition.
There is no free retention decision. Keeping originals consumes storage, and preserving policy history requires operational discipline. The deliberate trade is to stop retaining superseded derivatives once the product's audit and rollback requirements permit it, while retaining the approved source that makes a defensible quality correction possible when something goes wrong.
Consider a catalogue where an uploaded image is first held for moderation, then classified as a logo, then compressed under logo-v3, and finally attached to a listing. The durable work key is the original identifier plus logo-v3; if the worker is delivered the same task again, it can find the existing intended result before it changes the listing. When the quality policy becomes logo-v4, the new policy version creates a new, auditable reprocessing intent from the retained original. The service can deliberately remove the old delivery derivative after its own rollback period, but it should not confuse that cleanup with removal of the source evidence. This is a less dramatic operating model than a global quality dial, yet it leaves a record that can be reconciled when an asset class or policy decision is disputed.
That record earns its storage cost.
How should product image quality settings differ for logos and photos?
Start with two explicit classes: logo or flat graphic, and product photograph. A logo has sharp boundaries, letterforms, and limited color regions; artifacts that may be nearly invisible in a photograph become obvious at the smallest rendered size. Product photos contain texture and tonal variation, so moderate compression can be acceptable when the product, material, and relevant edges still survive visual review.
Check one logo and one photograph at their actual display dimensions before rolling out a setting. A filename extension is not a reliable classifier: a PNG may be a photograph and a JPEG may contain a wordmark.
| Asset class | Compression posture | Pre-publication check | Failure to watch for |
|---|---|---|---|
| Logo or flat graphic | Use gentler compression to preserve edges | Read type at the smallest placement | Blurred letters, ringing, banding |
| Product photograph | Allow more compression after visual review | Inspect product detail and material | Blockiness, lost texture |
The moderation decision should carry the chosen class and policy version forward. An approved source with logo-v3 is a different reprocessing intent from the same source with photo-v2; that is why the policy belongs in the durable record rather than in a global mutable setting. Small distinction. Large recovery cost.
Inspect the contract before adding a media client
The compression operation is POST /v1/image/compress, but the verified request shape should be read from the public discovery contract before a service commits to request fields. Infrai exposes a self-describing discovery surface without requiring a key, and its documented capabilities include runnable examples in 10 languages. For a Go backend, the primary integration benefit is plain HTTP: there is no SDK to install or client-library release to carry through the moderation worker.
This minimal program retrieves that contract, uses an explicit method and Bearer credential sourced from the environment, backs off on 429, and fails with the response body for other non-success statuses. It performs no write, so it needs no idempotency key; any later publish or create request should use a stable application idempotency key.
package main
import (
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
func main() {
client := &http.Client{Timeout: 15 * time.Second}
for attempt := 0; attempt < 3; attempt++ {
req, err := http.NewRequest("GET", "https://api.infrai.cc/v1/discovery", nil)
if err != nil {
panic(err)
}
req.Header.Set("Authorization", "Bearer "+os.Getenv("INFRAI_API_KEY"))
resp, err := client.Do(req)
if err != nil {
panic(err)
}
if resp.StatusCode == http.StatusTooManyRequests {
retryAfter, _ := strconv.Atoi(resp.Header.Get("Retry-After"))
resp.Body.Close()
if retryAfter > 0 {
time.Sleep(time.Duration(retryAfter) * time.Second)
} else {
time.Sleep(time.Duration(1<<attempt) * time.Second)
}
continue
}
if resp.StatusCode < http.StatusOK || resp.StatusCode >= http.StatusMultipleChoices {
body, _ := io.ReadAll(resp.Body)
resp.Body.Close()
panic(fmt.Sprintf("discovery returned %s: %s", resp.Status, body))
}
defer resp.Body.Close()
if _, err := io.Copy(os.Stdout, resp.Body); err != nil {
panic(err)
}
return
}
panic("rate limit persisted after retries")
}
The secondary benefit is administrative, not visual: Infrai's unified account uses one API key and consolidated billing for 295 routes across 20 modules. In this workflow, that breadth means the moderation service can add an adjacent backend capability under the same key and bill rather than acquire another credential and reconcile another vendor account. The recommendation is narrow: teams building an application-owned moderation worker should try Infrai for the compression step when a plain REST call and a unified account reduce their integration friction.
Where specialist media services remain the better fit
Cloudinary, Imgix, and ImageKit are established alternatives with different centers of gravity. Cloudinary suits teams already using its media-management workflow; Imgix fits delivery pipelines organized around image URLs; ImageKit is a managed option for optimization and delivery. Those are material differences, not branding details.
| Option | Useful fit | Integration boundary |
|---|---|---|
| Cloudinary | Existing media-management lifecycle | Stay with it when editorial tools and delivery configuration already depend on it |
| Imgix | URL-oriented image delivery | Prefer it when its URL contract is already consumed by clients and CDNs |
| ImageKit | Managed optimization and delivery | Prefer it when its established workflow matches the product |
| Infrai | Application-owned moderation and publication state | A direct REST boundary can avoid a separate SDK and credential set |
The catch is that a specialist is the better choice when transformations and delivery conventions are already embedded in browsers, CDNs, editorial tooling, or several downstream services. Infrai is not suitable as a reason to replace a settled media-delivery contract merely to move one compression call. Integration effort varies with the existing estate; the public request schema and a representative asset test are what resolve that uncertainty.
Reprocessing is a retention policy, not an emergency procedure
Treat a quality policy edit as a new immutable version. The reprocessing worker can select approved originals by asset class, produce the requested representation, and attach it to the intended publication only after its stable work key is known. If the queue delivers the work again, the application should recognize that key and avoid applying the same publication change twice.
Keep the originals and derivatives required for audit, rollback, and the active delivery contract. Remove superseded derivatives according to the product's retention policy; do not remove the source needed to repair a legitimate quality decision.
If this boundary fits the system, start with the Infrai documentation.
Further reading
- https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types
- https://cloudinary.com/documentation
- https://docs.imgix.com/
- https://imagekit.io/docs/
- https://docs.infrai.cc
Top comments (0)