DEV Community: Yuiko Koyanagi

How I export 1.2-gigapixel images on an iPhone without running out of memory

Yuiko Koyanagi — Mon, 13 Jul 2026 21:38:34 +0000

Rendering a big image on iOS is one of those things that looks trivial until your app gets killed by the OS mid-export. CGContext, draw, makeImage(), done — except the moment the output gets large, that innocent-looking pipeline quietly asks for gigabytes of RAM and iOS terminates you.

I hit this wall building Mozary, an iOS app that packs 100+ photos into a single giant picture (a photo mosaic). In v1.1.0 I finally killed the "high-resolution export crashes with out-of-memory" bug for good.

The fix: stop putting the canvas in RAM at all. Put it in a memory-mapped file and let the OS page it to disk. RAM usage dropped from "4.8 GB, please die" to a few dozen MB, flat, regardless of output size.

This post is the walkthrough — with the actual Swift. If you've ever seen Core Graphics blow up on a big image (mosaics, collages, stitched panoramas, high-res rendering — same trap), this is for you.

TL;DR

A non-compressed bitmap costs 4 bytes/pixel. A 1.2-gigapixel image = ~4.8 GB of RAM just for the canvas.
CGContext(data: nil, ...) allocates that in RAM. context.makeImage() then copies it again. Double death.
Back the canvas with a memory-mapped file (mmap). Writes transparently page out to disk and don't count against your app's memory footprint.
Wrap that same mapping in a CGImage via CGDataProvider — zero copy — and stream it straight to a JPEG on disk. Never call makeImage().
Decode source tiles at their draw size, not full size.
Because you now spend disk instead of RAM: add a free-space pre-flight check and clean up temp files after a crash.

Let's dig in.

The problem: "compressed file size" is a lie about memory

Mozary lays photos out on a grid. A typical high-res export is a 200 × 267 grid with each tile drawn at 150px:

width:  200 × 150 = 30,000 px
height: 267 × 150 = 40,050 px

That's ~1.2 gigapixels.

Here's the part people underestimate: the final JPEG is only a few hundred MB to ~2 GB because JPEG is compressed. But while you're drawing, the canvas is uncompressed — 4 bytes per pixel (RGBA):

30,000 × 40,050 × 4 bytes ≈ 4.8 GB

4.8 GB of RAM for the canvas alone.

iOS caps how much memory an app may use (varies by device, but you'll get jetsammed somewhere in the few-hundred-MB-to-~2-GB range). 4.8 GB is never happening. That's the crash.

The naive way (what I had before)

My original export looked like this — and honestly, it was brute force:

// ❌ OLD: allocate the giant bitmap in RAM

// "Pre-flight": compute how many bytes the bitmap needs
let bitmapBytes = UInt64(imgWidth) * UInt64(imgHeight) * 4
let availableMemory = os_proc_available_memory()
if UInt64(Double(bitmapBytes) * 1.3) > availableMemory {
    // Not enough → just give up on high-res
    throw NSError(domain: "MediaExporter", code: -10, ...)
}

// data: nil → CGContext allocates the bitmap in RAM
let context = CGContext(
    data: nil,
    width: imgWidth,
    height: imgHeight,
    bitsPerComponent: 8,
    bytesPerRow: imgWidth * 4,
    space: colorSpace,
    bitmapInfo: CGImageAlphaInfo.premultipliedLast.rawValue
)!

// ... draw all the tiles ...

// makeImage() duplicates the whole bitmap (another +4.8 GB)
let cgImage = context.makeImage()!

Two problems:

CGContext(data: nil, ...) allocates the canvas in RAM → asks for 4.8 GB.
context.makeImage() copies the canvas again → +4.8 GB at peak.

The os_proc_available_memory() check wasn't a fix — it was a polite "sorry, give up." High-res export only worked on the beefiest devices, and mid-tier sizes could sneak past the check and then crash on the makeImage() copy anyway.

I needed to render the same pixels without ever holding them all in RAM.

The fix: put the canvas on disk, not in RAM

The reframe that unlocked everything:

If 4.8 GB won't fit in RAM, don't put it in RAM.

Enter the memory-mapped file (mmap).

What `mmap` actually buys you

mmap maps a file into your address space. You get a pointer you read and write like normal memory — but the backing store is a file on disk.

The magic is that the OS manages that region in pages:

Pages you write become "dirty" and the OS writes them back to disk as needed.
Once written back (clean), those pages no longer count against your app's memory footprint (the thing that gets you jetsammed).

So even if the canvas is 4.8 GB, the only thing resident in RAM is the handful of pages you're touching right now. Everything else lives on disk. You never trip the memory limit.

In one sentence: I stopped trying to fit the work in the app's own memory, and the crash disappeared.

Step 1 — create the file and map it

let ppc = size.effectivePixelsPerCell(columns: columns, rows: rows)
let imgWidth  = columns * ppc
let imgHeight = rows * ppc
let bytesPerRow = imgWidth * 4
let totalBytes  = bytesPerRow * imgHeight   // ← can be ~4.8 GB

// 1. Create a temp file
let canvasURL = FileManager.default.temporaryDirectory
    .appendingPathComponent("mozary_canvas_\(UUID().uuidString).raw")
FileManager.default.createFile(atPath: canvasURL.path, contents: nil)

// 2. Open it and grow it to the needed size (ftruncate)
let fd = open(canvasURL.path, O_RDWR)
guard fd >= 0, ftruncate(fd, off_t(totalBytes)) == 0 else {
    if fd >= 0 { close(fd) }
    try? FileManager.default.removeItem(at: canvasURL)
    throw NSError(domain: "MediaExporter", code: -11, ...)
}

// 3. Map the file into memory
let mapped = mmap(nil, totalBytes, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0)
close(fd) // The mapping keeps the file alive, so we can close the fd
guard let canvas = mapped, canvas != MAP_FAILED else {
    try? FileManager.default.removeItem(at: canvasURL)
    throw NSError(domain: "MediaExporter", code: -12, ...)
}

// 4. ALWAYS release the mapping, on every exit path
defer {
    munmap(canvas, totalBytes)
    try? FileManager.default.removeItem(at: canvasURL)
}

ftruncate grows the file to totalBytes, but it creates a sparse file — disk is only actually consumed for the bytes you write.

Step 2 — hand the mapping to `CGContext`

CGContext lets you pass your own buffer pointer as data:. Just give it the mmap pointer:

guard let context = CGContext(
    data: canvas,   // ← the mmap'd file, not RAM
    width: imgWidth,
    height: imgHeight,
    bitsPerComponent: 8,
    bytesPerRow: bytesPerRow,
    space: CGColorSpaceCreateDeviceRGB(),
    bitmapInfo: CGImageAlphaInfo.premultipliedLast.rawValue
) else {
    throw NSError(...)
}

// Then just... draw. The destination is transparently disk-backed;
// the Core Graphics code doesn't change at all.
for row in 0..<rows {
    try Task.checkCancellation()
    for col in 0..<columns {
        // ... context.draw(tileCGImage, in: rect) ...
    }
}

This is the beautiful part: from Core Graphics' point of view, nothing changed. It thinks it's drawing into a plain memory buffer. The writes just quietly spill to disk.

Step 3 — nudge finished rows out to disk

The OS will page dirty pages out on its own, but you can help it: tell it explicitly "I'm done with this region, feel free to flush it." That keeps the set of dirty (not-yet-written-back) pages small. The tool is msync:

if row % 10 == 0 {
    progress(0.2 + cellProgress * 0.65)

    // Every 40 rows, async-flush the scanlines we've already finished.
    if row % 40 == 0, row > 0 {
        let flushedBytes = (row * ppc) * bytesPerRow
        msync(canvas, flushedBytes, MS_ASYNC)   // MS_ASYNC = non-blocking
    }
}

Why (row * ppc) * bytesPerRow? A bitmap is a single contiguous byte array in memory — rows laid out top to bottom. My draw loop goes top row → bottom row, so once I'm on row N, every row above it is finished and lives at the start of the buffer:

buffer: [==== finished ====][ drawing ][=== empty ===]
        ↑ canvas            ↑
        |←── flushedBytes ──→|
        msync(MS_ASYNC) on this range =
        "you can write these pages back now"

row * ppc → number of finished pixel rows (ppc = pixels per cell)
× bytesPerRow → convert rows to bytes

One nuance worth stating precisely: MS_ASYNC doesn't free memory directly. It marks those pages clean (safely written to disk). Clean pages are the ones the OS can evict for free when it needs RAM back — because an identical copy already exists on disk. So msync doesn't reclaim memory; it makes memory reclaimable, which keeps your peak footprint low.

The other trap: `makeImage()` copies everything

Second landmine: encoding the JPEG.

Remember context.makeImage() duplicates the whole bitmap. Call it here and you've just asked for +4.8 GB — undoing everything.

So skip it. Wrap the same mmap region in a CGImage directly, handing the pointer to CGDataProvider with no copy:

// Make sure the whole canvas is synced to disk
msync(canvas, totalBytes, MS_SYNC)

// Wrap the mapping in a CGImage WITHOUT copying it.
// The empty releaseData is intentional: the deferred munmap above
// owns the mapping, and it outlives this scope-local image.
guard let provider = CGDataProvider(
    dataInfo: nil,
    data: canvas,
    size: totalBytes,
    releaseData: { _, _, _ in }   // no-op
), let cgImage = CGImage(
    width: imgWidth,
    height: imgHeight,
    bitsPerComponent: 8,
    bitsPerPixel: 32,
    bytesPerRow: bytesPerRow,
    space: CGColorSpaceCreateDeviceRGB(),
    bitmapInfo: CGBitmapInfo(rawValue: CGImageAlphaInfo.premultipliedLast.rawValue),
    provider: provider,
    decode: nil,
    shouldInterpolate: false,
    intent: .defaultIntent
) else {
    throw NSError(...)
}

// Write JPEG straight to a file (no UIImage in between)
let tempURL = FileManager.default.temporaryDirectory
    .appendingPathComponent(UUID().uuidString).appendingPathExtension("jpg")

guard let dest = CGImageDestinationCreateWithURL(
    tempURL as CFURL, "public.jpeg" as CFString, 1, nil
) else { throw NSError(...) }

CGImageDestinationAddImage(dest, cgImage, [
    kCGImageDestinationLossyCompressionQuality: size.jpegQuality
] as CFDictionary)

guard CGImageDestinationFinalize(dest) else { throw NSError(...) }

return tempURL

CGImageDestinationFinalize reads from the CGImage (i.e. the mmap'd file) while it writes the JPEG. The encoder pulls data in tiles, so no giant buffer ever lands fully in RAM here either.

Result: both ends of the pipeline — the canvas input and the JPEG output — stay off the RAM budget.

Bonus win: decode tiles at draw size, not full size

One more thing that mattered. Mozary stores each tile's thumbnail as a 600px JPEG on disk. Decode all of them at full size for a 1,000-photo mosaic and:

600 × 600 × 4 bytes × 1000 photos ≈ 1.4 GB

1.4 GB just for the tile cache — but I only ever draw them at cell size (ppc, 60–150px). So decode them straight to that size with CGImageSourceCreateThumbnailAtIndex:

let thumbOptions = [
    kCGImageSourceCreateThumbnailFromImageAlways: true,
    kCGImageSourceShouldCacheImmediately: true,
    kCGImageSourceCreateThumbnailWithTransform: true,
    kCGImageSourceThumbnailMaxPixelSize: ppc   // ← decode at cell size
] as CFDictionary

// CGImageSourceCreateThumbnailAtIndex(source, 0, thumbOptions)

At 100px a tile is ~40 KB decoded. 1,000 of them fit in a few dozen MB. Never decode at a higher resolution than you'll draw — downsampling on decode is a Core Graphics rule of thumb worth tattooing somewhere.

Spending disk means guarding disk

Trading RAM for disk creates a new constraint: free disk space. During export the uncompressed canvas (4.8 GB) and the JPEG being written (~2 GB) coexist — a peak of ~7 GB.

So I check the actual working space needed, not the final file size, before starting:

// The final "~2 GB" file size badly understates what export transiently needs.
let requiredBytes = size.requiredWorkingBytes(columns: columns, rows: rows)
let freeSpace = (try? FileManager.default.temporaryDirectory
    .resourceValues(forKeys: [.volumeAvailableCapacityForImportantUsageKey])
    .volumeAvailableCapacityForImportantUsage) ?? 0
if freeSpace > 0, freeSpace < requiredBytes {
    throw NSError(...)  // "needs about N GB of temporary free space"
}

func requiredWorkingBytes(columns: Int, rows: Int) -> Int64 {
    let ppc = effectivePixelsPerCell(columns: columns, rows: rows)
    let pixels = Double(columns * ppc) * Double(rows * ppc)
    // uncompressed canvas (4B/px) + JPEG being encoded + safety margin
    return Int64(pixels * 4 + pixels * estimatedBytesPerPixel) + 500_000_000
}

I actually found this the hard way. On a test device with ~2 GB free, the export failed even though my original check (which only accounted for the final file) said there was room. Testing on a nearly-full device is what surfaced it — the real working set needs the transient space, obviously in hindsight. Glad I debugged on a cramped device.

And if the app gets killed mid-export, the defer cleanup never runs and a 2 GB+ temp file is orphaned — which would then eat into the next export's disk check. So I sweep old canvas files on start:

// Sweep temp canvases orphaned by a previous crash
if let leftovers = try? FileManager.default.contentsOfDirectory(
    at: FileManager.default.temporaryDirectory, includingPropertiesForKeys: nil
) {
    for url in leftovers where url.lastPathComponent.hasPrefix("mozary_canvas_") {
        try? FileManager.default.removeItem(at: url)
    }
}

(I also clamp cell size so no dimension exceeds JPEG's 65,535px limit, plus a few other small guards.)

Results

	Before	After
High-res export	Rejected by pre-flight, or crashed on some devices	Works
Peak RAM	~4.8 GB (canvas) + ~4.8 GB (`makeImage` copy)	A few dozen MB, flat
Depends on output size?	Yes — bigger = death	No — constant footprint

Ordinary iPhones now export 1.2-gigapixel mosaics without breaking a sweat.

Takeaways

On iOS, drawing a big image blows up because the uncompressed canvas (4 B/px) exceeds the memory limit — the compressed file size tells you nothing about that.
Back the canvas with mmap so writes page out to disk and stay off your app's memory footprint.
For the output CGImage, avoid context.makeImage() (it copies) — wrap the mmap region with CGDataProvider for a zero-copy hand-off, then stream to disk with CGImageDestination.
Decode inputs at draw resolution, never larger.
Once you spend disk instead of RAM, pair it with a free-space pre-flight and post-crash cleanup.

The general principle — "if it won't fit in RAM, back it with a file and let the OS page it" — goes way beyond Core Graphics. Any time you're wrangling a buffer bigger than memory, mmap is worth reaching for.

If you've fought the same "Core Graphics eats all my memory" battle, I hope this saves you a few crash reports.

Try it out!

Mozary is on the App Store if you want to see the export in action (and I'd genuinely love feedback):
👉 https://apps.apple.com/us/app/mozary/id6759013945

What's your go-to trick for large-image or large-buffer work on mobile? I'd love to hear it in the comments.

Want to keep using Fable 5? Teach Opus and Sonnet to "behave" like it.

Yuiko Koyanagi — Mon, 06 Jul 2026 21:45:11 +0000

A while back I wrote about how I use Fable 5 without going token-bankrupt:

Yuiko Koyanagi

Jul 2

Use Fable 5 where it pays for itself

#claudecode #ai #productivity #agents

7 min read

I put Fable 5 in the orchestrator seat — scoping, design, delegation, final review — while the hands-on implementation, testing, shipping, and code review are done by Opus and Sonnet subagents. The expensive model plans and judges; the cheaper models execute. This ran beautifully for most tasks.

There's just one problem. As you probably know, Fable 5 access via subscription ends on July 7. (I'm praying it comes back to subscription someday… 🙏)

The orchestration setup itself works without Fable 5 — but if the model at the top, the one cutting scope and judging everything, gets downgraded, output quality drops with it.

Here's the thing though: Opus and Sonnet are not bad models. Used correctly, they produce genuinely good output. What matters is writing down what to do, how to do it, and what to do when something fails. So before losing access, I decided to document how Fable 5 actually works and hand it down to Opus/Sonnet — as skills.

This post is about what I did and how. Finding a "replacement for Fable" seemed hopeless, so the goal became something else: raise the whole team's capability so that quality holds even with Opus in the orchestrator seat.

The gap between Fable 5 and Opus/Sonnet is not intelligence

To keep using a pseudo-Fable after the shutdown, I started by examining what the difference actually is.

When Opus/Sonnet produce output I didn't intend during everyday engineering, the failures turn out to follow recognizable patterns. For example:

Slapping "use client" at the top of a Next.js page because one button needs an onClick
- …which drops the entire page and its import tree onto the client
Writing fetch with no cache option
- The defaults are opposite between Next.js 14 and 15, but "it works" was only checked on the dev server — hello, production caching surprise
Skipping input validation in a Server Action because it's "only called from my form"
- It's actually a public POST endpoint anyone can hit with arbitrary arguments
Fetching initial data inside useEffect
- An await in a Server Component would do it, without the request waterfall and the layout flash
"Fixing" a failing test by rewriting the assertion
- Don't touch the assertion until you've proven, with evidence, that the code side is the wrong one
Saying "this should work now" without running anything
- Run it first, then conclude whether it works

What matters here: none of these are knowledge gaps. Ask Sonnet directly — "is a Next.js Server Action dangerous without input validation?" — and it answers correctly. The knowledge is in there. What's missing is the correct procedure.

Fable 5 runs these checks implicitly, without being asked, and pushes back when something's off. With Opus/Sonnet, those checks have to be written down explicitly.

Raw reasoning differences are real, of course. But for routine implementation, review, and debugging, most of the observable quality gap comes down to discipline, sequencing, and verification — and all three can be written as skills.

"Be careful" prompts don't work

My first attempt at Fable-izing Opus/Sonnet was writing "be careful, always verify, follow best practices" into the prompt. Result: nothing happened (obviously, in hindsight). A sentence that doesn't change the model's next move doesn't change its behavior.

So the first rule of documenting Fable's working method was a ban list. No line may contain:

"be careful" / "follow best practices" / "think hard" / "ensure quality"

Every line has to be executable or checkable — runnable as a command, defined as a threshold, expressed as if/then, or greppable as a pattern. It must be unambiguous what the reader does next.

I documented Fable 5's working method along five axes

Before getting into the "how": I maintain ccteams, a CLI that installs pre-built Claude Code subagent teams with one command.

From v0.2.x, every team ships with two skills: a shared working method and a per-team playbook. Here's what actually went into them, in order.

1. Fix the work routine

The classic Opus/Sonnet mistake is starting to write immediately — leaning on training data or earlier context ("Go is usually written like this", "this library's API was like that") without checking the repository in front of it.

So each playbook opens with a numbered procedure that forces pre-writing behavior:

Read go.mod (and its version) before using a language feature
Read the lockfile for the actually-installed version before trusting library docs
Read two neighboring files before picking a pattern
grep before writing a helper (it usually already exists under a different name)

In short, it pre-commits the model to one principle: don't decide from memory — read the repo and decide.

2. Define the failure patterns and their fixes

What mid-tier models lack isn't knowledge — it's that they carry wrong assumptions, and proceed on the premise that the plausible implementation is the correct one. Crushing that tendency is the priority.

So for each team, I defined the common failure patterns in a fixed format:

symptom → wrong instinct → correct move

so that when Opus/Sonnet hits the symptom, it knows exactly how to correct course.

From the ccteams Next.js playbook:

One button needs an onClick → put "use client" at the top of the page → extract the button into its own leaf component, mark only that file client, keep the page a Server Component.

From the Go playbook:

Handler hits an error → call http.Error(w, msg, 500) and keep going → add return immediately after. http.Error writes and returns; your handler doesn't — the success path below writes a second body onto a committed 500 response.

There are 10–15 of these per team (Go team, React Native team, Rails team, and so on). Naming the wrong instinct explicitly lets the model recognize the exact moment it's about to make the mistake. You're patching the decision point, not the knowledge base.

3. Define the decision branches

A frontier model's edge is judgment. Judgment itself can't be transplanted — but 80–90% of the recurring cases can be compiled into explicit branches. From the Go playbook:

Before launching any goroutine — three questions, "nobody" is a forbidden answer:

Who cancels it?

Who waits for it?

Where does its error go?

If any answer is "nobody", don't launch it.

Why this one? Because a goroutine is trivial to launch and hard to clean up. When a mid-tier model casually writes go doWork(), the typical outcomes are:

Nobody stops it → it keeps running after the program should be done, or lives forever (goroutine leak = memory leak)
Nobody waits for it → main exits first and the work silently never completes
The error has nowhere to go → failures inside the goroutine get swallowed, and no one ever notices

This is exactly the kind of thing that goes wrong when vibe-coding Go, so it's defined specifically for the Go team.

There's also a team-independent rule shared by everyone:

State your hypothesis before touching code. A fix without a confirmed root cause is a guess.

This blocks the classic mid-tier move of applying a plausible-looking fix before the root cause is confirmed.

For debugging specifically — where "patch the symptom's location and feel done" accidents are constant — the debug team has a dedicated gate:

Before writing any fix, you must be able to say: "X causes Y, because Z" — where X and Y are observed, and Z explains why this exact symptom appears. If you can't fill in Z, you have a correlation, not a cause.

In other words: no causal sentence, no fix phase. You get sent back to re-verify the hypothesis.

This is the pattern across ccteams: for each team, the decision branches that stop that team's characteristic accidents are written out explicitly.

4. Define the verification method

Verification is cheap compared to generation. Which means: a mid-tier model plus a strong verification harness beats a mid-tier model alone, by a wide margin. So every playbook contains an exact, ordered verification recipe.

Not "please test it" — but which commands, in which order, and what each failure means. For Go: go build ./... → go vet ./... → go test -race ./... (with -race marked non-negotiable). The frontend playbook includes checks no linter will ever run for you: a keyboard-only walkthrough, and resize tests at 320/768/1280px.

On top of that, the shared working method demands execution as the basis for claims. A typical mid-tier shortcut is returning code that has never been run, with a cheerful "this should work". To kill that:

The diff is a claim; execution is evidence. Only after actually running build/test/lint and reading their output is the claim backed.

And to enforce it, every claim in a report must carry a label — VERIFIED (ran it) / REASONED (read the code) / ASSUMED (unchecked) — with silent upgrades forbidden. You can no longer pass off "should work" as "works".

5. Absorb failures one at a time with a learning loop

Everything above was written by Fable in advance — rules based on predicting "a mid-tier model will probably get this wrong". Not bad, but predictions are predictions. Rules grounded in mistakes that actually happened in your project are obviously stronger.

So the working method includes a learning loop: the more you use the team, the more it optimizes itself to your project.

The rule itself is simple: when a mistake surfaces that the playbook didn't anticipate, turn it into a catalog entry, and add it as a rule after human approval.

From v0.2.2, running ccteams use automatically creates .claude/skills/team-lessons/SKILL.md. Once created, this file is never overwritten — not by team switches, not by ccteams updates. It exists to accumulate your project's own failure patterns and their fixes.

When an unanticipated mistake occurs, the AI works out the symptom → wrong instinct → correct move and asks you whether it should be recorded. On approval, the agent appends the entry to team-lessons/SKILL.md.

The result is a team that gets smarter with every failure it absorbs.

That said, bloat is unavoidable on a long-running project. As first-line countermeasures there's a duplicate check (sharpen an existing entry instead of appending a near-copy) and the human approval gate itself — but long-term operation is an open question I'm still thinking about.

Making sure it actually reaches the subagents

Claude Code skills are on-demand: they get invoked when the model decides they're relevant. Which means a "working method" skill is never used unless something makes it relevant — and the subagents actually doing the work never invoke skills on their own, period.

To solve this, I planted it in two places.

1. Embed it in the agent definitions

Every agent's system prompt now begins with FIRST ACTION: Read .claude/skills/<team>-playbook/SKILL.md and follow it. But "read this" alone is sometimes ignored — so as a fallback, the 5–6 most load-bearing rules from the playbook are also embedded inline in the system prompt itself.

2. Embed it at delegation time

The orchestration rules obligate the orchestrator to paste a compressed digest of the shared working method, verbatim, into every delegation prompt.

And as the last line of defense, in case both get slipped past: the orchestrator is instructed to check every report against named gates and reject on failure. "The build output isn't quoted? Sent back." Even if delivery fails completely, work that ignored the discipline doesn't get accepted.

Why not just paste the full text everywhere? Because the more instructions you add, the lower the compliance per instruction. So the always-loaded portion is 5–6 lines, each agent carries ~10 inline lines, and the full ~200 lines are read on demand.

Sounds like a lot of setup, right?

ccteams (v0.2.x and later) already ships with Fable 5's working method handed down to Opus/Sonnet, exactly as described above. If you just want a good team quickly — or a template to study — give it a try:

npm install -g ccteams
ccteams list
ccteams use go-api   # or next-ts, python-fastapi, rails, django, debug — pick your team
# restart Claude Code

If this saved you some setup time, a star on the repository would make my day. Issues and impressions from trying it are very welcome too!

Afterword

My initial plan was to define rules for the orchestrator only. That turned out to be a dead end — because the one getting weaker is the orchestrator. Fable could catch subagents' mistakes at report time with high precision and send them back; no amount of orchestrator-side rules reproduced that behavior on a weaker model.

Rejection is also more expensive than prevention. So I shifted the weight onto preventing mistakes in the first place — raising the whole team — rather than catching them at the top.

I reverse-engineered, shipped, and tested it, and the results were satisfying: bugs that Opus used to miss are now getting caught. For routine work, I'd say this setup has closed most of the gap between Fable and the other models.

What it can't cover is Fable's unique strength: handling the unanticipated. Noticing "something is off" when nothing on any checklist says so; grasping the structure of a genuinely novel problem at a glance. That doesn't transfer through anything you can write in a skill.

That remaining gap is what the learning loop above chips away at — one absorbed failure at a time.

"Make Opus/Sonnet behave like Fable 5" is an idea you see floated a lot, but I rarely found articles that go into the details — so I actually did it and wrote them down. I hope some of it is useful to you.

Use Fable 5 where it pays for itself

Yuiko Koyanagi — Thu, 02 Jul 2026 19:56:24 +0000

Claude Fable 5 is the model I reach for in Claude Code when a task is ambiguous, long-running, or full of tradeoffs — planning across steps, untangling a messy goal, weighing a design choice, keeping a long session pointed in the right direction. It's genuinely good at the hard parts.

Which is exactly why I stopped letting it do the easy ones. At $10 per million input tokens and $50 per million output — double Opus 4.8's $5 / $25 — spending it on boilerplate and lint fixes is like paying a principal engineer to reformat your imports. The work still needs doing. It just doesn't need that person doing it.

A Claude Code task is rarely one task. Take a one-liner like:

Add rate limiting to our API.

Sounds small. But it unfolds into work of very different weights:

deciding the algorithm — token bucket, sliding window, fixed window
choosing where the counter lives — in-memory, or Redis because we run multiple instances
thinking through what happens under a burst, and what a client sees on a 429
writing the middleware
wiring it into every route
writing the tests
fixing the lint and type errors
checking the edge cases — clock skew, the limiter itself failing, keys never expiring

The first three are real design decisions — the kind where a wrong call is expensive and annoying to unwind six months later. The rest is execution: careful work, but not work that rewards a frontier model over a merely-very-good one.

So I don't try to replace Fable 5. I just keep it on the decisions and hand everything else to something cheaper.

Make Fable 5 the lead, not the labor

Concretely, that means treating Fable 5 like a tech lead: it plans and delegates, and other models do the actual building.

Fable 5 = orchestrator — plans, decomposes, synthesizes. Writes no code.
Opus = deep reasoning subagent — architecture, complex debugging, review
Sonnet = mechanical work subagent — implementation, boilerplate, tests, chores
(Optionally) Codex = peer senior engineer — an independent second opinion from a different model family

Fable 5 thinks, delegates, and stitches the results together; the cheaper models handle work they're already good at. So the pricey model is only on the clock for the steps that actually reward its judgment.

The token savings were what I was after. What I didn't expect was the second effect: because Fable 5 never touches raw file contents or stack traces, its context stays clean, and it's still making sharp calls six hours into a session instead of drowning in half-finished edits.

I figured that was the whole setup — three quick steps. It wasn't.

The hard part is the subagents

On paper, it's three steps:

/model → Fable 5
Create subagents with /agents, pinned to Opus and Sonnet
Write routing rules in your CLAUDE.md — which work goes to whom

Step 1 takes ten seconds.

Steps 2 and 3 are where the actual work is. Creating a subagent is fast. Creating one that pulls its weight is not.

Three things I learned the hard way:

The description field decides who gets the work. The orchestrator picks a subagent by reading its description. "Use for reasoning-heavy tasks" is vague enough that the routing quietly drifts, and you don't notice until an answer comes back wrong.
The system prompt decides what comes back. Subagents can't see your conversation. If the prompt doesn't say what to read before acting and what to return — a conclusion, a diff, file:line findings — the orchestrator ends up cleaning up after them. Which is the one thing you were trying to avoid.
"Thinker" and "doer" is too few roles. It's a reasonable start. But real work splits into scoping, design, implementation, verification, and shipping. Collapse verification into the builder, and you have an agent reviewing its own code.

The decision that actually takes time, then, isn't picking models — it's writing a team of subagents whose roles are sharp enough that delegation just works. And that's a surprising amount of careful prose.

ccteams: install the team design in one command

This is the part I got tired of rewriting by hand, so I built a tool for it: ccteams, a package manager for Claude Code agent teams.

npm install -g ccteams
ccteams list           # see the teams
ccteams use generalist # apply one to the current project

That single command drops a full set of role-specialized subagents into .claude/ — descriptions, system prompts, tool restrictions, and a model: per agent already written — plus the orchestration rules that tell the lead session how to run them. Step 3 above (hand-writing routing rules in CLAUDE.md) ships in the box. So does the model assignment — more on that below.

Teams come stack-specific out of the box:

Team	What it's for
`generalist`	Stack-agnostic feature team: scope → design → build → QA → ship
`next-ts`	Next.js (App Router) + TypeScript + Tailwind
`go-api`	Go HTTP API backends
`python-fastapi`	FastAPI + Pydantic v2
`rails` / `django`	Rails / Django + DRF
`debug`	Reproduce → root-cause → minimal fix → regression test
`research`	Technical research that writes no code

Prefer staying inside Claude Code? There's a plugin:

/plugin marketplace add toffyui/ccteams
/plugin install ccteams@ccteams

Then /ccteams:choose-team something for backend API work picks and applies the right team from a natural-language description.

The models are already assigned

Here's the part I only got right recently: every bundled agent already ships with a model: in its frontmatter, assigned by how much reasoning the role needs. You don't add anything. ccteams use generalist lands this:

Agent	Role	Model (preset)
(main session)	Orchestrator	Fable 5 — you pick this with `/model`
`scope-planner`	Cut scope, pin down requirements	`opus`
`architect`	Design decisions	`opus`
`builder`	Implementation, boilerplate, tests	`sonnet`
`qa-reviewer`	Verification, edge-case hunting	`opus`
`shipper`	Commits, CI, chores	`sonnet`

Open any agent file and the line is right there:

---
name: architect
description: Technical design specialist. ...
tools: Read, Glob, Grep, WebSearch, WebFetch
model: opus        # ← already set by ccteams
---

The one model ccteams doesn't touch is the lead session's — that's yours to pick with /model (Fable 5). Everything below it is pinned.

The split is similar to the usual “thinker / doer” setup, but the extra roles matter. Once the work is separated into scoping, design, building, review, and shipping, delegation gets much more precise — and the model choice becomes part of the role instead of a judgment the orchestrator has to remake every time.

The important detail is that I do not assign Fable 5 to roles like architect or qa-reviewer.

That can look backwards at first. If planning and review are the important parts, why not put the best model there too? Because by the time a task reaches those agents, Fable 5 has already done the hardest part: turning an ambiguous user request into a clear, bounded problem that another model can solve.

That is where Fable 5 earns its keep — ambiguous, long-running work full of tradeoffs. Once the question is clearly framed, Opus is usually more than enough to propose a design or review a fix. And those agents still do not get the final say. They propose; Fable 5 decides what to accept.

So Fable 5 keeps control of the core judgment without spending tokens on every intermediate role. The setup does require good orchestration rules and agent prompts, but that is exactly what ccteams installs for you.

Adding Codex as the peer engineer

OpenAI's official Codex plugin lets you call Codex from inside Claude Code (install the Codex CLI on your machine first):

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup

Then add one paragraph to your project's CLAUDE.md (below the @.claude/active-team.md import that ccteams creates):

## Peer engineer
Codex (/codex:rescue --background) is a peer senior engineer with a different
perspective. For high-stakes decisions, task the architect agent and Codex on
the same problem in parallel and synthesize — without showing either the
other's answer.

The point is to use Codex as a peer rather than a rubber-stamp reviewer. On a high-stakes call, I give the same problem to the Opus-pinned architect and to Codex at the same time, neither seeing the other's answer, and let Fable 5 reconcile the two. You get the most out of this when the two models come from different lineages — Opus and Codex were trained differently enough that they tend to miss different things, so one often catches what the other glossed over.

Back to "add rate limiting"

Remember that one-liner from the top? Here's the whole prompt I use:

Add rate limiting to our API.
Context: Express + Redis, deployed as 3 instances behind a load balancer.

I just state the goal. Claude Code routes the rest on its own — it matches the task against each agent's description and delegates automatically, so Fable 5 sends the algorithm-and-storage question to architect, the implementation to builder, the edge cases to qa-reviewer, without me naming any of them.

And because each agent's model is pinned in its frontmatter, that routing decision is the model decision. The moment architect is chosen, the design call runs on Opus, where being wrong is expensive; builder's middleware and tests run on Sonnet. Fable 5 plans and synthesizes on a clean context and writes no code itself — so the priciest model in the room is billed only for the judgment that actually needed it.

That was the goal all along: not to spend less on Fable 5, but to spend it only where it pays for itself.

In short

Fable 5 is worth its price on judgment — planning, design, review — and wasteful on everything else
The hard part of this setup isn't picking models, it's designing the team that surrounds them
ccteams installs a considered team in one command — orchestration rules and a per-agent model: preset included, so the Fable-lead / Opus-reason / Sonnet-build split is live the moment you apply it
Pick your lead model with /model, restart Claude Code, and you're done — repin any agent's model: line if you want a different split

If this saves you some setup, a star on the repo is the nicest way to say so — and if the presets don't match how you'd split the work, open an issue and tell me 🙌

React Native team and django team are available now!

Yuiko Koyanagi — Wed, 01 Jul 2026 14:23:58 +0000

Yuiko Koyanagi

Jun 18

One command turns Claude Code into a full dev team

#claudecode #ai #opensource #cli

3 min read

I built a Chrome extension that lets you blow up any webpage

Yuiko Koyanagi — Tue, 30 Jun 2026 15:25:11 +0000

I built a Chrome extension called Site Bomb. It does exactly one thing: you drop little bombs anywhere on a webpage, and the text near the blast gets physically blown apart, letter by letter.

It is completely useless. It is also genuinely satisfying when you're stressed.

Here's how it works, and the three things I had the most fun figuring out.

1. Turning page text into something you can blow up

You can't apply physics to a plain text node — a paragraph is one indivisible blob as far as the DOM is concerned. So before anything explodes, Site Bomb walks the page and rewrites every visible text node, wrapping each individual character in its own element:

string.split("").map((char) =>
  /\s/.test(char)
    ? "&nbsp;"
    : `<particle style="display:inline-block;">${char}</particle>`
);

Now every letter is its own inline-block box that can be moved, rotated, and flung around independently — while the page still reads normally until a bomb goes off. Whitespace is preserved so the layout doesn't collapse.

2. The blast: a little bit of fake physics

When a bomb explodes, each particle (letter) looks at its distance from the blast center and gets pushed away with a force that falls off with distance — roughly an inverse-square feel, capped so close letters don't fly off to infinity:

const distX = this.x - blast.x;
const distY = this.y - blast.y;
const distance = distX * distX + distY * distY;

let force = 150000 / distance; // closer = stronger
if (force > 40) force = 40;    // clamp so it doesn't explode *too* hard

const rad = Math.asin((distY * distY) / distance);
this.velocityX = Math.cos(rad) * force * (distX < 0 ? -1 : 1);
this.velocityY = Math.sin(rad) * force * (distY < 0 ? -1 : 1);

Then every frame each letter drifts by its velocity, slowly bleeding off speed (a crude friction) and rotating as it goes, all driven through a CSS transform inside a requestAnimationFrame loop. It's not real physics — it just has to feel explosive, and a distance-based force plus some decay gets you there surprisingly cheaply.

3. The bug that annoyed me for years: clicks getting eaten

The most satisfying fix had nothing to do with explosions.

Originally the click handler lived on document.body.onclick. That relies on the click event bubbling up to <body>. The problem: tons of sites call event.stopPropagation() on their own click handlers, so the event dies before it ever reaches body. The symptom was maddening — on some sites bombs only dropped intermittently, and you'd click five times and then all five would go off at once.

The fix was to stop relying on bubbling and listen on the way down instead,
using the capture phase:

document.addEventListener(
  "click",
  (event) => dropBomb(event),
  true // useCapture — fires before any element can stopPropagation()
);

Capture-phase listeners run as the event travels from the root down to the target, before the bubbling phase where stopPropagation() usually lives. One true and clicks now register instantly, everywhere.

Keeping it well-behaved

Actually I released this a few years ago but then one day it got pulled from the Chrome Web Store because it didn't follow Chrome extension best practice.

So, whilst updating Manifest from V2 to V3 this time, I also made corrections to the following minor details.

A couple of small things that matter for an extension that injects into any site:

Minimal permissions. It only needs activeTab — temporary access to the current tab, granted when you click the toolbar icon. No "read all your data on every website" scare. (It's also Manifest V3, with the script injected via chrome.scripting.)
One click to toggle. Clicking the icon turns bomb mode on for that tab (with an ON badge), and clicking again turns it off — state is tracked per tab.
Don't break the page. A re-injection guard stops it from running twice, and elements like <script>, <input>, and <video> are skipped so the page stays usable.

Try it

If you ever want to blow up a webpage:

🔗 https://chromewebstore.google.com/detail/site-bomb/hnnabnffilimfgdcinlijkjkdemdonea?authuser=0&hl=ja

One command turns Claude Code into a full dev team

Yuiko Koyanagi — Thu, 18 Jun 2026 09:43:49 +0000

I love Claude Code's subagents. But I kept noticing the same chore: every new project, I'd hand-write the same crew again — a builder, a reviewer, someone to keep the stack conventions straight. Good setups, but they lived in one repo and never got reused.

So I built ccteams — a package manager for agent teams. One command drops a ready-made team of Claude Code subagents into your project.

npm install -g ccteams
ccteams use go-api // apply your favourite team

That applies a Go builder + reviewer, tuned for net/http, to the current project. Switch when the work changes:

ccteams use next-ts     # Next.js App Router + TypeScript + Tailwind
ccteams use generalist  # scope -> design -> build -> QA -> ship, any stack

Are you not sure which team you need? Don't worry, you can use /ccteams:choose-team and AI will choose the best team for you!

/plugin marketplace add toffyui/ccteams
/plugin install ccteams@ccteams
/ccteams:choose-team I want to create a todo app.

What's a "team"?

A team is just a curated bundle of Claude Code subagents — each a markdown file with the usual name / description / tools frontmatter and a system prompt — plus an orchestration.md that gets merged into your project's CLAUDE.md. Nothing magic, nothing proprietary. It's the setup you'd build by hand, except already built and ready to reuse.

ccteams ships with 8 teams:

generalist — stack-agnostic, takes a feature scope → design → build → QA → ship
next-ts — Next.js App Router + TypeScript + Tailwind
frontend — framework-agnostic UI/UX and accessibility
go-api — idiomatic Go HTTP APIs
python-fastapi — FastAPI + Pydantic v2
rails — Ruby on Rails
debug — reproduce → root-cause → fix → regression test
research — compares options and recommends; writes no code

What `use` actually does

No black box. ccteams use <team>:

Copies the team's agents into .claude/agents/
Writes .claude/active-team.md and adds an @.claude/active-team.md import to your CLAUDE.md
Tracks everything in .claude/.ccteams-manifest.json so switching teams is clean
Won't overwrite agents you wrote by hand — there's a collision guard

Switching to another team removes only what ccteams placed last time. Your own files are never touched.

The one catch: restart

Being honest, because this trips people up: Claude Code loads subagents at session start. So after ccteams use, you have to restart Claude Code for the team to take effect. It is not instant. Run the command, then /exit and relaunch.

Optional: do it from inside Claude Code

There's an optional plugin that adds slash commands, so you don't have to leave Claude Code:

/plugin marketplace add toffyui/ccteams
/plugin install ccteams@ccteams

Then /ccteams:list-teams, /ccteams:use-team <team>, and the fun one — /ccteams:choose-team — where you describe what you need in plain English and it picks the team for you. The plugin is optional; the CLI works fine on its own.

Power users: parallel teammates

If you want the team members to run in parallel and message each other instead of one-at-a-time delegation, opt in:

ccteams use generalist --agent-teams

That turns on Claude Code's experimental agent-teams mode for the project. It's experimental, so treat it as a power-user option, not the default.

Try it

npm install -g ccteams
ccteams list

It's open source (MIT): github.com/toffyui/ccteams. If it's useful, a star helps a lot.

One real question for you: which stack should I add a team for next? I'm weighing Spring Boot, Django, and SwiftUI — tell me in the comments what you'd actually use.

I built “Mozary”: An iOS App That Turns Your Photos Into a Zoomable Mosaic

Yuiko Koyanagi — Fri, 13 Mar 2026 15:42:56 +0000

Mozary is an iOS app that turns hundreds of your photos into a single zoomable mosaic.

Zoom out → it looks like one image
Zoom in → individual photos appear (and you rediscover forgotten moments)

App Link: https://apps.apple.com/us/app/mozary/id6759013945
Try it out!

#buildinpublic #mobileapp #computervision #imageprocessing #productdevelopment | Yuiko Koyanagi

I’ve been building a photo mosaic app that creates an image from images. You pick a target photo, and the app composes it using many smaller photos—so from a distance it looks like one picture, but when you zoom in, you can still see each individual photo clearly. I put a lot of work into the processing pipeline, and the generation is genuinely fast (the video isn’t sped up). Now it’s in app review—excited to share more once it’s live! #buildinpublic #mobileapp #computervision #imageprocessing #productdevelopment

linkedin.com

The idea (why I built it)

I take a lot of photos, but I rarely revisit them.

I wanted a way to turn “a pile of photos” into something you actually want to look at.

During a trip, I saw a huge mosaic wall and thought: what if my own memories could become a mosaic artwork?

That became Mozary.

How it works (user flow)

Choose a target image (what the mosaic becomes)
Choose photos from your library to use as tiles (up to 1000)
Generate (usually 5–20s, up to ~40s for 1000 photos)
Pinch to zoom, then export as an image/video

The engineering part: making the viewer buttery smooth

The hardest part wasn’t generating the mosaic.

It was rendering it interactively.

A mosaic like 200×150 already means 30,000 tiles.

Naively drawing them every frame is a fast path to jank (or crashes).

Borrowing an idea from Google Maps: LOD (Level of Detail)

Google Maps doesn’t draw every tiny detail at every zoom level.

It switches what it renders depending on zoom.

Mozary uses a similar LOD approach (3 levels):

Zoomed out: draw a single pre-rendered image

Instead of looping through 30,000 tiles, I pack each tile color into a pixel and render one image.

Same look, dramatically cheaper.
Zoomed in: render only what’s visible, in 256×256px tiles

I issue render requests only for the region currently on screen.
Keep the main thread free: heavy rendering runs on a background thread

So pan/zoom stays responsive.

Result: the mosaic scrolls/zooms smoothly even at large sizes.

Color matching: RGB → Lab

Mosaic quality is mostly about color matching.

I first tried RGB distance, but it often chose tiles that were numerically close yet visually off.

RGB isn’t perceptually uniform.

Switching to Lab color space improved matches immediately:

Convert each photo’s average color RGB → Lab
For each grid cell, pick the tile with the smallest Euclidean distance in Lab

Simple change, big visual improvement.

Optional: Color grading when your photo set lacks colors

Sometimes your selected photos don’t cover the target’s color palette.

So I added an optional “color grading overlay”:

overlay the target’s hue + saturation
keep the tiles’ luminance (so the photo texture stays)

It’s subtle when your set already has enough color, but helpful when it doesn’t:

Speed tricks that mattered

Two practical optimizations made generation fast enough for real use:

Parallelize photo analysis (average color computation)
Downsample for analysis (I use ~40×40px instead of full-res)

Even if photos are several MB, the color info needed for matching is captured at small size—saving both memory and time.

What I want to improve next

Reduce repeated use of the same tile photo (more even distribution)

That's it!

If you try it, I’d love feedback—especially on export quality and performance on older devices.

App Link: https://apps.apple.com/us/app/mozary/id6759013945

Hosting Applications with AWS CDK: An Introduction to Infrastructure as Code

Yuiko Koyanagi — Wed, 16 Oct 2024 10:18:27 +0000

Introduction

Until now, I have been manually building the infrastructure for my applications. This time, I challenged myself to manage the infrastructure using Infrastructure as Code (IaC).

By utilizing AWS CDK, I was able to codify complex infrastructure settings, manage them simply, and enable efficient deployments. In this article, I will introduce how to host an application using IaC with AWS CDK.

Overview of the Application Architecture

The application I created this time has the following structure. I designed it to efficiently run both the frontend and backend using Docker images on AWS.

Frontend: React + TypeScript
Backend: NestJS + TypeScript Below is a diagram of the application's architecture:

Infrastructure Design

First, I needed to create a secure network configuration using a VPC (Virtual Private Cloud). Therefore, I set up public and private subnets within the VPC.

I placed an ALB (Application Load Balancer) in the public subnet and the backend and frontend servers managed by ECS (Elastic Container Service) Fargate in the private subnet. This ensures that the servers are not directly exposed to the outside, enhancing security.

Users can access the application via the Internet Gateway. Access is received through the ALB placed in the public subnet. The ALB is designed to route requests to the appropriate services and perform load balancing.

For the database, I decided to use DynamoDB to store data. The ECS tasks in the private subnet are configured to access DynamoDB via VPC endpoints. This allows communication with DynamoDB without going through the internet, improving communication security and performance.

The Docker images used by the servers are stored in ECR (Elastic Container Registry). ECS uses these images to run the application. Additionally, by obtaining images from S3 and ECR via VPC endpoints, it is possible to use resources within the private network.

Implementation

Next, I will translate the above infrastructure design into code.

Setup

First, set up the authentication information using AWS CLI:

aws configure

Then, proceed with the CDK setup:

npm install -g aws-cdk
mkdir cdk && cd cdk  # Create a directory of your choice and move into it
cdk init app --language typescript
cdk bootstrap aws://${AWS_ACCOUNT_ID}/${AWS_REGION_NAME}

This automatically generates the files necessary for CDK settings.

Prepare Docker images for both the frontend and backend and store them in ECR.

Writing the CDK Content

Modify cdk-stack.ts Since the CdkStack class is already created, write the above design into its constructor. I want to create various environments such as testing and production, so I add environment as an argument to the constructor for future use.

export class CdkStack extends cdk.Stack {
  constructor(
    scope: Construct,
    id: string,
    environment: string, // Added
    props?: cdk.StackProps
  ) {

This CdkStack class is called in cdk.ts, so modify the code in cdk.ts to make environment usable:

#!/usr/bin/env node
import * as cdk from "aws-cdk-lib";
import "source-map-support/register";
import { CdkStack } from "../lib/cdk-stack";

const app = new cdk.App();
const environment = app.node.tryGetContext("env"); // Obtain from command line during deployment
new CdkStack(app, `${environment}CdkStack`, environment);
app.synth();

From here, write the content inside the constructor of the CdkStack class in cdk-stack.ts.

First, create a VPC. Since we need private and public subnets this time, write as follows:

const vpc = new ec2.Vpc(this, `${environment}AppVpc`, {
  vpcName: `${environment}AppVpc`,
  maxAzs: 2,
  natGateways: 1,
  subnetConfiguration: [
    {
      name: `${environment}AppPublicSubnet`,
      subnetType: ec2.SubnetType.PUBLIC,
      cidrMask: 24,
    },
    {
      name: `${environment}AppPrivateSubnet`,
      subnetType: ec2.SubnetType.PRIVATE_ISOLATED,
      cidrMask: 24,
    },
  ],
});

Regarding the Internet Gateway, since we are creating a public subnet, it is automatically created even though it is not explicitly mentioned in the code.

Next, create VPC endpoints that the private subnet will use:

// VPC Endpoint for DynamoDB
vpc.addGatewayEndpoint(`${environment}DynamoDbEndpoint`, {
  service: ec2.InterfaceVpcEndpointAwsService.DYNAMODB,
});

// VPC Endpoint for S3 (necessary for obtaining Docker images)
vpc.addGatewayEndpoint(`${environment}S3Endpoint`, {
  service: ec2.GatewayVpcEndpointAwsService.S3,
});

// VPC Endpoint for ECR (endpoint to send requests)
vpc.addInterfaceEndpoint(`${environment}EcrApiEndpoint`, {
  service: ec2.InterfaceVpcEndpointAwsService.ECR,
  subnets: { subnetType: ec2.SubnetType.PRIVATE_ISOLATED },
});

// VPC Endpoint for ECR Docker (endpoint to obtain Docker images)
vpc.addInterfaceEndpoint(`${environment}EcrDockerEndpoint`, {
  service: ec2.InterfaceVpcEndpointAwsService.ECR_DOCKER,
  subnets: { subnetType: ec2.SubnetType.PRIVATE_ISOLATED },
});

// VPC Endpoint for CloudWatch Logs (for logging)
vpc.addInterfaceEndpoint(`${environment}CloudWatchLogsEndpoint`, {
  service: ec2.InterfaceVpcEndpointAwsService.CLOUDWATCH_LOGS,
  subnets: { subnetType: ec2.SubnetType.PRIVATE_ISOLATED },
});

All connections are with the private subnet, but for DynamoDB and S3, we can use addGatewayEndpoint (gateway-type endpoints), so specifying the subnet is unnecessary.

Next, create ECS, which is necessary for container management:

const cluster = new ecs.Cluster(this, `${environment}AppCluster`, {
  clusterName: `${environment}AppCluster`,
  vpc: vpc,
});

Create an IAM role for Fargate to use:

const taskExecutionRole = new iam.Role(
  this,
  `${environment}TaskExecutionRole`,
  {
    // Ensure only ECS tasks can assume this role
    assumedBy: new iam.ServicePrincipal("ecs-tasks.amazonaws.com"),
  }
);

// Attach necessary access permissions
taskExecutionRole.addManagedPolicy(
  iam.ManagedPolicy.fromAwsManagedPolicyName(
    "service-role/AmazonECSTaskExecutionRolePolicy"
  )
);

Create a Fargate task definition for the frontend:

const frontendTaskDef = new ecs.FargateTaskDefinition(
  this,
  `${environment}AppFrontendTaskDef`,
  {
    family: `${environment}AppFrontendTaskDef`,
    memoryLimitMiB: 512,
    cpu: 256,
    executionRole: taskExecutionRole,
  }
);

Since we are using ECR, specify the image repository for the frontend (unnecessary if using Docker Hub):

const frontendRepository = ecr.Repository.fromRepositoryName(
  this,
  `${environment}frontendRepository`,
  "app-react-nginx-image"
);

Add container information to the task definition created above. This time, we specify the image repository:

const frontendContainer = frontendTaskDef.addContainer(
  `${environment}AppFrontendContainer`,
  {
    containerName: `${environment}AppFrontendContainer`,
    image: ecs.ContainerImage.fromEcrRepository(
      frontendRepository,
      "latest"
    ),
    logging: new ecs.AwsLogDriver({
      streamPrefix: "Frontend", // Prefix for logging
    }),
  }
);

frontendContainer.addPortMappings({
  containerPort: 80,
  protocol: ecs.Protocol.TCP,
});

The containerPort refers to the port for access from the ALB to Fargate, so it can remain as 80 regardless of whether the app itself is hosted with HTTPS.

Next, launch a Fargate service for the frontend server:

const frontendService = new ecs.FargateService(
  this,
  `${environment}AppFrontendService`,
  {
    serviceName: `${environment}AppFrontendService`,
    cluster: cluster,
    taskDefinition: frontendTaskDef,
    assignPublicIp: false,
    vpcSubnets: {
      subnetType: ec2.SubnetType.PRIVATE_ISOLATED,
    },
  }
);

// Configure auto-scaling
const scalingFrontend = frontendService.autoScaleTaskCount({
  minCapacity: 1,
  maxCapacity: 5,
});

// Auto-scale when CPU utilization exceeds 50%
scalingFrontend.scaleOnCpuUtilization("CpuScalingFrontend", {
  targetUtilizationPercent: 50,
});

// Auto-scale when memory utilization exceeds 70%
scalingFrontend.scaleOnMemoryUtilization("MemoryScalingFrontend", {
  targetUtilizationPercent: 70,
});

With this, the settings for the frontend server are complete. Next, proceed to set up the backend server. Since it is almost the same as the frontend server, explanations will be brief.

const backendTaskDef = new ecs.FargateTaskDefinition(
  this,
  `${environment}AppBackendTaskDef`,
  {
    family: `${environment}AppBackendTaskDef`,
    memoryLimitMiB: 512,
    cpu: 256,
    executionRole: taskExecutionRole,
  }
);

const backendRepository = ecr.Repository.fromRepositoryName(
  this,
  `${environment}backendRepository`,
  "app-nestjs-image"
);

const backendContainer = backendTaskDef.addContainer(
  `${environment}AppBackendContainer`,
  {
    containerName: `${environment}AppBackendContainer`,
    image: ecs.ContainerImage.fromEcrRepository(
      backendRepository,
      "latest"
    ),
    logging: new ecs.AwsLogDriver({
      streamPrefix: "Backend",
    }),
  }
);

backendContainer.addPortMappings({
  containerPort: 3000,
  protocol: ecs.Protocol.TCP,
});

const backendService = new ecs.FargateService(
  this,
  `${environment}AppBackendService`,
  {
    serviceName: `${environment}AppBackendService`,
    cluster: cluster,
    taskDefinition: backendTaskDef,
    assignPublicIp: false,
    vpcSubnets: {
      subnetType: ec2.SubnetType.PRIVATE_ISOLATED,
    },
  }
);

const scalingBackend = backendService.autoScaleTaskCount({
  minCapacity: 1,
  maxCapacity: 5,
});

scalingBackend.scaleOnCpuUtilization("CpuScalingBackend", {
  targetUtilizationPercent: 60,
});

scalingBackend.scaleOnMemoryUtilization("MemoryScalingBackend", {
  targetUtilizationPercent: 75,
});

Next, create the ALB:

const loadBalancer = new elbv2.ApplicationLoadBalancer(
  this,
  `${environment}AppApplicationLoadBalancer`,
  {
    vpc,
    loadBalancerName: `${environment}AppApplicationLoadBalancer`,
    internetFacing: true,
  }
);

Connect the ALB to resources in the private subnet:

const FrontendTargetGroup = new elbv2.ApplicationTargetGroup(
  this,
  `${environment}AppFrontendTG`,
  {
    targetGroupName: `${environment}AppFrontendTG`,
    vpc,
    port: 80,
    protocol: elbv2.ApplicationProtocol.HTTP,
    targets: [frontendService],
    healthCheck: {
      path: "/",
    },
  }
);

const backendTargetGroup = new elbv2.ApplicationTargetGroup(
  this,
  `${environment}AppBackendTG`,
  {
    targetGroupName: `${environment}AppBackendTG`,
    vpc,
    port: 3000,
    protocol: elbv2.ApplicationProtocol.HTTP,
    targets: [backendService],
    healthCheck: {
      path: "/v1/health", // Specify the API for health checks
    },
  }
);

Describe the ALB's request handling:

const listener = loadBalancer.addListener(`${environment}HttpListener`, {
  port: 80,
  open: true,
  defaultAction: elbv2.ListenerAction.forward([FrontendTargetGroup]),
});

listener.addTargetGroups(`${environment}BackendTargetGroups`, {
  targetGroups: [backendTargetGroup],
  priority: 1,
  conditions: [elbv2.ListenerCondition.pathPatterns(["/v1/*"])],
});

This time, we are using a single ALB to distribute traffic to the frontend and backend. By default, requests are forwarded to the frontend, but if there is access with /v1, it is set to forward to the backend Fargate. If you are using two ALBs, the addTargetGroups configuration is unnecessary.

Finally, create the necessary DynamoDB table. In DynamoDB, only the PartitionKey is mandatory, but you can include SortKey, Index, and TTL as needed.

const usersTable = new dynamodb.Table(this, `${environment}UsersTable`, {
  tableName: `${environment}-users`,
  partitionKey: {
    name: "account_id",
    type: dynamodb.AttributeType.STRING,
  },
});
usersTable.grantReadWriteData(backendTaskDef.taskRole);

Now that we have written the code necessary for IaC, we just need to execute and verify it.

Execution

First, check for syntax errors in the CDK code above:

cdk synth --context env=dev

If there are errors, they will appear as follows, so fix them as needed:

Error: Validation failed with the following errors:
  [undefinedCdkStack/undefinedAppFrontendTargetGroup] Target group name: "undefinedAppFrontendTargetGroup" can have a maximum of 32 characters.
  [undefinedCdkStack/undefinedAppBackendTargetGroup] Target group name: "undefinedAppBackendTargetGroup" can have a maximum of 32 characters.

If you can execute without errors, proceed to deploy. If the Docker image is not functioning properly, Fargate will repeatedly start up, encounter errors, shut down, and restart. If it is taking an excessive amount of time, please check the AWS Management Console.

cdk deploy --context env=dev

With this, hosting the application using IaC is complete.

Conclusion

This was my first attempt at IaC, and by managing the infrastructure as code, I found it very beneficial to build infrastructure for multiple environments such as production and development without human errors.

If this article was helpful in any way, I would be encouraged if you could press the like button! Thank you for reading to the end.

How to Automatically Adjust Colors in High Contrast Mode

Yuiko Koyanagi — Thu, 22 Aug 2024 14:10:05 +0000

Introduction

I recently received a bug report where an SVG icon was not displaying correctly in high contrast mode. In this article, I’ll share the solution that worked for me.

Solution

In high contrast mode, I used the CanvasText system color to automatically adjust the icon's color.

.icon {
  mask-image: url(svg-link);
  background-color: currentColor;
  ...
}

@media (forced-colors: active) {
  .icon::before {
    background-color: CanvasText;
  }
}

In my case, I initially used currentColor to inherit the color from the parent element. However, in high contrast mode, I wanted to set the background-color to CanvasText universally within the child element, so I applied this change.

What is CanvasText?

CanvasText refers to the text color used for application content or documents. It automatically adjusts to provide the best contrast against the system's background color.

By using CanvasText, you ensure that text and icons remain visible even when the user enables high contrast mode. Additionally, since CanvasText adapts based on the system's theme, it works well with both dark and light modes.

In my case, the icon's background-color was initially set to black. However, when the background turned black in high contrast mode, the icon became invisible. Changing the color to white made it visible again, but to handle this consistently across all scenarios, I opted to use the system color CanvasText.

References

https://developer.mozilla.org/en-US/docs/Web/CSS/system-color

OpenAI: AI reviews your code automatically!

Yuiko Koyanagi — Thu, 22 Dec 2022 09:07:51 +0000

Hi there!

Have you ever felt that reviews are a hassle?

I have launched an app which automatically reviews your code with using OpenAI, AI Code Reviewer!

[Note] I sold this Application and the owner is not me anymore.

I took first place in the Product hunt 🎉🎉🎉

https://www.producthunt.com/posts/ai-code-reviewer

How to use

It's very easy.
Just paste the code you would like reviewed and press the button.

For example, I purposely paste the wrong code which has type mistakes and have it reviewed: const [count, setCount] = useState<string>(0);

Good! AI said, "The code is missing a type annotation for the count variable. The type should be set to number instead of string. ".

Also try to have a Python code reviewed!.
Here is the code that I forgot to add the colon.

def hello()
  print('hello')

The reviews is:

This code has a syntax error. The print statement should be indented so that it is part of the hello() function. The correct code should look like this:

def hello(): print('hello')

Good! Yes, this code has a syntax error and now you got a good review.

Like that, AI Code Reviewer helps you write the right code.

If you have any questions, you can also ask AI Chat Bot.
Try to ask about useEffect.

I asked, "How should I use useEffect? What should I watch out for?", and AI answered, "Using useEffect can be tricky, so it's important to understand when and how to use it properly. You should consider the following: when you use useEffect, the function you pass to it will be called after the render is committed to the screen, which can lead to unexpected behavior if you're not careful. Additionally, useEffect runs after every render, so you should be mindful of how often you're running the effect and the impact it could have on performance. Finally, you should be aware of any potential side-effects that could be caused by your useEffect code."

Looks good!
You can ask anything to AI.

Check it out at: https://ai-code-reviewer.com
Youtube DEMO: https://youtu.be/V7K4IZV_k-E

How this application is structured

It consists of the following

Next.js
Chakra UI
TypeScript
OpenAI
Vercel

I started out using React, but switched to Next.js after reading the following section of the documentation.

Important note: When using Javascript, all API calls should be made on the server-side only, since making calls in client-side browser code will expose your API key. See here for more details.

As for OpenAI, I was able to set it up easily because the official site shows us a sample repository of setups written in Next.js.

https://github.com/openai/openai-quickstart-node

All you have to do is create an API using Next.js API Routes and hit it, as shown in the official sample code below.

import { Configuration, OpenAIApi } from "openai";

const configuration = new Configuration({
  apiKey: process.env.OPENAI_API_KEY,
});
const openai = new OpenAIApi(configuration);

export default async function (req, res) {
  const completion = await openai.createCompletion({
    model: "text-davinci-002",
    prompt: generatePrompt(req.body.animal),
    temperature: 0.6,
  });
  res.status(200).json({ result: completion.data.choices[0].text });
}

function generatePrompt(animal) {
  const capitalizedAnimal =
    animal[0].toUpperCase() + animal.slice(1).toLowerCase();
  return `Suggest three names for an animal that is a superhero.
Animal: Cat
Names: Captain Sharpclaw, Agent Fluffball, The Incredible Feline
Animal: Dog
Names: Ruff the Protector, Wonder Canine, Sir Barks-a-Lot
Animal: ${capitalizedAnimal}
Names:`;
}

You can try it!

That's it!

Thanks for reading.
This is my first time to use OpenAI, and I am happy to develop this app :D

Please send me a message if you need.

yuiko.dev@gmail.com
https://twitter.com/toffy_dev

If you think this article is useful, please buy me a coffee :)
https://www.buymeacoffee.com/yuikoito

Thank you!

Making eyes bigger in images with Amazon Rekognition and OpenCV

Yuiko Koyanagi — Tue, 28 Dec 2021 12:31:12 +0000

Hey guys, I have developed an application with Amazon Rekognition and OpenCV, that makes your eyes bigger in an image.

In this article, I will explain how to develop this application.

DEMO→https://eyedol.vercel.app/
github→https://github.com/yuikoito/eyedol

How to use

All you have to do is upload the image you want to make the eyes bigger and choose how big you want your eyes to be.
If you don't set it lower than "much" it will look very strange, so I don't recommend it.

If you choose "a little" or "some" you'll get a much better result.

Technology used

Frontend
- Next.js + TypeScript
- Chakra UI
Backend
- Python
- OpenCV
- Amazon Rekognition
Infrastructure
- AWS

The way to implement this is to use Amazon Rekognition to check where the eyes are, then use OpenCV to cut them out, expand them, composite them, and finally blur the boundaries.

So if you're looking sideways or wearing glasses, I don't think it will work very well.

This was the first time I used Amazon Rekognition, and it was easy to use.
However, the fee is much higher than I expected, so I added a Buy Me a Coffee link at the bottom right of the app.
link at the bottom right of the app.
If you can afford it, please buy me a coffee🙏.

I thought the same thing could be done with TensorFlow, so I'll try it with TensorFlow next time.

In order to make it as natural as possible, I adjusted the position of the eyes so that they were cropped as close to the edge as possible, and I also struggled a bit with the part where I blurred the border.

Implementation details

The implementation details are as follows

Recognize eyes with Amazon Rekognition
Crop the image using OpenCV, enlarge it, and composite it.
Blur the boundary to make it look natural after merging.

Recognize eyes with Amazon Rekognition

The code for detecting the location of the eyes is as follows.

import cv2
import boto3
from botocore.config import Config

config = Config(
   retries = {
      'max_attempts': 10,
      'mode': 'standard'
   }
)

def rekog_eye(im):
    #post amazon_rekognition
    client = boto3.client('rekognition','ap-northeast-1',config=config)
    result, buf = cv2.imencode('.jpg', im)

    #get face information by rekognition_image
    faces = client.detect_faces(Image={'Bytes':buf.tobytes()}, Attributes=['ALL'])

    leftEyeLeft = faces['FaceDetails'][0]['Landmarks'][11]
    leftEyeRight = faces['FaceDetails'][0]['Landmarks'][12]
    leftEyeUp = faces['FaceDetails'][0]['Landmarks'][13]
    leftEyeDown = faces['FaceDetails'][0]['Landmarks'][14]
    rightEyeLeft = faces['FaceDetails'][0]['Landmarks'][15]
    rightEyeRight = faces['FaceDetails'][0]['Landmarks'][16]
    rightEyeUp = faces['FaceDetails'][0]['Landmarks'][17]
    rightEyeDown = faces['FaceDetails'][0]['Landmarks'][18]
    EyeList = [leftEyeLeft, leftEyeRight, leftEyeUp, leftEyeDown, rightEyeLeft, rightEyeRight, rightEyeUp, rightEyeDown]

    EyePoints = {}
    h, w, ch = im.shape
    for eyepoint in EyeList:
        EyePoints[eyepoint['Type']] = {'X': int(eyepoint['X']*w), 'Y': int(eyepoint['Y']*h)}

    return EyePoints

I used boto3, a library that makes it easy to use various AWS services.
Then create a boto3 client and specify the service to be used (in this case, rekognition) and select the region.
In config, I specify how many times I want to try. In this case, the number is 10, so even if Rekognition doesn't work properly on the first try due to server error or network error, it will try again on the second try, and so on up to 10 times.

client = boto3.client('rekognition','ap-northeast-1',config=config)

Then, post the image byte sequence to the detection_faces of rekognition to detect the face.

faces = client.detect_faces(Image={'Bytes':buf.tobytes()}, Attributes=['ALL'])

Name the necessary landmarks in a way that makes them easy to use.
For example, the left edge of the left eye is called leftEyeLeft, and the right edge of the left eye is called leftEyeRight here.
Since I want to cut and spread the image at the very edge, I detect four points for each eye.

The detected locations are put into an array for easier use.

EyeList = [leftEyeLeft, leftEyeRight, leftEyeUp, leftEyeDown, rightEyeLeft, rightEyeRight, rightEyeUp, rightEyeDown]

Finally return them.

    EyePoints = {}
    h, w, ch = im.shape
    for eyepoint in EyeList:
        EyePoints[eyepoint['Type']] = {'X': int(eyepoint['X']*w), 'Y': int(eyepoint['Y']*h)}

Crop the image using OpenCV, enlarge it, and composite it

First, prepare functions to convert images from base64 to cv2 and vice versa.

import numpy as np
import base64

def base64_to_cv2(image_base64):
    """base64 image to cv2"""
    image_bytes = base64.b64decode(image_base64)
    np_array = np.fromstring(image_bytes, np.uint8)
    image_cv2 = cv2.imdecode(np_array, cv2.IMREAD_COLOR)
    return image_cv2


def cv2_to_base64(image_cv2):
    """cv2 image to base64"""
    image_bytes = cv2.imencode('.jpg', image_cv2)[1].tostring()
    image_base64 = base64.b64encode(image_bytes).decode()
    return image_base64

The code for cutting and merging is as follows.

def handler(event, context):
    ##############Extracting the request body from the request payload############
    # convert event['body'] to dict
    try:
        base_64ed_image = event.get('myimg', 'none')
        magnification = float(event.get('magni', 1.4)
        blur_num = int(event.get('blur', 3)) ##for blur
        im = base64_to_cv2(base_64ed_image)
        EyePoints = rekog_eye(im)
        bityouseix = 20
        bityouseiy = 5
        leftTop = min([EyePoints['leftEyeUp']['Y'], EyePoints['leftEyeDown']['Y'], EyePoints['leftEyeRight']['Y'], EyePoints['leftEyeLeft']['Y']])
        leftBottom = max([EyePoints['leftEyeUp']['Y'], EyePoints['leftEyeDown']['Y'], EyePoints['leftEyeRight']['Y'], EyePoints['leftEyeLeft']['Y']])
        leftRight = max([EyePoints['leftEyeUp']['X'], EyePoints['leftEyeDown']['X'], EyePoints['leftEyeRight']['X'], EyePoints['leftEyeLeft']['X']])
        leftLeft = min([EyePoints['leftEyeUp']['X'], EyePoints['leftEyeDown']['X'], EyePoints['leftEyeRight']['X'], EyePoints['leftEyeLeft']['X']])
        rightTop = min([EyePoints['rightEyeUp']['Y'], EyePoints['rightEyeDown']['Y'], EyePoints['rightEyeRight']['Y'], EyePoints['rightEyeLeft']['Y']])
        rightBottom = max([EyePoints['rightEyeUp']['Y'], EyePoints['rightEyeDown']['Y'], EyePoints['rightEyeRight']['Y'], EyePoints['rightEyeLeft']['Y']])
        rightRight = max([EyePoints['rightEyeUp']['X'], EyePoints['rightEyeDown']['X'], EyePoints['rightEyeRight']['X'], EyePoints['rightEyeLeft']['X']])
        rightLeft = min([EyePoints['rightEyeUp']['X'], EyePoints['rightEyeDown']['X'], EyePoints['rightEyeRight']['X'], EyePoints['rightEyeLeft']['X']])

        leftEye = im[leftTop:leftBottom+bityouseiy, leftLeft-bityouseix:leftRight+bityouseix]
        leftEye = cv2.resize(leftEye, (leftEye.shape[1], int(leftEye.shape[0]*magnification)))
        rightEye = im[rightTop:rightBottom+bityouseiy, rightLeft-bityouseix:rightRight+bityouseix]
        rightEye = cv2.resize(rightEye, (rightEye.shape[1], int(rightEye.shape[0]*magnification)))

        im[leftTop:leftTop+leftEye.shape[0], leftLeft-bityouseix:leftLeft+leftEye.shape[1]-bityouseix] = leftEye
        im[rightTop:rightTop+rightEye.shape[0], rightLeft-bityouseix:rightLeft+rightEye.shape[1]-bityouseix] = rightEye


        return {'status':200, 'message':'OK', 'img': cv2_to_base64(im)}
    except Exception as e:
        return {'status':500, 'message':str(e)}

In the following section, the coordinates for cropping are calculated again.
The Y-coordinate of EyeUp is not directly used as the Top because it takes into account the case where the eye is slanted.
(However, since it is just stretched vertically after cropping, it will be distorted.)

So, if necessary, I think it would be more natural to stretch the image diagonally when the right side is the maximum value, but since this is a crappy application, I didn't go this far.

        leftTop = min([EyePoints['leftEyeUp']['Y'], EyePoints['leftEyeDown']['Y'], EyePoints['leftEyeRight']['Y'], EyePoints['leftEyeLeft']['Y']])
        leftBottom = max([EyePoints['leftEyeUp']['Y'], EyePoints['leftEyeDown']['Y'], EyePoints['leftEyeRight']['Y'], EyePoints['leftEyeLeft']['Y']])
        leftRight = max([EyePoints['leftEyeUp']['X'], EyePoints['leftEyeDown']['X'], EyePoints['leftEyeRight']['X'], EyePoints['leftEyeLeft']['X']])
        leftLeft = min([EyePoints['leftEyeUp']['X'], EyePoints['leftEyeDown']['X'], EyePoints['leftEyeRight']['X'], EyePoints['leftEyeLeft']['X']])
        rightTop = min([EyePoints['rightEyeUp']['Y'], EyePoints['rightEyeDown']['Y'], EyePoints['rightEyeRight']['Y'], EyePoints['rightEyeLeft']['Y']])
        rightBottom = max([EyePoints['rightEyeUp']['Y'], EyePoints['rightEyeDown']['Y'], EyePoints['rightEyeRight']['Y'], EyePoints['rightEyeLeft']['Y']])
        rightRight = max([EyePoints['rightEyeUp']['X'], EyePoints['rightEyeDown']['X'], EyePoints['rightEyeRight']['X'], EyePoints['rightEyeLeft']['X']])
        rightLeft = min([EyePoints['rightEyeUp']['X'], EyePoints['rightEyeDown']['X'], EyePoints['rightEyeRight']['X'], EyePoints['rightEyeLeft']['X']])

Then cut it out according to its coordinates.

        leftEye = im[leftTop:leftBottom+bityouseiy, leftLeft-bityouseix:leftRight+bityouseix]
        rightEye = im[rightTop:rightBottom+bityouseiy, rightLeft-bityouseix:rightRight+bityouseix]

Resize the cropped left eye and right eye.

        leftEye = cv2.resize(leftEye, (leftEye.shape[1], int(leftEye.shape[0]*magnification)))
        rightEye = cv2.resize(rightEye, (rightEye.shape[1], int(rightEye.shape[0]*magnification)))

Then synthesize it.

        im[leftTop:leftTop+leftEye.shape[0], leftLeft-bityouseix:leftLeft+leftEye.shape[1]-bityouseix] = leftEye
        im[rightTop:rightTop+rightEye.shape[0], rightLeft-bityouseix:rightLeft+rightEye.shape[1]-bityouseix] = rightEye

Blur the boundary to make it look natural after merging

To blur the boundaries, I used OpenCV's Gaussian filter.

Reference:

http://labs.eecs.tottori-u.ac.jp/sd/Member/oyamada/OpenCV/html/py_tutorials/py_imgproc/py_filtering/py_filtering.html

Specify the blur area (image), kernel size, and standard deviation.

def mosaic_area(src, x, y, width, height, blur_num):
    dst = src.copy()
    for i in range(blur_num):
        dst[y:y + height, x:x + width] = cv2.GaussianBlur(dst[y:y + height, x:x + width], (3,3),3)
    return dst

By the way, I wanted to control how much blur is applied from the client side, so I used blur_num to specify how many times this blur should be applied.

Then, incorporate the above function in the handler function above.

            im = mosaic_area(im, leftLeft-bityouseix-int(bityouseix/2), leftTop, bityouseix, leftEye.shape[0]+bityouseiy, blur_num)
            im = mosaic_area(im, leftRight+int(bityouseix/2), leftTop, bityouseix, leftEye.shape[0]+bityouseiy, blur_num)
            im = mosaic_area(im, leftLeft-bityouseix, leftTop+leftEye.shape[0]-int(bityouseiy/2), leftEye.shape[1], bityouseiy, blur_num)
            im = mosaic_area(im, rightLeft-bityouseix-int(bityouseix/2), rightTop, bityouseix, rightEye.shape[0]+bityouseiy, blur_num)
            im = mosaic_area(im, rightRight+int(bityouseix/2), rightTop, bityouseix, rightEye.shape[0]+bityouseiy, blur_num)
            im = mosaic_area(im, rightLeft-bityouseix, rightTop+rightEye.shape[0]-int(bityouseiy/2), rightEye.shape[1], bityouseiy, blur_num)

In this case, there is no need to blur the upper part of the eye because nothing has been changed, but the left, right, and lower parts of the eye have been widened and composited so that the boundaries are visible. Since we are performing blurring at each boundary, we are using the blur filter 6 times above to blur the (left, right, bottom) x both eye parts.

After deploying this to Lambda, you can use APIGateway to make it into an API and you are done.
There is a little trick to using OpenCV in Lambda, so if you need it, please read this.

That's it!

Then finish!

Thanks for reading.
This is my first time to use Amazon Rekognition, and I am happy to make such a funny API :D

Please send me a message if you need.

yuiko.dev@gmail.com
https://twitter.com/yui_active

If you think this article is useful, please buy me a coffee :)
https://www.buymeacoffee.com/yuikoito

I made an app to enjoy Halloween🎃🦇🕸

Yuiko Koyanagi — Mon, 01 Nov 2021 19:00:22 +0000

Hey guys,

It was Halloween day, but in this self-restraint mode, it's hard to go out and enjoy dressing up in costumes.
So I made an app that lets you enjoy Halloween online!

Halloween has already passed, but you can even enjoy this app!

URL: https://ohmyface.ai/

How to use

The usage is as shown in the following slide.

First, when you visit to https://ohmyface.ai/, you can choose a favorite style from this week's popularity ranking or the overall ranking.

This ranking is based on the number of styles converted, and is updated daily at 9pm (JTC).

Once you have selected a style, all you have to do is just upload the image you want!
The loading process will run automatically and the image will be converted.

Don't worry, the uploaded images are not retained by the server.

Composition

The configuration is as follows.

Backend...python
Infrastructure...AWS (API gateway, Lambda, dynamo DB, s3)
Frontend...Next.js + TypeScript + Chakra UI

In order to develop the ranking, I created an API to post which style the image was converted in, along with a timestamp, then store the data in dynamo.

In order to aggregate the data, I create a Lambda function that returns the style data sorted by the number of conversions, and save the results in another table in dynamo.
That Lambda function is run once a day by EventBridge.

Then, I also created an API to access the dynamo table where the aggregate results are stored and retrieve the data, and call it from the client side to display the ranking order.

For the frontend, I used the usual Next.js + TypeScript, but this time I used Chakra UI for the first time.
It was very easy to use, and I'll use again for sure!

That's it!

Halloween is over, but I think it's an app that can be enjoyed even after Halloween, so I'd be happy if you could play it!

Contact

Please send me a message if you need.

yuiko.dev@gmail.com
https://twitter.com/toffy_dev

DEV Community: Yuiko Koyanagi

How I export 1.2-gigapixel images on an iPhone without running out of memory

TL;DR

The problem: "compressed file size" is a lie about memory

The naive way (what I had before)

The fix: put the canvas on disk, not in RAM

What mmap actually buys you

Step 1 — create the file and map it

Step 2 — hand the mapping to CGContext

Step 3 — nudge finished rows out to disk

The other trap: makeImage() copies everything

Bonus win: decode tiles at draw size, not full size

Spending disk means guarding disk

Results

Takeaways

Try it out!

Want to keep using Fable 5? Teach Opus and Sonnet to "behave" like it.

Use Fable 5 where it pays for itself

The gap between Fable 5 and Opus/Sonnet is not intelligence

"Be careful" prompts don't work

I documented Fable 5's working method along five axes

1. Fix the work routine

2. Define the failure patterns and their fixes

3. Define the decision branches

4. Define the verification method

5. Absorb failures one at a time with a learning loop

Making sure it actually reaches the subagents

1. Embed it in the agent definitions

2. Embed it at delegation time

Sounds like a lot of setup, right?

Afterword

Use Fable 5 where it pays for itself

Make Fable 5 the lead, not the labor

The hard part is the subagents

ccteams: install the team design in one command

The models are already assigned

Adding Codex as the peer engineer

Back to "add rate limiting"

In short

React Native team and django team are available now!

One command turns Claude Code into a full dev team

I built a Chrome extension that lets you blow up any webpage

1. Turning page text into something you can blow up

2. The blast: a little bit of fake physics

3. The bug that annoyed me for years: clicks getting eaten

Keeping it well-behaved

Try it

One command turns Claude Code into a full dev team

What's a "team"?

What use actually does

The one catch: restart

Optional: do it from inside Claude Code

Power users: parallel teammates

Try it

I built “Mozary”: An iOS App That Turns Your Photos Into a Zoomable Mosaic

#buildinpublic #mobileapp #computervision #imageprocessing #productdevelopment | Yuiko Koyanagi

The idea (why I built it)

How it works (user flow)

The engineering part: making the viewer buttery smooth

Borrowing an idea from Google Maps: LOD (Level of Detail)

Color matching: RGB → Lab

Optional: Color grading when your photo set lacks colors

Speed tricks that mattered

What I want to improve next

That's it!

Hosting Applications with AWS CDK: An Introduction to Infrastructure as Code

Introduction

Overview of the Application Architecture

Infrastructure Design

Implementation

Setup

Writing the CDK Content

Execution

Conclusion

How to Automatically Adjust Colors in High Contrast Mode

Introduction

Solution

What is CanvasText?

References

OpenAI: AI reviews your code automatically!

What `mmap` actually buys you

Step 2 — hand the mapping to `CGContext`

The other trap: `makeImage()` copies everything

What `use` actually does