DEV Community: casanovalabs

Serving AI-Generated Images at Scale on Next.js: Formats, Cache and the App Router Traps

casanovalabs — Sat, 01 Aug 2026 14:58:59 +0000

next/image is built for a mostly-static image set: a handful of hero shots, a product catalogue, a blog's cover images. Point it at a pipeline that generates a fresh image per user action — an edited listing photo, a new render — and a few defaults that are invisible in the common case start to matter.

We build CasaNova Labs, an AI studio for real estate photo and video editing, and every output the product generates gets served back through exactly this kind of pipeline. Here is what Next.js's own reference docs say about the parts that actually bite at that volume.

Format negotiation runs off the Accept header, not a version check

The formats config controls which encodings the optimizer is allowed to produce. The default is ['image/webp']; Next.js reads the request's Accept header to pick the best match, and if more than one configured format matches, "the array order matters" — the first hit in the array wins.

module.exports = {
  images: {
    formats: ['image/avif', 'image/webp'],
  },
}

The docs are specific about the cost of adding AVIF: it "generally takes 50% longer to encode but it compresses 20% smaller compared to WebP," and when multiple formats are configured, "Next.js will cache each format separately" — meaning every source image now produces multiple cached variants, not one. Worth deciding on purpose, not by copying a starter config.

The cache TTL is a floor, not a fact about the file

minimumCacheTTL sets the minimum seconds an optimized image is cached for; the default is 14400 (4 hours). The actual expiration is "defined by either the minimumCacheTTL or the upstream image Cache-Control header, whichever is larger" — so a slow-changing config value can still be overridden upward by whatever header the origin image sent.

The sharper edge is what happens when a source image changes: "there is no mechanism to invalidate the cache at this time." The documented fix is to change the src prop (a new URL is a new cache entry) or delete the cached file under <distDir>/cache/images. For anything that regenerates the same nominal image — a re-edited photo served from the same path — that's the detail that decides whether users see the old version for up to minimumCacheTTL seconds.

Static imports skip the whole caching question

For images that ship with the build rather than being generated at request time, the docs point at a different mechanism entirely: a Static Image Import. Importing a file directly, import hero from './hero.jpg', makes Next.js "automatically hash the file contents and cache the image forever with a Cache-Control header of immutable" — no TTL to tune, no invalidation problem, because a content hash in the URL means a changed file is a new URL. That only applies to build-time assets; anything generated after a request comes in still goes through the remotePatterns and minimumCacheTTL path above. Worth knowing which of the two a given image actually is before reaching for cache config.

There's a related edge worth checking before wiring up authenticated image sources: "the Image Optimization API using the default loader will not forward headers when fetching the src image." A signed or authenticated URL for a freshly generated image can fail silently through the optimizer for exactly this reason — the documented way around it is the unoptimized prop, which serves the source as-is instead of routing it through /_next/image.

Every external source has to be allow-listed

If the images being served don't live under /public, remotePatterns is mandatory — Next.js will 400 anything that doesn't match:

module.exports = {
  images: {
    remotePatterns: [
      { protocol: 'https', hostname: 'assets.example.com', pathname: '/renders/**' },
    ],
  },
}

domains, the older config, is deprecated since Next.js 14 specifically because it "does not support wildcard pattern matching and it cannot restrict protocol, port, or pathname" — for a storage bucket or CDN host serving generated output, that's a meaningfully wider allow surface than remotePatterns needs to grant.

`sizes` decides how much of the srcset gets built

Without a sizes prop, "the browser assumes the image will be as wide as the viewport (100vw)," which the docs call out directly as a cause of unnecessarily large downloads. sizes also changes what Next.js generates on the backend: without it, a limited srcset (roughly 1x/2x); with it, a full breakpoint-based srcset. For a grid of AI-generated thumbnails at a fixed card width, an unset sizes prop is a real bandwidth cost, not a cosmetic detail.

The quality allowlist is enforced server-side

As of Next.js 16, qualities is a required config — an explicit allowlist of quality values the optimizer will produce, defaulting to [75]. A quality prop that doesn't match an allowed value snaps to the closest one; hitting the optimization endpoint directly with a disallowed value returns 400. It exists, per the docs, because "unrestricted access could allow malicious actors to optimize more qualities than intended" — worth setting deliberately once output is coming from more than one static list of assets.

None of these are bugs in Next.js — they're defaults tuned for a mostly-static image set, documented plainly, and worth revisiting the moment a pipeline starts generating images instead of just storing them. That's exactly the case CasaNova Labs builds for on every listing photo it renders back to a browser.

What a Portal's Resize Pipeline Actually Does to a Real Estate Listing Photo

casanovalabs — Sat, 01 Aug 2026 14:58:58 +0000

A listing photo leaves the camera looking right. By the time a portal has resized it for a thumbnail grid and recompressed it for delivery, it can look flatter, softer, or faintly wrong in a way nobody can quite name. None of that requires a bug on anyone's part — every step is documented, default behaviour in the image libraries doing the work.

We build CasaNova Labs, an AI studio for real estate photo and video editing, and the same three operations — resize, recompress, convert format — run on every image the product touches. Here is what the defaults in sharp (the Node.js binding for libvips, the library most JS image pipelines end up calling) actually do at each step, read from sharp's own API docs rather than assumed.

The kernel decides what a downscale looks like

resize() takes a kernel option — the algorithm used to compute new pixel values when shrinking an image, with the inferred interpolator reused for upsampling. The default is lanczos3, not the linear or nearest-neighbour interpolation a naive implementation might reach for:

sharp(input)
  .resize(200, 300, { kernel: sharp.kernel.nearest })
  .toFile('output.png');

That line is in sharp's own docs as an example of what nearest-neighbour resizing looks like — a hard "before" case for comparison, not a recommendation. The docs also flag a second, easy-to-miss knob: fastShrinkOnLoad, on by default, which takes advantage of JPEG and WebP's built-in shrink-on-load feature for speed. The tradeoff is explicit in the reference: it "can lead to a slight moiré pattern or round-down of an auto-scaled dimension." Fine for a thumbnail grid, worth turning off for a hero image.

Chroma subsampling isn't the same default across formats

Chroma subsampling throws away colour resolution the eye is less sensitive to while keeping full luminance detail. Sharp's jpeg() output defaults to '4:2:0' — three-quarters of the colour data discarded — unless you set it explicitly:

await sharp(input)
  .jpeg({ quality: 100, chromaSubsampling: '4:4:4' })
  .toBuffer();

The part worth checking rather than assuming: avif() and heif() default the other way, to '4:4:4' (full chroma), and only drop to '4:2:0' if you ask for it. webp() sits in between, with a smartSubsample flag for higher-quality chroma subsampling and an effort scale from 0 (fastest) to 6 (slowest), default 4. Three formats, three different defaults for the same concept — a pipeline that hard-codes one assumption across all three will be right for one of them and wrong for the other two.

The colour profile gets stripped unless you say otherwise

This is the default sharp documents most plainly, and the one most likely to surprise: "the default behaviour, when keepMetadata is not used, is to convert to the device-independent sRGB colour space and strip all metadata, including the removal of any ICC profile." A photo shot in Adobe RGB or with a camera-embedded profile gets flattened to sRGB on the way out, silently, every time.

withMetadata() is the documented opt-out — it keeps EXIF, XMP and IPTC, and "will also convert to and add a web-friendly sRGB ICC profile if appropriate." For a specific target profile rather than the automatic one, withIccProfile() takes either a filesystem path or one of the built-in names: srgb, p3, cmyk.

await sharp(input).withIccProfile('p3').toBuffer();

Cropping for a grid uses the same defaults, silently

A portal's thumbnail grid almost always crops rather than letterboxes, and that crop has its own default worth knowing. Sharp's resize() takes a fit option — cover (default), contain, fill, inside or outside — modelled on the CSS object-fit property. With fit: 'cover', the crop is centred by default (position: 'centre'), but it doesn't have to guess blindly: sharp also documents gravity values (north, northeast, … centre) and two content-aware strategies, entropy (crops toward the region with the highest Shannon entropy) and attention (crops toward the region of highest luminance frequency). A pipeline that leaves fit and position at their defaults gets a centred crop every time — fine for a portrait already centred on the subject, wrong for a wide shot where the interesting part of the room sits off to one side.

sharp(input)
  .resize(800, 600, { fit: 'cover', position: sharp.strategy.attention })
  .toFile('thumbnail.jpg');

None of this throws an error

That is the actual problem with all three defaults: they are not bugs, so nothing fails and nothing logs. The image resizes, the format converts, the file ships — at three-quarters colour resolution, flattened to sRGB, through a kernel nobody chose on purpose. A pipeline that cares about the output has to set kernel, chromaSubsampling and the metadata/ICC handling deliberately, per format, rather than accept whatever the library shipped as a sane general-purpose default.

That is the layer we tune for every image CasaNova Labs outputs, so a listing photo that comes out of the pipeline keeps the colour fidelity it went in with, rather than whatever three unrelated defaults happen to agree on.

EU AI Act Article 50 for Image and Video Pipelines: What Actually Has to Be in the File

casanovalabs — Sat, 01 Aug 2026 14:45:58 +0000

Article 50 of the EU AI Act became applicable on 2 August 2026. It is one of the few provisions in the regulation that turns into an engineering ticket rather than a policy document: a system that generates images, audio or video must produce outputs that an automated tool can detect as artificially generated.

We build CasaNova Labs, an AI studio for real estate photo and video editing, and we shipped this ahead of the date across every image and every video the product outputs. What follows isn't a legal explainer — it's what the requirement means at the file level, and the three traps that will make a pipeline ship unmarked files while every test stays green.

Two obligations, two different actors

The single most useful thing to get right before writing any code: Article 50 bundles requirements that fall on different parties, and they are satisfied by different mechanisms.

§2 binds the provider of the generative system. Every synthetic output must carry marking in a machine-readable format. Nothing in it is about human visibility.
§4 binds the deployer — whoever publishes the content. Where the content qualifies as a deepfake under Art. 3(60), manipulated content resembling existing people, objects or places in a way that could pass as authentic, it must be disclosed "in a clear and recognisable manner."

That distinction has a direct architectural consequence: §2 is metadata a detector parses, §4 is a label a human reads. They are two separate pipelines with two separate failure modes, and conflating them is the most common design mistake we've seen discussed.

For our part, the claim we make and the only one: our outputs carry machine-readable marking within the meaning of Article 50(2).

What "machine-readable" resolves to

There is no bespoke format to invent. Detectors converge on the IPTC DigitalSourceType property, and the controlled-vocabulary value that matters for generated content is trainedAlgorithmicMedia. Written into an XMP packet, it is what an automated checker actually looks for — a string a parser can match, rather than a free-text note in a description field that no tool will ever read.

For still images that packet sits alongside standard EXIF fields. For MP4, it goes into a top-level uuid box carrying the UUID reserved for XMP by the XMP specification (Part 3, Storage in Files) — no re-encode required, since an MP4 is a flat sequence of [size][type][payload] boxes.

So far, so mechanical. The interesting part is everything that quietly removes it again.

Trap 1 — your own resize eats the metadata

Most image processing libraries drop metadata on transform by default; it's the safe behaviour for them and the wrong one for you. A thumbnail route that resizes on the fly will serve a file with no marking whatsoever, no matter what the stored original carries.

// strips EXIF/XMP — the thumbnail ships unmarked
await sharp(input).resize({ width: 320 }).webp().toBuffer();

// preserves it
await sharp(input).resize({ width: 320 }).withMetadata().webp().toBuffer();

Nothing throws. The image looks perfect. Audit every path that re-encodes an image between storage and the client, not just the one that writes it — delivery-time transforms are where this hides.

Trap 2 — in MP4, where you write it decides whether the file still plays

Appending a box to an MP4 is only safe at the end. The moov atom's stco table holds absolute byte offsets into mdat: insert anything before mdat and every one of those offsets is now wrong. This is not theoretical — a box inserted right after ftyp gives a file that decodes zero frames with Invalid NAL unit size. Appended after the last box, nothing shifts and playback is untouched.

If you take one thing from this article: append, never insert.

Trap 3 — the visible label destroys the machine marking

This one only appears once both obligations are implemented, which is why it tends to be found late.

A §4 visible label on video means overlaying a rendered label on every frame, which means a full re-encode. And a re-encode rebuilds the container from scratch — wiping out any uuid box you appended beforehand. Run the two steps in the intuitive order (machine marking first, since it's the cheap one) and the §2 marking silently disappears from every single video you ship.

The correct order is the counter-intuitive one: visible mark first, machine marking last. Whatever writes to the container has to be the final operation in the chain.

There's a broader version of this rule worth internalising: the marking step belongs at the single choke point every output passes through on its way to storage, and it belongs after every transform. Anything that runs later gets to undo it.

Closing

Article 50(2) is a small, mechanical requirement once you separate it cleanly from §4: write a controlled-vocabulary metadata field, in a format that survives your own transforms, at the one point every output funnels through. The whole difficulty is in ordering — and none of the three traps above produce an error, a log line or a failing test. They produce a file that looks correct and isn't marked.

We shipped this across every image and video CasaNova Labs produces, ahead of the 2 August 2026 date. If you're building on the generation side, the three ordering rules above are what the requirement actually costs you: an afternoon, and knowing where to look.