AI photo enhancement and background removal that sizes a family's photo for the print it goes on

Enhance first topped out at 2,496 pixels on the long edge. At 200 pixels per inch, the threshold Messenger uses for paper, that’s about 12.5 inches, which is why banners and casket panels kept showing the low-resolution warning after an enhancement.

Now every request asks the model for the largest size it accepts at the photo’s shape: both edges a multiple of 16, neither over 3,840 pixels, at most 8,294,400 pixels in all. A 2:3 portrait comes back at 2,336 x 3,520. The source is shrunk to a 4,096 pixel long edge before it’s sent, with the same restoration prompt every time.

The bigger change is where the request starts. The canvas in the editor measures each placed photo’s effective resolution at the size it’s printed. When a photo there is under target, its warning offers “Enhance image size”, and that request carries the pixel size the placement needs to print at 200 ppi. At a fixed placement, effective ppi grows in step with pixel size, so the size needed is the measured size times 200 over the measured ppi. When the model’s output is smaller than that, a Lanczos resample grows it the rest of the way. The model draws the detail and the resample supplies the size. An output that already covers the target is kept exactly as the model returned it.

For a photo filling its spot, before and after:

• 8.5 x 11 page: 196 to 275 ppi
• 24 x 36 banner: 69 to 200 ppi
• Casket panel: 79 to 200 ppi
• Full-bleed floor banner: 31 to about 93 ppi

The floor banner is the one we couldn’t fix. Targets are capped at 36 megapixels so the editor and the PDF renderer stay responsive, which is enough for a 24 x 36 print at 200 ppi. A full-bleed photo on the 33.75 x 79.25 inch floor banner would need about 60 megapixels even at 150 ppi. It still warns. Bigger outputs also mean longer waits. A generation at the model’s largest size takes about 100 seconds.

There’s one shape the model won’t take. The endpoint refuses anything whose long edge is more than three times its short edge, so a panorama strip can’t be enhanced. The editor hides Enhance once it has measured a photo like that, and the backend refuses it with ASPECT_UNSUPPORTED before any row exists, so nothing reaches the model and nothing is billed.

Each generation becomes one row in CaseImageVariant, with a kind (UPSCALE or BG_REMOVAL), a status, the source variant it was made from, whether it was accepted and which order line billed it. That one row is both the job status the editor polls and the billing record. The upload pipeline around it already existed: the browser puts the file straight into S3 through a presigned URL, and a Bull worker runs Sharp and the optimizer before the photo is committed.

A variant job goes onto the same queue. The start route creates the row and enqueues the job in one idempotent step, so a double click or a second tab reuses the generation already running instead of paying for another. Discarding a result and pressing Enhance again reopens that same result for free. The editor polls every 2 seconds for up to 240, which is the model’s 180 second budget plus a minute for the queue, the resample and the upload, so a slow generation that succeeds is never shown as an error.

Every failure is final. We turned retries off in the OpenAI SDK, because a retry is a second paid generation, and the only retry is the person pressing “Try again”. Failures carry a stable code that the editor translates, and each code decides whether “Try again” is offered:

• MODERATION_BLOCKED when the model refuses the photo
• SPEND_LIMIT when the API account has hit its limit
• MODEL_ERROR and ENQUEUE_FAILED, which can be retried
• DAILY_CAP_REACHED, from a ceiling of 200 Enhance generations a day per environment, where 0 works as a kill switch

The background removal endpoint scales to zero when it’s idle, so a request to a cold endpoint gets a 503 while its T4 GPU wakes up. The client waits 15 seconds and tries again, inside a 240 second budget measured in elapsed time, and only starts a retry when at least 30 seconds are left, about what a warm removal takes. A timeout or a connection reset partway through a request is final, since the GPU may already have done the work.

For local development and tests, each model has a fake adapter that refuses to load in production. The fake upscaler runs the same resample step, so local results come out at production sizes.

The first time someone runs Enhance, the editor shows what it costs per use and a notice Messenger wrote. Generative upscaling invents new detail to fix blur, and it can occasionally change a subtle facial expression, a skin texture or something in the background. That matters more on a photo of someone who just died than almost anywhere else. The notice is in English, Spanish and French, and it shows again on the result screen before the billable button, because a person who dismissed the first screen skips it after that.

The result opens in a compare slider, a draggable and keyboard-operable divider between the original and the enhancement. “Accept Enhancement” is the only action that can bill. Discard leaves the result unaccepted.

Once accepted, the enhancement becomes the photo. One rule picks which file represents a case photo (the newest accepted upscale, then the optimizer’s copy, then the upload), and every reader uses it: the editor canvas, the PDF renderer, the proof screenshots, the memorial slideshow and the Memorial Maker storefront. Accepting moves every saved placement of that photo on every layout page. The tile and the canvas item carry an “Edited with AI” tag, which is drawn only in the editor and never prints.

There’s no un-accept, because the charge stands. “Revert changes” shows the original again for everyone and everywhere the photo is used, and “Show enhancement” brings it back at no charge.

Remove Background is a tab in the editor’s Adjust Image modal, beside Pintura’s own crop and filter tools, and it follows the same steps with the same slider. It cuts out whatever the editor is showing. When that’s an accepted enhancement, the backend cuts out the enhancement’s file, or a photo shown at 3,840 pixels would come back as a cutout the size of the original upload. A photo stored sideways with an EXIF orientation tag is turned upright first, since the model ignores the tag. If the item already has crops or filters, those edits are applied again to the cutout and saved as a PNG so the transparency survives.

Nothing is charged at the moment of accept. The first order for a case that checks out counts every accepted variant no earlier checkout billed, writes one charge row per kind on that order and marks those variants billed in the same transaction. If two checkouts race over one case, the one that can’t mark every variant it charged rolls back. The checkout page sends the AI total it showed, and when a price changed in between, checkout refuses and reloads, so nobody pays an amount they didn’t see.

An admin sets each kind’s price in Memorial Maker’s Site Admin, and the editor asks for the current price every time a tool opens. Remove Background won’t start until that price is on screen.

Five days after launch, Messenger asked that edits a designer makes on a family’s behalf not be charged to the family. A designer opens the editor through an order’s edit link, which the backend resolves as the order’s owner, so their accepts looked exactly like the customer’s. We added an acceptedByStaff flag, written in the same update that marks the accept, and every billing query leaves those rows out. Designer and QC links and internal staff sessions are covered. A staff member working on the customer’s own link is still billed like the customer, because that link carries the customer’s role, and we wrote that limit into the docs.

Both edits sit behind one switch for every funeral home at once, and it started off. A super admin flips it in Site Admin. The write carries the value the admin’s page showed, so if another admin flipped it in the meantime the save is refused, and each change writes an audit row with the old and new value. The backend reads it on every request, so turning it on or off needs no deploy. An edit accepted while the switch was on keeps showing and printing after it’s turned off.

In November, Messenger asked that the edits be offered only on Memorial Maker orders. The backend now refuses any start, accept or revert from an editor opened on a My Designer Lab order before it reads the switch, and the editor hides every entry point there.

To be clear, we don’t have usage numbers yet. The switch stayed off in production through the follow-up release on October 23, and we can’t tell you how many families have kept an enhancement or what it has earned Messenger.

It went out on October 20 as a stack of 13 pull requests, each reviewed on its own, from the shared contract (error codes, Zod schemas, the size rules) up through the worker, the editor, checkout and the admin switch. Eleven more followed from QA and code review and were tested together, among them the fix that moves every saved placement of a photo on accept.

The editor’s tests run the real components, hooks and store with only the backend calls replaced. One follows a photo from the canvas warning through the server’s size rule and checks the warning clears on a 24 x 36 banner, a casket panel and a 5 x 7 card and stays on the floor banner. Checkout and the admin prices run against a real database.