Why this exists
The story behind FigureLab
There is a Ghanaian adage about a piglet quizzing their mother about why she has such a big snout, only for the mother to respond that it was a matter of time before the piglet would grow to experience such a predicament.
I first encountered this particular predicament at a Texas ASM Branch meeting. I was sitting behind someone working on their laptop, wrestling with ImageJ, Inkscape, and PowerPoint. Cropping a microscopy panel. Dragging it into Inkscape. Trying to align a set of figures. I watched for a few minutes before quietly looking away — privately glad it wasn't me, and privately filing it away as something deeply familiar.
Then it was me.
I had a set of N4 phage infection time-course images that needed to become an eight-panel figure for a manuscript. Calibrated scale bars, annotations to add, brightness adjustments to make. I know Fiji well. I know Inkscape well. I have done this before. And yet two hours in, I was exporting the same TIFF for the fifth time because the panel labels kept rendering at the wrong size, the scale bar math was off when I cropped the image, and the SVG I had painstakingly annotated had lost half its arrows when I reopened it. To add salt to injury, I could not seem to align everything perfectly.
I ended up with a figure I did not like, assembled through a process I hated, using tools I respect but that were simply not designed for this job.
So I did what I sometimes do when I hit a wall in this age of AI: I remembered that you can just build things.
The actual problem with figure assembly
To be clear, Fiji is excellent software. ImageJ has been the backbone of biological image analysis for decades, and the community that built and maintains it deserves enormous credit. Inkscape is a genuinely powerful vector editor. The problem is not that these tools are bad. The problem is that making a publication figure involves a very specific workflow — arrange panels in a grid, apply uniform brightness adjustments, add calibrated scale bars, annotate with arrows and labels, export at 300 or 600 DPI — and none of the tools in the standard academic stack were designed specifically for that workflow. You are constantly leaving one application and entering another, re-importing files, re-doing work.
The hidden cost is not the time per se. It is the fragmentation. Your figure exists simultaneously as a Fiji macro, a set of exported TIFFs, an Inkscape SVG, and a mental model of how they all relate. When something changes — a reviewer wants panel C cropped differently or the scale bar moved — you go back to the beginning of the chain.
The specific failures I kept hitting
Scale bar pixel math that ignored my crop region, giving me a bar that was visually correct but numerically wrong. SVG exports from Fiji that silently dropped my annotations when reopened. PNG files that looked fine on screen but were flagged as 72 DPI by the journal submission portal. A session file that crashed when I had more than four large TIFF files loaded.
These are not exotic edge cases. These are the normal workflow for any microscopy-heavy biology paper.
What I built — and what it became
FigureLab started as a single HTML file with a grid, a crop editor, and a scale bar. You open it in your browser. You drag in your images. You build your figure. You export it. No installation, no account, no server, no data leaving your machine. I deliberately kept it as a single file because the last thing a stressed PhD student needs is a dependency to manage.
The core loop was simple: drop images into a panel grid, adjust each one independently, annotate directly on the canvas, apply a journal preset, and export. But the tool kept growing — not because I set out to build something big, but because every workflow it touched surfaced another problem worth solving.
Version 3.1 adds things I did not plan but probably should have from the start. A freeform canvas mode — so figures that do not fit a grid (posters, graphical abstracts, multi-part schematics) have a home. A pre-use crop editor that intercepts every image before it enters the canvas, so you are never cropping the same thing twice in two different tools. A real quantification engine: ROI intensity, integrated density, line profiles, cell counting by threshold. A reproducibility log baked into every PNG export as metadata. And AI-generated scientific diagrams — type a prompt, get a BioRender-style cartoon, place it directly into your figure, background removed.
The ambition changed a little. It is not just a microscopy figure tool anymore. It is closer to what you would get if PowerPoint, ImageJ, and BioRender had a single-file offspring that cared about publication correctness.
On building tools as a scientist
There is a version of scientific training that treats tool-building as a distraction from real science. Get the data, analyze it, write it up, move on. And there is real wisdom in that: time spent building infrastructure is time not spent at the bench.
But there is another version — one I have come to believe more fully as my PhD has progressed — the act of building a tool forces you to understand a problem at a depth that using tools never does. When I wrote the scale bar rendering code, I had to think carefully about what "calibrated" actually means when you have cropped an image. The source pixel width after cropping is not the same as the original image width, and getting that wrong produces a scale bar that looks right but lies.
The act of building a tool forces you to understand a problem at a depth that using tools never does.
I am not claiming FigureLab is finished. It has gaps I know about and probably gaps I do not. But it is real, it runs, and it has already saved me more time than it took to build. That seems like the right bar for whether something was worth doing.
A note on how it was built
FigureLab was built collaboratively with Claude (Anthropic's AI). The ideas, the workflow design, the frustration that motivated it, the decisions about what to build — those are mine. Claude was the implementation partner: writing and debugging the canvas rendering code, the TIFF export logic, the annotation system, the scale bar math. Working this way let me turn a specific scientific frustration into a working tool faster than I could have alone, and I think it is worth being transparent about that.