GPT Image 2.5 for Scientific Figures: What Journals Accept

The figure that made me take this seriously was a participant flow diagram. Every number was right: 1240 screened, 240 excluded (140 for missing imaging, 100 for missing outcome), 1000 included, then split 600 / 200 / 200. The legend distinguished model development from final evaluation with a solid and a dashed line, exactly as asked.

And one arrow pointed the wrong way. The internal test set had an arrow running back into the frozen model, which is the thing a reviewer circles in red. The figure looked right. It said something methodologically wrong.

That gap is the problem with GPT Image 2.5 scientific figures. It is genuinely good enough to draw them now. Whether you can use them is a separate question with two parts: what your publisher allows, and what survives a careful read.

Which journals accept GPT Image 2.5 scientific figures

There is no single rule across publishing, and the differences are large enough that you should check before you generate rather than after.

The broad shape of it as of September 2026:

• Nature published a blanket ban on AI-generated images in submissions back in 2023 and later withdrew it, replacing it with a risk-tiered framework. The category that remains explicitly prohibited is photorealistic imagery.
• Science has been the most conservative of the three and has not relaxed: AI-generated illustrations require explicit editorial permission.
• Elsevier is the most useful to reason from because it names categories. Flowcharts, conceptual schematics and experimental workflow diagrams are permitted. Fabricating or altering original data images is not.

Two things follow, and they decide what you are allowed to attempt.

First, the safe zone is diagrams that carry no data. A flow diagram, a pipeline, an architecture overview, an apparatus schematic: all of these communicate structure that you already know. The model is doing layout, not measurement.

Second, anything derived from a raw image is out, regardless of how good it looks. This is not a style question or a quality question. It is a data-integrity question, and it does not have a workaround.

Always check your target journal's own author guidelines and disclose AI use where their policy requires it. The summary above is a starting point for deciding what to attempt, not a substitute for the policy you will actually be held to.

The GPT Image 2.5 style preamble for every figure prompt

Every prompt in this post starts with the same block. It is what separates a figure that looks like a paper figure from one that looks like a stock illustration.

An image for the body of an academic paper. White background,
restrained two-dimensional scientific illustration style, no
decorative background, no drop shadows, no meaningless icons. One
consistent sans-serif typeface. Text, numbers and connections must
follow the input exactly, adding no results or conclusions that were
not provided. Prioritise correctness and legibility at final print
size.

Each clause is there for a reason.

"No decorative background, no drop shadows, no meaningless icons" removes the three things that mark an image as not-a-paper-figure. Left unsaid, the default is a gradient background with a soft shadow under every box. I have also had a gear icon appear beside a box labelled "processing".

"One consistent sans-serif typeface" matters because the default behaviour is to vary weight and family for emphasis, which reads as a slide, not a figure.

"Adding no results or conclusions that were not provided" is the important one. Image models will write a P value under a comparison box on their own initiative, or add "significant" to an arrow. In a methods figure that is fabrication. Nothing in these four runs invented a number, and the two figures where it would have been easiest, the pipeline and the architecture, came back clean.

"Legibility at final print size" is a nudge toward larger type and fewer elements. A figure that reads on screen at 1024 px can be unreadable at one column width in print.

Figure 1: a participant flow diagram in GPT Image 2.5

The one at the top of this post. The prompt specifies every box and every edge, because that is how you get a figure that matches your actual study rather than a generic one.

[style preamble]

Draw a horizontal participant flow diagram. Starting cohort box
"Screened, n = 1240". An exclusion branch "Excluded, n = 240",
itemising "Missing imaging, n = 140" and "Missing outcome, n = 100".
Remaining box "Included, n = 1000". The included cohort splits into
"Training, n = 600", "Validation, n = 200" and "Internal test,
n = 200". Training points to "Model fitting"; Validation points to
"Hyperparameter selection"; both then point to a single box "Frozen
model". Frozen model is applied separately to "Internal test" and to
an independent "External cohort, n = 300", and both lead to
"Performance evaluation". The external cohort is not part of the
original 1240. No arrow may point from the test set or the external
cohort back to training or tuning. Use a solid line style for model
development and a dashed line style for final evaluation.

What came back was correct on every number, correctly nested the two exclusion reasons under the exclusion box, and got the solid/dashed legend right.

It got two edges wrong. The direction of one: the internal test box pointed into the frozen model rather than receiving from it. And a missing one: the prompt said both the internal test set and the external cohort lead to "Performance evaluation", but only the external cohort got that dashed arrow. On the figure, the internal test set is a dead end.

It is worth being exact about how I lost that one, because it is instructive. The prompt specified that direction only positively, in "Frozen model is applied separately to Internal test". My negative clause named training and tuning, not the frozen model. So the model did not break the rule I wrote; it broke one I had only implied. A negative instruction protects the boxes it enumerates and nothing else. Write it as "no arrow may point from Internal test or External cohort back into any earlier box".

This is the failure to design your checking around. Arrow direction encodes your methodology, and the model treats arrows as layout rather than logic. Read every edge out loud as a sentence, as in "the frozen model is applied to the internal test set", and check that the arrowhead agrees with it.

Figure 2: analysis pipeline

Multi-stage pipelines are the case where this is clearly faster than drawing one by hand.

[style preamble]

Draw a horizontal single-cell multi-omics analysis pipeline in four
stages, with no figure title.
Stage 1 "Study design": 8 donors, split into "Control n = 4" and
"Treatment n = 4", each donor giving a joint RNA plus ATAC
measurement of the same cells.
Stage 2 "Paired measurements": upper track "scRNA-seq / Gene
expression", lower track "scATAC-seq / Chromatin accessibility", the
two tracks linked by "Cell barcode" and labelled "Paired within
cells".
Stage 3 "Modality-specific processing": the RNA track runs "RNA QC"
then "Normalization" then "PCA"; the ATAC track runs "ATAC QC" then
"TF-IDF" then "LSI".
Stage 4 "Joint analysis": both tracks converge into "Weighted nearest
neighbors", which branches to "Joint embedding", "Cell clustering"
and "Cell-type annotation".
Below the main flow, a separate module "Donor-level comparison"
aggregates RNA raw counts by donor and cell type into "Pseudobulk
differential expression"; its input arrows come from RNA counts and
from Cell-type annotation, not from embedding coordinates.
Colour the RNA track blue throughout, the ATAC track orange
throughout, and the joint analysis purple. Do not add differential
gene counts, P values or disease conclusions.

This one came back essentially usable. The four stages are numbered and boxed, the three track colours (blue, orange, purple) never cross over, and the detail I was actually testing held: the pseudobulk module takes its arrows from RNA counts and cell-type annotation rather than from the embedding, which is the methodologically correct wiring and an easy thing to draw wrong.

One small deviation: the summary module along the bottom picked a fourth colour, teal, that was not in the prompt. It does not affect correctness, but if your figure has a strict colour key you will want to name that module's colour too.

It also obeyed the negative instruction: no invented gene counts, no P values, no disease claims.

The pipeline taught me two things worth carrying forward. Numbering your stages in the prompt gets them numbered in the figure, which saves a revision round. And assigning a colour per track, as in "RNA blue throughout", is more reliable than asking for "a clear colour scheme", because it gives the model a rule it can apply rather than a goal it has to interpret.

Figure 3: model architecture

These are tedious to draw by hand, and nearly compulsory in a methods paper. This was the most complex specification of the four and it held up.

[style preamble]

Draw a network architecture overview for a 3D encoder-decoder
segmentation model with residual blocks and a dilated bottleneck.
Left to right: an input volume labelled "Input 1 x 128 x 128 x 128".
A contracting path of four stages, each a residual convolution block
followed by downsampling, with channel counts 32, 64, 128 and 256
written on each stage. A bottleneck of three parallel dilated
convolution branches with dilation rates 1, 2 and 4, concatenated.
An expanding path of four stages mirroring the contracting path, each
an upsampling step followed by a residual convolution block, with
channel counts 256, 128, 64 and 32. Skip connections drawn as
horizontal arrows joining each contracting stage to the expanding
stage at the same resolution. A final 1x1x1 convolution to an output
labelled "Segmentation map". Include a small legend distinguishing
residual block, downsample, upsample, skip connection and dilated
convolution. Do not add accuracy numbers or dataset names.

Channel counts correct in both directions, the dilated bottleneck built and concatenated properly, skip connections joining matched resolutions, and a complete legend. No invented accuracy numbers.

The one deviation was stylistic rather than factual: the preamble asked for restrained two-dimensional, and it produced isometric 3D blocks. For a network figure that is a defensible convention, but if your journal wants flat, say "flat two-dimensional rectangles, no isometric or perspective drawing" explicitly, because "two-dimensional" alone did not carry.

The pattern across the four is not the one I expected going in. What the model renders faithfully is anything I enumerated: boxes, counts, colours, components, order. What it gets wrong is anything it has to infer, and edge direction is almost always inferred. The architecture figure came out strongest because every channel count and every connection was written down. The flow diagram slipped on the one edge whose direction was left implied.

Figure 4: experimental setup

The fourth type worth having is the apparatus schematic, the figure that shows a reader how the experiment was physically arranged.

[style preamble]

Draw a schematic of a laboratory perfusion experiment setup, viewed
from the side as a clean line diagram. From left to right: a "Medium
reservoir" flask, connected by tubing to a "Peristaltic pump", then
to a "Bubble trap", then into a "Perfusion chamber" that sits on the
stage of an inverted microscope drawn in simplified outline. An arrow
from the chamber outlet returns to a "Waste bottle". Label the flow
direction along the tubing with small arrows. Mark the chamber with
"Temperature 37 °C" and "Flow 0.5 mL/min" as annotated callouts with
leader lines. Include an inset box in the upper right showing a
magnified cross-section of the chamber with "Cell monolayer" on a
coverslip and "Laminar flow" shown as parallel streamlines above it.
Do not include brand names, model numbers or manufacturer logos.

Every component present and in order, flow arrows pointing the right way, both callouts attached by leader lines, and the inset drawn as asked with the monolayer on the coverslip and laminar streamlines above it.

The Do not include brand names, model numbers or manufacturer logos line is doing quiet work here. Lab equipment in training data is covered in manufacturer marks, and an invented logo on a pump is both a trademark problem and an implicit claim about your methods.

The line you cannot cross with AI scientific figures

Everything above is a diagram you specified. There is a neighbouring use that looks similar and is not publishable.

If you hand an image model a medical scan and ask it to outline the lesion, it will return something that looks like a segmentation. It is not one. The model redraws the scan and paints an outline onto the redrawing. The contour may look plausible against the original, but pixel for pixel the underlying image is no longer your data. It is a new image that resembles your data.

That fails on two counts at once. It is a fabricated data image under every policy quoted at the top of this post. And even setting policy aside, the boundary it draws carries no measurement, so any area or volume you compute from it is meaningless.

The same reasoning rules out generating detection boxes, heat maps or any other overlay on real data. If you need a segmentation, produce it with a segmentation method and render the overlay in code, where the original pixels are preserved and the mask is an actual mask.

The reason this one matters more than a wrong arrow is that it is invisible. A wrong arrow gets caught in review.

Statistical plots: write code, not a GPT Image 2.5 prompt

Box plots, ROC curves, forest plots, survival curves: none of these should go near an image model. The model would probably draw them beautifully. That is the problem.

A plot is a rendering of your data. It has to be reproducible from that data, it has to be regenerated when a number changes, and a reviewer may ask for the code. Ask a language model for a plotting script and you get something you can run, check and version. Ask an image model for a plot and you get a picture of a plot, with axis values it invented.

The division is clean: if the numbers come from your data, write the plotting code. If the figure only shows what you designed, generate it.

What GPT Image 2.5 still gets wrong in scientific figures

Four figures is a small sample, but four things are worth checking every time.

Edge direction, and missing edges. Covered above, and the ones with real consequences. A reversed edge and an absent edge do the same damage. Read every edge as a sentence, then count that all the edges you asked for are actually there.

Typographic conventions. Journals want the sample-size n in italics. Neither of the two figures that carries an n italicised it, and I would not trust the model to stay consistent about it within a single figure either. It is a small thing that makes a figure look unprofessional, and it is one of the things you cannot proofread out of a raster image.

Dense small labels. None of these four hit it, because none of them is label-heavy. But the smallest type is what degrades first in this genre, and the pipeline figure was already close to the limit at four stages. If your figure needs twenty labels, it probably wants to be two figures.

Empty margins. Figures 1 and 3 both left the drawing occupying about two-thirds of the canvas. For print you will want to crop to the content, so do not judge a figure's proportions from the raw output.

Fixing a figure without regenerating

When a figure is nearly right, regenerating is usually the wrong move, because you lose everything that was right along with the mistake.

Better to do one of two things. Ask for a targeted edit, along the lines of "keep everything, reverse only the arrow between Frozen model and Internal test". Precise editing is one of 2.5's headline improvements, though I have not put this particular fix through it. Or rebuild the near-miss in an editable tool. Taking a good generated layout into slides or a vector editor and fixing the one wrong edge by hand takes a couple of minutes and gives you a source file you can update when a reviewer asks for a change. For a figure that will go through revision rounds, having an editable version eventually matters more than how it was first drawn.

GPT Image 2.5 settings for scientific figures

These are the settings behind the four figures above:

A note on resolution. 1K is enough to judge whether a figure is correct, which is the expensive question, and correctness is what you should be testing on the first pass. It is not enough for submission: a journal will want 300 dpi or better at final column width, so once a figure is right, regenerate it at 2K or 4K before you place it.

Both GPT Image 2.5 models run in the browser on the GPT Image 2.5 page without a ChatGPT account. An image costs 8 credits at the default medium quality and 1K; high quality and 2K or 4K cost more, and the generator shows the price before you run. New accounts start with free credits, which is enough to test whether your figure specification survives the trip.

Which GPT Image 2.5 model to use for figures

Everything here ran on Flare, the default, and I did not rerun any of it on Sunburst. For line-and-box figures I would not expect the extra time to buy much: the failures here are logical rather than optical, and more rendering time does not make a model read your methodology more carefully.

Sunburst's advantage shows up on material, light and fine texture, which is a different kind of figure: a rendered mechanism illustration, a realistic apparatus drawing, a cover image. Our Flare and Sunburst comparison has the side-by-sides. For methods figures, generate on Flare and spend the time you saved proofreading edges.

Writing the AI disclosure for your paper

Most policies that permit generated diagrams also require you to say that you used a model. It belongs in the methods section or the figure legend, depending on the journal, and it needs three facts: which tool, what it was used for, and who checked the result.

A sentence that carries all three:

That last clause is the one worth keeping. It pre-empts the question an editor is actually worried about, which is whether anything in your figures came out of your data.

Two more things worth knowing. Check whether your journal wants the disclosure in the methods, the figure legend, or a separate AI-use statement, because all three exist. And if a figure was generated and then hand-edited, say so: "drafted with [tool] and edited by the authors" is both accurate and reassuring.

AI figures in theses, grants and posters

The journal bar is the strictest one you will meet, and most figures are not headed to a journal.

Theses normally follow the institution's own policy rather than a publisher's, and those are usually less restrictive about illustration but more explicit about disclosure. Check your graduate school's statement on generative AI.

Grant applications care about accuracy rather than provenance. A generated pipeline figure is unremarkable; the risk is the same one as everywhere, which is a diagram that implies a design you are not proposing.

Conference posters and slides are the loosest use, and the easiest place to start. A poster wants a clear pipeline figure more than it wants a publication-grade one, and nobody is going to ask for the source file.

The two constants: no data-derived imagery, and check every arrow.

A GPT Image 2.5 figure workflow that survives review

1. Decide the figure type before the policy matters. If it carries data, stop; nothing below applies.
2. Write the figure as a specification, not a request. Every box, every edge, every label, in words. The prompts above are long because the figures are exact.
3. Keep the style preamble byte-identical across every figure in one paper, so they look like a set.
4. Proofread every edge as a sentence before anything else. This is where the real errors are.
5. Keep an editable version of any figure that will go through revisions.
6. Disclose AI use where the journal's policy asks for it.

You can run these prompts in the browser on the GPT Image 2.5 page, or from the text-to-image generator if you want to control ratio and quality between attempts.

The Bottom Line

For flow diagrams, pipelines, architectures and apparatus schematics, GPT Image 2.5 now gets close enough to journal standard that it is worth starting there rather than in a drawing tool, as long as you budget for a proofread and often a round of hand-fixing in something editable. It held every number in a participant flow, kept a three-colour scheme across a four-stage pipeline, and built a network architecture with correct channel counts and skip connections, then pointed one arrow backwards in the figure where direction was the whole point. Treat it as a fast draughtsman with no understanding of your methods. Specify everything. Then read every edge before you believe any of it.

Related reading

• GPT Image 2.5 Flare vs Sunburst: 6 Same-Prompt Tests
• GPT Image 2 Knowledge Graph Prompt Guide: 5 Production Templates
• Can You Use GPT Image 2 Commercially? Copyright Guide
• GPT Image 2.5 3D Map Prompts: Cities as Miniature Dioramas

gpt-image2.art is an independent site and is not affiliated with OpenAI. Publisher policies are summarised as of September 2026 and change; check your target journal's current author guidelines before submitting AI-generated figures.