DEV Community: casanovalabs

Per-Property vs Per-Credit: The Unit-Economics Choice Behind a Media SaaS Pricing Page

casanovalabs — Sun, 16 Aug 2026 22:08:45 +0000

There are two ways to price an AI media tool, and the choice quietly decides what your customer optimizes for. You can bill per operation, usually dressed up as credits, or you can bill per unit of the customer's actual work. We build CasaNova Labs, an AI studio for real estate photo and video editing, and we bill per property rather than per credit. Here is the reasoning, because it is a real tradeoff and not obviously the right call for everyone.

What per-credit optimizes for

A credit is a unit of your cost, not the customer's value. When a tool bills per credit, the customer's incentive is to spend fewer credits, which means generating fewer images, which is the opposite of what makes their listing sell. Every render becomes a small yes-or-no budgeting decision. For a per-credit example with real, checked numbers, Roomagen bills by the credit and spends two credits per delivered image, which resolves to roughly $0.40 down to $0.23 per image depending on tier. The buyer's mental math is entirely at the image level: every render is a credit-to-image conversion done in your head before you click.

That model is honest and works fine when usage is spiky and unpredictable. It maps cost to consumption, which is exactly what you want if a customer might run one image this month and four hundred the next. The downside is behavioral: it makes the customer ration the very thing your product is for.

What per-property optimizes for

A property is a unit of the customer's work. A real estate agent does not think in renders, they think in listings. Billing per property, with a generous per-listing image allowance, changes the incentive: within a listing, generating one more staged room or one more sky replacement costs nothing marginal, so the agent does the thing that actually helps the sale. The unit of billing matches the unit of value.

The cost to us of that model is variance. Some agents will use the full allowance on every listing, some a fraction, and we carry the spread rather than passing it through per render. That is a deliberate cost we take on to remove the per-image hesitation. The full grid and where the per-listing line lands is on the pricing page, and how it compares against the per-credit tools is laid out in the alternatives breakdown.

The engineering consequence nobody mentions

The billing unit leaks into the architecture. Per-credit billing forces a metering system: every operation is counted, reconciled, and shown to the user, and that counter is now on the critical path of every render. Per-property billing moves the accounting boundary up to the listing, so the render path itself carries no metering, which is simpler and faster and removes a class of "why was I charged for a failed generation" support tickets. The pricing model you pick is also a system-design decision, and the per-unit-of-value model happens to have the cleaner internals.

When each is right

Per-credit wins when consumption is genuinely unpredictable and the customer is technical enough to reason at the operation level, an API product for developers, say. Per-unit-of-value wins when the customer thinks in their own domain object and you want them to use the product freely rather than ration it. For real estate, the domain object is the listing, so that is the unit we bill. If you are designing a media SaaS, the question to answer first is not what to charge, it is what unit your customer already counts in, and whether your incentive should push them to do more of the thing or less.

You can run the per-property model against ten photos without a card at CasaNova Labs.

The Phone Is Now the Camera and the Darkroom: What a Mobile Real Estate Photo Pipeline Actually Runs On-Device

casanovalabs — Sun, 16 Aug 2026 20:44:21 +0000

An agent walks a property with a phone, not a DSLR and a laptop. They want the listing photo finished before they are back in the car. That expectation quietly decides the architecture of any tool that serves them, because it forces a split: some of the work genuinely runs on the device, and some of it cannot, and pretending otherwise is where most mobile photo tools get slow or lie about latency.

We build CasaNova Labs, an AI studio for real estate photo and video editing that people use from a phone browser, so this split is something we reason about constantly. Here is the honest map of what sits where.

What the phone actually does well

The capture side is entirely local, and modern phones are good at it. Exposure metering, multi-frame HDR merge, lens correction, and the preview you frame the shot with all run on the device silicon before a single byte leaves it. This is why the practical advice for shooting a listing on a phone is mostly about technique rather than gear: hold the phone level at chest height, use the main or ultra-wide lens rather than digital zoom, lock exposure so a bright window does not crush the room, and shoot in daylight. We wrote the full field version of that up in how to take real estate photos with an iPhone, and none of it needs a server, because none of it is generative. It is optics and metering.

The phone is also fine for the light edits: crop, straighten, a global exposure or white-balance nudge. Those are per-pixel operations with no model behind them, so they run in the browser on a canvas without a round trip.

Where it has to leave the device

The moment the operation is generative, the phone stops being enough. Replacing a grey sky, removing clutter from a room, or staging an empty space with furniture are all diffusion-model inferences. A single such pass is billions of floating-point operations against multi-gigabyte weights. That does not fit in a phone browser tab, and it should not: you do not want the model weights shipped to every device, and you do not want the battery and thermal cost of running them there.

So the architecture that actually works is boring and correct: the phone captures and does the cheap edits locally, then hands the heavy generative step to a GPU on a server, and streams the result back. The user experience target is that the round trip feels like a filter, not like a render job. In practice a staging or replacement pass finishes in about 30 seconds on average, which is the number that decides whether an agent waits for it on-site or gives up and posts the raw photo.

The install question the App Store hides

There is a second consequence of "from a phone" that is not about compute at all. A native app means an install, an update cycle, and a review queue, per platform. For a tool whose heavy work is server-side anyway, a large part of that install buys the user nothing, because the model was never going to run locally. A web app in the phone browser skips the install and keeps the same session open on a laptop later, which matches how agents actually work: shoot on the phone, tidy the batch on a desktop that evening.

The tradeoff is real and worth stating plainly. Native still wins on camera-native capture flows and on true offline use. If you never have signal at the property, a web tool cannot do the generative step there, and a native app that caches a small on-device model could. We laid out that comparison in full, including what native does better, in the virtual staging app breakdown, and the same install-versus-browser logic applies to the broader category of free AI interior design apps.

The takeaway for anyone building this

If you are architecting a mobile media tool, draw the line by asking one question per operation: is there a model in it? No model, keep it on the device and make it instant. Model in it, move it to a server and spend your engineering budget on making the round trip feel local. The mistake is trying to push generative work onto the phone to claim it is "on-device," which trades a 30-second server call for a slower, hotter, worse local one. The phone is the camera and the darkroom for everything that is optics. It is a thin client for everything that is inference. Building as if that line does not exist is how these tools end up slow.

You can try the generative side of this on ten photos without a card at CasaNova Labs.

The Credit-to-Image Ratio Is the Number AI Tool Pricing Pages Bury

casanovalabs — Fri, 14 Aug 2026 05:07:14 +0000

Credits are a pricing abstraction. They sit between the number a buyer reads on a plan card and the number that actually matters, which is what one finished, usable output costs. Most of the time the two are close enough that nobody checks. Sometimes they are not, and the gap is entirely legal, disclosed in a sentence most people skip.

We build CasaNova Labs, an AI studio for real estate photo and video editing, so we spend a lot of time reading competitors' pricing pages the way a buyer at volume would. This is the one normalization step that changes the ranking of tools more than any headline discount, and it takes about two minutes per tool.

Credits are not outputs

A plan advertises a monthly credit balance. A separate line, usually further down, tells you how many credits one operation spends. The cost that matters is the second number divided into the first, then divided into the price.

Here is a real grid. Roomagen, rates checked July 2026, lists a free tier at 6 credits, Starter at $12 a month for 60 credits, Pro at $29 for 200, and Business at $79 for 700. On its own that reads like roughly 60 to 700 units of value per tier. But one image spends two credits. So the delivered-image count per tier is 30, 100, and 350, and the real grid is:

Starter: $12 / 30 images = $0.40 per image
Pro: $29 / 100 images = $0.29 per image
Business: $79 / 350 images = about $0.23 per image

None of those numbers are hidden or improper. The two-credits-per-image rule is stated plainly. But the plan card shows you 60, 200, 700, and your brain anchors on those. The number you will actually budget against is 30, 100, 350.

The formula

For any credit-based media tool, normalize before you compare:

cost_per_output = plan_price / (plan_credits / credits_per_output)

Run it for every tier, not just the one you think you will buy, because the per-unit curve is where the tiers actually differ. Roomagen's curve above bends about 43% from smallest to largest tier, which is a genuinely tiered grid and, per unit, lands under a lot of the market including ours. A tool that charges one credit per output and a tool that charges two can advertise the same credit price and cost you double or half. The headline price tells you nothing until you divide it down.

What the unit price still does not capture

Cost per output is necessary, not sufficient. Once every tool is on the same per-output axis, three things decide the actual bill that the axis hides:

The credit-to-output ratio can vary by operation. One image at two credits is simple. A tool that spends two credits on a staging pass and five on a video clip has two different real prices under one balance. Normalize per operation type you will actually run, not once for the whole tool.
Coverage under one balance. If photo and video draw from the same credits, the per-image number understates value, because the same budget also buys the more expensive operation. If they are separate products with separate balances, two cheap-looking plans can be one expensive stack. We put photo and video on one balance for exactly this reason, and it makes our per-image number look worse in isolation and better in a real month.
Expiry. Credits that reset monthly are a use-it-or-lose-it liability on anything with uneven volume, which real estate is. Rollover changes the effective price of every credit you do not burn. It rarely appears in the per-unit math and often dominates it.

Why this belongs in an engineering conversation

If you are building the tool, the ratio is a product decision with a trust cost: a two-to-one credit rule is defensible, a variable and unpredictable one trains buyers to distrust the balance. If you are buying, it is a procurement step you can script. Pull each competitor's plan price, credit balance, and credits-per-operation into three columns, apply the formula, and the tools re-sort themselves in front of you. The winner on the plan card is frequently not the winner on the third column.

We wrote the full worked version of this, tier by tier and in each tool's own currency without inventing an exchange rate, as a direct comparison: CasaNova Labs versus Roomagen for listing photos. It says plainly where the per-image price goes the other way, because on that axis it does. If you want to run the same math against our own grid, the pricing page lists every tier and the free trial is 10 transformations with no card, where one transformation is one delivered image.

The point is not that any one tool wins. It is that the number on the plan card is the wrong number, and the right one is two minutes of division away.

What One AI-Staged Room Actually Costs to Render: The GPU Math Behind Per-Image Pricing

casanovalabs — Thu, 13 Aug 2026 16:42:01 +0000

If you have run a diffusion model locally, the marginal cost of one image feels like zero. The model is already in memory, the GPU is already warm, and you just call pipe(prompt) again. That intuition is what makes teams underestimate the real number when they move the same feature into a product. The per-image cost in production is dominated by things the notebook hides: the seconds you pay for a GPU that is loading a model, the VRAM you rent whether or not a request is in flight, and the renders you throw away.

We build CasaNova Labs, an AI studio for real estate imagery, so this arithmetic is our unit economics. Here is how it actually breaks down, with numbers you can plug your own rates into.

The model is bigger than people remember

The workhorse for photoreal room generation is an SDXL-class latent diffusion model. Per the SDXL technical report, its UNet has around 2.6 billion parameters, roughly three times the UNet of Stable Diffusion 1.5, and it renders natively at 1024x1024. In half precision that weight sits at about 10 GB of VRAM before you add anything, and a real staging pipeline adds plenty: a ControlNet to keep the room geometry, an inpainting pass to swap furniture without touching the walls, sometimes an upscaler on top.

So the first cost is not compute, it is the size of the box you have to rent. You cannot serve a 10 to 14 GB working set on a small GPU. You are renting an A10G, an L4, or an A100-class card, and you are renting it for the whole time the process is alive, not only while a request runs.

Cold starts are the line item nobody budgets for

Loading a multi-gigabyte checkpoint from disk into VRAM is not instant. Depending on where the weights live and how fast the storage is, moving 10-plus GB into the GPU takes on the order of seconds to tens of seconds. If you run serverless GPU inference and let workers scale to zero to save money, every request that lands on a cold worker pays that penalty before it renders a single pixel.

This is the tradeoff that quietly sets your cost floor:

Keep a worker warm and you pay for idle GPU time between requests.
Let it scale to zero and your tail latency spikes, and you burn GPU seconds re-loading the model instead of rendering.

Neither option is free, and the cheaper one depends entirely on your request pattern. Bursty, unpredictable traffic (which is exactly what a listing-editing tool sees) is the worst case for both.

The arithmetic, with a rate you can change

Take the compute itself. A 1024x1024 SDXL render at around 30 steps is a few seconds of GPU time on a mid-range card, call it 4 seconds for a round number, more with ControlNet and an upscale pass. Now assume a GPU that costs 2 dollars an hour. That is:

2 dollars / 3600 seconds = 0.00056 dollars per GPU-second
4 seconds x 0.00056        = 0.0022 dollars of pure compute per image

A fifth of a cent. That is the number that makes AI rendering look almost free, and it is the number demos quote. It is also fiction as a unit cost, because it ignores everything around the render:

Cold-start seconds amortized across real, bursty traffic.
Idle GPU time when you keep workers warm to hide those cold starts.
Retries and rejects. Diffusion is stochastic; some fraction of outputs miss and get re-rolled, and you pay full compute for images a human never keeps.
Storage and egress for the input photo, the output, and usually several intermediate variants.

Depending on how warm you run and how often you retry, the real cost per delivered image can land several times higher than the raw compute line. The exact multiple is the entire engineering problem, and it is why serious inference platforms bill by the GPU-second rather than by the image: the per-image number is not stable enough to quote until you have absorbed all of the above.

Why this maps onto build versus buy

If you are adding an AI image feature to your own product, this is the honest tradeoff. Running it yourself means you own the warm-pool tuning, the autoscaling, the retry logic, and a GPU bill that is mostly idle time and cold starts rather than the four seconds of actual rendering. That is real, ongoing engineering, not a weekend integration.

The alternative is to let someone who has already amortized that infrastructure across many tenants absorb it, and pay a flat, predictable number per delivered image. That predictability is the product. It is why our per-image pricing is a fixed figure per render rather than a metered GPU bill you cannot forecast, and why the virtual staging itself is priced by the finished photo, not the compute behind it.

The takeaway is not that one path always wins. It is that the demo number, a fifth of a cent, is never the number you ship on. Before you decide to run diffusion inference in-house, price the cold starts and the idle time, not the render. That is where the cost actually lives.

Why a 30-Second Real Estate Video Can Be 8 MB or 80 MB: The ffmpeg Settings That Decide

casanovalabs — Thu, 13 Aug 2026 16:35:18 +0000

Two 30-second walkthrough clips, same resolution, same footage quality, can land at 8 MB and 80 MB out of the same encoder. The gap is not the camera or the content. It is three settings in the ffmpeg/libx264 invocation, all documented in FFmpeg's own H.264 encoding guide.

We build CasaNova Labs, an AI studio for real estate photo and video editing, and every video the product renders goes through this same re-encode step before it reaches a listing page. Here is what actually drives the size, straight from the docs.

CRF, not bitrate, is the setting that controls quality

FFmpeg's guide recommends Constant Rate Factor as "the recommended rate control mode for most uses" when you care about consistent quality over a guaranteed file size. The scale runs 0 to 51 for 8-bit video: 0 is lossless, 23 is the default, 51 is the worst quality possible. The docs describe "a subjectively sane range" of 17 to 28, with 17 and 18 as "visually lossless or nearly so."

The part that explains the 8 MB against 80 MB swing directly: "the range is exponential, so increasing the CRF value +6 results in roughly half the bitrate / file size, while -6 leads to roughly twice the bitrate." Applied to the documented sane range, moving from CRF 18 to CRF 28, a 10-point difference, works out to roughly a threefold difference in bitrate for identical footage, using that same exponential relationship. That is before touching resolution, frame rate or anything else.

Why not just target a fixed file size instead

CRF mode is the documented default recommendation, but the guide is upfront about what it gives up to get there: "you can't tell it to get a specific filesize or not go over a specific size or bitrate, which means that this method is not recommended for encoding videos for streaming" in the sense of guaranteeing a bitrate cap. For a walkthrough clip served once from a listing page rather than adaptively streamed, that tradeoff runs the other way: a consistent visual quality at whatever size the footage needs is the more useful property than hitting an arbitrary size target and letting quality float.

That tradeoff is also where the cost sits, because bytes served and encoder minutes are both billed. We broke down what that adds up to per listing in our breakdown of virtual staging costs.

The preset trades encoding time for file size, not quality

A preset is, per the docs, "a collection of options that will provide a certain encoding speed to compression ratio." At a fixed CRF, a slower preset produces a smaller file for the same visual quality, because the encoder spends more time finding a more efficient way to represent the same picture. The documented list, fastest to slowest:

ultrafast, superfast, veryfast, faster, fast, medium (default), slow, slower, veryslow, placebo

placebo is explicitly called out as "not useful" in the docs' own FAQ. The stated rule of thumb: "use the slowest preset that you have patience for." A worked example from the guide, targeting good quality with better compression:

ffmpeg -i input -c:v libx264 -preset slow -crf 22 -c:a copy output.mkv

-c:a copy there stream-copies the audio track instead of re-encoding it. There is no reason to spend CPU re-compressing audio that is not being touched.

`faststart` is one flag, and it decides whether playback waits for the whole file

-movflags +faststart moves part of an MP4's metadata to the front of the file. FFmpeg's guide is direct about why it matters for the web specifically: it "will allow the video to begin playing before it is completely downloaded by the viewer," and it is not required for a platform like YouTube because "they can begin re-encoding before uploads complete" on their end. That distinction matters if a video is being served directly rather than re-processed by a hosting platform.

ffmpeg -i input.mp4 -c copy -movflags +faststart output.mp4

Putting the numbers together

None of ultrafast/CRF 18, slow/CRF 23, or veryslow/CRF 28 will look dramatically different at a glance on a 30-second walkthrough. But per FFmpeg's own exponential CRF relationship, the gap between the low and high end of the sane range alone is close to threefold, before preset compounds it further and before faststart decides whether that file streams cleanly or stalls on the first frame. That is the trade CasaNova Labs tunes on the server side for every video the platform renders, so a walkthrough clip lands at a size a listing page can actually serve, instead of whatever preset and CRF a default ffmpeg invocation happened to pick.

If you are building the generation side of a video pipeline yourself, these three settings are most of what a 30-second clip's file size comes down to. CasaNova Labs is where we apply them to real estate listings specifically.

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.