DEV Community: Serhii Kalyna

How I recorded my first product demo in 54 seconds (OBS, ffmpeg, openai.fm)

Serhii Kalyna — Sun, 23 Aug 2026 04:59:37 +0000

I shipped my first product demo video this week for Convertify (my free image converter). 54 seconds, no team, no budget. Here is the exact toolchain and what I would change next time.

The stack

OBS Studio for screen recording at 1920x1080, 60fps, CRF 20.

The 60fps is not vanity. Product demos live and die on smooth scroll and cursor motion. 30fps for a converter tool with drag-and-drop looks laggy even when the tool is fast. CRF 20 instead of the default 23 because text on white backgrounds compresses ugly at higher CRF: you get that faint mosaic around letter edges.

Free, open source, deterministic. No mobile screen recording because I needed the desktop browser context (this is a "your iPhone photos on Windows" story).

ffmpeg for trim and crop.

ffmpeg -i raw.mkv -ss 3.2 -to 57.4 \
  -filter:v "crop=1920:1000:0:40" \
  -c:v libx264 -crf 20 -c:a copy trimmed.mp4

CLI over Kdenlive or DaVinci Resolve because I knew the exact cuts. Two ffmpeg commands beat 20 minutes of GUI timeline scrubbing. Crop removed the taskbar and top window chrome without re-encoding twice.

openai.fm for voiceover. Ash voice.

I tested Alloy, Fable, Nova, Ash. Ash landed clearest for technical explanation pacing. Alloy sounded like it was reading a bedtime story, Fable had a slight British lilt that felt wrong for the American tech audience I am targeting, Nova was too energetic.

Hiring a voiceover artist starts at $50 for a one-off and rises fast if you iterate. openai.fm generates in 20 seconds per attempt. I regenerated the voiceover 6 times across script rewrites and it cost nothing.

ffmpeg merge as the last step.

ffmpeg -i trimmed.mp4 -i voiceover.mp3 \
  -c:v copy -c:a aac -shortest final.mp4

Separate audio and video passes. If voiceover timing slips, re-recording audio alone is 30 seconds. Re-recording the screen is 10 minutes plus 3 blown takes.

The script lesson

v1 was 180 words. It opened with "Convertify is a free tool that converts HEIC files to JPG." I wrote it, recorded a test take, listened back, and it was plodding. It sounded like I was describing a product, not solving a problem.

v4 is 118 words. It opens with "Your iPhone saves photos as HEIC format. Windows does not. Neither do most websites, Slack, or Discord."

The pattern that unstuck me: start with the user's pain, not the product name. The product name earns the right to appear once the pain is on screen. In 54 seconds you cannot afford to spend 5 seconds on brand introduction before the viewer knows why they should care.

Four rewrites to arrive at something obvious. That is the honest part.

What I would do differently

Script cursor movements ahead of time. I improvised on takes 1 through 4 and each felt slightly different, which made editing harder. Take 5 with a mental map was noticeably tighter.
Test all voices first, not sequentially. I burned an hour on Alloy before realizing I should have generated one line in each voice on day one.
Record the screen segment before writing the voiceover, not after. I wrote v1 first, then discovered the cursor motion was faster than the words. Rewriting to fit visible pacing was easier than the reverse.

Try it

Convertify is at convertifyapp.net. Free, no signup, no watermarks, batch up to 20 files.

Feedback on the video welcome, especially if you have shipped product demos as a solo dev and hit different tradeoffs.

Week 20 building Convertify: the blog post I did not write

Serhii Kalyna — Thu, 20 Aug 2026 18:59:08 +0000

The temptation

Query cluster around "AVIF vs WebP vs HEIC 2026" is competitive and valuable. My blog id 1 covers it, published months ago, indexed, gets a small trickle of clicks. The obvious move on paper: write a fresh landing page for the head keyword, link internally, watch it rank.

I did not do that.

Why extend instead

Cannibalization. When two pages on the same domain target the same intent, Google splits the ranking signal. Both underperform. A new page also needs its own authority pool, its own indexing wait, its own crawl budget. On a 5-month-old domain still in sandbox, that trade never pays.

The alternative: take the existing post from 8 to 12 sections, 8 to 12 FAQ items, add schema_faq, refresh updated_at, add 12 internal deep-links (10 to spoke pages, 2 cross-links to my benchmark post as data source). Same authority pool concentrated on one page. Fresh timestamp signal. New internal links flowing back to spokes.

Rich Results Test came back clean: 3 valid items, 0 errors.

The safe SQL pattern

Every extension goes through the same transactional shape:

`sql
BEGIN;
UPDATE blogs
SET sections = sections || jsonb_build_object(...),
faq = faq || jsonb_build_array(...),
schema_faq = ...,
read_time = 11,
updated_at = NOW()
WHERE id = 1;

SELECT id, jsonb_array_length(sections), jsonb_array_length(faq), updated_at
FROM blogs WHERE id = 1;

COMMIT;
`

Append-only via ||, zero DELETE statements, verify SELECT before COMMIT. If the row looks wrong I ROLLBACK. In 20 weeks of running this pattern I have not lost a section.

Also this week: closing the "30 MB PNG bug"

Different topic, same theme. Every week for two months I logged "30 MB PNG output on backend" in the carried-bugs list. This week I sat down to fix it and realized there is no bug.

A 24.5 megapixel iPhone Pro photo at full resolution is 4284 by 5712 pixels. Uncompressed RGBA that is 98 MB. PNG deflate on photo content with AI-generated mask edges compresses to about 25 to 35 percent. Output: 25 to 40 MB. That is the honest number. Anything smaller means downscaling the user's photo or silently switching to a lossy format.

I shipped a WebP output toggle two weeks ago for users who want smaller files. That is the correct answer to "I want a smaller file." Silently downscaling PNG is the wrong answer.

Closed the item in my strategy file as [CLOSED: not a bug]. Two months of guilt about a non-issue.

Sandbox exit signals

GSC 3-month rolling: avg pos 52. Last two days baseline: 787 impressions, pos 42. Impressions up 77 percent week over week.

Google positions look worse on paper (52 vs 42) because impressions grew fastest on long-tail queries where I sit deeper. That is expected. The signal I care about is impressions trending up on the same content, meaning Google is testing me on more queries.

Bing meanwhile: 942 impressions, CTR 1.49 percent. Bing has forgiven the young domain. Google is still auditing. The split between the two channels is normal for a 5-month-old site, not a bug in either.

Takeaway

Two decisions this week that looked like avoidance:

Not writing the new blog post
Not "fixing" the 30 MB output

Both were the right call. The scoreboard is starting to agree.

Next week: YouTube demo #1 (HEIC to JPG on iPhone), second Qwoted pitch using the benchmark AI-citation data as unique hook.

Week 19: Cloudflare Email Routing, Wikidata citations, and the benchmark that keeps citing itself

Serhii Kalyna — Sun, 09 Aug 2026 08:24:59 +0000

Trust foundation continues. Real numbers from Bing AI, one 10-minute email setup, and a bug I keep punting.

The scoreboard

Two projects continue in parallel. Convertify shipped an entity foundation over week 18: Wikidata item Q140754389 for the brand, centralized JSON-LD schema graph with @id cross-references, IndexNow integrated into the sitemap generator, and an AI-crawler-explicit robots.txt. Week 19 was about seeing what those signals actually do.

Bing Copilot AI Performance: up 3.1x quarter over quarter. The top grounding query was "latest HEIC file format comparison," 43.24% share. The page Copilot cites is our own image format benchmark, published back in June with real measured numbers from a Rust + libvips pipeline.

That last part is the interesting piece. The content didn't change between July and August. What changed was how readable and verifiable Convertify became as an entity, on paper.

Cloudflare Email Routing was 10 minutes

I needed a serhii@convertifyapp.net for source verification on Qwoted, which is a HARO alternative for journalist requests. Cloudflare Email Routing does exactly this: enable it, add MX + SPF + DKIM records with one click, add destination address, add routing rule, done. Forwarding to my primary inbox in under 30 seconds.

If you own a domain on Cloudflare and don't have a branded email yet, this is a genuinely free 10-minute upgrade. It also matters for pitch credibility. Journalists reading pitches from founder@yoursaas.com respond at a different rate than pitches from random@gmail.com. Whether or not that's fair is a different conversation.

The 30 MB PNG bug I keep punting

Still not fixed. It's a 16-bit alpha channel that doesn't get cast to 8-bit after libvips bandjoin, so background-removal PNGs sometimes leave the server at 30 MB when they should be 2-3 MB. Symptom masked in the browser because the frontend canvas re-encodes to 8-bit as part of a compositing step that isn't even needed for the transparent-background case.

I did close the canvas re-encode issue this week (early return when bg is transparent, skip the useless composite pass). The backend cast is next. It's a two-hour fix that keeps getting bumped by higher-leverage work. That's a reasonable priority call for one week; two weeks in a row it becomes a pattern I don't like.

What I learned about AI search this week

The clearest takeaway from Bing's AI Performance data: measured content beats theoretical content when AI grounding pipelines need a source to cite. Every benchmark I've published quotes real file sizes from actual conversions on the same production pipeline that handles user uploads. Every other image-format article on the internet is quoting codec spec figures, not measurements. Copilot seems to prefer the measurements.

Entity signals amplify this. The Wikidata item and JSON-LD graph don't add new content, they add proof of who is making the claim. That's what changed between May and August, and citation counts moved with it.

None of this generalizes cleanly. Bing is not Google is not ChatGPT is not Perplexity. But the principle probably does: give AI grounding pipelines something concrete and verifiable, tie your identity to it, and see what happens.

Next week

Second benchmark asset covering AVIF vs WebP at real-world quality settings, more journalist pitches, and yes, actually fixing the 30 MB PNG bug.

Building a 600-DPI PDF to JPG converter in Rust: the megapixel clamp that saved production

Serhii Kalyna — Fri, 31 Jul 2026 17:49:02 +0000

If you need to convert PDF to JPG at 600 DPI for print, archival, or high-res extraction, the short answer is: it works, but only if you clamp the output. A 600 DPI conversion on a large PDF page can produce a multi-gigabyte JPG per page. That crashes any server without a memory budget. I hit this in production on Convertify and had to build a fix that stayed close to the user's request while never letting the process explode.

This post walks through the clamp function I wrote in Rust + libvips, the math behind it (spoiler: sqrt), real numbers from production, and where the tradeoffs are. If you just want to use the tool, here's the 600 DPI PDF to JPG converter. Free, no signup, and the clamp described below runs on every request.

Why 600 DPI matters

DPI in "PDF to image" isn't a physical property of the PDF. It's a scaling factor. When you tell libvips to load a PDF page at 600 DPI, you're saying: rasterize this page at 600 pixels per inch of original document dimensions. So the output size depends entirely on how large the PDF thinks it is.

For most cases, 300 DPI is enough. Print, most magazines, high-quality photo output, 300 DPI is the standard. 600 DPI shows up when:

Archival scanning. You want to preserve every detail from the original.
High-quality print on large formats: posters, technical drawings, engineering plans.
OCR on dense layouts. Small fonts and unusual glyphs benefit from higher raster resolution.
Large-format documents. Cartography, blueprints, wide-format schematics. This is where I first hit the problem. These PDFs often have huge native dimensions (24" × 36" or bigger), and at 600 DPI they explode.

If someone types pdf to jpg 600 dpi into a search engine, they usually have one of these needs. And they don't want a tool that silently downgrades to 300 without telling them.

The naive approach (and why it broke)

Loading a PDF page at a given DPI in libvips is one line:

let img = VipsImage::new_from_file(&format!("{file_path}[dpi=600,page={page}]"))?;

That's it. libvips-poppler handles the rendering. On a typical A4 page, you get about a 35 megapixel image, around 8-15 MB as JPG. Fine.

Now paste in a large-format PDF, say a 24" × 36" technical drawing. The same code produces a 300+ megapixel image. As raw pixel data in memory, that's over 1 GB. Encoded as JPG at quality 90, it can still land at 200-400 MB per page. Multi-page PDF at 600 DPI: you're looking at gigabytes of output, often before the user knows what's happening.

Real symptoms I saw in production:

Server OOM kills mid-conversion.
Downloads that started and never finished because the file was too big for the browser to handle.
Users complaining that a "small" PDF produced enormous outputs.

The lazy fix is to cap DPI at 300 globally. But that punishes the honest use case: someone who legitimately wants 600 DPI on a normal-sized PDF gets stuck with a downgrade for the one weird case. So I needed something adaptive.

The megapixel budget

The real constraint isn't DPI. It's output pixel count. A 35 megapixel JPG and a 350 megapixel JPG are two very different animals, regardless of what DPI produced them.

So instead of clamping DPI directly, I set a megapixel budget: "the output image must not exceed N megapixels." Then before every conversion, I probe the page dimensions at a low DPI, calculate what the requested DPI would produce, and if it's over budget, back off the DPI just enough to fit.

On Convertify, my budget is currently 100 MP. That's more than enough for 600 DPI on any normal document (a standard letter-size page at 600 DPI is only ~34 MP). It only kicks in on the pathological cases: huge PDFs, or edge geometry where the input pushes past what the server can honestly deliver.

The clamp function

Here's the actual function that ships in production:

pub fn clamp_dpi_to_megapixels(
    file_path: &str,
    page: i32,
    requested_dpi: i32,
    max_megapixels: f64,
) -> i32 {
    let probe = VipsImage::new_from_file(&format!("{file_path}[dpi=72,page={page}]"));

    let (w, h) = match probe {
        Ok(img) => (img.get_width() as f64, img.get_height() as f64),
        Err(_) => return requested_dpi,
    };

    let scale = requested_dpi as f64 / 72.0;
    let mp = (w * scale) * (h * scale) / 1_000_000.0;

    if mp <= max_megapixels {
        requested_dpi
    } else {
        let factor = (max_megapixels / mp).sqrt();
        ((requested_dpi as f64 * factor).floor() as i32).max(72)
    }
}

Let me walk through it.

Probe at 72 DPI. libvips-poppler treats 72 DPI as PDF's native "point" grid, so loading at 72 is cheap and gives us the true page dimensions in points. An 8.5" × 11" page comes back as 612 × 792 pixels.

If the probe fails (page number out of range, malformed PDF, anything else), I return the requested DPI unchanged. The downstream conversion will fail with a proper error. This isn't the place to swallow it.

Calculate what the requested DPI would produce. Multiply the base dimensions by requested_dpi / 72, then convert to megapixels. That same 8.5" × 11" page at 600 DPI: (612 × 8.33) × (792 × 8.33) / 1_000_000 ≈ 33.6 MP. Well under budget.

Under budget, return unchanged. If the naive DPI produces ≤ max MP, we're done. This is the happy path, probably 95%+ of user requests.

Over budget, back off proportionally. Here's where the math matters. To bring 350 MP down to 100 MP, we need to shrink by a factor of 100/350. But that ratio is pixels. DPI shrinks pixels quadratically. Halve the DPI, quarter the pixels. So the DPI factor is sqrt(100/350) ≈ 0.53. Applied to 600 DPI: 600 × 0.53 ≈ 318 DPI. Still well above the safe fallback of 300, but low enough to fit.

The .floor() and .max(72) are safety rails. Floor prevents rounding up past the budget; 72 is the effective minimum, since you can't rasterize below the PDF's native grid without producing garbage.

Why sqrt (a short math digression)

Nothing exotic here, but it's worth stating clearly because it's the whole insight.

Pixel count scales with the square of DPI, not with DPI itself. Double the DPI, both width and height double, so pixels quadruple. Triple the DPI, pixels grow 9×. The relationship is:

pixels = base_pixels × (dpi / 72)²

Solve for DPI when you know the target pixel count:

dpi = 72 × sqrt(target_pixels / base_pixels)

Which is exactly what the clamp does, just factored through requested_dpi. If you skip the sqrt and multiply DPI directly by the pixel ratio, you over-correct. You end up with a DPI far lower than the budget actually allows, and the user gets a needlessly low-resolution output.

I've seen "clamp DPI by proportional scaling" written in a few places online. Their outputs come out at a fraction of what they should be. This is why.

Real numbers from production

Here's what the clamp actually does at 100 MP budget:

Input document	Base @ 72 DPI	Requested	MP at requested	Clamped DPI	Output MP
Letter (8.5" × 11")	612 × 792 (0.48 MP)	600	33.6 MP	600	33.6
A3 (11.7" × 16.5")	842 × 1191 (1.0 MP)	600	69.6 MP	600	69.6
Large blueprint (24" × 36")	1728 × 2592 (4.5 MP)	600	311 MP	340	100
Wide schematic (36" × 60")	2592 × 4320 (11.2 MP)	600	778 MP	215	100

The pattern: on normal documents, 600 DPI passes through untouched. On the edge cases where the naive approach would produce hundreds of megapixels, DPI is scaled back to whatever fits the budget, and the user still gets an output much closer to their intent than a global 300 DPI fallback would give.

When to use TIFF instead

Worth flagging: if you're doing archival work at 600 DPI, JPG is often a poor fit. JPG is lossy, and at high DPI you're usually preserving fine detail specifically because you want it lossless: text edges, thin lines, small annotations.

For those cases, TIFF is the right format. LZW-compressed TIFF is lossless at reasonable file sizes, and every archival system on earth reads it. libvips handles it natively.

I ship the same clamp behind a PDF to TIFF converter, just with a different encoder. If you're building something similar, don't force JPG for 600 DPI archival work. Support TIFF too. Your users will thank you.

What I'd change if I did it again

Two things.

Per-page feedback. Right now the clamp runs silently. A 200-page document where one map spread got scaled from 600 to 340 DPI: the user doesn't see it. Silent is friendly for most cases, but for archival workflows people want to know exactly which pages hit the budget. I'd surface it in the response.

Adaptive budget. 100 MP is a hardcoded constant. On a bigger server it could be 250. For a mobile-only session, 40 makes more sense. Deriving the budget from request context (or letting users opt into a higher tier) would be a small config change with real impact.

Neither is urgent, but both are on the list.

Try it

If you need 600 DPI PDF to JPG conversion right now: Convertify does it. Free, no signup, batch up to 10 files, and the clamp function above runs on every request. Upload something huge and you'll get the highest DPI that fits a sane memory budget. Not a crash, not a silent global downgrade.

If you're building your own PDF-to-image tool and hit similar problems, the function above is production-tested and short enough to drop in as-is. Adjust max_megapixels to fit your infrastructure and move on.

If you want to see more of Convertify's engineering, I write about it weekly in Building Convertify in Public on this account. libvips tricks, Rust patterns, real production bugs. No filler.

Building in public, week 17: turning one feature into a page cluster (and the internal-linking layer nobody sees)

Serhii Kalyna — Sun, 05 Jul 2026 18:44:45 +0000

Week 16 shipped the AI background remover: Rust-native, ort + ISNet + libvips, no Python. That was the feature. Week 17 was not about writing more of it. It was about the boring, high-leverage part that most side projects skip: turning one working feature into pages that can actually rank, and wiring those pages together so search engines can find them.

No new engine code this week. Just leverage on what already existed. Here is what that actually looked like.

The problem: a hub with nothing pointing at it

The background remover lives at /remove-background. That is the hub. The plan was classic hub-and-spoke: one general tool page, then use-case spokes that each target a specific intent (removing a signature background, prepping an Amazon product photo, and so on).

I built two spokes this week. But halfway through, I looked at how internal links actually worked on the site and found the real problem: nothing linked from the hub to the spokes. The spokes linked back to the hub in their body text, but the hub had no idea they existed. Neither did the ~180 converter pages.

Tool links on the site were hardcoded in a frontend constant, roughly:

export const IMAGE_TOOLS = [
  { label: "Compress JPG", href: "/compress/jpg", tool: "compress" },
  { label: "Resize Image", href: "/resize-image", tool: "resize" },
  { label: "Crop Image", href: "/crop-image", tool: "crop" },
  { label: "Images to PDF", href: "/images-to-pdf", tool: "convert" },
] as const;

That list covered the converter tools. It did not include the background remover or its spokes at all. So the new pages were orphans: reachable only through the sitemap, with no internal links carrying any signal to them. For a domain that is still young and still earning Google's trust, orphan pages get discovered slowly and rank even slower.

The fix: one constant as the source of truth

Instead of hardcoding links in three different places, I made a single constant describe the whole cluster:

export const BACKGROUND_TOOLS = [
  { label: "Background Remover", href: "/background-remover" },
  { label: "Signature Background", href: "/remove-signature-background" },
  { label: "Amazon Product Photo", href: "/amazon-product-photo-background" },
] as const;

Then a small server component renders it, with an exclude prop so each page drops itself from the list:

export default function BackgroundTools({ exclude }: { exclude?: string }) {
  const tools = BACKGROUND_TOOLS.filter((t) => t.href !== exclude);
  if (tools.length === 0) return null;

  return (
    <section>
      <h2>Background Removal</h2>
      <div>
        {tools.map(({ label, href }) => (
          <Link key={href} href={href}>{label}</Link>
        ))}
      </div>
    </section>
  );
}

The nice part is that the same constant became the source of truth for detecting a background-removal page too. The main layout used to repeat the same array-of-slugs check three separate times. That collapsed into one line:

const isBgRemoval = BACKGROUND_TOOLS.some((tool) => tool.href === `/${mode}`);

So now: the hub links to both spokes, each spoke links to the hub and its sibling, and the whole thing renders only on background-removal pages. Adding a fourth spoke later is one line in the constant and it is cross-linked everywhere automatically. I also added the same list as a footer column, which puts the links on every page of the site, not just the cluster.

The bug that only shows up in production

The two spokes are stored as structured content in the database, and each section body is rendered with dangerouslySetInnerHTML inside a <p>. On one spoke I added a small "before you upload" checklist as a <ul>. It looked fine locally. In production, React threw a hydration mismatch.

The reason is plain once you see it: a <ul> is not valid inside a <p>. The browser silently auto-closes the paragraph before the list, so the DOM the browser builds does not match the HTML React rendered on the server, and hydration fails. The fix was to keep the section body to inline content only, so the checklist became <br>-separated lines instead of a real list.

The lesson I actually kept: I added a build-time guard that scans every section body for block-level tags (ul, ol, li, div, table, headings) and fails the build if it finds one. The class of bug is now impossible to ship again, which matters more than the one fix.

The honest numbers

Building in public means posting the numbers even when they are boring or bad.

Background pages live: 3 (hub + 2 spokes). The plan asked for 1 or 2, so this part went well.
Benchmark on the real VPS: the background remover runs at about p50 2.4s, p95 9.6s per image on a 4-core box.
AI citations: the site is cited 75 times across Microsoft Copilot, mostly on HEIC content. That is visibility that never shows up in a rank tracker, and I only found it by looking.
Google: still sandboxed. Impressions exist, positions are deep (average around the mid-40s), clicks are a trickle. Bing, meanwhile, ranks the same pages on page one. Same content, different trust curve. This is normal for a young domain and I am not fighting it, just waiting it out while the content compounds.

What week 18 looks like

More spokes, but slowly. Google's spam updates punish thin template-swap pages, so the rule is one or two good pages with genuine unique data, not ten shells. On the list: a couple more use-case spokes, a low-competition webp remove background page I found in my keyword data, and continuing the slow grind of backlinks to lift domain authority, which is the real ceiling right now.

The feature was week 16. The leverage was week 17. If you are building something similar, the thing I would repeat is this: shipping the feature is the easy half. Making it findable, and keeping the pages honestly connected, is the half that actually decides whether anyone ever sees it.

You can try the background remover here: https://convertifyapp.net/remove-background

I added AI background removal to my image converter in a week, in Rust, no Python

Serhii Kalyna — Mon, 29 Jun 2026 08:10:04 +0000

Part of an ongoing build-in-public series on Convertify, a free image/file converter I build solo. This week: background removal. The honest version, with the walls I hit.

Most "remove image background" tutorials end with pip install rembg and a happy screenshot. Mine started with a constraint: my whole backend is Rust, and I did not want to bolt a Python process onto it just to run one model.

Here is how the week went. The good parts, and the three or four times I stared at a compiler error wondering if the constraint was worth it.

The starting point

Convertify is a free image converter. The backend is Rust + Axum + libvips, the model has to run CPU-only on a modest VPS, and there is no GPU anywhere in the budget. The obvious path for background removal is rembg, which is excellent, but it is Python and ships as a separate server process. Adding it would mean a second runtime, a second thing to deploy, a second thing to crash at 3am.

So the question for the week was simple: can I run the same models rembg uses, but natively in Rust?

Short answer: yes. rembg is, under the hood, just ONNX models plus some image pre and post processing. The models (u2net, isnet, silueta) are all .onnx files. If I can run ONNX in Rust and do the image work in libvips (which I already have), there is no Python in the picture at all.

The plan

The pipeline for background removal is not magic, it is five boring steps:

Decode the image, resize a copy to the model input size
Normalize the pixels into a tensor
Run inference, get a mask (one value per pixel: subject or background)
Normalize the mask, resize it back to the original size
Composite the mask onto the original as an alpha channel, export a transparent PNG

Steps 1, 4, 5 are libvips, which I already use everywhere. Step 3 is ONNX Runtime via the ort crate. Step 2 is a tight Rust loop. No Python anywhere.

[dependencies]
ort = { version = "=2.0.0-rc.12", features = ["download-binaries"] }

The download-binaries feature pulls a CPU build of ONNX Runtime at build time, so there is nothing to install on the box. That alone deleted half the "deploy a Python service" anxiety.

Wall #1: the model name lied about its size

I grabbed isnet-general-use.onnx from the rembg releases, expecting ~44 MB. What landed was 171 MB. My first thought was a broken download or an HTML error page renamed to .onnx. Quick check:

file models/isnet-general-use.onnx
head -c 200 models/isnet-general-use.onnx | xxd | head

The header showed a real pytorch 1.13.1 signature and tensor names like input_image and conv_in.weight. So it was a valid ONNX model, just heavier than the name suggested. Lesson: verify the file is actually what you think before you spend an hour debugging "why is RAM so high."

Wall #2: `ort` errors are not `Send + Sync`

First compile against anyhow and I get hit with this:

the trait `Sync` is not implemented for `NonNull<OrtSessionOptions>`
required for `anyhow::Error` to implement `From<ort::Error<SessionBuilder>>`

anyhow::Error wants Send + Sync. The ort error type holds raw pointers into the ONNX Runtime C++ session, which are not Sync. So ? straight into anyhow does not compile.

The fix is to stringify the error at the boundary. Display gives you a String, and String is Send + Sync:

let session = build(model_path, intra_threads)
    .map_err(|e| anyhow!("ort session init: {e}"))?;

The pointer never leaves, only the message does. Once I understood why, the pattern was mechanical: every ort ? that crosses into anyhow gets a .map_err(|e| anyhow!("...: {e}"))?.

Wall #3: `run` takes `&mut self`

This one actually changed my architecture. In this ort version, Session::run takes &mut self. I had the session behind an Arc in my Axum app state so it could be shared. You cannot get &mut through an Arc.

cannot borrow `self.session` as mutable, as it is behind a `&` reference

Options were a session pool, or a Mutex. Since my traffic is low and I gate inference to one at a time anyway, I wrapped the session in a Mutex:

pub struct BgRemover {
    session: Mutex<Session>,
}

remove(&self) stays &self, so Arc<BgRemover> still works in app state. The Mutex hands out the &mut for the single inference call. With a one-permit semaphore in front, the mutex never even contends. When traffic grows, the upgrade path is a pool of sessions, but that is a future-me problem.

Wall #4: `*mut VipsImage` is not `Send`

libvips image pointers are not Send, which means they cannot be held across an .await. If I ran inference directly in the async handler, the borrow checker would stop me, and even if it did not, a multi-second CPU inference on an async worker thread would freeze the whole runtime.

The answer is spawn_blocking. The entire libvips + inference chain runs on a dedicated blocking thread and returns finished PNG bytes (which are Send):

let png = tokio::task::spawn_blocking(move || {
    let _permit = permit;       // hold the semaphore for the whole job
    remover.remove(&bytes)
}).await??;

Every VipsImage is created and dropped inside that closure, never crossing an await point. The async runtime stays free to serve everything else while one image is being cut out.

The part that surprised me: privacy came for free

Because the handler returns the PNG straight in the HTTP response, the image is never written to disk. It comes in as multipart bytes, gets processed in memory, and the result streams back. Nothing is stored, nothing is queued, nothing to clean up.

I did not plan that as a feature, it fell out of the architecture. But "your photo is processed in memory and never saved" is a genuinely strong thing to be able to say, and it is true, not marketing.

Does it actually work?

Yes. First real test through Postman with a HEIC photo: 200 OK, transparent PNG out. The model is ISNet (the IS-Net dichotomous segmentation architecture), and on clean subjects, products, people, logos, the cutout is sharp.

What I would tell past-me

rembg is "just" ONNX + image ops. If you already have an image library, you can skip the Python entirely with ort.
The ort 2.0 API churns between rc versions. Pin the exact version and expect to fix one or two method names.
spawn_blocking is not optional for CPU-heavy, non-Send work. It is the whole reason the server stays responsive.
Constraints ("no Python") are annoying in the moment and clarifying in hindsight. The Rust-native version is one binary, one deploy, nothing to babysit.

If you want to see the result, background removal is live and free (no signup, no watermark) on Convertify. Upload a photo, get a transparent PNG. It runs the exact pipeline above.

Next week: turning one tool into a set of use-case pages (passport photos, product shots) without drowning in duplicate content. That one is more SEO than Rust, but the build-in-public log continues.

What would you have done differently on the &mut self session problem? A pool, a mutex, something smarter? Curious how others handle shared ONNX sessions under load.

I Benchmarked 17 Image Conversions on My Production Server. Some Results Were Not What I Expected.

Serhii Kalyna — Sat, 20 Jun 2026 06:01:01 +0000

I run Convertify, a free image converter built on Rust and libvips. Last week I decided to stop guessing about format performance and actually measure it. I took 50 real images (26 PNGs, 24 iPhone HEIC photos), ran 17 conversions through the production pipeline, and recorded every file size and encode time.

Some results confirmed what everyone says. Others did not.

The three results that surprised me

1. Converting HEIC to JPG makes files 14% bigger, not smaller.

This one hurt. "Convert iPhone photos to JPG" is probably the most common advice on the internet. But HEIC wraps the HEVC codec, which compresses roughly 2x better than JPEG. Going from a better codec to a worse one means the file grows. Every time.

If you actually want smaller iPhone photos: HEIC to WebP saves 43%, HEIC to AVIF saves 57%.

2. AVIF encodes 7x slower than WebP for 10% more compression.

AVIF Q63: 55 KB, 1.30s per image.
WebP Q80: 61 KB, 0.19s per image.

That is a 10% size difference for a 7x speed penalty. For a single hero image, nobody cares. For a batch pipeline processing thousands of product photos, that is the difference between 3 minutes and 21 minutes.

3. PNG at 600 DPI is smaller than PNG at 300 DPI when rasterizing PDFs.

This was the weirdest one. I was benchmarking PDF-to-image and noticed PNG output shrank from 2,221 KB at 300 DPI to 1,660 KB at 600 DPI. I spent an hour convinced I had a bug.

Turns out it is a real property of PNG encoding. Higher DPI renders smoother gradients between adjacent pixels, and PNG's prediction filters (Paeth, sub, up) compress smooth gradients dramatically better than the sharp edges you get at lower resolutions. Not a bug. Just PNG being PNG.

The quick reference table

Conversion	Size change	Speed
JPG to WebP Q80	-64%	0.19s
JPG to AVIF Q63	-68%	1.30s
PNG to WebP Q80	-92%	0.21s
PNG to JPG Q85	-86%	0.07s
HEIC to JPG Q85	+14%	1.90s
HEIC to WebP Q80	-43%	5.64s
HEIC to AVIF Q63	-57%	14.52s
WebP to JPG Q85	+60%	0.09s
AVIF to JPG Q85	+80%	0.15s

What I actually recommend

For most websites: WebP Q80. 64% smaller than JPG, fast to encode, universal browser support since 2020.

For maximum compression with no time pressure: AVIF Q63. 68% smaller than JPG but 7x slower to encode.

For iPhone photos: Do not convert to JPG. Go straight to WebP or AVIF. JPG is a downgrade in both efficiency and file size.

The full benchmark

The complete data with PDF rasterization benchmarks, DPI comparisons, and methodology is in the full benchmark post on Convertify. Every number was measured on June 18, 2026 on the production Rust + libvips server. No theoretical figures, no borrowed data.

Week 14 of building Convertify in public. Previous posts in the series cover the SSG migration, libvips segfaults, and why I stopped trusting my own landing page copy.

Building in public, week 13: the debt week nobody posts about

Serhii Kalyna — Sun, 14 Jun 2026 07:16:50 +0000

I'm building Convertify, a free image converter, in public over 52 weeks. It's a solo project on Rust + Axum + libvips with a Next.js frontend. This is week 13, and I want to write about it honestly because it was a week with no shiny new feature, and those weeks rarely get posts.

Here's what actually happened.

I chased a double-free instead of shipping

My "images to PDF" path had been crashing in production, intermittently, with a GObject assertion failure. Convert a few files, fine. Convert a few more, segfault. The worst kind of bug.

Root cause: a derived Clone on the libvips image type was doing a bitwise pointer copy of a C object without taking a reference. Two Rust values ended up owning one underlying GObject, and when both dropped, g_object_unref ran twice on the same thing. A textbook double-free, wearing a .clone() as a disguise.

// the bug
let copy = image.clone();   // copies the pointer, no g_object_ref

// the fix
let copy = ops::copy(&image)?;   // real new GObject with its own refcount

One line. A couple of evenings to be sure it was that line. I wrote the full story up as a separate dev.to article this week.

I fixed a UX dead-end I'd been ignoring

If you went over the 20 MB upload limit, the convert button disabled itself, and there was no obvious way out. You couldn't remove a single file from the list. People were quietly getting stuck.

So I rebuilt the file list: each file is a card with a remove button, there's a size-limit toast that fires when you cross the limit, and the dropzone goes red.

While refactoring the upload handler I also collapsed three separate file-handling paths (choose, drop, remove) into one gate. That killed a whole class of bugs where the three paths had drifted apart (drop wasn't updating the size map, re-selecting the same file silently did nothing, etc).

I audited my own content for honesty

This is the unglamorous one. I went through landing pages and removed claims that didn't match what the backend actually does, checking each against the real Rust code (metadata handling, compression details). I'd rather say less and be correct than pad pages with things that aren't true.

Funny side effect: an SEO audit I ran this week pointed at exactly this kind of honest, specific content as the thing that sets the site apart from templated competitors. The discipline turned out to be the moat.

The most useful thing I did wasn't code

I finally set up Bing Webmaster Tools. Took five minutes (you can import straight from Google Search Console).

It immediately showed me search intent Google had been hiding: around 25 different queries for "pdf to jpg at N dpi" (600, 300, 150), in multiple languages, where I'm already ranking on page one. People who need a specific print resolution. I had no idea that demand existed because Google's console never surfaced it. That's now the top candidate for next week's backend work.

Lesson: if you only watch Google, you're watching most of the market through one keyhole. Other search consoles are free and show you different things.

Numbers, honestly

Impressions and indexing are both at period highs (impressions peaked around 225/day this week). Clicks are still small and spiky, which is normal for a 3-month-old domain with almost no backlinks. Nothing regressed, despite a scary-looking week-over-week dip that turned out to be me comparing a 7-day peak against a 3-month total.

Threads is quietly my best referral source (real sessions every week), and ChatGPT keeps sending people too, which means I'm getting cited in LLM answers even though I haven't seen the AI crawlers hit me directly.

Next week is a real technical week

Backend debt: selectable TIFF compression, multipage TIFF, a CMYK path, and that DPI feature the Bing data justified. Plus refactoring my upload handler properly before I pile more on it, and turning my real benchmark data into a public study people can actually cite (which an audit suggested is a stronger link lever than guest posts).

No new converter pages. The lever this stretch is depth and correctness, not surface area.

If you're building something image-heavy, it's at convertifyapp.net. No account, files deleted 6 hours after conversion. Week 13 of 52 done.

The Rust binding compiled fine. then it started segfaulting in prod

Serhii Kalyna — Thu, 11 Jun 2026 07:59:39 +0000

I run a free image converter, its built on rust + axum + libvips. it had been happily running for months. then one feature, images-to-pdf, started falling over in production with this:

g_object_unref: assertion 'G_IS_OBJECT (object)' failed

and the fun part: only sometimes. convert a couple images, fine. convert a few more, boom. the non-deterministic kind of crash, which is the worst kind, because it makes you sit there wondering if you even understand the language you've been writing for years.

Turns out the bug was mine. the trigger was one tiny innocent .clone(). heres the whole thing because i'm pretty sure other people doing rust over a C lib will eventually step on the same rake.

"But rust is memory safe"

This is what messed with my head for a while. rust is supposed to stop exactly this. no double frees, no use after free, borrow checker has your back. so how am i double freeing anything at all?

One word makes all those guarantees quietly disappear: FFI.

Libvips is a C library built on GObject, and GObject does its own manual reference counting. the rust crate wraps those C objects in rust types. and the second a rust type is holding a raw pointer into C land, the borrow checker just... cant help you anymore. it sees a struct. it does not see that the struct is actually a handle to a refcounted thing living on the C heap. safety stops right at that line and nobody tells you.

The actual cause: a Clone that doesnt clone

Heres roughly what was blowing up. i was building a multi-page pdf and somewhere in the loop i cloned the image:

// the crash version
let copy = image.clone();
// ... use copy ...
// both `image` and `copy` drop here

VipsImage in the crate derives Clone. and a derived clone on a thing that holds a pointer does the obvious dumb thing: it copies the pointer. bit for bit. so now the same C object has two rust owners, and here is the kicker, nobody incremented the GObject refcount. libvips still thinks there is exactly one reference to that object.

Then rust does its job a little too well. both values go out of scope, Drop runs twice, and each drop calls g_object_unref on the same object. first unref takes the count to zero and frees it. second unref runs on already-freed memory, libvips checks G_IS_OBJECT, the assertion blows, and depending on timing you either get a glib critical or a clean segfault.

So. a textbook double free. wearing a .clone() as a disguise. the "random" part was just the allocator deciding whether the freed slot had been reused yet or not.

A correct clone here would have to call g_object_ref so each owner actually accounts for its own reference. the derived one doesnt. so calling it Clone is generous. its an aliased pointer with two destructors aimed at it.

The fix

Stopped cloning the handle, started asking libvips for a real new object instead:

// the fixed version
let copy = ops::copy(&image)?;

ops::copy runs an actual libvips copy and gives you back a fresh GObject with its own refcount. now each rust value owns its own distinct C object, each drop unrefs its own thing, nothing gets freed twice. crash gone.

one line. took me a couple evenings to be sure it was that line, which is always how these go.

a few more libvips + rust landmines from the same evening

since i was already in there bleeding, a few neighbours showed up:

JpegsaveBufferOptions::default() hands you a busted keep value. the default came out as something like keep | 32, which libvips just rejects with a glib critical. fix was to stop trusting the default and set it myself:

keep: ops::ForeignKeep::None,

the operation cache was a second way to die. libvips caches operations by default, and under load that cache plus the lifecycle mess above gave me another crash, this time inside cache trimming. i turned the operation cache off entirely while getting things stable, which killed that path. just know it exists and that its global state.

VipsApp::new(name, false) is not what it looks like. that second bool is detect_leak, not some concurrency switch, which is exactly what i had lazily assumed it was. read the signature, dont pattern-match on vibes.

bumping the crate did not save me. i tried going from 1.7.x up to 2.1.0 hoping the lifecycle stuff was just fixed upstream. nope, changed nothing for this. reverted to 1.7.6 and fixed it properly on my end.

what i actually took from this

a derived Clone on a type that wraps a foreign, refcounted resource is a trap. #[derive(Clone)] assumes a clone is a cheap copy-the-fields job. for a GObject handle thats the exact wrong assumption: copy the pointer without taking a ref and you've got two owners, one refcount, and rust's own Drop happily freeing it twice.

so the rule i walked out with: when a rust type owns a C resource that has its own lifecycle, treat Clone and Drop as suspects, not freebies. need another handle? reach for the library's own copy/ref function before you derive Clone and hope.

if you've hit something like this with libvips bindings or any GObject FFI, i'd genuinely love to hear how you dealt with it, the comments are the fun part. the tool this was all holding up is at convertifyapp.net if you want a look. no account, files get deleted after.

Week 12 building Convertify in public (free image converter, Rust + libvips + Next.js SSG)

Serhii Kalyna — Sun, 07 Jun 2026 16:47:13 +0000

What I shipped:

Two new tools live: Resize Image and Crop Image, both on libvips natively
A long-form guide, "How to Compress Images Without Losing Quality," written to feed my compress JPG/PNG/WebP pages with real internal links and real benchmarks from 24 of my own iPhone photos
A site-wide "Image Tools" block (inline section + footer column) so every page now cross-links to the new tools
Squashed a nasty non-deterministic segfault in the libvips Rust bindings. It was a double-free: the binding derives Clone over the raw image pointer, so cloning copied the pointer without bumping the refcount and Drop freed the same object twice. Replaced the clone with an explicit copy, disabled the op cache, and the crashes plus the G_IS_OBJECT warnings are gone. Happy to write up the war story if anyone wants it.

The numbers (last 7 days):

Clicks doubled, up 100% week over week. Still small in absolute terms, but real and trending the right way for the first time in weeks.
Impressions also up 100%, as the new pages finished getting indexed.
Average position is creeping up, into the mid-40s on the most recent day, from around 51 the week before.
A brand-new long-tail query, "sony hif file to jpg converter," is already sitting at position 6. That is exactly the kind of low-competition query I am betting the whole strategy on.

The honest read:
Clicks and impressions both doubled, which is great, but the absolute numbers are still small and capped by domain authority. I have around 15 referring domains; the big converters have thousands. On competitive terms like "avif to png" (KD 42) I cannot rank without backlinks, and that is a months-long game. So the play stays low-KD long-tail: pages that can reach the top 10 even at low DR. That position-6 result on a niche query is the early proof it works.

Next week:

Concentrate internal links on the low-KD pages that already have impressions
Start background removal (rembg sidecar) research
Keep backlink outreach slow and quality-first

convertifyapp.net

Building in public, week 11: 143 pages indexed, a TinyPNG alternative in Rust

Serhii Kalyna — Sun, 31 May 2026 11:15:26 +0000

Week 11 of building Convertify a free image converter (Rust + Axum + libvips, Next.js SSG frontend) in public. Solo, no funding, 52-week run.

Here's the honest headline: **indexing jumped from 100 to 143 pages, I shipped image compression in Rust, and my clicks are still stuck.

What I shipped

1. Internal linking between blog and converter (the debt I kept dodging)

I launched a blog in week 10 (3 posts, full schema, the works) and immediately got 18 views/week on one post. Great except that traffic had nowhere to go. The blog talked about HEIC; it never pointed at the page that actually converts HEIC.

So week 11 I built a RelatedArticle component and wired it both ways:

Blog -> converter: inline contextual links in the body + a CTA block at the end.
Converter -> blog: a "Learn more" card driven by a related_blog_slug column on each page.

The component went through a small evolution. First version showed one article. Then I made it multi-article it pulls 2–3 related posts, matches them by topic via slug, caps at 3, and (the part that bit me) guards against the literal string "NULL" sneaking in from a missing DB value. Nothing fancy, but it closes the loop: informational traffic can finally flow to the transactional pages.

2. Image compression a free TinyPNG alternative, in Rust.

This was the fun one. TinyPNG does ~3M visits/month. That demand is enormous and I was leaving it on the table. libvips already gives me everything I need, so the backend was fast to stand up:

JPEG -> mozjpeg. libvips can hand JPEG encoding to mozjpeg, which does trellis quantization and smarter Huffman tables. Same visual quality, meaningfully smaller files than baseline libjpeg.
PNG -> imagequant. This is the same lossy-PNG approach pngquant (and TinyPNG) use: quantize a 24-bit PNG down to an optimized palette. Huge size drops on PNGs with limited color, transparency preserved.

The UX is a quality slider (1-100%) and a before/after size readout, so you actually see the reduction. I shipped three landing pages /compress-jpg, /compress-png, /compress-webp positioned as the free alternative.

The interesting signal: Compress JPG Free pulled 24 views in its first week, landing straight in my top pages. Different user intent than conversion (people converting a format vs people shrinking a file), and it showed up immediately. That alone made the cluster worth it.

3. Blog post #4

"Why HEIC Files Won't Open" published, 8 FAQs, FAQ schema embedded in the BlogPosting. Continuing the content momentum and feeding the new internal-linking machine.

Also did a cannibalization audit across blog + landing pages. Came back clean: intent is cleanly split (blog = informational, landing = transactional), so they're not fighting each other in search.

The numbers

Google Search Console (3 months):

Indexed: 100 -> 143 (+43, second-biggest jump ever)
Not indexed: 65 -> 39
Avg position: 40 -> 39.5

Google Analytics (7 days): 31 active users (+29%), 24 new (+33%), 52 sessions (+11%).

Traffic sources had a surprise: l.threads.com sent 13 sessions in a week Threads quietly became a real referrer. chatgpt.com has been a steady trickle for over a month now too (LLMs citing the blog posts).

Housekeeping wins

Cleared a stack of small debts that were quietly rotting: fixed the 404 source (broken internal links), cleared the redirect errors flagged in GSC, and consolidated my project docs into a single source-of-truth file instead of three drifting documents.

Next week (12)

Two new tools that are low-effort / high-ROI: resize + crop and background removal.
A compression-focused blog post to feed the new cluster.
The real work: on-page pushes on my top-impression pages to finally break something into the top 20.

If you've shipped a programmatic-SEO site and watched impressions climb while clicks flatlined I'd genuinely like to hear how (or whether) you broke out of it. That's the wall I'm at.

Convertify is built with Rust + libvips + Next.js. Following along week by week.

Building Image Compression in Rust with libvips Real Benchmarks, Real Tradeoffs

Serhii Kalyna — Fri, 29 May 2026 13:00:32 +0000

I've been building Convertify a free image converter for 11 weeks now. Last week I added compression support (JPG, PNG, WebP) using Rust + libvips. Here's what I learned, with actual numbers.

The Stack

Backend: Rust + Axum
Image processing: libvips 8.15.1 via the libvips crate
JPEG encoder: libjpeg (bundled with libvips)
PNG quantization: imagequant (same algorithm as pngquant / TinyPNG)
PNG parser: libspng (faster than libpng)

One thing worth knowing upfront: libvips does not include mozjpeg by default. You get standard libjpeg. I'll come back to why this matters.

How the API Works

The compression endpoint is the same /api/upload used for conversion — just pass format_to=jpg (or png, webp) with a quality parameter (1–100):

curl -X POST https://convertifyapp.net/api/upload \
  -F "files=@photo.jpg" \
  -F "format_to=jpg" \
  -F "quality=80"

On the Rust side, quality flows into libvips save options via build_output_path, which appends [Q=N] to the output filename — libvips picks it up automatically:

fn build_output_path(base: &str, format: &str, quality: Option<u32>) -> String {
    match (format, quality) {
        ("jpg" | "jpeg" | "webp", Some(q)) => format!("{}[Q={}]", base, q),
        ("png", Some(q)) => format!("{}[Q={}]", base, q),
        _ => base.to_string(),
    }
}

Clean. No separate code path for compression vs conversion.

The Benchmarks

Test image: 1920×1080 synthetic photo, 1.5 MB original JPG (Q=95 source).

JPG → JPG (re-compression)

Quality	Output size	Saved
Q=90	1,172 KB	22.7%
Q=80	890 KB	41.3%
Q=70	737 KB	51.4%
Q=60	627 KB	58.6%
Q=50	542 KB	64.2%

PNG → PNG (imagequant lossy)

Test image: 1024×768, 678 KB original PNG.

Quality	Output size	Saved
Q=90	486 KB	29.8%
Q=80	441 KB	36.2%
Q=70	396 KB	42.7%
Q=60	377 KB	45.5%
Q=50	348 KB	49.7%

JPG → WebP (format switch as compression)

Quality	Output size	Saved vs original JPG
Q=90	1,120 KB	26.1%
Q=80	872 KB	42.5%
Q=70	760 KB	49.9%

The Surprising Part

WebP at Q=80 saves almost the same as JPG at Q=80 — 42.5% vs 41.3%. Not the dramatic 2× improvement you'd expect from the marketing.

Why? On already-complex photographic content (lots of high-frequency detail), the gap between WebP and JPEG narrows significantly. WebP's advantage is most visible on graphics, flat colors, and images with transparency.

The other surprise: if the source JPG is already compressed at Q=70–75 (common for web photos), re-compressing to the same format gives you almost nothing. You're fighting the JPEG DCT artifacts that are already baked in. This is where converting to WebP actually helps different codec, fresh encode.

Why Not mozjpeg?

mozjpeg typically gives 10–15% better compression than libjpeg at the same quality level. To use it with libvips you need to compile libvips from source with --with-mozjpeg. On Ubuntu:

# Not trivial requires building mozjpeg first
git clone https://github.com/mozilla/mozjpeg.git
cd mozjpeg && cmake -G"Unix Makefiles" && make install

# Then rebuild libvips pointing at mozjpeg
./configure --with-jpeg-includes=/opt/mozjpeg/include \
            --with-jpeg-libraries=/opt/mozjpeg/lib

For a production VPS running PM2 + Caddy with system libvips, the operational complexity wasn't worth it. libjpeg at Q=80 already delivers 40%+ savings which covers 90% of use cases.

PNG: imagequant is the real hero

The selected quantisation package: imagequant line in vips --vips-config is significant. This is the same engine behind pngquant and TinyPNG's PNG compression. It works by reducing the color palette to 256 colors (lossy) while preserving perceptual quality.

The Q parameter maps to imagequant's quality range. Q=80 gives ~36% savings with barely visible quality loss on photographic PNGs. For logos and flat graphics the savings are even better since there are fewer unique colors to begin with.

The Sweet Spot

After running these benchmarks, the defaults I settled on for the UI:

JPG: Q=82 (hits the knee of the quality/size curve, ~40% savings)
PNG: Q=80 (36% savings, imagequant artifacts not visible at normal viewing)
WebP: Q=80 (consistent with JPG behavior)

These are close to what Squoosh and Lighthouse recommend. The difference is users can move the slider themselves the before/after size display makes the tradeoff tangible.

What's Next

The compression cluster is live at convertifyapp.net/compress/jpg. Next up: RAW format support (CR2/NEF) for photographers, and eventually mozjpeg as an opt-in for maximum compression.

If you're building something similar libvips in Rust is genuinely great. The libvips crate is well-maintained, the C library is fast (faster than ImageMagick by a wide margin), and imagequant bundled for PNG is a nice bonus.

Building in public week 11 of 52. Follow along if you're into indie dev + Rust + SEO experiments.

DEV Community: Serhii Kalyna

How I recorded my first product demo in 54 seconds (OBS, ffmpeg, openai.fm)

The stack

The script lesson

What I would do differently

Try it

Week 20 building Convertify: the blog post I did not write

The temptation

Why extend instead

The safe SQL pattern

Also this week: closing the "30 MB PNG bug"

Sandbox exit signals

Takeaway

Week 19: Cloudflare Email Routing, Wikidata citations, and the benchmark that keeps citing itself

Trust foundation continues. Real numbers from Bing AI, one 10-minute email setup, and a bug I keep punting.

The scoreboard

Cloudflare Email Routing was 10 minutes

The 30 MB PNG bug I keep punting

What I learned about AI search this week

Next week

Building a 600-DPI PDF to JPG converter in Rust: the megapixel clamp that saved production

Why 600 DPI matters

The naive approach (and why it broke)

The megapixel budget

The clamp function

Why sqrt (a short math digression)

Real numbers from production

When to use TIFF instead

What I'd change if I did it again

Try it

Building in public, week 17: turning one feature into a page cluster (and the internal-linking layer nobody sees)

The problem: a hub with nothing pointing at it

The fix: one constant as the source of truth

The bug that only shows up in production

The honest numbers

What week 18 looks like

I added AI background removal to my image converter in a week, in Rust, no Python

The starting point

The plan

Wall #1: the model name lied about its size

Wall #2: ort errors are not Send + Sync

Wall #3: run takes &mut self

Wall #4: *mut VipsImage is not Send

The part that surprised me: privacy came for free

Does it actually work?

What I would tell past-me

I Benchmarked 17 Image Conversions on My Production Server. Some Results Were Not What I Expected.

The three results that surprised me

The quick reference table

What I actually recommend

The full benchmark

Building in public, week 13: the debt week nobody posts about

I chased a double-free instead of shipping

I fixed a UX dead-end I'd been ignoring

I audited my own content for honesty

The most useful thing I did wasn't code

Numbers, honestly

Next week is a real technical week

The Rust binding compiled fine. then it started segfaulting in prod

"But rust is memory safe"

The actual cause: a Clone that doesnt clone

The fix

a few more libvips + rust landmines from the same evening

what i actually took from this

Week 12 building Convertify in public (free image converter, Rust + libvips + Next.js SSG)

Building in public, week 11: 143 pages indexed, a TinyPNG alternative in Rust

What I shipped

1. Internal linking between blog and converter (the debt I kept dodging)

2. Image compression a free TinyPNG alternative, in Rust.

3. Blog post #4

The numbers

Housekeeping wins

Next week (12)

Building Image Compression in Rust with libvips Real Benchmarks, Real Tradeoffs

The Stack

How the API Works

The Benchmarks

JPG → JPG (re-compression)

PNG → PNG (imagequant lossy)

JPG → WebP (format switch as compression)

Wall #2: `ort` errors are not `Send + Sync`

Wall #3: `run` takes `&mut self`

Wall #4: `*mut VipsImage` is not `Send`