Skip to content

ChordEdit: One-Step Low-Energy Transport for Image Editing

Best Student Paper Honorable Mention · CVPR 2026Generative modeling

ChordEdit performs text-guided image editing in a single step for one-step image generators, without training or inversion, using a low-energy control field derived from dynamic optimal transport. On PIE-bench the full version runs in 0.38 seconds.

Explanation level

One-step image generators are fast, but editing with a text prompt tends to distort objects and damage the background. ChordEdit smooths the editing signal through an optimal-transport view so that one large step becomes safe. This article reads the method, the numbers verified against the paper, and what the paper does and does not claim.

Overview

ChordEdit edits an image from a text prompt using a one-step text-to-image generator such as SD-Turbo, InstaFlow or SwiftBrush-v2. It needs no training and no inversion (a step that maps the real image back to noise). Input: a source image, a source prompt and a target prompt. Output: the edited image.

The authors claim four contributions: a dynamic optimal-transport view of editing; the Chord Control Field, a smoothed editing signal that is stable enough for one large step; an optional proximal refinement; and PIE-bench experiments with ablations. It matters because interactive editing needs speed and a stable result at once.

Research Problem

Training-free, inversion-free editors such as FlowEdit and InfEdit build an editing field by subtracting the model's prediction under the source prompt from its prediction under the target prompt. Over many steps this is stable. Forced into one step, the paper reports two failures (Figure 3): the edited object is distorted, and the background and surrounding structures break up.

The authors' explanation is that distilled one-step models respond very non-linearly to the text condition, so the difference of two large, diverging predictions is an erratic, high-energy field, and one large integration step accumulates its error. The one-step alternative SwiftEdit avoids this by training a dedicated inversion network, which gives up the training-free, model-agnostic setting.

Key Idea

The core idea is the Chord Control Field. Take the naive editing field at two times, t-δ and t, and blend them with weights t/(t+δ) for the earlier point and δ/(t+δ) for the later one. This is temporal smoothing: it lowers the field's energy and variance, so one large step along it is safer.

Tiny example: with t=0.90 and δ=0.15 the weights are about 0.857 and 0.143. With δ=0 the blend is the naive field. The name comes from replacing a wobbly curve by the chord between two of its points. Both queries fit in one batch, so the transport step still costs one network evaluation.

Methodology

EyeCode diagram: two queries at t and t-delta blend into the chord field, then one step and optional refinement
EyeCode schematic (original illustration of the method as described in the paper; not a reproduction of the authors' figure) · EyeCode Tech (Original EyeCode illustration) · Source

Inputs are the source image latent (in the VAE latent space), a source prompt and a target prompt. The anchor is the clean source latent, so no inversion is needed. With one noise sample (n=1), the model is queried at t=0.90 and t-δ=0.75 under both prompts. The prompt difference is converted by a time-only linear map into velocity units, which lets noise-prediction models (SD-Turbo) and velocity models (InstaFlow) share one template.

The two results are blended into the chord field û, and the transport step is x_pred = x_src + λû with λ=1. All intermediate quantities are computed in one batch, so this counts as 1 NFE (network function evaluation). The optional proximal refinement is one more forward pass with the target prompt only, at t_c=0.30, using the model's x0 prediction with a fixed noise draw. With it the method is NFE=2; without it, NFE=1. The authors ran everything on a single 24 GB NVIDIA Titan GPU.

Experiments & Results

Table 1 of the paper (main text), PIE-bench: ten of its twelve method rows, base model in brackets, MSE and LPIPS printed x10^3. Higher is better for PSNR and CLIP-Edited; lower is better for the rest. Left out here: DDIM+MasaCtrl, DDIM+PnP and the CLIP-Whole column. The appendix Table 4 repeats these rows with identical values (only the DDIM+MasaCtrl runtime differs, 55.20 s versus 55.19 s) and adds SSIM, structure distance and the naive rows.
Method (base model)PSNRMSELPIPSCLIP-EditedNFERuntime (s)VRAM (MiB)
Direct Inversion + MasaCtrl21.787.9987.3821.3810079.1012272
Direct Inversion + PnP21.438.10106.2622.6310028.039262
FlowEdit (SD3)22.177.69104.8123.69337.2217140
TurboEdit (SDXL-Turbo)21.449.49108.6021.7942.6913826
InfEdit (SD1.4)24.146.8255.6921.8841.416502
InstantEdit (PeRFlow-SD1.5)23.804.2160.9221.8281.3016270
SwiftEdit (SwiftBrush-v2)21.718.2291.2221.8520.5415060
ChordEdit (SwiftBrush-v2)22.047.13111.2222.5820.386988
ChordEdit w/o prox (SD-Turbo)23.895.0588.3621.8710.206988
ChordEdit (SD-Turbo)22.206.84128.2522.9620.386988
Tables 2, 3 and 4 of the paper combined: naive field (δ=0) versus Chord field (δ=0.15). PSNR and CLIP-Edited come from Tables 2 and 3, MSE and LPIPS (x10^3) from the appendix Table 4. With prox means NFE=2; w/o prox means NFE=1 (SD-Turbo only). Higher is better for PSNR and CLIP-Edited, lower for MSE and LPIPS. The SD-Turbo with-prox LPIPS gain is small (131.30 to 128.25).
BackboneFieldPSNRMSELPIPSCLIP-Edited
InstaFlow (with prox)Naive (δ=0)22.0510.45103.3320.19
InstaFlow (with prox)Chord (δ=0.15)23.055.4553.3321.39
SwiftBrush-v2 (with prox)Naive (δ=0)20.5217.17127.4321.06
SwiftBrush-v2 (with prox)Chord (δ=0.15)22.047.13111.2222.58
SD-Turbo (with prox)Naive (δ=0)21.389.73131.3021.96
SD-Turbo (with prox)Chord (δ=0.15)22.206.84128.2522.96
SD-Turbo (w/o prox)Naive (δ=0)21.8910.84105.2720.83
SD-Turbo (w/o prox)Chord (δ=0.15)23.895.0588.3621.87
User study (appendix J, Figure 21; the paper presents it as a figure, not a table): share of votes in a four-way blind comparison, 150 participants x 30 prompts = 4,500 votes per criterion. Each column sums to 100%.
MethodSemantic alignment (%)Preservation quality (%)
ChordEdit42.548.3
FlowEdit25.37.1
InfEdit19.635.4
SwiftEdit12.69.2
Log-scale bar chart: runtime per edit of nine configurations on PIE-bench, ChordEdit 0.38 and 0.20 seconds, Direct Inversion + MasaCtrl 79.10 seconds
EyeCode redraw of the runtime column of Table 1 (log scale). Original illustration, not the authors' figure. · EyeCode Tech (Original EyeCode illustration) · Source
Dot plot: PSNR and CLIP-Edited of the naive field versus the Chord field on InstaFlow, SwiftBrush-v2 and SD-Turbo
EyeCode redraw of Table 3 (axes start at 20, not zero). Original illustration, not the authors' figure. · EyeCode Tech (Original EyeCode illustration) · Source

Protocol. PIE-bench: 700 images in 10 editing categories, 512x512, with edit masks. Background fidelity: PSNR and MSE on the non-edited region, and LPIPS. Semantics: CLIP-Whole and CLIP-Edited. No method used protective masks, and each baseline ran on its officially specified model. Baselines: DDIM and Direct Inversion with MasaCtrl or PnP, FlowEdit, TurboEdit, InfEdit, InstantEdit and SwiftEdit (first table).

Headlines. The full SD-Turbo ChordEdit takes 0.38 s, NFE=2, 6988 MiB, with CLIP-Edited 22.96; FlowEdit takes 7.22 s and 17140 MiB with 23.69. The transport-only variant reaches PSNR 23.89 in 0.20 s. The Chord field beats the naive field on InstaFlow, SwiftBrush-v2 and SD-Turbo (second table). In the user study ChordEdit was chosen most often for semantics (42.5%) and preservation (48.3%) (third table).

Not uniform. InfEdit has higher PSNR (24.14) and far lower LPIPS (55.69) than full ChordEdit, FlowEdit has higher CLIP-Edited, and InfEdit uses less VRAM (6502 MiB).

Limitations

Reported by the authors

The paper has no limitations section. Its conclusion and Appendix I acknowledge that real-time, consistent edits could be used for deceptive content and that edits may inherit and amplify biases of the underlying pretrained model. The appendix also notes that δ above about 0.3 over-smooths and lowers CLIP, and that a stronger refinement (higher t_c) trades background fidelity for semantics.

EyeCode analysis (editorial interpretation)

From Table 1, ChordEdit does not lead every column: InfEdit has better PSNR, LPIPS and VRAM, and FlowEdit has higher CLIP-Edited. With the proximal step on SD-Turbo, the LPIPS gain over naive is small. The evidence is one benchmark and the authors' own runs; the text we read shows no failure cases of ChordEdit itself and no independent replication.

Key Takeaways

Lessons from the paper:

  • A naive difference of two prompt-conditioned predictions is a high-energy field that breaks in one step; smoothing it in time is enough to make a large step usable (Tables 2 and 3).
  • The chord field is a convex blend of two queries, so it lowers energy without extra NFE because the queries share a batch.
  • Separating transport from refinement gives a knob: without prox PSNR 23.89, CLIP-Edited 21.87; with prox PSNR 22.20, CLIP-Edited 22.96.
  • Judge editors on quality, runtime and memory together: no method in Table 1 wins every column.

Suggested directions (EyeCode suggestions, not claims from the paper)

  • Test whether the chord smoothing carries over to other backbones or to video editing, which the paper does not study.

References

  1. ChordEdit: One-Step Low-Energy Transport for Image Editing (arXiv 2602.19083v2; Tables 1-4, Sections 3-6, appendices A-K)
  2. CVPR 2026 Open Access: ChordEdit
  3. CVPR 2026 Best Papers
  4. ChordEdit project page
  5. ChordEdit code repository (README)

KEEP EXPLORING

Keep connecting the ideas.