FireFlow: Fast Inversion of Rectified Flow for Image Semantic Editing

We sincerely appreciate the authors for carefully verifying our theoretical claims and constructive comments. Responses to your concerns as follow:

Q1: Include the original midpoint method's results in Table 4 and its inference time in Table 5.

• Although both ours and Midpoint are 2nd-order solvers, they exhibit different numerical stability when applied to ReFlow ODE. Since $v_\theta(x,t)$ predicted by neural network is not perfectly accurate, numerical solvers handle the resulting noise differently. Ours demonstrates robustness to these inaccuracies, leading to slightly better results.

Q2: Fig. 3 should include error analysis of the original midpoint. Fig. 4 and 7 can include RMSE of the original midpoint.

• Thanks for valuable suggestions. We hope to clarify that Fig. 3 illustrates the approximation error between the estimated midpoint velocity and true midpoint velocity. The original midpoint method does not involve such an approximation, so an error analysis is not applicable. Regarding Fig.7 with RMSE values, we revised the illustration of RMSE versus ODE steps "for better understanding of the effects of modification of the first substep of the midpoint method" at link.

Q3: Can authors include the prompts used in Fig. 6?

• Due to this year’s strict character limit for rebuttal, we hope to include the prompts in appendix to make room for addressing your other insightful comments. We appreciate your understanding.

Q4: How many sampling steps were used to compute time cost in Table 5?

• We used 8 steps for FireFlow, 15 steps for RF-Solver, and 28 steps for RF-Inversion, consistent with Table 4. We appreciate your suggestion and will include an additional column to indicate the number of steps.

Q5: Table 4 mentions steps for RF-Solver as 15 but line 328 mentions it as 25.

• We hope to clarify that line 328 states, “up to 25 steps.” According to RF-Solver's official code, step number is not fixed and up to 25. Since 15 steps results in a computational cost comparable to RF-Inversion, we report 15 in Table 4 for a fair comparison.

Q6: In Fig. 2, how were the pairs of points for plotting the transport maps/trajectories chosen? The number of points in transport maps are fewer than scatter plots.

• We strictly follow the official instructions provided by the original ReFlow paper for visualizing Fig. 2. According to their code, the first 30 pairs of points are selected to draw the transport trajectory, while all pairs are used for the scatter plot.

Q7: Could authors elaborate why trajectories of midpoint method are less straight than the proposed method?

• Please kindly refer to Reviewer ekVQ’s Q3, where we explain why FireFlow performs better.

Q8: Alg. 1 and 2 mention $V_{t_{N-1}}^{inv}$ in self-attention layers. Could you elaborate the context of self-attention layer? Isn’t $V_{t_{N-1}}$ simply the prediction of ReFlow model? How does this relate to the discussion in Lines 1008-1012?

• We hope to clarify that $V_{t_{N-1}}^{inv}$ refers to the $V$ feature in $\text{softamx}(\frac{QK}{\sqrt{d}})V$ within the self-attention layer of ReFlow model, whereas $v_{t_{N-1}}(X_{t_{N-1}})$ denotes the prediction of network. Algorithms 1 and 2 mentioned $V_{t_{N-1}}^{inv}$ as it involved in the editing technique introduced by RF-Solver, which we follow to ensure a fair comparison (detailed in “Image Semantic Editing” section). We observe that using $V_{t_{N-1}}^{inv}$ can lead to certain failure cases, and Lines 1008-1012 discuss its limitations along with some simple alternatives.

Q9: Have authors tried using proposed method for unconditional image generation from ReFlow models?

• Thanks for your suggestions. We follow the original ReFlow paper’s protocol for unconditional image generation on CIFAR10, using open-source 1-Rectified-Flow-distill weights. Our method performs well:

Q10: Can FireFlow be used for solving SDEs similar to original Midpoint method? Do any assumptions in the proof not hold?

• In fact, neither FireFlow nor the original Midpoint can be directly applied to SDEs because they do not properly handle the stochastic term. The noise term $dW_t$ in SDE representing a Wiener process is nowhere differentiable, rendering approximations that rely on smoothness invalid. Besides, if someone tries to use a midpoint method, would implicitly assume a Stratonovich interpretation, while SDEs are defined in the Itô sense. Standard ODE solvers don’t account for the correction term required when switching between these interpretations.

We sincerely appreciate the reviewer’s detailed feedback and constructive suggestions for improving our paper. Below are our responses to your concerns:

Q1: As shown in Table 2, the effect of the 20-step method should be compared again to observe how much better its solver performance is compared to the synchronous number.

• Thank you for your valuable suggestion. We have now reported all three methods with the same 20 steps, and our approach continues to outperform the others, as shown below:

Q2: Some chart captions are too simple, such as Table 2, Table 4, and Figure 6.

• Thank you for pointing that out. We will revise the descriptions for Table 2, Table 4, and Figure 6 to make the captions more complete and self-explanatory.

Q3: In Figure 2, why is the result of a low-cost approximation of the Midpoint method even better than the Midpoint method under the same NFE?

• To clarify, the standard Midpoint method requires 2 NFEs per step, whereas our approach requires only 1 NFE per step. This means that, under the same computational cost, our method effectively has more steps. Using more steps (i.e., smaller step sizes) generally improves accuracy by reducing truncation error, which is bounded by the step size, in the discretization of the continuous ODE. This explains why our low-cost approximation achieves better results despite using the same total NFE.

Q4: Except for the approximation, what are the most valuable contributions of this paper, according to the author?

• We believe our work challenges the conventional notion that high-order ODE solvers must be computationally expensive. Beyond mere approximation, we introduce a new direction for accelerating ReFlow ODEs with a solid theoretical foundation and a fully training-free approach. Our method is distinctly different from training-based distillation and traditional model compression techniques. The modified Midpoint method simply serves as a starting point, we are actively exploring a broader group of high-order methods to further enhance efficiency.

Q5: Under different seeds, what is the comparison of the results produced by inversion and editing, and do they have diversity?

• We would like to clarify that, unlike T2I which begins from random noise, inversion-based editing and reconstruction start from a fixed original image as the initial point in the ReFlow ODE. As shown in Algorithm 1 and 2, solving the inversion and denoising ODE do not involve any randomness, resulting in no diversity across different seeds. For a quantitative analysis, please kindly refer to our response to Q1 for Reviewer MGiL.

Q6: When NFE is extremely small (1-4), how is the performance? Some distillation-based methods seem to be able to achieve inversion and generation with fewer steps.

• Thank you for your insightful question. Our current modified midpoint method is not designed for extremely small NFEs (1–4) and the results are unsatisfactory. However, we are actively exploring this avenue and have found higher-order solvers compatible with FireFlow, enabling faster inversion with as few as 4 steps, yet this exploration seems to extend beyond the scope of this submission.
• Regarding distillation-based methods, FireFlow is a fully training-free approach, making direct comparisons with training-based methods less fair. Besides, efficient solver introduces a novel perspective for accelerating ReFlow models, offering a distinct and complementary direction to existing techniques.

Q7: Why does this article indeed compare with methods such as dpmsolver++, unipc, etc., and why can't these methods be adapted to the sampling method of rectified flow?

• DPM-Solver++ and UniPC rely on diffusion model ODEs, which contain an analytically tractable term. ReFlow lacks this structure, making these solvers ineffective. Specifically:
  • Fast solvers for diffusion models exist because traditional diffusion trajectories are curved and inefficient, requiring precise numerical integration. In contrast, ReFlow straightens these paths. Since DPM-Solver++ and UniPC refine curved trajectories through multi-step corrections, they are unnecessary for ReFlow. Instead, as demonstrated by FireFlow, an efficient solver for ReFlow should focus on minimizing discretization error without requiring multiple steps.
  • Formally, both DPM-Solver++ and UniPC leverage the diffusion model ODE structure $\frac{dx}{dt}=f(t)x+g(t)e\_\theta(x,t)$ where the linear term $f(t)x$ allows for partial analytical integration, enabling efficient numerical solvers. However, ReFlow follows a different ODE $\frac{dx}{dt} =v_\theta(x,t)$ which lacks an explicit drift term $f(t)x$. As a result, the analytical simplifications used by DPM-Solver++ and UniPC do not apply, making these fast solvers inapplicable without a fundamental redesign.

We sincerely appreciate the authors for carefully verifying our theoretical claims, especially given the heavy review process. We will do our best to address your concerns.

Q1: It is a fully training-free method which does not involve 'learning' methods which are better aligned with ICML.

• We respect the reviewer’s opinion on whether a fully training-free method fits within the scope of machine learning. However, we believe that generative models are a prominent topic in the field of machine learning, and the ReFlow model, as a pioneering work in this area, warrants attention. FireFlow, with its efficiency gains, demonstrates practical applicability, which aligns with the interests of the machine learning community, hence aligns with ICML.

Q2: Whether it will be better to estimate the next midpoint velocity by measuring the current velocity and previous velocity to propagate, achieved by Numerical Extrapolation (using the previous two velocity values from the network to extrapolate next midpoint)?

• Thank you for your insightful suggestion. If we understand correctly, the proposed numerical extrapolation involves using the previous two velocity values, $v_t$ and $v_{t-1}$, generated by the network to approximate the next midpoint velocity as $\hat{v}\_{t+\frac{1}{2}\Delta t}=v_t + 0.5(v_t-v_{t-1})$ and updating the state as $X_{t+1}=X_t+\Delta t\cdot\hat{v}_{t+\frac{1}{2}\Delta t}$. To evaluate this approach, we have conducted an ablation study on step selection, and our approach continues to outperform the others, with results on PIE-Bench presented below:

Q3: Whether the proposed method will downgrade to 1st-order ODE if the velocity estimation of the midpoint is not accurate enough, whether the method can be well generalized to other ReFlow models, especially when $v$ is not accurate enough.

• Thank you for your insightful question. We recognize that the robustness of our approach, particularly when velocity estimation is less accurate, is an important aspect to explore further. Since the accuracy of $v$ directly impacts image quality, we assess our method on earlier-generation, medium-sized Stable Diffusion models, such as SD3-medium, which has a significantly lower ELO score than the FLUX model and serves as a meaningful test case. We apply different ODE solvers to ReFlow-based editing, and the results on PIE-Bench are as follows:

• While the speedup rate is lower than FLUX, our method consistently outperforms 1st-order ODE across most metrics, achieving approximately a 2× speedup while maintaining high-quality results. Given that the accuracy of $v$ is directly linked to image quality, we believe it is more meaningful to focus on state-of-the-art models with higher accuracy and better generation capabilities—such as the FLUX model, as discussed in our paper.

Q4: The paper does not introduce enough novelty in inversion and editing, with problems like all other inversion-based method like poor identity preservation.

• We respectfully disagree with the claim that our work lacks novelty in inversion and editing. Our fast ODE solver for ReFlow introduces a fundamentally new approach to accelerating generative models, with no direct overlap with existing acceleration methods. This is substantiated by both rigorous theoretical analysis and extensive experiments, demonstrating clear improvements.
• As with any training-free editing method, certain failure cases are expected, and claiming otherwise would be unrealistic. This is precisely why we have transparently acknowledged limitations in the appendix. However, occasional challenges in identity preservation should not overshadow the consistently strong performance demonstrated on widely recognized benchmarks. Our results indicate that FireFlow surpasses prior methods in efficiency and effectiveness.
• More importantly, our core contribution extends beyond individual editing performance—it establishes a new direction for accelerating ReFlow models. This is not merely an incremental improvement but a principled advancement, supported by both theoretical foundations and empirical validation.

Q1: Results on PIE-Bench are reported with fixed seed? Variance across multiple runs is not reported.

• Thank you for your valuable feedback. To clarify, T2I generation starts from random noise determined by seed, while inversion-based editing starts from a fixed image as the initial point in ODE and solving ODE does not involve randomness. Nonetheless, we have re-run the experiments 5 times using different random seeds:

Q2: Minor gaps in dataset diversity and human evaluation.

• Thank you for your comment. We evaluated FireFlow using three public datasets—MSCOCO Caption, Densely Captioned Images (DCI), and PIE-Bench—across T2I, inversion, and editing tasks. While additional experiments could further support our findings, the current results already show significant improvements over recent methods. Notably, PIE-Bench includes 10 diverse editing tasks, including style transfer, as requested.
• Regarding human evaluation, we are conducting a crowdsourced blind experiment. Due to time constraints, we couldn’t gather enough voting results for the rebuttal. However, we will include the user study results in the appendix for a more comprehensive evaluation.

Q3: Without controlling for NFEs or steps for baseline methods, will the claimed speedup (e.g., "3× runtime speedup") be exaggerated?

• Thank you for your insightful question. To clarify, we did not intentionally increase the NFEs or steps in the baseline methods to exaggerate the reported speedup. We followed the standard settings for a fair comparison. Besides, we conducted an ablation study on RF-Inversion and RF-Solver, which shows that reducing the number of NFEs or steps leads to higher image editing failure rates. This demonstrates that the selected steps are more optimal for editing tasks.

Q4: More discussions on the cause of limitation should be given. Any solutions for these cases?

• Thank you for your valuable comment. As a fast, training-free inversion-based editing method, we believe the limitations of our approach can be attributed to the following factors, along with potential solutions:
  • Practical conditions vs. Proposition 4.1: As shown in Table 4, increasing the number of steps contributes to smoother velocity, which in turn improves performance. Additionally, more powerful ReFlow models offer more accurate velocity estimations, helping to bridge the gap between the theoretical assumptions and real-world scenarios. This is reflected in Table 7, where SD3.5 performs better than SD3.
  • Editing technique compatibility: Our method works as a fast solver for ReFlow models, which makes it compatible with other ReFlow-based editing techniques. However, it inherits both the strengths and weaknesses of those methods. As such, improving the design of the editing technique itself will further enhance the performance of our approach.
  • Prompt suitability: It is well-known that prompt engineering plays a crucial role in image generation. The official prompt for PIE-Bench is relatively brief, which could limit further improvements in editing quality. A more sophisticated vLLM-based prompt generator could better align the prompt with the editing task and yield better results.

Q5: Experiments focus on ​semantic edits (e.g., object replacement). Complex edits like stylization, multi-object manipulation is unexplored.

• Thank you for pointing that out. We apologize for the bias in the illustrations, which mainly focus on object replacement and may have been misleading. In fact, our approach performs well on more complex tasks, including stylized generation and multi-object manipulation. For additional results, please refer to the following anonymous link.

Q6: Can this method be extrapolated to further accelerate by approximating higher-order methods through more caching intermediate steps?

• Thank you for your insightful suggestion. We are actively exploring this avenue and have already found higher-order solvers compatible with FireFlow, enabling faster inversion with as few as 4 steps. We are also working towards a theoretical proof that a class of numerical solvers can be accelerated in this way.
• However, we believe the current submission is self-contained, and we view this as an exciting direction for future work. We appreciate your suggestion and plan to explore it further in subsequent research.