DEV Community: FigCanvas

A repeatable workflow for paper figures so you stop redrawing them every revision

FigCanvas — Sun, 31 May 2026 02:24:15 +0000

If you've shipped a paper, you know the figure tax: you build a beautiful schematic, a reviewer asks you to move one box, and you spend an afternoon re-aligning everything by hand. Do that across three revisions and you've spent more time nudging vectors than running the analysis.

I started treating figures the way I treat code: as something that should be regenerable from a source, not hand-crafted once and patched forever. Here's the workflow that stuck.

1. Write the figure as text first

Before opening any drawing tool, I write the figure as a plain description in the repo:

ligand -> receptor (binding)
receptor -> kinase (activation)
kinase -> targetA, targetB (phosphorylation)
targetA -| receptor (inhibition, feedback)

This forces the logic to be explicit. If you can't write the relationships down cleanly, the figure isn't ready — and that's a science problem, not a drawing problem.

2. Generate a first draft instead of starting from a blank canvas

I feed that description into a tool that will create scientific figures with AI and get a laid-out first draft. The point isn't "AI does my figure." The point is the boring geometry — consistent boxes, even spacing, arrow routing — is done before I start, so my time goes into the parts that need judgment.

3. Keep the output editable and vector

The non-negotiable: the result has to be editable vector, not a flattened PNG. When the reviewer asks to move a box, I move a box. When a journal wants a different size, it scales without turning into mush.

4. Treat revisions as diffs

Because the source description lives in the repo, "revision 2" is a diff, not a rebuild. I change the text, regenerate, fix the few labels that matter, export. Twenty minutes instead of an afternoon.

What this doesn't solve

It won't make a bad figure good — encoding, color logic, and what you choose to show are still on you. And the first draft always needs cleanup; anyone promising one-click publication figures is selling something.

But moving the source of truth from "a fragile vector file" to "a text description plus a generator" changed figures from a dreaded last step into something I can iterate on as fast as I iterate on the writing.

How do you handle figure revisions? Still hand-editing in Illustrator, or have you found a more reproducible setup?

How we test color palettes before they ship in scientific figures

FigCanvas — Wed, 27 May 2026 00:57:06 +0000

The journals don't reject papers because the palette is wrong. They just give you another revision round, and the senior reviewer writes "figures are difficult to read in print." Same outcome, slower.

We work on FigCanvas, an AI tool for scientific figures, so we end up looking at a lot of bad palettes. After a few hundred of them we built a checklist for testing a palette before any plot using it ever ships. Most of it is engineering-style: deterministic, runnable, fast.

The four tests that catch ~90% of palette failures

1. Colorblind simulation, not "ask someone with deuteranopia"

The most common test people do is "send the figure to a friend." This is fine and you should still do it. But it's not a unit test — your friend isn't going to look at every iteration.

Run the palette through a deterministic simulator first. For each color in the palette, compute the deuteranopia and protanopia versions (these cover ~95% of the colorblind population). Then check pairwise distance in CIELAB. If any two colors collapse to a distance under ~10 in either simulation, the palette is broken — pick another.

A few tools that do this server-side: colorspace in R has deutan() / protan(); in Python, colorblind or daltonize. You can hand-roll the transform from the Brettel/Viénot matrices in about 20 lines.

2. Grayscale fallback

A surprising number of reviewers print papers. A larger number of journals still publish print editions. If two colors in your palette collapse to similar lightness, they will be indistinguishable when the journal's production team rasters everything to grayscale for proofing.

Test it the dumb way: take a 1×N strip of swatches, desaturate, look. Or compute the L* channel for each and make sure the spread is >5 between adjacent categorical colors.

Both Okabe-Ito and viridis pass this. Most "I built a custom palette for our lab" palettes fail.

3. Perceptual uniformity (continuous only)

For continuous scales — heatmaps, density plots, anything with a colorbar — the palette needs to be perceptually uniform. Equal numerical steps should look like equal visual steps. Rainbow / jet famously aren't, which is why every modern visualization library has moved away from them as default.

viridis, magma, inferno, cividis, and plasma all pass. So does mako from seaborn. The deltaE-2000 metric is the right one if you want to check programmatically.

4. Shape stress test

Palettes that look fine as 200×200 swatches in a swatch grid often collapse when applied to actual chart shapes. A small scatter point picks up far less color than a large bar. Lines on a noisy background read worse than filled areas.

We test every palette on five shapes before shipping:

bar chart (large filled regions)
scatter (small isolated points)
line plot (thin lines)
heatmap (large continuous gradient)
volcano plot (mixed sparse + dense)

This catches palettes where, e.g., the "light blue" you picked reads fine in a bar but vanishes as scatter points against the gridlines.

What we ended up shipping

After enough manual testing we wrapped this into a small in-browser tool — a figure tool for researchers that runs all four tests on any palette you paste in, including Okabe-Ito, viridis variants, and Nature/Science-style limited sets. The interesting part is the preview pane: it renders each candidate palette on all five shape types simultaneously, so you can see at a glance which palette holds up under your actual chart type.

This is not a deep technical contribution. It's tooling around the boring testing step that everyone skips because it takes 20 minutes by hand. Compressed to 5 seconds, it suddenly becomes worth doing.

Reviewer time is the bottleneck

The reason any of this matters is that figure review costs reviewer time, which is the most expensive resource in the academic publication pipeline. A figure that's wrong by half a deltaE in deuteranopia simulation is going to send a paper back for one more revision round. That's two weeks. For one color choice.

Palette testing is the cheapest leverage point in scientific figure work. It's also the one most authors skip because the existing tooling is annoying. Most of the engineering value of "AI for science" right now is just removing the annoyance from steps that, in principle, were always doable.

TL;DR

Run pairwise colorblind simulation, fail if any pair collapses
Desaturate, fail if L* spread is too narrow
For continuous palettes, check perceptual uniformity (deltaE-2000)
Render on all five chart shape types before shipping

Doing this once per palette saves us at least one revision round per paper we touch. Easy ROI.

Why text-to-image AI keeps failing at scientific figures (and what actually works)

FigCanvas — Wed, 13 May 2026 00:12:02 +0000

Over the past month I've been trying to replace my "spend half a day in Illustrator drafting figures" workflow with AI tools. I tried Midjourney, GPT-Image-1, DALL-E, Stable Diffusion fine-tunes, generic diagram-from-text tools, and finally a purpose-built scientific illustration tool. Only the last one actually worked for figures destined for a peer-reviewed paper. This post is the autopsy on why.

The three failure modes of generic image AI on figures

1. Label hallucinations

You ask for a figure showing "PCR cycling steps: denaturation, annealing, extension," and the model writes "Denaturition", "Aneling", and "Estention" inside the boxes. Or it gets the words right but spells "DNA" as a five-letter blob. This happens because image-gen models treat text as pixels; they don't know it's text.

Workarounds people try:

Generate the image, then edit text in Photoshop. Works, but it's manual and removes the speed advantage.
Use models with stronger text rendering (Flux 1.1 Pro, Ideogram). Better, but still wrong ~20% of the time, and you don't see which 20% until you've already exported.

For a journal figure, the failure mode is invisible until a reviewer screenshots a mislabeled box and tells you to redo Figure 3.

2. Layouts don't iterate

This is the real killer. Say the model gives you a four-panel figure: A, B, C, D. Reviewer asks: "Add a fifth panel showing the control condition."

In pixels, there is no "add a panel." The only way to edit is to re-prompt. The new image will not preserve the exact layout, colors, fonts, or sizing of panels A-D. Every revision starts from scratch.

Real-world cost: in a recent paper I had three revisions over six months. With pixel-AI tools, that's three from-scratch redraws. With Illustrator, it's three quick edits. With a structured-canvas tool that holds the figure as boxes/arrows/labels under the hood, it's three "add panel E" instructions, no redrawing.

3. Wrong visual vocabulary

General image AIs are trained on stock photos, art, memes — not on scientific publications. The "diagram" they produce is the cartoony kind you'd see on a tech blog: 3D glossy boxes, comic-style arrows, gradient fills. Journals expect 2D, line-weight-controlled, color-restrained, vector outputs.

You can prompt your way around some of this ("flat, minimal, journal style"), but the visual primitives the model knows are still pop-art primitives. It doesn't know what a cell membrane looks like in a methods schematic, or what a Sankey diagram for ecological flow should look like.

What actually works: a structured canvas with science-aware primitives

The pattern that breaks all three problems: keep the figure as a structured representation (boxes, arrows, labels, panels) underneath the natural-language prompt, and only render to pixels at export time.

That way:

Text is text. It can't hallucinate spelling.
"Add panel E" is a real operation on the structure.
The library of primitives can be science-shaped: receptor cartoons, organelles, pathway arrows, multi-panel grids with consistent spacing.

The tool I landed on after the experiment is figcanvas.com — paste a Methods paragraph, get a structured first draft, iterate per panel with plain English, export vector. The first-draft quality isn't perfect (it sometimes drops a label when reshuffling), but the iteration loop is the win: I went from "empty Illustrator file" to a clean methods schematic in 25 minutes that used to be a half-day job. More importantly, when the second reviewer asks for changes, those changes take 10 minutes instead of two hours.

TL;DR

Image-gen AI is great for thumbnails, blog hero images, and concept art. For scientific figures it's a trap because:

Text inside images is unreliable.
Edits aren't compositional.
The visual style is wrong for journals.

Pick a tool that treats the figure as structure, not pixels.

If you write papers and resent every minute spent in Illustrator, the structured-canvas approach is worth a weekend trial. Even if you don't switch tools long-term, you'll learn what the AI tooling actually can and can't do for academic work in 2026.