DEV Community: 王龙

Build log: turning one photo into a ~13-second racing meme video on Cloudflare Workers

王龙 — Fri, 16 Oct 2026 18:43:07 +0000

A short racing clip has been going around on short-video apps: someone in a deep squat, flying down a highway at absurd speed, with a chase behind them. People wanted to put their own face in it. I built a small site that does exactly one thing: you upload one photo, and about 4 minutes later you get an about 13-second racing meme video with an original backing track.

This post is the build log: the pipeline, the parts that were harder than they looked, and the mistakes that cost me re-runs. No benchmarks; where I only have one data point, I say so.

Disclosure: I built this. MemeMotion is unofficial and not affiliated with TikTok, the creator, or the Crazy Frog rights holders. Motion reference from the original post by @wdmowski. Rights to the original clip belong to its creator.

The shape of the product

The constraints I set myself before writing any code:

One template, one button. No prompt box. The user picks a photo and pays; everything else is fixed on the server.
Pay per video, no subscription. One credit = one video. Packs are $7.99 / 1, $14.99 / 2, $27.99 / 4, paid once.
Google sign-in before generating, so jobs, credits and downloads belong to an account.
Short retention. The finished video (and the source photo) is deleted 7 days after the job finishes.
Never charge for something that can't work. Check the photo before money moves; refund automatically when generation fails.

The pipeline

Everything runs in one Cloudflare Worker: D1 for users, jobs and the credit ledger; R2 for photos, reference media and outputs; a Queue producer/consumer for jobs; and two cron triggers for sweeps and cleanup.

Step 1: check the photo before charging

The model wants one clear face. If you send a group photo or a profile shot, it still bills you and the result is bad. So the first thing that runs, before any credit or budget is touched, is a cheap check: exactly one, roughly frontal face.

Workers can't run a face-landmark model in-process, and I didn't want a new vendor just for this, so the check uses a small vision model on the same provider I already send the photo to. The comment in the code says it plainly:

/**
 * Pre-charge photo check: exactly one, roughly frontal face.
 * ...
 * Runs before any credit or budget is touched.
 */

Two details that mattered in practice:

Tiny face boxes are usually faces in posters or backgrounds, so boxes below 1.5% of the frame are ignored.
If the check service itself errors, the request fails closed: a 503 and nothing charged. Silently letting it through would mean charging for jobs that are likely to fail.

Step 2: the reference clip is the product

This is a video-to-video job: a fixed motion reference plus the user's photo. Getting the reference right turned out to be most of the work.

The reference is stored privately in R2 and handed to the model through a short-lived signed link. It is never used as a public <video> source on the site; the pages show only outputs made with fictional people. The page credits the original post.

I went through more than one model while prototyping (the code still has a switch for three providers), and the default is now a recast-style model that keeps the reference's camera move, timing and poses and swaps in the person from the photo. It bills by output seconds, and output length equals reference length, which brings me to the most useful bug of the project.

The close-pass shot that broke identity

The first outputs looked right for most of the clip, then in the last 1–2 seconds the face drifted away from the uploaded photo and back toward the man in the template footage.

The cause was the end of the reference: a fast close pass by the camera with heavy motion blur. In that shot the model had almost nothing sharp to anchor the new face to, so it fell back to the person it could see in the reference.

The fix didn't need any paid re-runs. I trimmed the reference so that shot is gone:

/**
 * The racing reference is trimmed to exactly 12.80s (384 frames; the old shot 5,
 * a blurred close pass, made the rider's face drift) ...
 */
export const RECAST_REF_SECONDS = 12.8;

and tightened the prompt so the person from the photo stays the rider "in every shot, including any close pass by the camera".

A side effect: billing follows output length, so the shorter reference also made every clip cheaper. It's also why the site says "about 13 seconds" instead of 15.

Step 3: a guard against "the model returned a different length"

Because the pipeline assumes output length equals reference length, the runner checks it. The tolerance is deliberately small:

export function outputDurationMatches(inputSeconds: number, outputSeconds: number): boolean {
  if (!Number.isFinite(inputSeconds) || !Number.isFinite(outputSeconds)) return false;
  if (inputSeconds <= 0 || outputSeconds <= 0) return false;
  const tolerance = Math.max(0.2, Math.min(0.5, inputSeconds * 0.03));
  return Math.abs(outputSeconds - inputSeconds) <= tolerance;
}

The same module rewrites the MP4 timing table (stts) to constant frame rate when needed, and there's a test named "accepts small encoder drift and rejects a shortened or lengthened clip". A clip that is a second short would break the music sync in the next step, so it's better to catch it here.

Step 4: strip the audio, then add our own

Whatever audio comes back must not ship. The reference had its audio removed when it was prepared, but I don't trust that alone, so there's a small MP4 box walker that drops audio tracks from the result and zeroes the orphaned sample bytes:

/**
 * Drop audio tracks from a non-fragmented MP4 and zero the orphaned sample bytes.
 * Reference-clip audio must not ship with the result. If the file is not an MP4
 * we can prove is silent, callers should refuse to store it.
 */

The music is an original backing track generated for the site, not any existing song. It's stored privately in R2 and merged with a hosted ffmpeg merge endpoint. The trick that removed all filter work: the track is cut to 13.0 s with a 0.5 s fade-out that ends at 12.8 s, which is exactly the clip length. The merge never cuts the music mid-fade.

Muxing is best effort. If it fails, the job still succeeds with the silent version. Users get both: the music version by default, and a silent copy, because some platforms want you to add a sound inside the app.

The job page. The uploaded photo is blurred here for the screenshot.

Step 5: money, queues and refunds

This is the part I'd tell anyone building a paid generator to design first.

One active job per user. A unique index on active jobs in D1 enforces it. If someone pays for another video while one is running, it's charged and parked as waiting_slot, then started when the previous job ends (queue consumer hook) or by the cron sweep. If it can never start, its credit is refunded once.

A site-wide daily spend cap. Generation costs real money per second of output, so there's a daily cap on provider spend plus a per-user daily limit. At the cap, a new job is parked as waiting_budget with no credit charged and no budget reserved, and the cron promotes parked jobs oldest-first when budget frees up. An admin alert goes out once per day when spend crosses a threshold.

Failures are classified, not retried blindly.

A moderation rejection from the provider is final: never resubmitted, credit refunded, plain message to the user.
Other failures get at most one automatic rerun, with a fresh idempotency key so the provider doesn't dedupe it onto the failed request. Then refund.
Refunds are deduplicated per job, so a retry storm can't refund twice.

Never submit twice by accident. A network failure on submit doesn't mean the job wasn't created. Before any second submit, the runner looks up an existing request for that job; a failed status check never triggers a submit.

Step 6: delivery, sharing and the 7-day rule

When a job finishes, the user gets one "ready" email (or one "failed" email) and the video is in their account.

Name in the greeting blurred.

The share panel links to the site, not to the video. Videos stay private until the user posts the file themselves; on mobile, TikTok/Instagram use the native share sheet with a download fallback.

Retention is enforced in code, not policy text: when a job completes it gets expires_at = now + 7 days, and a cleanup job deletes both the output and the original photo from R2. Failed or never-finished jobs are cleaned up 7 days after creation.

What I'd do differently

Watch the reference shot by shot before tuning prompts. The single biggest quality fix was removing one shot from the reference, and it cost nothing.
Make output length a server constant from day one. My copy said "15 seconds" for a while and had to be changed everywhere when the reference changed.
Write the refund paths before the happy path. Parking, one rerun and per-job dedupe were much easier to reason about as a state machine than as patches.
Keep one fact source. Prices live in one JSON catalog that both Stripe and the UI read, so copy and checkout can't drift apart.

Numbers I can actually stand behind

Output: about 13 seconds (the reference is 12.80 s).
Time to finish: about 4 minutes. This is from the first live job, a single data point, not an average.
Retention: 7 days.

That's it. If you've fought identity drift in video-to-video models, I'd like to hear what worked for you in the comments.

If you want to try it: MemeMotion. MemeMotion is unofficial and not affiliated with TikTok, the creator, or the Crazy Frog rights holders. Motion reference from the original post by @wdmowski.

Why your transparent video turns black: I tested WebM alpha, ProRes 4444 and HEVC alpha in Chrome, Firefox, Edge and OBS

王龙 — Fri, 09 Oct 2026 18:07:19 +0000

Search for "transparent video" and you'll find plenty of confident compatibility tables. Most of them don't say whether anyone actually played the file. I wanted one where every cell answers a simpler question: did someone check this, and how?

So I encoded the same 4-second clip five ways, put each one over a solid magenta background, and read the pixels back. The rule for the table: a cell is either tested (by me, with versions and a date), per official docs (with a link to the vendor's own words), or not tested. No guessing to fill gaps.

That rule leaves a lot of cells empty, and I think the gaps are useful too. If you can fill one in from macOS or Windows, please do it in the comments.

TL;DR

Web (Chrome, Firefox, Edge): WebM VP9 with alpha kept transparency in all three (tested, Linux).
OBS: WebM VP9 alpha and ProRes 4444 both kept transparency through a Media Source (tested, OBS 30.2.3 on Linux).
H.264 MP4 never has alpha. It plays, and the transparent area comes out black (tested). Asking x264 for yuva420p doesn't help; it quietly falls back to yuv420p.
Safari + WebM alpha: WebKit's own bug tracker describes it as playing "with a grey background rather than transparent" (per docs, not tested by me).
HEVC with alpha: Apple documents it for Safari on iOS 13 / macOS Catalina and later. I could not test it, because libx265 on Linux silently drops the alpha plane. More on that below.
Editors (Premiere, Resolve, After Effects, Final Cut Pro): vendor docs point to ProRes 4444 for alpha. I didn't run import tests in any editor.

The test setup

Everything ran on 2026-09-24 on one machine:

Item	Version
OS	Debian GNU/Linux 13 (trixie), x86_64
ffmpeg	7.1.5-0+deb13u1
Chrome	151.0.7922.169
Firefox	153.0 (Playwright build)
Edge	153.0.4234.48
OBS Studio	30.2.3 (X11)

The source clip is synthetic: ffmpeg drew a cyan circle on a fully transparent background, 320×180, 4 seconds. A synthetic clip makes the check easy. The corner pixel should be fully transparent and the circle fully opaque, so there's nothing in between to argue about.

Encodes (the exact commands I ran)

# WebM VP9 with alpha
ffmpeg -y -i source-synthetic.mov -an -c:v libvpx-vp9 -pix_fmt yuva420p \
  -auto-alt-ref 0 -deadline good -cpu-used 4 -b:v 0 -crf 33 -t 4 01-webm-vp9-alpha.webm

# HEVC "with alpha" attempt (spoiler: no alpha in the output)
ffmpeg -y -i source-synthetic.mov -an -c:v libx265 -pix_fmt yuva420p -t 4 02-hevc-alpha-attempt.mov

# ProRes 4444 with alpha (profile 4 = 4444)
ffmpeg -y -i source-synthetic.mov -an -c:v prores_ks -profile:v 4 -pix_fmt yuva444p10le -t 4 03-prores4444-alpha.mov

# H.264 MP4 control (no alpha by design)
ffmpeg -y -i source-synthetic.mov -an -c:v libx264 -pix_fmt yuv420p -preset fast -crf 23 -t 4 04-mp4-h264-noalpha.mp4

# PNG sequence (RGBA)
ffmpeg -y -i source-synthetic.mov -an -vf format=rgba -start_number 0 05-png-seq/frame_%04d.png

Browser check: magenta stage + canvas pixel read

A local HTTP page put each file inside a <div> with background: #ff00ff. Playwright drove Chrome, Edge and Firefox. Once the video played, the page seeked to 0.1 s, painted magenta onto a canvas, drew the video frame over it, and sampled two pixels: a corner (should be transparent) and the circle (should be cyan).

ctx.fillStyle = '#ff00ff';
ctx.fillRect(0, 0, 320, 180);
ctx.drawImage(video, 0, 0, 320, 180);

const corner = ctx.getImageData(10, 10, 1, 1).data; // transparent area
const circle = ctx.getImageData(40, 90, 1, 1).data; // opaque area
// corner ≈ [255, 0, 255] → alpha kept (magenta shows through)
// corner ≈ [0, 0, 0]     → no alpha (black)

Real readings from Chrome 151: the WebM corner was [255, 0, 255, 255]. The H.264 MP4 corner was [0, 0, 0, 255]. Same clip, same page.

OBS check: Color Source + Media Source

In OBS I put a magenta Color Source at the bottom of the scene and a Media Source pointing at the test file above it, then took a screenshot of the preview. If alpha survives, you see a cyan circle on magenta. If it doesn't, you see a black rectangle.

Results

Legend: ✅ tested = I ran it, on Linux, 2026-09-24, with the versions above. 📄 docs = the vendor's own documentation says so (footnote links); not tested by me. — not tested = no test and no usable official statement, so I'm not claiming anything.

Browsers

Format	Chrome 151	Firefox 153	Edge 153	Safari (macOS)	Safari (iOS)
WebM VP9 + alpha	✅ alpha kept	✅ alpha kept	✅ alpha kept	📄 plays, grey bg instead of transparent [1]	— not tested [2]
HEVC + alpha	— not tested [3]	— not tested [3]	— not tested [3]	📄 supported (Catalina+) [4]	📄 supported (iOS 13+) [4]
ProRes 4444 MOV	✅ won't play	✅ won't play	✅ won't play	— not tested	— not tested
H.264 MP4 (control)	✅ plays, black bg	✅ plays, black bg	✅ plays, black bg	— not tested	— not tested
PNG sequence	✅ N/A as `<video>`; frame via `<img>` keeps alpha	✅ same	✅ same	— not tested	— not tested

OBS and editors

Format	OBS 30.2.3	Premiere Pro	DaVinci Resolve	After Effects	Final Cut Pro
WebM VP9 + alpha	✅ alpha kept	— not tested	— not tested	— not tested	— not tested
HEVC + alpha	— not tested [3]	— not tested	— not tested	— not tested	— not tested
ProRes 4444 MOV	✅ alpha kept	📄 imports ProRes; 4444 carries alpha [5]	📄 ProRes decode Yes; alpha exports 4444 [6]	📄 ProRes import/export; 4444 carries alpha [7]	📄 imports all ProRes; use 4444 to preserve alpha [8]
H.264 MP4 (control)	✅ plays, black inside the frame	— not tested	— not tested	— not tested	— not tested
PNG sequence	— not tested	📄 PNG import listed; sequence alpha not stated [9]	📄 png decode/encode Yes [6]	📄 PNG import; stills importable as sequence [7]	📄 PNG stills supported [8]

Count: 50 cells. 15 tested, 11 per official docs, 24 not tested.

The "✅ won't play" cells are real results, not failures of the test. Chrome and Edge returned DEMUXER_ERROR_NO_SUPPORTED_STREAMS for the ProRes MOV. Firefox returned NS_ERROR_DOM_MEDIA_DEMUXER_ERR. ProRes is an editing format, not something to put on a web page.

Sources for 📄 cells

Safari 14.1 release notes: "WebKit on macOS supports WebM files containing VP8 or VP9 video tracks" (webkit.org). For alpha, WebKit bug #275908, "VP9 with transparency plays back incorrectly … with a grey background rather than transparent", status NEW when I checked (bugs.webkit.org).
The bug doesn't say whether it covers iOS, and the Safari 14.1 WebM paragraph is about macOS, so I'm not extending either one to iOS.
I couldn't produce a real HEVC-with-alpha file on Linux. See the next section.
Apple WWDC19 session 506: "HEVC video with Alpha is supported by Safari in iOS 13 and macOS Catalina" (developer.apple.com). See also Using HEVC video with alpha.
Adobe lists Apple ProRes as a supported native format (helpx.adobe.com). Apple: ProRes 4444 and 4444 XQ "are also the only Apple ProRes codecs that support alpha channels" (support.apple.com/102207).
DaVinci Resolve 20 Supported Codec List: Apple ProRes, mov/mkv, Alpha Exports: 4444, Decode: Yes. png: Decode/Encode Yes (PDF).
After Effects supported formats: "Apple ProRes codec — Import and Export", "Portable Network Graphics (.png)", and "You can import files of any still image format as a sequence" (helpx.adobe.com). The alpha part comes from Apple 102207, as in [5].
Final Cut Pro supported media: "Apple ProRes (all versions)", PNG under still-image formats (support.apple.com). Apple's FCP transcoding note: "To preserve the alpha channel, choose ProRes 4444 or ProRes 4444XQ" (support.apple.com/101763). For compositing see Use alpha channels.
Premiere's supported-formats page lists PNG. I found no Adobe sentence that says sequence alpha is preserved, so I'm not claiming it.

ffprobe will mislead you twice

1. A VP9 file with alpha reports yuv420p. This is the ffprobe output for the WebM that kept alpha in every browser above:

"codec_name": "vp9",
"pix_fmt": "yuv420p",
"tags": {
  "alpha_mode": "1",
  "ENCODER": "Lavc61.19.101 libvpx-vp9"
}

If you only grep for yuva, you'll decide this file has no alpha, and you'll be wrong. For WebM, look for the alpha_mode=1 tag, then confirm with a visual composite test like the one above.

2. x264 and x265 accept a yuva request and silently ignore it. I asked for alpha three times and got none:

Command asked for	ffprobe reported	Alpha?
`libx264 -pix_fmt yuva420p`	`yuv420p`	No
`libx265 -pix_fmt yuva420p`	`yuv420p` (Main)	No
`libx265 -pix_fmt yuva444p10le`	`yuv444p10le` (Rext)	No

The ProRes encode was the opposite case: I asked for yuva444p10le and ffprobe reported yuva444p12le, profile 4444, tag ap4h. The alpha survived, and the decoder just reports the 12-bit pixel format. In short, when an encoder can store alpha, ffprobe shows a yuva format. When ffprobe shows yuv with no alpha tag, the alpha is gone.

Why I couldn't test HEVC with alpha on Linux

Apple's HEVC-with-alpha format isn't simply "HEVC with an extra channel." According to WWDC19 session 506, each frame carries two layers inside a single video track, a base color layer and an alpha layer, using special HEVC syntax. Apple says encoding goes through AVFoundation / VideoToolbox (AVAssetWriter, export presets "with Alpha", or VTCompressionSession).

On Linux I have libx265, which (as shown above) drops the alpha plane without raising an error. I don't have VideoToolbox there. So my "HEVC alpha" file was really ordinary opaque HEVC, and testing it would only show how browsers handle opaque HEVC. For the record, Chrome and Edge refused to play it, and Firefox played it with a black background. That's why every HEVC cell in my browser and OBS columns is not tested, and the Safari cells rely on Apple's documentation.

The same talk explains why a "working" HEVC alpha file can still lose its transparency somewhere else: an HEVC decoder "that does not know how to handle the Alpha layer will ignore it and display the base layer alone." The file plays, but the alpha layer is skipped.

Serving one overlay to every browser

MDN documents how <source> fallback works: "The browser goes through a list of <source> elements to find a format it supports. It uses the first one it can display" (MDN). The usual pattern pairs an HEVC-alpha file for Safari with a WebM VP9 alpha file for everyone else:

<video autoplay muted loop playsinline>
  <!-- HEVC with alpha (encoded on macOS) — Safari per Apple docs; NOT tested by me -->
  <source src="overlay-hevc-alpha.mov" type="video/quicktime">
  <!-- WebM VP9 alpha — tested: Chrome 151 / Firefox 153 / Edge 153 on Linux -->
  <source src="overlay-vp9-alpha.webm" type="video/webm">
</video>

Two caveats, both based on the documents above rather than on a test of my own. First, the order matters, because the browser takes the first source it can play. Second, per the WWDC note, a browser that can decode HEVC but not the alpha layer would show the opaque base layer. Before you ship this, open it in every browser you care about, on the operating systems your users actually run. I haven't run this snippet, so I can't tell you which source each browser picks.

Pick the format by destination

Destination	Use	Basis
Chrome / Firefox / Edge `<video>`	WebM VP9 alpha (`yuva420p`)	✅ tested (Linux)
Safari `<video>`	HEVC with alpha, encoded with Apple tools	📄 Apple WWDC19 506; not tested
OBS Media Source	WebM VP9 alpha or ProRes 4444	✅ tested (OBS 30.2.3, Linux)
Premiere / Resolve / AE / Final Cut	ProRes 4444 MOV	📄 vendor + Apple docs; not tested
Anything where you need alpha	Not H.264 MP4	✅ tested: black background

"My transparent video turned black": a checklist

Each item points to its evidence:

The file never had alpha. H.264 MP4 has no alpha. ✅ In Chrome, Firefox, Edge and OBS the transparent area rendered black.
Your encoder dropped the alpha without telling you. x264 and x265 both did this (the table above). Check with ffprobe.
You exported ProRes, but not 4444. Apple: only ProRes 4444 and 4444 XQ support alpha. 📄
WebM VP9 alpha in Safari. WebKit #275908 describes playback "with a grey background rather than transparent". 📄 (I haven't seen it myself; Safari isn't in my test.)
HEVC alpha in a decoder that doesn't know about the alpha layer. Per Apple, it shows the base layer only. 📄
The editor interprets the alpha differently. Saying an editor "supports ProRes" doesn't tell you whether it treats alpha as straight or premultiplied by default. If edges or backgrounds look wrong after import, check the footage interpretation settings (Interpret Footage in Adobe apps) before you blame the file.

Caveats

Linux only. Chrome, Firefox, Edge and OBS ran on Debian 13. Don't assume the same results on macOS, Windows or mobile, where decoders and GPU paths differ.
OBS used software GL (X11 + llvmpipe). Hardware decoding paths may behave differently.
Synthetic clips. The test files came from ffmpeg, not from any particular app's export pipeline.
"Per docs" isn't a test. I quoted vendor documentation exactly and linked it, but I didn't open Premiere, Resolve, After Effects or Final Cut Pro.
PNG sequences aren't a <video> format. The browser cells only show that a single RGBA frame kept alpha when drawn with <img>.

What I haven't tested yet (help wanted)

These are the 24 empty cells, grouped:

Safari on macOS and iOS: every format. I have no Safari results of my own, including WebM alpha (only the WebKit bug above) and HEVC alpha (only Apple's docs).
Real HEVC with alpha anywhere: it needs an encode from VideoToolbox on a Mac.
WebM VP9 alpha in Premiere, Resolve, After Effects and Final Cut Pro
H.264 MP4 in all four editors and in Safari (expected to have no alpha, but nobody has checked)
PNG sequence in OBS (Image Slide Show or similar)
macOS and Windows builds of Chrome, Firefox, Edge and OBS

If you can run the magenta test on any of these, post the app version, OS, file type and what you saw in the comments. I'll update the table and credit you.

How I produce these files day to day

Disclosure: I build ExportAlpha. It's a browser tool that removes the background from a video and exports it as WebM VP9 with alpha (yuva420p, clips up to 60 seconds) or ProRes 4444 MOV (up to 8 seconds), which are the two formats that passed the OBS test above. It doesn't export HEVC with alpha, so for the Safari row you'll still need Apple's tools. The test clips in this post were made with plain ffmpeg, not with ExportAlpha, so the matrix doesn't depend on my product. The full matrix, with per-cell notes, is also published here.

If you've been fighting a black box behind a "transparent" overlay, I'd like to hear which app and format it was. Questions about the Playwright and canvas setup are welcome in the comments, too.

Drafted with AI assistance; every test result comes from the run described above, and each cited claim links to its source.

Build log: a free BaZi chart calculator and one-time PDF reports on Cloudflare Workers

王龙 — Mon, 05 Oct 2026 19:26:43 +0000

I've been building PillarChart — live under the product name BaZi Chart — a small site that turns a birth date, time and place into a BaZi (Four Pillars) chart, shows every step of the calculation, and offers optional one-time PDF reports.

BaZi isn't rare on the English web. What I wanted was different from the "drop a birthday, get a destiny score" pattern: a calculator whose rules you can audit, content pages that cite classical sources instead of inventing personality claims, and a monetization path that doesn't need a subscription. The funnel shape is familiar — free chart, then a paid written report, the same shape that works for other niche calendar/astrology calculators with sample PDFs — but the visual language and the content depth are not copied from anyone else's layout. I cared more about looking like a careful calendar tool than like a generic "AI oracle."

This post is the engineering and editorial log: the engine, the receipt, the Workers stack, the content wedge, and how the paid reports sit on top of deterministic chart facts.

The stack

Everything runs on Cloudflare:

Next.js 16 deployed to Workers via @opennextjs/cloudflare
D1 for accounts, orders and report jobs
R2 for finished PDF reports
Queues for report generation (max_batch_size = 1, max_retries = 3)
Auth.js (next-auth) for Google sign-in when someone wants a written report
pdf-lib to assemble the report PDFs on the Worker

The chart engine itself is custom TypeScript under src/lib/bazi/. It never calls a network API. Solar-term instants for 1900–2100 are a committed lookup table generated offline with Astronomy Engine (SearchSunLongitude). Independent calendar libraries (lunar-javascript, tyme4ts, sxtwl) appear only in tests, as cross-check oracles — they are not the production engine.

Why a receipt matters more than a reading

Most BaZi disagreements online aren't mystical. They're convention disagreements:

Does the year change at Li Chun (Sun at ecliptic longitude 315°) or at Chinese New Year?
Does the day change at 23:00 (start of the Zi hour) or at midnight?
Is the hour taken from clock time, or corrected to true solar time at the birthplace (longitude + equation of time, daylight saving removed)?
Was daylight saving stripped out before the hour pillar was set?

Our defaults are published on /methodology: Li Chun year, solar-term months, true solar time on when you give a city, day change at 23:00 (switchable to midnight). Every chart prints an engine version — currently bazi-lichun-jieqi-tst-v1 — and a receipt: UTC instant, DST minutes removed, longitude and equation-of-time corrections, the solar terms before and after the birth, and the resulting true solar time.

If you don't know your birth time, you get three pillars and no hour. The form never fills in noon.

How I check the engine (published numbers)

I don't want to claim "accurate" without saying against what. The methodology page lists the checks that ship with the site:

Solar terms: all 4,824 terms from 1900–2100 compared with sxtwl, tyme4ts and lunar-javascript. Largest difference: 73 seconds. Sample published Li Chun instants match to the minute.
Four pillars: 10,000 random births plus 2,500 near a boundary, against lunar-javascript (midnight day change) and tyme4ts (23:00 day change), with no differences; another 1,200 births within three minutes of a solar term also match.
Luck pillars: 5,000 random births vs lunar-javascript's minute-precise method — same direction and pillars; start offset within one day.
Other calculators: reproduced the published outputs of seven calculators in the open Jade Almanac conventions dataset (CC0) once each tool's conventions were aligned.
Manual spot check: 20 charts vs bazi-calculator.com; 18 match on all pillars. The two that differ are births 14 and 18 minutes after Li Chun — border cases that site itself flags.

Those numbers live on the public methodology page, not in a private spreadsheet. If a future engine revision changes a rule, the version string on the chart changes with it.

The free layer (no account)

Three calculators are free and need no sign-up:

Full BaZi chart on the homepage — pillars, hidden stems, Ten Gods labels, weighted five-element count, Day Master strength, luck pillars when gender is given, plus the receipt.
/day-master-calculator — just the Day Master stem, for people who only searched that question.
/compatibility — two charts side by side: Day Master element relation and stem combinations, Ten Gods both ways, day-branch harmony/clash/same/none, and five-element complement vs doubling. No score, no percentage match, no "compatible / not" verdict. It also doesn't do Chinese zodiac (year-animal) compatibility — different method.

Nothing from those free flows is saved.

Thick content instead of thin SEO glue

A calculator alone feels thin. I wrote a first wave of English explainers that sit next to the engine and quote only passages I could check against an online edition (Wikisource / Chinese Text Project), with our own translations labelled as such:

Live page	What it's for
`/methodology`	Every calculation rule, sources, school disagreements, verification
`/classical-sources`	Which books we cite (Di Tian Sui, Yuanhai Ziping, Sanming Tonghui, Ziping Zhenquan, …) and for what
`/li-chun-bazi-year-start`	Li Chun vs Chinese New Year, with worked boundary charts
`/five-elements`	Generating/controlling cycles, seasonal strength, how we count
`/hidden-stems`	Twelve-branch table from the Yuanhai Ziping verse; our weights called out as ours
`/weak-day-master` · `/strong-day-master`	What the labels mean; thresholds (42% / 58%) are our method
`/day-master/jia-wood`	Pilot Day Master page (甲); more stems follow the same template
`/about`	Editorial team (no invented master lineage), how AI is and isn't used

The about page is deliberate: charts are never computed by AI; optional short written readings for signed-in users are disclosed separately; articles are drafted with AI assistance and classical quotes are checked against linked editions. We write "the Di Tian Sui describes…" — not "you will…".

One-time reports (not a subscription)

After a free chart, the result page offers written PDF reports. Prices are listed on /pricing:

SKU	Price	What's in it
Essential Natal Report	$19	10 chapters · listed as 11–14 pages
Complete Natal + 10-Year Luck Report (featured)	$29	Everything in Essential + luck-pillar chapters and a decision filter · 14 chapters · listed as 15–23 pages
Compatibility Report	$19	Two charts · 8 chapters · listed as 9–13 pages
2027 Annual Forecast	$24	Year pillar vs natal + current luck · month by month · listed as 11–13 pages

Anyone with a Google account can buy a report after signing in with Google — the free chart still needs no account. Delivery is a PDF (sample downloads are already public). Refunds: delivery failures in full; wrong payment or wrong birth details reviewed within 7 days; delivered personalized reports are not normally refunded — same wording as the pricing page.

Each chapter is built the same way: chart evidence (facts the engine already computed) → a reading → one question to reflect on. There is no overall life score. The only percentage in a natal report is the Day Master strength share from the published point method.

Samples you can read without paying

/sample-report — Complete report for one fictional person (real engine chart: 15 June 1990, 14:30, Shanghai → 庚午 / 壬午 / 辛亥 / 乙未; Xin Day Master; weak at 38% on our method). Sample PDF: 15 pages. The page states clearly that Essential has 10 of Complete's 14 chapters, so Essential buyers don't expect luck-pillar chapters.
/sample-compatibility-report — Maya and Leo, two fictional people, two real charts (Chicago / Manchester). Sample PDF: 9 pages. Relations shown are ones the engine actually computes (e.g. Wood produces Fire; Mao–You clash) — still no match score.

Turning a chart into a PDF on a Worker

The paid path is intentionally boring:

You calculate a free chart (still no account).
On the result page you pick Essential or Complete (or start from the compatibility calculator for the pair report).
Sign in with Google (any Google account) to check out that SKU; the order stores the chart query, not a free-form essay prompt.
A queue consumer builds chapter facts from the same engine functions the free page uses, fills the template (and may polish prose with a model when enabled — the sample pages show the template wording), assembles a PDF with pdf-lib, stores it in R2, and emails a time-limited download link.

That order of operations is the whole point of the product bet: if the pillars were wrong, prettier prose would make it worse. The expensive mistake in this category is letting a model invent a clash or a Ten God the code never computed. Keeping the engine authoritative and the PDF downstream is how I avoid that.

The 2027 annual SKU is the same pipeline with an extra year-pillar overlay: natal chart + current luck pillar + month-by-month walk of 2027. It is listed on pricing now so people who care about the coming Li Chun boundary can see it early.

Design notes (without pretending to be a temple)

I wanted the UI to feel like paper, ink and vermilion calendar work — because BaZi is a calendar system — not a generic "mystic AI" gradient. Stems, branches and solar terms belong to the calculation. Motifs that belong to other Chinese traditions (luopan compass, Hetu/Luoshu, bagua logos) stay out unless they're clearly labelled as something else. The homepage already walks year → month → hour the way the engine does: Li Chun, the twelve jie, true solar time.

Lessons so far

Publish the conventions, or you'll spend forever explaining "why does site X disagree?" The receipt and the methodology page are the product, not a footer link.
Keep the LLM away from the pillars. Deterministic code owns the chart; any prose sits on top of facts the code already produced. The sample natal page even says buyers get the template text when no writing model is used.
Cross-check libraries are oracles, not dependencies. Shipping tyme4ts (or any single library) as "the" engine would hide which conventions you chose. Generating a solar-term table with Astronomy Engine and owning the rest of the rules made verification reports possible.
Compatibility without a score is a feature. People arrive from zodiac-compatibility habits; saying what we don't compute (year animals, match %) sets better expectations than a fake 87%.
One Day Master page as a pilot beats ten thin stubs. Jia Wood is live; the other nine stems reuse the same outline once the depth and citation style are locked.
Same funnel shape, different surface. Free calculator → sample PDF → one-time report is a proven indie pattern. The differentiation is auditability and content thickness, not a novel checkout flow.

If you want to see the receipt on a real birth (yours or a fictional one), try the free chart on PillarChart. No account for the calculator. After you sign in with Google, you can buy a one-time PDF report from the result page or pricing. If you read Chinese metaphysics content for fun, I'd especially like feedback on where the methodology page is still unclear, or which Day Master page you'd want next after Jia Wood.

Questions about the OpenNext/Workers setup, the solar-term table pipeline or the report chapter structure are welcome in the comments.

BaZi is a traditional Chinese cultural practice. PillarChart / BaZi Chart is for reflection, education and entertainment — not medical, legal, financial or psychological advice. Different schools may read the same chart differently.

Build log: turning photos into printable coloring pages with Seedream on Cloudflare Workers

王龙 — Sun, 04 Oct 2026 17:53:11 +0000

I've been building CrayonInk, a small web app that turns a photo into a black-and-white coloring page you can print at home. Upload a picture of your dog, your grandparents, a wedding photo, and get back a page with clean, closed outlines that's ready for crayons.

The idea isn't new. This post is about the engineering: the pipeline, a model comparison with per-call billing data, the prompt changes that mattered, and the cost guardrails I added before letting strangers spend my inference budget.

The stack

All of it runs on Cloudflare:

Next.js 16 deployed to Workers via @opennextjs/cloudflare
D1 for jobs, accounts, credits and a spend ledger
R2 for source photos and finished pages
Queues for generation jobs (max_batch_size = 1, max_retries = 3)
A cron trigger every 15 minutes that recovers stuck jobs (and refunds the user's page), deletes source photos older than 24h, and clears out expired results and PDFs
Cloudflare Email Service for operator alerts

The AI step is a single image-edit call to fal, using fal-ai/bytedance/seedream/v5/lite/edit. One more mode, "outline", skips AI entirely: it's Canny edge detection running inside the Worker. It's instant and costs nothing, but the lines are rougher and often don't close.

How a photo becomes a page

In the browser: the photo is downscaled to at most 2048px on the long edge, re-encoded as JPEG (quality 0.9), and its EXIF data is stripped. Nothing is uploaded until the user clicks Generate.
Submit: the API checks the user's credits, creates a job in D1 and drops a message on the queue.
Queue consumer: builds the prompt from the selected detail level and style and calls Seedream. The photo goes inline as a data URI.
Post-processing: the model's output gets converted to grayscale, thresholded to a 1-bit PNG at 300 DPI, and padded so the page keeps the photo's aspect ratio. The pages are pure black and white, with no gray anti-aliasing to muddy a home print.
Delivery: PNG, or a single-page PDF in A4 or US Letter. Several pages can also be assembled into a coloring book PDF with a cover.

Post-processing is what turns "a drawing" into "something that prints cleanly," so every model in the comparison below went through this exact step.

Two bugs my first smoke test caught

Early on I ran 8 jobs through the live API (6 test images, all AI-generated with FLUX schnell, including the two children, so no real kids' photos). All 8 succeeded, nothing was blocked, and AI pages averaged 46.6 s end to end. Two problems mattered more than speed.

1. The model recomposed my photos into squares. Without image_size, Seedream returned a square. It didn't stretch a 4:3 photo; it re-framed it, and on one dog photo it invented a porch above the dog. For a product that promises "your photo," that's a bug.

The fix: compute an output size that matches the input's aspect ratio. This is the version from the commit that fixed it (the current code adds an optional long-edge target for larger paid sizes):

/** Seedream 5 Lite accepts 2560×1440 … 4096×4096 total pixels. */
const SEEDREAM_MIN_PIXELS = 2560 * 1440;
const SEEDREAM_MAX_PIXELS = 4096 * 4096;
const SEEDREAM_TARGET_PIXELS = 2048 * 2048;
const MAX_ASPECT = 3;

export function falImageSize(width: number, height: number): FalImageSize | null {
  if (!(width > 0 && height > 0)) return null;
  const aspect = Math.min(MAX_ASPECT, Math.max(1 / MAX_ASPECT, width / height));
  const round16 = (v: number) => Math.max(16, Math.round(v / 16) * 16);
  let w = round16(Math.sqrt(SEEDREAM_TARGET_PIXELS * aspect));
  let h = round16(Math.sqrt(SEEDREAM_TARGET_PIXELS / aspect));
  while (w * h < SEEDREAM_MIN_PIXELS) { w += 16; h = round16(w / aspect); }
  while (w * h > SEEDREAM_MAX_PIXELS) { w -= 16; h = round16(w / aspect); }
  return { width: w, height: h };
}

2. sync_mode doesn't do what my code comment said. I'd written that sync_mode "keeps the output out of fal's request history." It doesn't; it only returns the output inline instead of as a CDN URL. Querying the request history, I could pull back the full input payload, base64 photo included, for 5 of 7 requests. That matters when parents upload photos of their kids.

What I do now:

export const FAL_RETENTION_HEADERS: Record<string, string> = {
  "X-Fal-Store-IO": "0",
  "X-Fal-Object-Lifecycle-Preference": JSON.stringify({ expiration_duration_seconds: 3600 }),
};

About 90 seconds after each request, a queue message checks fal's request history for it. If anything was kept, it tries to delete the payload, and it records the outcome on the job (not_stored / deleted / stored / pending / error). Caveat: deleting payloads needs an admin API key. The privacy page names fal and what it receives, and I deliberately don't promise "we never train on your photos," because that's not my policy to make.

The model bake-off: Seedream vs Nano Banana 2 vs GPT Image 2.5

Then I checked whether I'd picked the right model, using the exact production prompt and parameters and the production post-processing, all via fal.

Setup: 8 photos from Wikimedia Commons (2 adults, 2 multi-person family photos, 2 children, 2 pets) × 2 detail levels (Standard and Detailed) × 4 model configs = 64 calls, run 8 at a time. Total spend: $3.37.

	Seedream 5.0 Lite edit (production)	Nano Banana 2 edit (1K)	GPT Image 2.5 Flare (medium)	GPT Image 2.5 Sunburst (high)
Cost per page*	$0.0350	$0.0800	$0.0266	$0.0689
End-to-end time, median (max)	61.7 s (127.5 s)	13.1 s (44.1 s)	21.8 s (42.4 s)	41.7 s (56.5 s)
Child photos blocked	0 of 4	0 of 4	0 of 4	0 of 4
Likeness, 1–5 (subjective)	3.6	2.9	3.4	3.9
Printability, 1–5 (Standard / Detailed)	4.5 / 4	4 / 3.5	4 / 3	3.5 / 3
Main problem	Slowest; children's eyes often left blank	Least like the person; invents things (added trees to a cat photo)	Cartoonish, pupils filled solid black	Ignores framing, often deletes the background; heavy hatching

*Cost is fal's per-request x-fal-billable-units response header × unit price. My API key couldn't read the billing endpoints (they need an admin key), so these numbers aren't reconciled against an invoice. The GPT configs came out above fal's listed 1024px prices because auto size produced roughly 2048px outputs and my prompt is long.

A few notes on reading that table honestly:

"Likeness" isn't a face-recognition metric. It's a 1–5 score from eyeballing side-by-side face crops (every image at Standard, three spot-checked at Detailed). With 8 photos, it's a hint, not a benchmark.
"Blocked" means the model refused or returned an error. No model refused any of the 4 child-photo calls (or the 4 family-photo calls with kids), and Seedream never returned an NSFW flag. Don't expect the model's safety filter to set your policy on kids' photos; your product has to.
The printability gap is mostly ink density. After post-processing, all four outputs are pure black and white. The difference is how much black: on GPT's Standard pages heavy strokes and solid black take about 10–14% of the page, versus about 3% for Seedream and about 1% for Nano Banana 2.
Speeds were measured with 8 requests in flight, so they're comparative, not single-request latency.

What I decided: Seedream stays the default. Among the cheap options it holds the frame best (no cropping, deleting or inventing), and its Standard pages are the cleanest to color. The price is speed: roughly a minute per page, so I don't promise "seconds." GPT Image 2.5 Flare is the challenger: about 24% cheaper and roughly 3× faster, but more cartoonish, so it's my next A/B candidate on a small slice of real traffic. Sunburst had the best likeness but costs about twice as much and drops backgrounds, so it only fits a premium "refine" option. Nano Banana 2 costs 2.3× as much and scored lowest on likeness.

Prompt tuning: what actually changed

The prompt is assembled from parts: a base instruction, a detail-level line, and a block of shared rules. Three changes made a real difference.

1. Forbid recomposing, explicitly. The image_size fix handled the canvas shape, but the model still liked to "improve" the shot. The shared rules went from "Keep the same composition and pose" to:

Trace the photo exactly as framed: keep the same composition, camera angle, subject position, scale and pose, and the same aspect ratio. Do not crop, zoom, extend the scene, add new elements or recompose. Keep faces and key features recognizable and faithful to the photo.

Post-processing had the same bug in miniature: it used to crop to the ink's bounding box, which also changed the aspect ratio. Now it pads each side proportionally instead.

2. Say what a coloring page isn't. Image models love shading, so the shared rules spell out the negatives: "Black lines only: no shading, no gray tones, no color, no hatching, no gradients, no text, no watermark, no frame or border." The thresholding step would turn gray shading into black blobs anyway, so it's better if the model never draws it.

3. A preset for detail-heavy photos. For things like wedding photos, "Bold & detailed" asks for "the same thick, even, confident black stroke, like a thick felt-tip marker," with "facial features … drawn cleanly and recognizably with the eyes left open and not filled in" and "lace, embroidery and beading as simplified open motifs." Post-processing then thins the lines to a centerline and redraws them with a round pen: 9px in open areas, down to 5px in dense ones like hair and lace. It's still one Seedream call per page.

Eyes are still a weak spot: in the bake-off, Seedream left the eyes blank on one child photo at both detail levels. I haven't changed the default preset for that yet; it's next, as its own small experiment.

Abuse prevention and cost control

At $0.035 per page, an anonymous free tier is an invitation to drain my fal balance. Here's what's in place:

AI pages need Google sign-in. Signed-out visitors can browse examples and use the zero-cost outline tool. Clicking Generate opens a sign-in modal.
A one-time signup grant, not a monthly allowance. New accounts get a small number of free pages once, and it never resets. The grant is idempotent per user, and the same IP (or IPv6 /64) or the same normalized account name can claim at most 2 grants in 24 hours.
One active AI job per account, enforced atomically when the job is created, so two tabs can't race each other.
A USD circuit breaker on the backend. Every AI page is charged to a D1 ledger at a configured cost per page at the moment it's submitted to the provider, and the charge is never reversed, even if the job fails, gets blocked or is deleted. Grant-funded pages have their own daily budget. When it's hit, new grants pause and never-paid accounts can't start AI pages until 00:00 UTC, while paying users carry on. An optional overall breaker can stop everything. Alert emails go out at 80% and 100%.

// Pure admission rule: paid users ignore the grant breaker; the overall breaker blocks everyone.
export function admissionAllowed(state: BreakerState, userHasPaid: boolean): boolean {
  if (state.overallTripped) return false;
  if (state.grantTripped && !userHasPaid) return false;
  return true;
}

Charging on submission and never refunding the ledger is the key choice: the provider bills you either way, so the breaker counts the same way. (Users still get their page credit back on failure; that's a separate counter.)

A private-beta switch. GENERATION_ALLOWLIST is a comma-separated list of Google emails. When it's set, only those accounts can generate, receive the signup grant or open checkout, and everyone else sees a "coming soon" panel. I ran with just my own account for a while, then cleared the list to open sign-ups.
Turnstile is on in production (Managed mode, server-side verification and a 30-minute pass cookie). Most people never see a challenge; scripted requests without a valid token get a 403 before any model call.

Lessons and trade-offs

Smoke-test the live API before tuning anything. Eight requests found a framing bug and a privacy bug.
Read your provider's retention docs, not your own comments. The comment was confidently wrong.
Compare models on post-processed output. Users print the thresholded page, not the raw generation.
Label where cost numbers come from. Without an admin key I can't reconcile against an invoice, so I say whether a number is list price or billable units.
Slow is a real trade-off. I'm accepting about a minute per page for better framing and cleaner lines.
Small samples are small. 8 photos, 64 calls and one person's eyeball scores. Good enough to rule out a 2.3× more expensive model, not good enough to declare a winner between two close ones.

If you want to see what it does with one of your photos, try CrayonInk. Sign in with Google and your new account gets a one-time batch of free pages to test with. The outline tool works without signing in. I'd love feedback on where it fails: hair, glasses, busy backgrounds, whatever breaks it.

Questions about the Workers/OpenNext setup, the queue design or the breaker are welcome in the comments.

Comparison photos: adult portraits by Anthony Ginsbrook and Leroy Skalstad, Labrador by Dktue (all CC0, via Wikimedia Commons); cat by Anil Öztas, CC BY-SA 4.0, via Wikimedia Commons. The derived comparison grid is shared under CC BY-SA 4.0.

I shipped a birthday keepsake that sings their name — not another Happy Birthday name-swapper

王龙 — Fri, 04 Sep 2026 20:24:35 +0000

Most “personalized birthday song” tools still feel like stuffing a name into Happy Birthday. I wanted a keepsake: their name in the chorus, your real memories in the verses, and a page they can open — not just an MP3 dump.

So I shipped NameVerse.

NameVerse homepage. Official product screenshot. Source: nameverse.app.

You write who it is for, add a few inside stories, pick a style, and get a Free 60s Preview (Take A) before you unlock. Unlocking is one-time: $19.99 for one song (WAV + gift envelope) or $49 for three ($16.33 each). No subscription — the live site says it does not believe in recurring subscriptions for personal gifts. Checked on pricing, 5 September 2026.

Pricing. Official product screenshot. Source: nameverse.app/pricing.

What you actually unlock

Paying unlocks the full master, an alternate take, and an interactive gift page the recipient opens. There is a public sample so you can see the unboxing without buying:

Sample gift for Elena — marked Sample. Demo from Jamie to Elena (wife).

Sample gift page (/g/sample-elena). Official product screenshot. Source: nameverse.app/g/sample-elena.

The site also states a Birthday Promise: one free quality re-record if pronunciation or a memory needs tuning.

The searches that became pages

Each of these is a question page first, then a CTA — not a cloned “AI song generator” homepage fighting MusicSmith and App Store results.

Question page: will it actually sing their name? Official product screenshot. Source: nameverse.app/birthday-song-with-name.

Question page for wife gifts. Official product screenshot. Source: nameverse.app/birthday-song-for-wife.

What it is not

Copied from the site’s own framing: not a novelty robot track, and “we do not make disposable AI novelty sounds.” Preview first, pay once, send a gift page. If the singer misses a rare name, pick the other take or respell how it sounds — the gift page keeps the real spelling.

Live tool: https://nameverse.app/

I shipped a transparent-video exporter because “remove background” usually just means a black fill

王龙 — Mon, 24 Aug 2026 19:17:53 +0000

I kept hitting the same search after “AI remove video background”: why is the result a black rectangle? Does MP4 even carry transparency? Why is the WebM fine in Chrome and black in Safari? How do I drop this into OBS without chroma-keying a green screen that was never there?

The answer is usually not “the model failed.” Everyday H.264 MP4 does not carry an alpha channel. A lot of players composite transparent pixels onto black. Safari ignores WebM alpha. So I shipped ExportAlpha — a small exporter that writes a real alpha channel: transparent WebM (VP9, yuva420p) for Chrome, Firefox, and OBS, or ProRes 4444 MOV for Premiere, Resolve, and Final Cut.

ExportAlpha homepage. Official product screenshot. Source: exportalpha.com.

Fifteen free seconds on first Google sign-in. No card required to try a short clip. Upload is MP4 / MOV / WebM / M4V, up to 60 seconds, 1080p, 200MB. It is a file workflow, not a live-stream plugin.

What I refused to invent

The site has a public Sources & Method page. Retrieval dates are 19 August 2026. A few gaps stay labeled instead of being filled in:

HEVC-with-alpha for Safari is the correct destination format on paper (WWDC 2019 Session 506). We have not verified Safari transparency on our own exports. The sources page marks that feature experimental.
CapCut / iMovie / DaVinci Resolve importing WebM-with-alpha: public docs contradict each other. The format guide says test your version; if WebM fails, use ProRes 4444.
HEVC inside OBS on Windows/Linux depends on system codecs. The OBS guide recommends VP9 WebM as the cross-platform overlay.

I also do not claim this is real-time webcam matting. The OBS page says it in plain language: no virtual camera, no live filter, no stream plugin. You upload a clip, download a file, then add a Media Source.

The model stack is listed on that same sources page: fal.ai calling Bria VRMBG 3.0. RVM is cited only as a paper on temporal consistency, not as the production model.

The searches that became pages

Each URL is a question people already type. The page answers it, then links the dated source.

Why does my transparent video have a black background? — alpha was never written, or the player composites onto black. Check ffprobe for yuva420p / yuva444p10le / rgba, or drop the file over a colored plate in an NLE.
Does MP4 support a transparent background? — everyday H.264 does not. Do not export H.264 if you need transparency.
Which transparent video format should I export? — WebM for Chrome/Firefox/OBS; HEVC-with-alpha for Safari (we have not verified our own HEVC); ProRes 4444 for editors; already-composited H.264 only as a finished deliverable.
Why is my transparent WebM black in Safari? — Safari ignores WebM alpha. Chrome and Firefox composite it.
How do I make a WebM video with a transparent background? — VP9 with yuva420p, or FFmpeg if you already have alpha.
Can I use a transparent video overlay in OBS? — Media Source + local WebM, or Browser Source for a hosted page. Do not add a Chroma Key filter if the file already has alpha.
Why does AI video background removal flicker? — frame-by-frame masks drift; a temporal video model keeps edges stable.
What is a video alpha channel? — the fourth channel. Without it, “transparent” regions become black.

Homepage examples: hair, hand overlay, home-office talking head, product. Official product screenshot. Source: exportalpha.com.

Guide: black background is usually format or playback, not a failed job. Official product screenshot. Source: exportalpha.com/guides/why-transparent-video-has-black-background.

Decision table: WebM vs HEVC vs ProRes vs composited MP4. Official product screenshot. Source: exportalpha.com/guides/what-transparent-video-format.

OBS: Media Source + VP9 WebM. Not a live camera plugin. Official product screenshot. Source: exportalpha.com/guides/how-to-use-transparent-video-in-obs.

Pricing as it sits on the page today

Credits: 1 credit = 1 started second. New accounts get 15 seconds. Plan credits reset monthly; pack credits never expire. Failed jobs refund credits. Successful exports do not. Checked on the live homepage, 25 August 2026.

Monthly: Creator $19 (1,200 seconds), Pro $39 (3,000 seconds), Studio $79 (7,200 seconds). Annual is shown as $15.83 / $32.50 / $65.83 per month ($190 / $390 / $790 billed once). One-time packs: Quick $5.99 / 240s, Starter $9.99 / 480s, Plus $29.99 / 1,800s.

Homepage pricing. Official product screenshot. Source: exportalpha.com/#pricing.

What it will not do

Copied from the site’s own “We can’t” list: restore quality lost to heavy compression, act as a real-time live-stream plugin, bypass content safety, or process clips longer than 60 seconds. Adult content, minors, and non-consensual use are blocked. Results are kept 7 days, then deleted.

If you are exporting a stream alert, a lower-third, or a talking-head overlay and you keep getting a black plate: the file probably never had alpha, or the player is lying to you. Export WebM or ProRes 4444, then test over a colored background.

Live tool: https://exportalpha.com/

I shipped a sourced question hub for Mortal Shell II instead of another cloned wiki

王龙 — Sat, 22 Aug 2026 19:50:25 +0000

Mortal Shell II released worldwide on 20 August 2026. The searches I kept seeing were not "give me a weapons dump." They were when did it release, what are the PC specs, which edition has Advanced Access, how many Shells are there, and which weapon names are actually official.

Official answers exist, but they are split across the Steam store, Playstack notes, mortalshell.com, and Steam achievement unlock titles. A cloned wiki that invents the missing numbers would rank for a week and then rot.

So I shipped mortalshellii.info as an independent question hub: one search question per page, official source URL next to every changing fact, gaps left visible.

mortalshellii.info homepage. Independent question hub. Not affiliated with Cold Symmetry or Playstack.

What I refused to invent

Steam App 2584270 lists minimum PC requirements only (as of the hub's 22 August 2026 check): Windows 10/11, Intel i7-10700K or AMD Ryzen 5 3600, 16 GB RAM, RTX 2060 SUPER or RX 6600, 70 GB SSD required. No recommended tier is published. The specs page does not invent one.

Steam achievements officially name 7 melee weapons and 6 sidearms via individual "Unlock [weapon name]" achievements, plus "Lord of War" and "Guns. Lots of Guns." Community guides commonly list 8+8, including three names (The Iconoclast, Naylshotte, Troubadour's Lute) that are not in Steam achievement unlock titles. The weapons page keeps those labeled Community / Pending instead of merging them into an invented official list.

Total weapon/sidearm counts stay pending. "Unlock all Weapons" and "Unlock all Sidearms" confirm the sets exist; they do not publish the totals.

Acquisition routes and region labels from community guides stay Pending. The page does not turn GameRant routes into first-party map pins.

The pages that match the search

Each URL is a question a launch-week player actually types:

When did Mortal Shell II release? — Worldwide 20 August 2026 on Steam, PlayStation 5, and Xbox Series X|S (10:00 AM PDT / 17:00 UTC per the hub's timezone table). Devout Edition Advanced Access started approximately 17 August 2026 (up to 3 days early). Sourced to Playstack and Steam.
What are the system requirements? — Steam minimum only; no recommended tier invented.
What editions are available? — Standard $49.99 / €49.99 / £39.99; Devout $59.99 / €59.99 / £47.99 (Advanced Access + 8 Obsidian Shell skins). Physical PS5 Revered Edition noted as sold-out in most territories, matching official site copy.
Weapons & sidearms — Steam achievement names first; community names labeled; totals pending.
Guides hub — combat, Shells, bosses, progression, 53 Steam achievements, difficulty options — strategy tips labeled unofficial; factual claims tied to Steam / Playstack / mortalshell.com.
Quick facts on the homepage also call out eight Shells, stamina-unrestricted combat, a compact interconnected open world, and 60+ dungeons — language that tracks Steam / official marketing rather than fan wiki inventiveness.

Steam English user reviews, as listed on the store page when this draft was prepared, read Very Positive (83% of 3,195). That number lives on Steam. I do not treat it as a Metascore substitute.

Why this is a website and not a Notion dump

Searchers land on a question. The page has to answer that question, cite the dated official note, and say what is still unknown. That is why the homepage is a question hub, not a franchise cover.

Weapons page: Steam achievement names vs Community/Pending labels. Gaps left visible.

I did not invent recommended PC specs, a closed weapon count, or step-by-step dungeon unlock maps that Cold Symmetry and Playstack have not published as official lists.

The site is not affiliated with Cold Symmetry or Playstack. Corrections get a source and a same-day edit.

If you are building a launch-week game hub: start from the search question, keep official text dated, and leave the gaps visible. The empty cell is more honest than a confident guess.

Live hub: https://mortalshellii.info/

I pinned Palworld 1.0 breeding data in the browser so the pair table is not a live API

王龙 — Wed, 19 Aug 2026 18:46:47 +0000

The useful Palworld breeding sites already own the obvious search queries. I did not build Palbreed to outrank them.

I built it because I wanted a local-first 1.0 calculator: a pinned pair table, three tools that read the same snapshot, and no live breeding API in the critical path.

The site is Palbreed. Unofficial. Not affiliated with Pocketpair. Palworld and related assets belong to their rights holders.

What "local-first" means here

Palbreed is a Next.js app. After the page loads, the solver reads a bundled snapshot from /data/palworld-1.0.json (cache: "force-cache"). The client refuses to boot the graph unless all three checks pass:

meta.palcalcRelease === "v1.17.6"
pals.length === 299
breeding.length === 44851

The snapshot is labeled PalCalc database v26 on Palworld 1.0. The loading copy on the site is blunt: the local graph and portraits are prepared in the browser, and no network data source is required for that graph.

That is the product claim I am making. The pair table is not fetched from a wiki, a scrape, or a third-party breeding endpoint at query time. If a later patch moves a recipe, the badges have to move with the file. Until then, the calculator, reverse search, and path solver all read the same pin.

Roster, settings, and saved plans stay in localStorage. There is no account and no application database for that state.

If you want a specific child, parent pair, or route, open the tool. I am not going to paste a combo table into this post. Hand-filled lists go stale the moment the snapshot changes.

Tool 1: two parents, one child

Page: https://palbreeding.org/calculator

The homepage 308s to /calculator. The screen is a direct pair tool:

Choose two parents. Reveal their child.

It uses the verified 1.0 snapshot, including fixed combinations and gender-specific results. "Why this result?" on the child card says the answer is read from the bundled PalCalc 1.0 breeding table, which already applies fixed recipes, gender rules, exclusions, power ranking, and tie-breaking.

I am not listing example pairs here. If you care about a specific outcome, go check the calculator.

Tool 2: start from the child

Page: https://palbreeding.org/reverse

Reverse Search flips the question. Pick a target Pal, then read every direct parent pair in the bundled snapshot.

The page copy is: it shows direct Palworld 1.0 parent pairs from that snapshot. Filters on the live screen include owned pairs first, gender-specific recipes only, and both parents owned.

Again: no handwritten list in this post. The ranking belongs on /reverse, next to the same version badges.

Tool 3: a route from what you already have

Page: https://palbreeding.org/paths

Path Solver is the multigeneration view. It expands only from Pals marked owned in My Pals, and falls back to the smallest direct capture set when needed.

The route graph comes from the bundled 1.0 pair table. Egg counts on that screen are planning estimates, not simulated probabilities. The disclaimer page says the same thing: generation counts come from the graph; egg and time labels are estimates; later patches, mods, or extraction errors can disagree with the snapshot.

Save a route as a plan if you want. Plans stay on the device.

What I refused to ship in this post

A combo dump. A "best Anubis line" list. A promise that Palbreed will rank for Palworld breeding calculator.

Those SERP slots are already held by large databases. This post is a build note and a link to a pinned tool, not a content-site play.

The Data Status screen on the site also records a boundary I kept: 299 PalCalc breeding entities drive the solver. One extra Paldeck-only boss entry is bundled for roster completeness and never enters breeding results.

If a number in this post disagrees with the live badges, trust the badges and the calculator.

Try it

Calculator: https://palbreeding.org/calculator
Reverse Search: https://palbreeding.org/reverse
Path Solver: https://palbreeding.org/paths

Unofficial fan tool. Check the result in-game before you spend Cake.

I shipped a sourced question hub for The Sinking City 2 instead of another cloned wiki

王龙 — Wed, 19 Aug 2026 10:14:31 +0000

The Sinking City 2 launched on 18 August 2026. The searches I kept seeing were not "give me a weapons dump." They were when does it release, what are the PC specs, which edition has Holloway Manor, is there a demo, and do I need the first game.

Official answers exist, but they are split across the Steam store, dated community announcements, and Frogwares press notes. A cloned wiki that invents the missing numbers would rank for a week and then rot.

So I shipped thesinkingcity2.net as an independent question hub: one search question per page, official source URL next to every changing fact, gaps left visible.

thesinkingcity2.net homepage. Independent question hub. Not affiliated with Frogwares.

What I refused to invent

Steam App 2825860 lists single-player only. I do not quote "no crossplay" as an official line. Frogwares has not published a crossplay feature, so the page says that.

Frogwares has not said whether you need The Sinking City 1. The FAQ does not invent a "must play" or "skip it" answer.

Steam Recommended names a Medium preset. The 10 July 2026 press copy says Balanced. The specs page shows both and dates them. I do not pick a winner.

Playtime is not a first-party number. Official channels do not publish campaign length. If a reviews page cites named outlets, it is labeled as reception, not as Frogwares copy.

Mac, Linux, and Switch are not listed on the current Steam and press pages. That is not the same as "confirmed never."

The pages that match the search

Each URL is a question a launch-week player actually types:

When does it release? — 18 August 2026 on PC, PlayStation 5, and Xbox Series X|S. Delay history only as Frogwares announced it. Physical copies: no official announcement.
What are the system requirements? — Steam min/rec, including 16 GB RAM, GTX 1070 / RX 5700, 70 GB SSD.
Which editions? — Standard $49.99, Deluxe $54.99, Premium $59.99 on Steam, plus the named DLC and the Chthonic Arsenal pre-order items as edition deltas, not a weapons table.
Is there a demo? — a Next Fest demo shipped in June. After launch I point at the live Steam page instead of declaring it forever available.
Official news — Frogwares Steam announcements only, dated.
FAQ and sources — the editorial rules are public.

Steam current user reviews, as of 19 August 2026, read Very Positive (92% of 339). That number lives on Steam. I do not treat it as a Metascore substitute.

Why this is a website and not a Notion dump

Searchers land on a question. The page has to answer that question, cite the dated official note, and say what is still unknown. That is why the homepage is a question hub, not a franchise cover.

Release-date page: August 18, 2026, sourced to Steam. Mac/Linux/Switch left as “not listed.”

I did not add a weapons wiki, a maps directory, or a settings optimizer. Those pages would need numbers Frogwares has not published.

The site is not affiliated with Frogwares. Contact is support@thesinkingcity2.net. Corrections get a source and a same-day edit.

If you are building a launch-week game hub: start from the search question, keep official text dated, and leave the gaps visible. The empty cell is more honest than a confident guess.

I built a source-attributed hub for Hell Let Loose: Vietnam instead of another cloned wiki

王龙 — Tue, 18 Aug 2026 08:24:34 +0000

Hell Let Loose: Vietnam launched on 13 August 2026. In the first week, the searches I kept seeing were not "give me a weapon dump." They were how do I join a server, why did my AMD GPU crash, why does proximity chat sound robotic, and is Hotfix 1 actually out.

Official Steam screenshot. Team17 / Expression Games.

Official answers exist, but they are split across Steam announcements, a living Team17 comms thread, and a performance blog. A cloned wiki that invents the missing numbers would rank for a week and then rot.

So I shipped Hell Let Loose Vietnam as an independent hub: official news in, dated claims, gameplay pages separated from troubleshooting.

What I refused to invent

Steam App 3079210 lists 17 roles. The marketing page says 19 specialised roles. The site keeps the explicit 17-role directory and flags the mismatch instead of filling two mystery slots.

First-party material names six launch maps. Only four modes currently have detailed published rules (Warfare, Offensive, Conquest, Domination). Undocumented mode names stay off the page.

Steam current-player counts are Steam only. They are never treated as a cross-platform population.

Vietnam PC requirements come from that same Steam app, not the franchise site page that still looks like the original Hell Let Loose.

Official Steam screenshot. The site does not invent undocumented weapon stats to match a pretty picture.

Launch issues get their own library

Gameplay stays on maps, roles, vehicles and guides. Launch defects live under Fixes & Troubleshooting, each with a status label: acknowledged, monitoring, still investigating, or confirmed in Hotfix 1.

Hotfix 1 went live on 16 August. The pages I keep pointing people to:

Cannot join a server / incorrect VIP message — browser listings went stale at launch; Hotfix 1 refreshes more often and hides full servers by default
AMD GPU crashes — official DX11 / DX12 launch-option sets, plus "do not combine them"
Robotic proximity voice — still investigating; I do not pretend a community toggle is a fix
PS5 audio cutting out — named dropout is marked fixed in Hotfix 1; later cut-outs are a new report
Hotfix 1 notes, player-facing

If a workaround is official and temporary, the page says so. If a number is not in a first-party source, it is not on the page.

Why this is a website and not a Notion dump

Searchers land on a question. The page has to answer that question, cite the dated official note, and tell them what is still unknown. That is why role selection, US vs NVA, and map selection are decision guides, not lore essays.

Official Steam screenshot. Role pages stay on documented responsibilities, not cinematic loadouts.

The full editorial rules are public: editorial policy and sources & corrections. Contact is support@hellletloosevietnam.org. The site is not affiliated with Team17 or Expression Games.

If you are building a launch-week game hub: start from the search question, keep official text dated, and leave the gaps visible. The empty cell is more honest than a confident guess.

I Built an AI Tool to Reconstruct Matcha-Filtered Images—Here’s What I Learned

王龙 — Thu, 13 Aug 2026 10:50:37 +0000

A heavily stylized “matcha” filter can do more than shift colors toward green. It can flatten skin tones, posterize shadows, exaggerate edges, replace texture, and destroy small details.

That creates an interesting product question:

Can generative AI turn the remaining visual structure into a natural-looking image again?

I recently built Matcha Filter Remover, a small AI tool that explores exactly that problem. This post is a practical breakdown of what worked, what did not, and the engineering decisions that mattered most.

First: reconstruction is not recovery

This was the most important product decision.

When a destructive filter overwrites pixels, those original pixels are gone. No model can reliably recover the exact source photo from information that no longer exists.

The tool therefore does AI reconstruction, not original-photo recovery.

That distinction appears throughout the product:

The output is described as a new AI-generated interpretation.
Exact identity, text, logos, hands, jewelry, and background details are not guaranteed.
The before/after interface keeps the filtered input visible.
The product never claims forensic restoration or access to hidden content.

This is not only safer wording. It also sets an honest user expectation for a probabilistic system.

The model comparison surprised me

I tested multiple image-editing models with different kinds of matcha-filtered inputs.

The first test image was a portrait with a strong yellow-green embossed effect. The second was a tiny, low-resolution café scene with severe edge enhancement and very little reliable color information.

Two models stood out:

Seedream 5 Pro produced cleaner color reconstruction and stronger overall photographic coherence.
Nano Banana Pro was useful as a fallback, especially when preserving composition, but sometimes left more of the original green cast in the image.

For this specific task, Seedream became the primary model and Nano Banana the fallback.

The key lesson was that “best image model” is too broad a question. A model can be excellent at creative editing but weak at removing a particular destructive visual style. The evaluation set has to resemble the actual user input.

I also stopped relying on an aggressive pre-classification step. In practice, matcha-filter detection produced too many uncertain or incorrect decisions. A false negative is especially frustrating because the user already knows why they uploaded the image.

The current workflow instead uses a fixed, conservative reconstruction prompt and lets the image editor handle the full scene.

Prompt design: constrain the invention

A useful prompt for this workflow needs two opposing properties:

Remove the strong artificial filter.
Avoid redesigning the entire image.

The prompt emphasizes:

natural photographic color and lighting;
preservation of pose, framing, subject placement, and scene structure;
removal of olive/yellow-green tint, embossed edges, posterization, and false texture;
realistic skin, fabric, objects, and background;
no beautification, identity substitution, or unrelated additions;
no claim that the result is the original photo.

This does not eliminate hallucination, but it gives the model a much narrower job than “make this look good.”

The production architecture

The app is built with:

Next.js 16 and React 19 for the application;
Cloudflare Workers for the runtime;
Cloudflare D1 for users, credits, jobs, and payment records;
Cloudflare R2 for temporary uploads and generated results;
Cloudflare Queues for asynchronous reconstruction jobs;
fal.ai for image-generation models;
Google OAuth for account access;
Stripe Checkout for one-time credit purchases.

A simplified request flow looks like this:

Browser upload
  -> authenticated API route
  -> temporary R2 object
  -> D1 job + credit reservation
  -> Cloudflare Queue
  -> primary image model
  -> output safety check
  -> temporary R2 result
  -> authenticated result page

Uploads and results are scheduled for deletion within 24 hours. The credit balance itself does not expire.

Payments were more than adding a button

Stripe Checkout made card collection straightforward, but reliable fulfillment still required server-side work.

The live payment flow validates:

the Checkout Session belongs to the signed-in user;
the session is in live mode;
payment status is paid;
currency and amount match the selected pack;
the returned Stripe Price ID matches the server configuration.

Credits are granted through an idempotent ledger entry. If Stripe retries the webhook—or the success page and webhook both request fulfillment—the same Checkout Session cannot grant credits twice.

The site sells one-time packs rather than subscriptions:

8 credits for $4.99
20 credits for $9.99
45 credits for $19.99

Purchased credits remain available until used.

Safety boundaries belong in the architecture

An image reconstruction tool can be misunderstood if its limits are vague.

The product explicitly prohibits:

explicit content;
content involving minors;
non-consensual imagery;
clothing removal or “see-through” behavior;
private-content reveal claims;
attempts to bypass safety controls.

Generated results pass an output safety check before being retained and displayed. A blocked or failed job returns the reserved reconstruction credit through an idempotent refund entry.

The UI also requires the user to confirm that they are 18+ and own the image or have permission to use it.

These decisions are not a policy-page afterthought. They affect job state, storage, credit accounting, result delivery, and copy across the entire product.

What I would do differently

1. Build the evaluation set first

I initially spent too much time tuning around individual examples. A small benchmark containing portraits, objects, indoor scenes, tiny images, text-heavy images, and multiple filter strengths would have made model selection faster.

2. Treat copy as part of system design

Phrases such as “remove,” “restore,” and “recover” can imply very different capabilities. The final product repeatedly uses “AI reconstruction” because the system generates plausible pixels rather than retrieves missing ones.

3. Test mobile checkout early

One responsive CSS rule accidentally hid all purchase buttons on mobile. Desktop tests passed; mobile end-to-end tests caught it before launch.

4. Make every credit mutation idempotent

Generation failures, safety blocks, webhook retries, and payment redirects can all repeat. A ledger with unique idempotency keys is much safer than directly incrementing and decrementing a balance in scattered code paths.

5. Keep temporary media and permanent entitlements separate

Images expire after 24 hours for privacy. Purchased credits do not expire. Mixing those concepts would create confusing product behavior and complicated data retention rules.

The result

The project is now live at matchafilterremover.online.

It is still an experiment in a narrow visual problem, and the output will not be perfect. But that constraint is exactly what made the build interesting: model quality, honest product language, privacy, safety, async processing, and payment integrity all had to work together.

If you are building a small AI image product, my biggest recommendation is simple:

Evaluate on the real failure cases, and design the product around what the model cannot know.

I would love to hear how other developers evaluate image-editing models or design reliable credit-based AI workflows.

I Built a Privacy-First QR Code Generator for Print-Ready Batch Workflows

王龙 — Tue, 30 Jun 2026 16:29:07 +0000

I recently built QRForge, a QR code generator focused less on tracking dashboards and more on print-ready workflows.

Most QR tools I found fell into two buckets: simple one-off generators, or dynamic QR platforms that route scans through their own tracking URLs. I wanted something more boring but useful: direct static QR codes, CSV batch generation, clear previews, and export files that are ready for labels, badges, packaging, or menus.

What I built

QRForge currently supports:

Static URL QR generation without signup
CSV upload for batch QR projects
First-row previews before export
Named PNG and SVG outputs
Manifest and error report files
PDF project summary
ZIP delivery for print workflows

The main idea is that a user should know what they are about to print before they generate hundreds of QR codes.

Why static QR codes?

Dynamic QR codes are useful, but they also introduce a dependency: the QR provider has to keep redirecting scans forever.

For printed materials, that tradeoff matters. A static QR code points directly to the destination URL. Once printed, it does not depend on my app staying online.

Stack

The project is built with:

Next.js
React
Cloudflare Workers
Stripe Checkout for one-time batch exports
Server-side ZIP generation for print packs

What I am still figuring out

The biggest question is positioning.

I am testing whether “Verified Print Pack” clearly communicates the value: preview the CSV, catch obvious problems, then export a print-ready bundle.

I’d love feedback from builders, designers, or anyone who has had to generate QR codes for real-world print materials.

Project: https://qrcodegenerator.page