DEV Community: 王龙

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

I revived a small Mayan Tzolk'in calendar calculator and found real user demand

王龙 — Wed, 17 Jun 2026 13:54:27 +0000

I recently revived a small niche web tool I had left untouched for months:

Mayan Astrology Calculator

It converts a Gregorian birth date into a Mayan Tzolk'in calendar reading.

The Tzolk'in is a 260-day sacred calendar cycle made from 20 day signs and 13 tones. The tool calculates a user's Nawal day sign, Galactic Tone, and a short reflective interpretation.

Why I came back to it

The project had been quiet for a while, but Google Search Console showed that people were still finding it through search.

Queries like:

mayan astrology calculator
mayan zodiac sign calculator
mayan birth chart
mayan calendar calculator

were still getting impressions and clicks.

That was enough of a signal to make me revisit the project instead of abandoning it.

What I added

The original version was mostly a single calculator. I expanded it into a more complete static tool site:

A Mayan astrology birth date calculator
A result page with Nawal and Galactic Tone interpretation
Today's Mayan date
A compatibility calculator
A guide to the 20 Nawal day signs
A guide to the 13 Galactic Tones
SEO pages for related search intents
A simple waitlist for deeper personalized PDF reports

The site is built with Next.js and exported as a static site.

The interesting part: waitlist validation

I wanted to test whether this could become more than an ad-supported content site.

Instead of building payments, accounts, and PDF generation immediately, I added a lightweight waitlist CTA on the result page:

Want a deeper personalized Mayan birth chart report?

When users click it, they are invited to email us if they want early access.

This is intentionally higher friction than a normal email input. If someone actually opens their email client and sends their birth date and result, that is a stronger signal than a passive signup.

Within a short time, a couple of users actually emailed us with their birth dates and Mayan signatures.

That changed the question from:

"Is this just a fun niche calculator?"

to:

"Is there enough intent here to justify a paid personalized report?"

Why I did not build payments first

It would be tempting to add Stripe immediately.

But for a niche tool, I think that would be premature.

Before building a full payment flow, I want to validate:

Do users want deeper reports?
Would they pay for them?
What kind of report feels valuable?
Does a PDF report feel trustworthy enough?
What methodology explanation is needed?

So the next step is manual delivery: generate a few early-access PDF reports, send them to interested users, and ask for feedback.

Credibility matters

For a tool like this, trust is important.

The calculator part is deterministic: it converts a Gregorian date into a Tzolk'in signature.

The interpretation part is reflective. It is not scientific, medical, legal, or psychological advice.

For the PDF reports, I am adding:

A methodology section
A cultural note
A clear distinction between calculation and interpretation
A disclaimer
A sample report structure

I think this matters, especially when working with cultural or spiritual systems. The goal is to be useful and respectful, not to pretend to be an official authority.

Tech stack

The current stack is intentionally simple:

Next.js
Static export
Cloudflare Pages
Google Search Console
Google Analytics
Plain HTML/PDF templates for early report samples

No database yet. No payment integration yet. No account system.

The project is still in the validation stage.

What I learned

A few takeaways from this small experiment:

Old niche projects may still have search demand.
Google Search Console can reveal what users actually want.
A calculator can be more valuable than a blog post because the result is personal.
High-friction waitlists can be useful when you want stronger intent signals.
Paid product development should probably start manually before becoming automated.

Feedback welcome

I'd love feedback on the tool and the approach:

Mayan Astrology Calculator

Specifically:

Is the calculator flow clear?
Does the result page feel useful?
Would a paid PDF report make sense here?
How would you improve trust and credibility for a niche spiritual/calendar tool?

Thanks for reading.

I Built a Color-Memory Game with Next.js + Cloudflare: Making "Guess the Hue from Memory" Fun and Fair

王龙 — Tue, 09 Jun 2026 16:49:00 +0000

Hey everyone — I'm Potter, the solo developer behind Toon Tone.

💡 The Pitch in One Sentence
You are given the name of an iconic cartoon character and a specific part of them, but only a solid white block is displayed — you must drag the H/S/B (Hue, Saturation, Brightness) sliders to recreate the exact color from your memory. Five rounds, scored from 0–10 based on how close your color is to the target.

🎨 Why This Exists
We all think we perfectly "remember" pop culture colors — SpongeBob's signature yellow, Pikachu's rosy cheeks, or Mario's red cap.

But the moment you lose the visual context of the character's lines and shapes, and find yourself staring at a blank color picker, you realize a shocking truth: your visual memory and the actual RGB values are separated by a massive, humbling gulf. That exact psychological gap — the "I know I know this, but I'm completely guessing right now" feeling — is where the fun of Toon Tone lives.

🛠️ Two Core UX and Architectural Decisions
As a solo project, making a simple "guess the color" mechanic feel both intuitive and mathematically fair required some deep thought into the details:

HSB Sliders Instead of RGB In daily web development, we are used to dealing with RGB or Hex codes. However, in game design, RGB sliders are an absolute UX nightmare.

When the human brain wants to make a color "a bit more red" or "a lighter blue," we don’t naturally calculate how much to push the Red axis or subtract from the Green axis. We perceive color in a sequence: first we identify what the color is, then how vivid it is, and finally how bright it is.

Because of this, I strictly went with the HSB (Hue, Saturation, Brightness) model for the sliders:

Hue helps players anchor "which color" it actually is.

Saturation controls the vividness and intensity.

Brightness dictates the light and shadow.

Player feedback has proved this right: people instinctively set the hue first, then fine-tune the saturation and brightness, perfectly mirroring how the brain extracts visual memories.

Scoring System: Brutally Rigid sRGB Euclidean Distance In color science, using a perceptually uniform algorithm like CIEDE2000 is technically more accurate to how the human eye registers different spectrums. However, during early prototype testing, complex perceptual math just ended up confusing players. People would get frustrated, saying, "I feel like these two colors look almost identical, why did the game dock so many points?"

So, I made a very deliberate, hardcore engineering choice: calculating scores based strictly on standard sRGB space Euclidean distance.

While it might not be a perfect representation of human biology, it brings three massive wins to the table:

Brutal Fairness: There are no gray areas or hand-waving. Every unit of RGB deviation costs you points, pure and simple.

High Predictability: Players learn the exact "temperament" of the scoring model within two rounds.

Instant Performance: The calculation executes in roughly 0.0001ms, meaning zero rendering lag.

📈 Surprises & Insights from the Game
Content Cadence: I am currently keeping a rhythm of adding 1–2 new character colors every single Friday to steadily grow the pool.

The Charm of "Blind Color Guessing": Because the game renders only a solid color block without any surrounding illustrations or outlines, it acts as a pure, stripped-down test of isolated visual memory.

Polarized Difficulty: The hardest color to nail so far is SpongeBob's yellow (almost everyone oversaturates it and gets penalized heavily). On the flip side, the easiest to score high on is Pikachu (those two red cheeks are so deeply burned into collective human DNA that people's memory holds strong).

The Decay of Memory: The biggest predictor of a high score isn't whether someone has art training — it's whether they have watched or interacted with that specific show recently. "Nostalgia memory" decays at a wildly different rate than "recent recognition memory." This has actually shifted my weekly curation strategy; I now actively look out for what old anime are getting remakes or what's trending on streaming platforms to catch players at the peak of their cultural memory.

💻 The Ultra-Lean Stack (Next.js + Cloudflare Workers)
As an indie hacker, my top priority for this project was keeping maintenance costs at zero, rendering fast, and eliminating bloat. To achieve that, I built the entire architecture around the Cloudflare ecosystem:

Framework: Powered entirely by Next.js, which ensures a fantastic developer experience and clean code organization.

Compute & Deployment: Utilizing Cloudflare's official @cloudflare/next-on-pages, the entire Next.js project is deployed directly on Cloudflare Workers, taking advantage of ultra-low latency edge nodes globally.

Storage: Combined with Cloudflare KV / D1 to read and store core game configuration and data at maximum performance and near-zero cost.

Thanks to Cloudflare's edge network, the site loads incredibly fast across the globe. On a standard 4G mobile connection, the initial page load clocks in at around 200ms, delivering a frictionless, instant-play experience.

🎮 Test Your Own Color Memory!
The site is fully live in English with a clean, distraction-free UI. There are no signups, no paywalls, and no installations required — a full 5-round game takes less than 3 minutes.

Give it a spin here: https://toon-tone.net/?utm_sorce=https://dev.to/

Once you finish a run, drop a screenshot of your scorecard in the comments, or let me know: which character's color made you completely question your own memory?