FlexEvent: Towards Flexible Event-Frame Object Detection at Varying Operational Frequencies

We sincerely thank Reviewer RR3R for the thoughtful assessment and helpful suggestions, and we appreciate the recognition of our good presentation and comprehensive experiments. Below, we respond to your comments and suggestions in detail.

---

Q1: "Does Eq. (2) use Kronecker delta functions? Please clarify the notation."

A: Thanks for your comment. Yes. In Eq. 2, the symbols $\delta(·)$ denote Kronecker deltas over discrete indices (polarity, time bin, and pixel coordinates). We will add a sentence in Sec. 3.1, stating this explicitly to avoid ambiguity. This event-tensor construction (discrete binning with deltas) is standard and follows the RVT formulation.

---

Q2: "The event representation and pre-processing follow the design in RVT, but no citation is provided here."

A: Thank you for asking. We apologize for our oversight. We will add an explicit citation to RVT in Sec. 3.1, where we construct the event tensor, and state that our implementation follows RVT to enable 2D convolutions.

---

Q3: "It is unclear how a 4D tensor is processed with 2D convolutions for subsequent RGB-event fusion."

A: Thanks for your insightful concern. As in RVT, we flatten polarity and time into the channel axis, converting the 4D tensor to a 3D tensor of shape (2T, H, W) that is directly compatible with 2D convolutions. We will add more details about the data processing in the supplementary material.

---

Q4: "With dynamic aggregation, how is the high-frequency event slice aligned with the prediction time at the end of the sampling interval?"

A: We appreciate this valuable question. Our detection is anchored at the end timestamp $t_2$ of the labeled interval $[t_1, t_2]$ with $t_2 = t_1 + \Delta t_a$. The inputs are: the RGB frame $F(t_2)$, the low-frequency event aggregation $E_a=[t_1, t_2]$, and one high-frequency event slice $E_b$ of duration $\Delta t_b$. We randomly sample $E_b$ within $[t_1, t_2]$; in practice, we allow a millisecond-scale jitter so the slice may end at $t_2-\varepsilon$ ($\varepsilon$ is small), which serves as implicit temporal augmentation against synchronization noise. This keeps the prediction target (the boxes at $t_2$) aligned with its preceding event evidence, ensuring $(F, E_a, E_b)$ are consistently paired across modalities and frequencies for subsequent fusion and decoding.

---

Q5: "RGB and event cameras may differ in intrinsics/extrinsics/resolution; events also show duplication from temporal accumulation. Did you consider cross-modal alignment?"

A: Yes. We synchronize the event stream and frames over $[t_1, t_2]$ and operate in a common image plane $H \times W$ before fusion (resize/rectify using the dataset’s provided calibration). FlexFuse then adapts the contribution of the two modalities via learned soft weights, which mitigates residual appearance/geometric mismatch and duplication artifacts at the feature level. We will add a short implementation note on using the provided calibration and the shared resolution in the revised version.

---

Q6: "In Eq. (7), what is the weighting factor $\lambda$? What happens if $\lambda=0$ (no regularization)?"

A: Thank you for pointing this out. Eq. 7 adds a variance-over-mean regularizer on the fusion gates ($\alpha$, $\beta$) with weight $\lambda$. We use a small positive $\lambda = 0.1$ chosen on the validation set. This regularization ensures balanced utilization of both the event and frame branches, and it penalizes large variations in the soft weights, encouraging a more uniform contribution from both modalities. Intuitively, setting $\lambda = 0$ removes the balance constraint and can let one branch dominate. In practice, we observe a small drop in mAP without this term, and we will report the numbers in an ablation table in the revised version.

---

Q7: "What is $\beta$ in $\mathcal{L}_\mathrm{tune}$? If the low-frequency label and high-frequency pseudo label become very similar at high rates, is the term still necessary?"

A: Thanks for raising this point. The tuning loss mixes human GT and high-frequency pseudo labels with coefficient $\beta$ (chosen on validation, $\beta = 0.5$ in our experiments to reflect moderate trust in the pseudo labels). When the low-frequency label $y$ and the high-frequency pseudo label $\tilde y$ become very similar at high rates, the pseudo-label term behaves as a consistency regularizer across dense time steps: if $\hat y \approx \tilde y \approx y$, its contribution (and gradient) is near zero, so it does not bias training; if small misalignments arise from sync jitter or occlusions, it stabilizes predictions and helps propagate supervision between sparse GT frames. In ablations, setting $\beta=0$ means not using pseudo high-frequency label, which yields a performance drop (48 → 43.7), especially at mid/high frequencies.

As a practical refinement, we can confidence-weight the pseudo-label term and/or decay $\beta$ with frequency to avoid over-reliance when $\tilde y$ is already near-perfect.

---

Last but not least, we would like to sincerely thank Reviewer RR3R again for the valuable time and constructive feedback provided during this review.

We sincerely thank Reviewer BJuF for devoting time to this review and providing constructive feedback. We are encouraged by the thoughtful assessment and helpful suggestions. Below, we respond to your comments and suggestions in detail.

---

Q1: "Robustness to modality-specific noise."

A: Thank you for emphasizing this important aspect. Event cameras are particularly valuable in adverse conditions (e.g., low light, rapid motion). As shown in Table R1 below, our fusion model consistently outperforms RGB-only baselines, which tend to degrade severely under low illumination.

Table R1. Additional experiments on DSEC-Det

On DSEC night sequences (noisy RGB), our model achieves 53.2 mAP, suggesting that the fusion gate effectively up-weights the event branch when frames deteriorate. In sparse-event regimes (high-frequency inputs), at 180 Hz (events-only) we obtain 30.4 mAP vs 22.9 for the baseline, indicating resilience when the event stream becomes sparse.

In the revision, we will provide additional diagnostics, like noise-stress tests (low-light RGB, background-activity in events). We believe these additions will make the robustness story clearer and more reproducible.

---

Q2: "FlexTune vs semi-supervised baselines."

A: We appreciate the request for clearer positioning. We compare with LEOD (a semi-supervised baseline) in Table 1, where we obtain higher mAP. In ablations, even with events-only, we reach 54.6 mAP (LEOD 41.1), underscoring that our FlexTune (pseudo labels + temporal-consistency calibration + cyclic self-training) is effective beyond backbone choice. There are no widely used SSL baselines with consistency regularization or teacher-student models tailored to event-frame detection. In the future, we will try EMA teacher–student, consistency regularization, and FixMatch/Noisy-Student-style bootstrapping under the same unlabeled high-frequency pool and compare with our work.

---

Q3: "Edge feasibility with a 45.4 M-param model."

A: This is an important practical consideration. The fusion head contributes ~1.5 M parameters; the remainder (~44 M) lies in the backbone, which is already optimized in prior work. Our FP32 checkpoint is ~546 MB. As summarized in Table R1 in Q1, our model is faster and/or smaller than several prior detectors that have been successfully deployed, and we sustain real-time inference. To address feasibility more thoroughly, we will report real-time throughput/memory on an edge SoC and include FP16 results in the revised version.

---

Q4: "Generalization to untrained frequencies."

A: Thank you for pointing this out. We already report 20–180 Hz, covering sampling gaps from 50 ms → 5.56 ms. Moving to 200 Hz+ reduces the gap only to ~5 ms, a marginal change. We expect similar behavior, and in the revision/supplement, we will add zero-shot results at 200 Hz (and higher) under the same protocol (no re-training).

---

Q5: "Potential biases."

A: We appreciate this reminder. Per-class results (Table R2) show higher AP for large vehicles and lower AP for small objects (bicycle/rider), and performance is better in day (61.6 mAP) than night (53.2 mAP), according to our experiments. Importantly, our method remains stronger than all compared baselines across these conditions. In the revision, we will include more class-wise and condition-wise results, and propose some practical mitigations (rebalancing, small-object augmentation, confidence calibration for deployment). We see this as essential documentation for safe use in real-world settings.

Table R2. Per-class on eight categories

---

Q6: "Safety implications and dataset bias."

A: Thank you for emphasizing safety. We will add a dedicated section outlining: (i) operational design domain (lighting/motion ranges), (ii) risks from detection errors in autonomous scenarios and recommended thresholding/fallbacks under low confidence, (iii) shift detection (e.g., day → night) and suggested interventions (recalibration or conservative policies), and (iv) a brief discussion of dataset bias and its implications.

---

Last but not least, we would like to sincerely thank Reviewer BJuF again for the valuable time and constructive feedback provided during this review.

Dear Reviewer BJuF,

Thank you for taking the time to read our manuscript and provide a final rating. We noticed, however, that no written feedback was recorded. We would be grateful to know whether our previous response addressed your concerns, or if there are any remaining points you would like us to clarify.

Your feedback would help us further polish the work and ensure the final version is as clear and useful as possible. We deeply value every reviewer’s perspective and remain fully available during the discussion phase to elaborate on any aspect you might wish to revisit.

Thank you again for your time and service to the community. We look forward to hearing from you.

Warm regards,

Authors of Submission 1326

We sincerely thank Reviewer kyoZ for the thoughtful assessment and helpful suggestions, and we appreciate the recognition of our work as well-structured and promising. Below, we respond to your comments and suggestions in detail.

---

Q1: "Aggregate information for a longer period for each event aggregation."

A: Thanks for your suggestion. In our setup, “high frequency” refers to the sampling cadence (label rate $a$ vs. higher event rate $b>a$) rather than to a fixed aggregation window. Our detection is anchored at the end timestamp $t_2$ of the labeled interval $[t_1, t_2]$ with $t_2 = t_1 + \Delta t_a$. The inputs are: the RGB frame $F$ captured in $t_2$, the low-frequency event stream $E_a$ captured in $[t_1, t_2]$, and one high-frequency event slice $E_b$ of duration $\Delta t_b$.

We split the interval $\Delta t_a$ into $b/a$ sub-intervals and sample one high-frequency event $E^b$ captured from the $b/a$ sub-intervals, detections are produced at the end of $\Delta t_a$. This keeps the sampling gap small, pairs each RGB frame with its preceding high-frequency events, and introduces only millisecond-scale jitter that acts as implicit temporal augmentation for synchronization noise.

To address the reviewer’s suggestion, we add an ablation that keeps the sampling gap $\Delta t_a$ fixed but enriches semantics, we use multi-sample encoding within each $[t, t+\Delta t_a]$: take $K$ event slices captured from the $b/a$ sub-intervals instead of sampling only one, encode each, then average features to align with one RGB frame. We report this variant as the FlexEvent** row in Table R1 (see below from Q2), and the result shows that it yields a slight mAP improvement, while inference time increases approximately linearly with $K$.

This averaging effectively behaves as a low-pass filter, weakening high-frequency event cues (especially for small/fast targets) without improving supervision at >20 Hz (pseudo labels remain and can introduce timing mismatch), so the marginal accuracy gain does not justify the near-linear increase in latency/compute. Accordingly, we retain single-slice inference with cadence-aware gating and consider lightweight learned temporal pooling as a better trade-off.

---

Q2: "More experiments with RGB-based and fusion-based methods."

A: Thank you for pointing this out. For a fair comparison with recent fusion-based detectors, we follow the ACGR (CVPR'25) evaluation protocol and report results on the eight DSEC-Det categories. We merge our numbers into ACGR’s Table 1 for a side-by-side view (Table R1). We also add the results of two other recent fusion-based methods, FAOD and HDI-Former.

Compared with RGB-only baselines, our model achieves consistently higher mAP, reflecting the complementarity between frames (semantics) and events (high-frequency motion cues). Relative to prior fusion methods, we also observe gains in mAP, which we attribute to improved cross-modal alignment and frequency-aware supervision in our design.

---

Table R1. Additional experiments on DSEC-Det

---

Q3: "Generalization to more object categories."

A: Thank you for highlighting this. In Table R2, per-category results show that large objects (truck, bus) obtain the highest AP, while pedestrian, rider, and bicycle are more challenging due to small scale and appearance variability. Train is the weakest class because it has very few instances in the dataset.

All numbers are computed under the same settings as ACGR. Pretraining is kept identical across compared methods/backbones, ablations indicate that the main gains stem from our FlexFuse/FlexTune rather than pretraining.

---

Table R2. Per-class on eight categories

---

Q4: "RVT for events backbone and ResNet-50 for RGB backbone and pre-trained weights."

A: We appreciate this concern. We adopt modality-appropriate encoders, ResNet-50 for RGB frames and RVT for events, because the two signals have very different statistics (intensity images vs. asynchronous polarity streams). Our focus is on flexible event–image fusion and frequency-adaptive learning, so we keep the backbones standard and isolate our contributions in the fusion/adaptation modules. ResNet-50 is initialized from ImageNet-1K and RVT from the 1Mpx event dataset, then both are fine-tuned in our detector.

In ablations, RVT pretraining gives a small gain, and the main improvements come from FlexFuse and FlexTune. When we train RVT from scratch (FlexEvent* row in table above), our method still outperforms prior work, which shows that pretraining is helpful but not the reason for the overall gains. Given the small size of DSEC and the common ImageNet practice, we did not repeat a from-scratch ResNet study.

---

Last but not least, we would like to sincerely thank Reviewer kyoZ again for the valuable time and constructive feedback provided during this review.

Dear Reviewer kyoZ,

Thank you very much for your thoughtful and constructive feedback on our submission!

Following your suggestions, we incorporated additional experiments to investigate multi-sample aggregation within each interval, expanded our evaluation to include recent RGB and fusion-based detectors, and provided detailed per-class performance to clarify generalization across object categories. We also elaborated on the choice of backbones and pretraining, with ablations showing our gains are driven by FlexFuse and FlexTune rather than pretraining alone.

Your feedback has been instrumental in improving the rigor and clarity of our study.

We are actively participating in the Author-Reviewer Discussion phase and would be happy to further clarify any points!

Best regards,

The Authors of Submission 1326

2) Why is our setting fair (and what are we changing)?

A: We agree that our earlier sentence "pretraining is kept identical across compared methods/backbones" was poorly phrased, and we apologize for placing it under the wrong question in our previous response. What we meant is in Table R1, we disable event-encoder pretraining to ensure a fair comparison to methods without event pre-training. And through the below comparisons/ablations, we show that event pre-training helps but is not the main driver of the performance gains.

• In Table R3, we re-evaluate RVT, SAST, SSM, and LEOD on DSEC-Det using the authors’ 1Mpx pre-trained checkpoints and report those pre-trained results alongside our method trained from scratch; under the same protocol, our model still outperforms all baselines, demonstrating superiority without pretraining.

• Table R4's ablation study pinpoints the source of gains. On DSEC-Det (8cls, scratch), removing FlexFuse drops mAP 0.441 → 0.346 (−0.095), and removing FlexTune drops 0.441 → 0.368 (−0.073). This performance gain is particularly pronounced at high frequencies. At 180 Hz, from the baseline, FlexFuse improves 0.113 → 0.316 (+0.203), while FlexTune improves 0.113 → 0.289 (+0.176), highlighting label-efficient frequency adaptation. By contrast, RVT pre-training yields mAP gains of 0.016 (2-class) and 0.057 (8-class) at 20 Hz, and only 0.039 (2-class) and 0.032 (8-class) at 180 Hz, which is useful, but smaller than the gains from our proposed modules, especially for high frequency. This highlights our core contributions: FlexFuse, which leverages the complementary strengths of event and frame modalities to enable efficient, accurate detection in dynamic scenes; and FlexTune, a frequency-adaptive fine-tuning scheme that generates frequency-conditioned labels and improves generalization across diverse motion frequencies.

• We additionally have a comprehensive ‘scratch’ track across three datasets: on DSEC-Det, FlexEvent (RVT scratch) achieves 0.441 mAP, exceeding FAOD (0.425, in submission) and SODFormer-ACGR (0.317, CVPR’25 accepted), which is shown in Table R5. On DSEC-Detection, FlexEvent (scratch) reaches 0.459 (vs. 0.474 with pre-train; prior SOTA 0.380). On DSEC-MOD, FlexEvent (scratch) is 0.342 (vs. 0.369 with pre-train; prior SOTA 0.290). Thus even without pre-training, FlexEvent outperforms all compared methods on all three datasets.

3) How will we integrate the extra results without a major rewrite?

A: We will adjust the figures/tables as needed.

• Table 1 (main): test methods in current Table 1 at the 8-class setting and merge the results with Table R5, add a FlexEvent (scratch) row, and annotate our current result as FlexEvent (RVT-1Mpx); keep baselines that do not use event pre-training so the comparison is like-for-like.
• Tables 2-3: Add one extra FlexEvent (scratch) row each.
• Figure 6: Add an extra FlexEvent (scratch) histogram across frequencies.
  Full per-class results and training logs/checkpoints will be placed in the supplement + repo for easy verification. Thus, we believe only modest revisions are needed: we will adjust the figures/tables as appropriate, while the methodology and core contributions remain unchanged.

We hope these clarifications address the fairness concern: (i) we explained why pre-training is reasonable for events and how RVT’s design makes it practical; (ii) we provide a scratch-only track showing FlexEvent’s superiority without pre-training; and we additionally validate several baselines initialized with pre-trained weights; (iii) ablations verify that the main gains come from our two core contributions (FlexFuse, FlexTune) rather than pre-training; and (iv) we keep the paper concise by integrating the essential numbers and moving full details to the supplement. We appreciate your critical feedback; it has helped us improve both the clarity and the rigor of the manuscript.

With appreciation,

Authors of Submission 1326

Dear Reviewer kyoZ,

Thank you again for your continued engagement and for articulating your concerns so clearly. Here, we address the pre-training issue directly, including why we use it, how we ensure fairness, and how the additional experiments fit into the paper.

---

1) Why do we use pre-trained weights?

A: In the image/video domain, initializing backbones from large-scale data and then fine-tuning on the task dataset is standard practice because it:

• (i) improves feature quality when the task data is relatively small;
• (ii) accelerates convergence and stabilizes optimization;
• (iii) provides a stronger starting point in difficult conditions.

In the event camera domain, large, generic pre-training datasets are rarer, but RVT offers validated encoders trained on substantial event detection datasets (GEN1 / 1Mpx). We adopt RVT (1Mpx) for events as modality-appropriate starts, then fine-tune end-to-end. Our consideration in doing this is:

• Isolatable backbone–head design. RVT has a clean backbone + detection head separation, so we can isolate the event feature extractor and fine-tune it within our framework with minimal modification.
• Dataset scale rationale. DSEC (≈1 hour, ~390k boxes) is much smaller/less diverse than RVT’s pretraining datasets (GEN1 ≈39 hours, ~256k boxes; 1Mpx ≈15 hours, ~25M boxes). Transferring features learned on broader event data to DSEC is therefore reasonable and stabilizes training.
• Community relevance. Our findings indicate that the pre-training paradigm, long proven in images, is also effective for events. While not yet universal in all tasks, we believe this evidence is informative for the community.

Empirically on DSEC-Det (8 classes), moving from RVT-scratch → RVT-1Mpx improves mAP and reduces training from 400k → 100k iters, showing pre-training is helpful but, as shown below, not the direct reason for our overall gains.

Below, we attach the experiment tables for your reference: Table R3 updates the original Table 1 in the paper with both pre-train and no pre-train results; Table R4 reports the ablation on all 8 DSEC-Det classes; and Table R5 adds further comparisons on all 8 DSEC-Det classes, with highlighted pre-train / no pre-train information to ensure high clarity:

Table R3. Experiments on DSEC-Det(2 classes).

Table R4. Ablation study on DSEC-Det(8 classes).

Table R5. Experiments on DSEC-Det(8 classes).

Dear Reviewer kyoZ,

Thank you again for your thoughtful review and constructive suggestions.

Since our previous response we have:

1. Explained in detail why event pre-training is reasonable and how RVT’s architecture makes it practical.
2. Added comprehensive experiments demonstrating FlexEvent’s superiority without pre-training, and also reported several baselines re-run with pre-trained weights for an apples-to-apples comparison.
3. Included ablations confirming that the main gains come from our two core contributions, rather than from pre-training.
4. Outlined a clear plan for integrating the new results into the paper without requiring a major rewrite.

We hope these additions fully address your pre-training and fairness concerns, but we would be very grateful to hear whether any points remain unclear or if further analysis would be helpful. Your feedback and remarks will be enthusiastically incorporated in the final revision.

Thank you once more for your time and expertise.

We look forward to any further comments you may have.

Best regards,

The Authors of Submission 1326

We sincerely thank reviewer xQ9Q for the thoughtful assessment and helpful suggestions, and we appreciate the recognition of our intuitive motivation and real-time suitability. Below, we respond to your comments and suggestions in detail.

---

Q1: "Novelty over concurrent work FAOD."

A: We appreciate this insightful concern. FAOD and our work are concurrent, and both are in submission. The comparisons are summarized as below:

• Label-efficient frequency adaptation.
  FlexTune transfers low-frequency supervision to high frequencies via pseudo-labels + temporal-consistency calibration + cyclic self-training, requiring no extra high-frequency labels. By contrast, FAOD’s Time-Shift is closer to a data-augmentation/consistency trick: it does not create high-frequency supervision, and its effect depends on tuned hyperparameters (shift range/schedule). Large shifts can introduce label/content misalignment, so it is more sensitive to tuning and has greater limitations. FlexTune thus provides a more reliable, label-efficient path to frequency adaptation.

• More input-adaptive and interpretable fusion.
  FlexFuse learns gated Softmax weights for the event and frame branches and adds a variance regularizer to prevent collapse, yielding explicit, interpretable branch weights that show how fusion adjusts with the input condition and confidence. FAOD emphasizes alignment correction followed by attention, which improves geometry/style consistency but does not expose a direct, per-input fusion weighting. FlexFuse, therefore, offers stronger interpretability and direct input adaptivity.

• High-frequency robustness and scalable evaluation.
  FlexEvent provides fine-grained results from 20→180 Hz; it maintains 50.9% mAP at 180 Hz (full model). With events-only, enabling FlexTune lifts 180 Hz mAP from 22.9→30.4, evidencing true frequency adaptation rather than reliance on augmentation alone. Results on DSEC-Detection / DSEC-MOD further indicate cross-dataset transferability. On DSEC-Det, FlexEvent achieves an eight-class mean of 49.8%, outperforming FAOD’s reported 42.5%, as shown in Table R1 below.

• Engineering practicality.
  FlexEvent performs frequency adaptation offline, adding no inference overhead, and inference runs at ~12–14 ms/frame over 20–180 Hz. Both FlexEvent and FAOD are real-time, but FlexEvent sustains real-time performance across a broader frequency range with stronger robustness.

In summary, FlexEvent is novel in unifying frequency-aware fusion (FlexFuse) with label-efficient frequency adaptation (FlexTune), yielding higher accuracy on shared benchmarks and broader frequency robustness, while keeping real-time inference without extra cost.

---

Table R1. Additional experiments on DSEC-Det

---

Q2: "Lack of generality analysis."

A: Thank you for your question. We mainly follow ACGR (CVPR’25) and DAGr (Nature’24) evaluation protocols and evaluate on DSEC because it is a standard, large-scale benchmark for outdoor event detection with paired event + frame data, and event cameras have shown great potential in outdoor autonomous driving scenarios, while large-scale indoor datasets are limited.

Nevertheless, across three variants of the DSEC dataset, our method has shown strong superiority over previous methods across different object categories and scenarios, which proves our effectiveness. In the revision, we will add more experiments on another larger outdoor event–image dataset (PKU-DAVIS-SOD) and on an indoor event dataset with minimal tuning, and we will release code/configs to facilitate third-party validation.

---

Q3: "mAP rises from 20→36 Hz, then degrades toward 180 Hz?"

A: We appreciate your emphasis on this point. The 20 Hz results are evaluated against human-annotated ground truth, whereas >20 Hz results use interpolated/pseudo ground truth (as stated in line 277) because no human ground truth at high frequency is available. Because the supervision differs, the numbers are not directly comparable from 20→36 Hz. As the frequency increases from 36 to 180 Hz, with a fixed aggregation window, each event slice becomes sparser and noisier (background activity dominates), which hurts small/fast classes; in parallel, pseudo-label noise grows at higher rates. Together, these effects explain the mAP drop toward 180 Hz.

---

Q4: "Comparison to other fusion+frequency-adaptive works."

A: Thank you for pointing this out. We compare our approach with FAOD and DAGr (Nature’24):

• Fusion / Alignment. FlexEvent (FlexFuse) learns frequency-aware gating to balance event/RGB features; FAOD uses an Align Module (e.g., AdaIN/deformable ops) plus attention after alignment; DAGr fuses unidirectional image features into an asynchronous GNN over events.

• Frequency adaptation. FlexEvent (FlexTune) provides label-efficient adaptation via pseudo-labels + temporal consistency+cyclic self-training; FAOD leverages Time-Shift training to reduce train–test frequency mismatch; DAGr does not propose a dedicated module to handle frequency adaptation.

• Scope. FlexEvent is backbone-agnostic and covers 20–180 Hz with the same detector; FAOD focuses on high-frequency fusion with alignment; DAGr demonstrates a hybrid image+event pipeline for low-latency automotive detection.

• Performance. FlexEvent demonstrates the strongest result across different frequencies, as shown in Table R1. In terms of efficiency, FlexEvent performs adaptation offline and adds ~1.5 M params in the head; inference remains real-time. FAOD emphasizes light parameter count and alignment; DAGr is the slowest, even though it has a smaller model size.

As suggested, we have included a side-by-side summary table in the revised manuscript for better clarity.

---

Last but not least, we would like to sincerely thank Reviewer xQ9Q again for the valuable time and constructive feedback provided during this review.