Site Images & Generated Art

The problem this solves

Some artwork on the player site sits in a fixed position rather than belonging to a game — the jackpot card in the casino lobby's hero row, the registration banner at the top of the lobbies, a promotion's banner, a loyalty tier's badge. That art originally shipped inside the web bundle, which meant changing a picture required a developer and a deploy.

Site images move those positions into the backoffice. Each one is a named slot an operator fills, replaces or clears, with the file stored in the platform's own object storage — and each can be filled by upload or by AI generation.

The slots

A slot holds exactly one image per operator. Replacing it deletes the previous object once the new one is committed, so storage does not accumulate orphans. An upload up to 8 MB is accepted and shrunk to the slot's size, so an ordinary full-resolution PNG does not need to be pre-compressed.

The casino lobby draws these slots through its page layout: the jackpot card sits in the hero row section and the banner in the registration banner section of the casino and home pages (see Casino). Removing the section from the layout removes the art from the page; the slot's image is kept.

Nothing is required: an empty jackpot slot falls back to the art shipped with the bundle, the cutout is simply absent unless set, and a registration banner with no picture renders as a plain themed strip whose copy still reads. The registration banner can also be switched off entirely in the casino settings.

The registration banner is always one flat picture: every word and button on it is real page text laid over a themed scrim, so the copy translates, stays accessible, and never turns into garbled lettering painted by a model. Over narrow screens the picture is washed down behind a full scrim; from the banner step up the scrim covers the copy's leading edge only, so the art stays visible on the other side. The dark and light tones exist because a scene lit for the dark themes reads as a hole under the light theme, and vice versa; a per-theme override lets one theme carry art painted in its own palette. The override list is fixed by the platform and still names an earlier set of themes; of the themes players can pick today only Graphite is on it, so every other theme shows its tone's dark or light picture.

The registration banner is shown at a different crop on desktop (short and wide) and phone (near square). Its slot menu offers Adjust focus, which sets the point of the picture that stays in view at each crop, shown side by side. The welcome strip for signed-in players uses the same picture and focus. A re-upload keeps the chosen point.

Promotion banners, tier art and sports banners are managed the same way but are owned by their promotion, tier or sports scope rather than by a fixed slot — see below.

Why the promo card takes two images

A single transparent image cannot do both jobs. The banner must be clipped — it carries the card's rounded corners, its outline, and the edge treatment that fills whatever letterbox an off-ratio upload leaves. The character must escape that clip, or it cannot cross the frame at all. So they are separate slots with opposite handling:

• The banner is cropped to the plate's fixed ratio. Whatever shape is uploaded, the stored image is the slot's shape.
• The cutout is never cropped. It is trimmed tight to its own silhouette and bounded to a maximum size, keeping its transparency intact. Cropping it would cut the figure, which is the entire point of the asset.

When a cutout is present the card also stops framing the banner and paints it as the card's own background instead, so the figure reads as standing inside a scene rather than beside a picture of one.

Image families

Every kind of generated art belongs to a family, and the backoffice groups them for the operator:

Each family is described by data — its variants, the images each draft makes, the pipeline stages it runs, which reference modes it honours, and its example subjects — and the backoffice draws every screen from that description. Adding a new kind of site image is one description and one adapter on the server; the backoffice renders it without any interface change.

What the operator sees

The backoffice Site images page has two tabs.

Images lists every family under its group (collapsed by default, with a count of image types and drafts). For each family it shows:

• a preview of what is currently live, or an empty state saying the player site is showing its bundled default,
• one line saying where in the player UI it appears,
• upload, replace and clear for each live slot,
• its drafts inline, with their status — queued, running, ready or failed.

References is the reusable reference-image library described below.

Transparent images preview on a checkerboard. That is deliberate: a transparent image and an opaque one look identical on a dark card, and the checkerboard is what makes a missing transparency obvious before it reaches players.

Nothing on this page changes what players see until an operator applies a finished draft or uploads over a live image.

Generating art instead of uploading it

Generate draft opens the composer. The operator picks the family (and, for a promotion, sports scope or tier, which one), types a subject — "a jade dragon rearing over a hoard of coins" — or starts from one of the built-in examples, and presses Generate. Families with a figure also offer a framing: full body, bust, head, or a standalone object. A seed can optionally be pinned so a retry reproduces a composition.

Only the subject is operator-supplied. The prompts around it are owned by the platform, because they have requirements that are easy to break and costly to discover: the background prompt must ask for no characters or the card ends up with two subjects, the character prompt must not describe a scene or the figure cannot be cut out cleanly afterwards, and figures are painted in a restrained house palette so generated art sits with the product's own colours rather than reading as pasted-in provider art. A per-theme registration banner additionally takes that theme's palette.

A figure run performs three steps and takes roughly a minute; the draft shows each stage as it happens:

1. Gemini generates the background banner,
2. Gemini generates the character on a plain backdrop,
3. Fal BiRefNet removes that backdrop, leaving a real transparent cutout.

The object framing skips the separate background and composes a square tile around the cut-out object instead. Registration banners, sports banners and tier hero banners are a single flat picture with no cutout step; a tier badge is a figure-style cutout trimmed onto a transparent square.

Promotion art is flat, with no cutout. A promotion draft paints one full-bleed scene from the subject (plus the promotion's name and description) with the key subject inside a centred safe area, because cards crop the picture and lay copy over it. The run has three model steps and its stage track reads queued, painting banner, reframing, saving:

1. Gemini paints the square (1216 × 1216, 1:1), using any style or composition reference the operator chose,
2. Gemini recomposes that exact square for a wide 16:9 frame (1792 × 1008) and a tall 3:4 frame (912 × 1216), run together, with the square passed as the input image so subject, palette, lighting and style carry over,
3. all three are stored as the draft's square, wide and tall images, and the draft is complete only when it holds all three.

The family takes no framing and no character reference. Applying a draft to a promotion copies all three shapes: the banner row keeps the square as its picture and the shapes are stored beside it, so every reader of a banner keeps working. Surfaces pick the shape that fits their frame (wide for media cards and the page, square for compact cards and the lobby hero card, tall for posters) and fall back to the banner image where a shape is missing. Drafts made before this change hold a plate and a cutout; they stay listed, and applying one copies only the plate.

Sets. The registration banner generates its dark and light pictures — and any theme overrides the operator ticks — as one set from one subject. Each picture can be retried on its own, and the set can be applied once every picture in it has succeeded.

Reference images

An admin can start a draft from one reference mode. Choose one mode only; modes do not combine, and each family offers only the modes its pipeline honours — the flat registration banner takes Style and Composition, not Character:

Use the References tab (the reference library) to upload reusable sources for later drafts. Every library file must be a PNG, JPEG, or WebP image no larger than 8 MiB.

Adding references. Add reference, or pasting images from the clipboard (Cmd+V or Ctrl+V) while the References tab is open, opens a full-screen upload dialog that takes many files at once. Inside it, drop more files on the drop zone, choose them with its file picker, or paste again. A paste into a text field is left alone. Each file becomes a large preview with a name you can edit; the name starts as the file name without its extension, and pasted images are called "Pasted image 1", "Pasted image 2" and so on. One usage (style, character or composition) and one group apply to the whole batch; pick New group… and name it to create the group as the batch uploads. Upload all sends the files a few at a time and shows each row's status. Rows that uploaded clear; a row that failed keeps the server's message and is retried by pressing Upload all again. The dialog closes once every file has uploaded; closing it earlier discards the queued files. A file of the wrong type or over 8 MiB is rejected on its row and is never sent. Composition sources must be opaque.

Groups. Group related references (a character's poses, a campaign's look) so they can be chosen together. The library lists references in one section per group plus an Ungrouped section. New group creates a group, a group can be renamed, and a card's group menu moves its reference to another group or to Ungrouped. Group names are unique among an operator's groups, ignoring case. Removing a group never deletes its references; they move to Ungrouped. Groups only organise the library: a draft's recorded input is unchanged.

In the generator, the reference picker shows the same sections. Use group selects every image in that group for the chosen mode. It refuses, with a message, when the group holds more images than the mode allows or, for composition, any image that is not opaque; it never picks a subset. Individual images can still be ticked one by one.

The platform does not collect an ownership or licence attestation for either a library source or a one-off upload; the operator remains responsible for having the right to use it.

A one-off file is a private input for its single draft, not a reusable library entry. Select library sources or upload one one-off file — never both. Sources only guide generation: they are not copied into active slots or shown on the player site. The retained draft shows its reference metadata and previews to backoffice users so that a later review or retry uses the recorded input.

Reference images are read from the platform's stored bytes and sent to Gemini as inference inputs. They do not change the generated output contract: each family still produces its fixed shapes — for the jackpot, a 912 × 1216 pixel 3:4 plate published to players as a 608 × 811 WebP; for promotion art, the square, wide and tall sizes above — and a cutout still has to pass the same transparency and upright silhouette checks before it is retained.

Retire a library source when it must not start new work. Retirement removes it from new selections, but does not rewrite completed or retryable drafts: each draft keeps an immutable input snapshot. A source used by a queued or running draft cannot be retired until that work is no longer in flight. One-off source storage is removed when its associated inactive draft is deleted, once no generation still uses it.

The form refuses an unsupported or oversize file, an empty or over-limit selection, a mixed library/one-off selection, an opaque-required composition source with transparency, or composition without its preservation setting (Low, Balanced, or High). Correct the stated issue before starting a draft.

Drafts and applying

Generate never changes the player site. A run's result is retained as a draft under its family, and the workflow is:

Generate -> draft (queued -> running -> ready) -> operator reviews -> Apply -> live -> player sees result

Opening a draft shows its images, its recorded subject, framing, seed and references, and the actions that fit its state:

• Apply puts a finished draft live. A jackpot banner and its cutout are always applied together; operators cannot apply one half of a pair. Promotion art is applied as its three shapes together.
• Retry starts a fresh attempt, optionally with an edited subject, framing or seed. The original draft remains.
• Delete removes a draft for good. The live draft cannot be deleted or applied again, and deleting any draft never removes an image that is live.

Every draft stays until an operator deletes it, so earlier attempts remain available while newer ones are generated and compared. Manual uploads, replacements and clears still act directly on the live images and leave drafts untouched.

Because a run outlives any single request, its state is recorded: closing the browser does not lose it. Only one run per surface may be in flight at a time, since two would race to pay for and prepare the same result. If a worker stops after claiming a run, the expired run is marked failed with Generation worker stopped before completion. Retry. No model call is made by the recovery path.

Using generated art in promotions

Promotion pairs are never applied to a site slot; they become rows in a promotion's creative rotation. A finished pair — generated for a specific promotion, or kept unassigned for later — offers two actions:

• Append to promotion adds the pair as the last row of the chosen promotion's rotation. It never replaces an existing row.
• Replace banner swaps the pair into one chosen row, leaving the rest of the rotation's order unchanged.

The promotion's own creative panel generates through the same promotion family, so a pair started from a promotion's page and one started from Site images are the same kind of draft. Both actions copy the files into promotion-owned rows; the draft remains independently, so changing or removing a promotion row never removes its source. A legacy banner-only row can stay in a rotation and renders without a cutout.

Tier art

Each loyalty tier can carry a badge (a transparent square emblem) and a hero banner (a wide opaque picture behind the Levels page's tier card). Staff reach them from an Art column on the tier ladder in the backoffice, and can generate, upload, replace, clear or apply each one there. Players see the badge on tier cards and on the small tier marks — the XP ring, the account menu — once one is applied. Until then the art positions show a placeholder ramp by ladder position, while the small marks keep the tier's own colour so tiers stay distinguishable. See Gamification.

When it refuses

A generation costs money per attempt, so the pipeline would rather fail loudly than publish something broken. It rejects:

• A cutout with no transparency. This means background removal handed back its own input, and publishing it would put a hard rectangle over the card.
• A figure wider than it is tall. A wide subject gets fitted to the card's width, sits inside the frame, and never crosses it — the art would render perfectly and do nothing. Upright, standing subjects work; wings spread wide, reclining animals and vehicles do not.
• A provider policy rejection. Gemini returns the rejection as a visible failure; the platform does not automatically switch to another provider.
• A blank image. The model returns a prompt its safety filter rejected as a uniformly black picture with an otherwise successful response, so this is the only available signal that the subject was refused.

Each refusal is shown on the pair with its reason, so the operator can reword and retry rather than guess.

Sports lobby banners

Catalog → Sports hero banners manages the wide artwork behind the featured sports event. Choose the Generic lobby, a Sport, or a particular Event scope before uploading, replacing, clearing, or adjusting the focal point. Resolution is deliberate and predictable: an event banner wins over its sport banner, which wins over the generic lobby fallback.

Generated sports art is banner-only. Its prompt may describe the visual scene, but it must not carry team names, scores, odds, calls to action, or other readable copy. The player keeps the actual match names, live state, and prices as real DOM text over the left-side scrim, so those details remain current and accessible rather than becoming stale pixels in artwork.

Generate a draft in the selected scope, review it, then apply it only after the generation succeeds. Failed drafts can be retried and any draft can be deleted; applying a draft creates the selected scope's active asset. Replacing or clearing an event asset removes that event override, so the featured match immediately falls back to its sport banner or the generic banner. Deleting a draft never clears an already-applied banner.

Sports banners also appear as a family on the Site images page, so their drafts are reviewed and applied alongside every other kind of generated art. A banner there can be replaced or cleared by hand with an upload as well as by applying a draft.

Storage

Images are processed server-side and stored through the platform's asset layer: an S3-compatible bucket when one is configured, otherwise a local mount for development. Object keys include a hash of the stored bytes, so a given URL's content never changes and files can be served with long-lived immutable caching — a replacement publishes a new URL rather than waiting out a cache.

Generated files are never committed to the repository. The only copies live in storage, with the database holding the row that points at them.

Requirements

Generation needs both platform-level API keys: GEMINI_API_KEY for plate and figure generation, and FAL_KEY for Fal BiRefNet background removal. They are billed to the platform rather than to an operator, and generation is optional: without the required keys the page reports generation as unavailable while every other function — upload, replace, clear — continues to work. Generating is limited to admin staff.

Scope & Roadmap

Implemented. Operator-managed slots for the jackpot card and the registration banner (per tone and, for the themes on the override list, per theme), with preview, upload, replace, clear and an adjustable focal point; server-side processing that crops banners to their slot and trims cutouts to their silhouette; transparent-cutout support end to end, including the player-side layering that lets a figure leave the card frame; six descriptor-driven image families — jackpot hero, registration banner, promotion pairs (assigned and unassigned), sports banners and tier art — rendered by one generic backoffice; generation from a subject line with built-in examples, framings and optional seeds; multi-picture sets; reference-guided drafts with per-family modes, reusable and one-off sources, immutable input snapshots and retirement; retained drafts with pair-only apply, retry with edits, and explicit deletion; promotion append and replace; tier badges and hero banners; durable run status with failure reasons and abandoned-worker recovery; one-run-per- surface locking; and content-addressed storage on S3 or a local mount with cleanup of replaced or deleted objects.

Not built. There is no batch generation across families and no dry-run preview of a prompt before a paid attempt. The background-removal provider is fixed rather than selectable. Tier art is not yet shown in the level-up and chest reveals. Keys are platform-wide, so a multi-tenant deployment cannot yet bill generation per operator.