{"id":"18d76cb0-1950-49dc-a310-d7bebc3025d4","arxiv_id":"2506.17457","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"A multimodal network combining an asynchronous graph neural network for events with a CNN for RGB images detects driving anomalies with competitive accuracy and lower response time than prior methods, but only on simulated event data.","lead":"This paper proposes a hybrid network that fuses simulated event streams with RGB video to detect traffic anomalies faster than prior methods, reporting up to 579 frames per second. It introduces a response-time metric and shows gains on two driving datasets, though the event data is generated from ordinary video rather than recorded with real event cameras.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Table 1 reports mResponse = 1.17 s (ROL) and 1.21 s (DoTA), yet the abstract and §3 claim 'millisecond-level' response; 1.17 s is 1170 ms, so the central real-time claim is contradicted by the paper's own metric.","rationale":"Reader's verdict is CONDITIONAL with medium confidence, and I largely agree. The most defensible single point is the mismatch between the abstract's 'millisecond-level real-time' claim and Table 1's mResponse of 1.17-1.21 s. This is not an unstated assumption; it is the paper's own metric contradicting its central claim. Eq. (3) makes clear that response time includes both detection delay and inference, and mResponse is described as the mean detection delay across thresholds, so the 1.17 s value cannot be dismissed as a simple unit typo. The missing Response_j definition (Eq. 20) also makes the result non-reproducible. Separately, the reader's v2e concern remains valid: event streams are synthesized from the same RGB videos, and Appendix H's DSEC validation covers only normal scenes and shows roughly 0.2 s differences in mResponse/mTTA (Table 9), which is not minimal for a latency-centric claim. However, the mResponse contradiction is more directly load-bearing because it undercuts the central real-time claim even if v2e fidelity were perfect. I recommend keeping the CONDITIONAL verdict unchanged: the paper should not be rejected outright because the architecture and ablations may still be salvageable, but the central claim must be re-measured and the metric fully specified.","tokens_in":20859,"tokens_out":5434,"duration_ms":54713,"concrete_test":"Run the released code/checkpoints on the ROL and DoTA test splits, log anomaly-onset timestamps and first-threshold-crossing timestamps at a fixed operating threshold, and compute mean/median wall-clock response; then compare with Table 1. Alternatively, re-derive Table 1 by specifying Response_j (e.g., delay between anomaly onset and first time the score exceeds each of n thresholds) and reproduce the 1.17/1.21 s entries. If the reproduced or directly measured response is of order 10^3 ms, the abstract's 'millisecond-level' claim fails.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central contribution is real-time anomaly detection with millisecond-level response (Abstract; Sec. 3: 'response times at the millisecond level'). Its own primary latency metric, mResponse, is reported in Table 1 as 1.17 s on ROL and 1.21 s on DoTA (column header MRESPONSE(S), values given in seconds). Eq. (3) defines response time as T_inference + detection delay, so these are total response times, not merely inference latency. 1.17 s = 1170 ms. The 579 FPS figure implies roughly 1.7 ms inference, but the paper does not claim 'inference-time-level' performance; it claims millisecond-level response. Section 5.3 even praises this as an 'exceptionally low mean response time'. Moreover, the definition of mResponse is incomplete: Eq. (20) averages Response_j over n thresholds, but no formula for Response_j, the threshold set, or n is given, so the value cannot be reproduced or independently checked. This is an internal inconsistency: the headline performance claim is not supported by the paper's own table.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a multimodal asynchronous hybrid network for real-time traffic anomaly detection in autonomous driving. The method fuses RGB frames (processed with a ResNet) and event streams (processed with an asynchronous graph neural network using spline convolution), then applies GRUs and attention at the object level to produce risk scores. The authors introduce a mean response time metric (mResponse) and claim millisecond-level real-time performance, reporting improvements in AUC, AP, mTTA, and response time on the ROL and DoTA datasets. They also present ablations, a new Rush-Out subset, comparisons with other real-time methods, and appendices on synthetic event validation and hardware deployment. The event data are generated from RGB videos using v2e because the datasets lack real event camera recordings.","tokens_in":21088,"tokens_out":6530,"duration_ms":59773,"significance":"If the results are reproducible and the v2e-generated events are a valid proxy for real event camera signals, the paper would demonstrate a useful method for anomaly detection with lower response time than several frame-based baselines, which matters for safety-critical driving. The paper ships a code link, provides extensive ablation tables, and discusses hardware feasibility, which are strengths. However, the central 'millisecond-level real-time' claim is directly contradicted by the paper's own mResponse values (1.17 s and 1.21 s), and the event modality is simulated from the same RGB frames, so the claimed advantages of event cameras' high temporal resolution are not empirically established. The architecture may still be of interest, but the headline claims need substantial revision and additional evidence.","major_comments":[{"comment":"The abstract and Section 3 claim 'millisecond-level real-time performance' and 'response times at the millisecond level,' but Table 1 reports mResponse = 1.17 s on ROL and 1.21 s on DoTA. Since Eq. (3) defines R = ΔT_detection + T_inference, these are total response times; 1.17 s is 1170 ms. Section 5.3 then calls this 'exceptionally low mean response time,' which is internally inconsistent. The 579 FPS figure supports an inference latency of roughly 1.7 ms, but the paper does not limit its claim to inference latency. Please recalibrate the headline claims to the reported metric or re-report the metric in milliseconds with a clear breakdown of inference time and detection delay.","section":"Abstract / Sec. 3 / Table 1"},{"comment":"The event stream is generated from the RGB video using v2e, as stated in Section 5.1 and Appendix H. Because the events are a deterministic transformation of the same RGB frames, they do not constitute an independent sensory modality; any information in the events is already present in the RGB input. Claims in Section 5.5 and Appendix D that the method performs 'inter-frame anomaly detection' and exploits the 'high temporal resolution' of event cameras are not supported by experiments with simulated events. The DSEC comparison in Appendix H validates v2e only on normal driving scenes, not on anomaly scenes, so it does not justify transfer to anomaly detection. The authors should either test with real event data on at least a subset of anomaly videos, or substantially soften the conclusions about event-camera advantages and add an explicit argument that v2e-generated events provide a meaningful proxy.","section":"Sec. 5.1 / Appendix H / Sec. 5.5"},{"comment":"The mResponse metric, which is the primary latency metric for the paper's central claim, is not reproducibly defined. Eq. (20) gives mResponse = (1/n) Σ Response_j, but the paper does not specify how Response_j is computed, what threshold values are used, or the value of n. Without this information, Table 1's latency numbers cannot be independently checked, and the comparison to baselines is not verifiable. Please provide the full protocol, including the threshold grid and the definition of Response_j.","section":"Sec. 5.2, Eq. (20)"},{"comment":"The claim of outperforming existing methods 'in both accuracy and response time' is not supported by Table 1. For ROL, TTHF achieves AP = 0.585, while OURS achieves 0.570; for DoTA, TTHF achieves AUC-Frame = 0.847, while OURS achieves 0.823. Section 5.3 states 'OURS achieves leading performance in both AUC and AP metrics,' which is contradicted by these numbers. Please revise the claims to specify the metrics on which the method is actually superior, or include error bars and significance tests to support the superiority claims.","section":"Abstract / Table 1 / Sec. 5.3"},{"comment":"The ablation analysis attributes specific improvements to individual modules in a way not supported by the table. The text states 'Integrating GRUs increases AUC from 0.805 to 0.817 and AP from 0.479 to 0.508,' but the row with 0.817/0.508 corresponds to adding several modules at once (row 2 has five checkmarks), not GRU alone. Without a row that adds only the GRU to the baseline, the observed gain cannot be attributed to the GRU. The same issue applies to the attention module discussion. Please add per-module ablations or revise the attribution statements.","section":"Sec. 5.4, Table 2"}],"minor_comments":[{"comment":"Table 2 and Table 5 (Appendix A) contain rows with only checkmarks; the column alignment is ambiguous, so it is impossible to determine exactly which modules are active in each row. Please add explicit row labels (e.g., '+GRU') or use check/cross marks for all columns.","section":"Table 2 / Table 5"},{"comment":"Table 8 reports OURS mResponse = 2.35 s on ROL, while Table 1 reports 1.17 s for the same configuration; if both tables refer to the same model, this discrepancy needs to be reconciled.","section":"Table 8"},{"comment":"The comparison 'DSEC' vs 'DSEC+V2E' in Appendix H is not clearly described; please clarify whether both rows use real DSEC event data or whether the second row uses v2e-generated events from DSEC frames.","section":"Appendix H, Table 9"},{"comment":"The statement 'requires only 8.732 MFLOPs per event' is confusing because MFLOPs is not naturally a per-event unit when combined with the event rate of 560k events/s; please specify the total computational cost per second or per frame.","section":"Appendix J"},{"comment":"Table 1 reports single-point numbers for all metrics without error bars or multiple runs, which makes it difficult to assess whether the differences between OURS and the closest baselines are statistically meaningful.","section":"Table 1"}],"recommendation":"major_revision","confidential_remarks":"The paper has a promising architecture and a reasonable experimental design, but the headline 'millisecond-level real-time' claim is contradicted by the paper's own mResponse numbers, and the simulated event modality is a fundamental limitation that the authors acknowledge but do not fully address. I would encourage the editorial team to require the authors to either obtain real event data or explicitly reframe the contribution as using v2e-simulated event streams as auxiliary input, and to correct the metric definition and accuracy claims before resubmission. The code release is a positive signal, but the central claims need to be made consistent with the reported evidence."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: this is a reasonably competent architecture paper, but the central real-time claim does not survive contact with its own table. Table 1 reports mResponse of 1.17s on ROL and 1.21s on DoTA. That is over a second, not milliseconds. The abstract and intro repeatedly say \"millisecond-level real-time performance.\" This is not a rounding issue; mResponse as defined in Eq. (3) includes detection delay on top of inference, so the total is what matters. The 579 FPS figure speaks to inference speed only, and the paper does not claim merely inference-time-level performance.\n\nWhat is actually new: the specific integration of an asynchronous GNN event branch with a ResNet RGB branch and GRU-plus-attention for traffic anomaly detection is a genuine new combination, and the mResponse metric is a sensible attempt to measure response time across thresholds. The ablations are honest about what each component contributes, and the appendices go further than most papers in this area—sensitivity analysis, failure cases, and a DSEC-based check of the v2e simulator. Code is promised. That is real evidence, and it should be credited.\n\nSoft spots, in order of severity:\n\n1. The millisecond contradiction. Either the claim or the metric is wrong. If mResponse is in seconds, the paper cannot say millisecond-level. If they meant inference time, they need to say that explicitly and argue why that is the safety-relevant number.\n\n2. The event modality is simulated with v2e from the same RGB videos. So the \"multimodal\" comparison does not test an independent sensory channel. The DSEC validation in Appendix H covers only normal driving, not anomalies, so it does not establish that real event cameras would deliver the same benefit, especially the inter-frame detection story.\n\n3. The mResponse definition is incomplete: no formula for Response_j, the threshold set, or n. The metric cannot be reproduced from the text.\n\n4. Minor: no error bars or repeated-run statistics, and the FPS protocol is undescribed.\n\nThe architecture is plausible and the gains are consistent across the ablations, but the paper overstates its case. A serious referee could fix this. It deserves peer review rather than desk rejection because the core system and the new metric are worth evaluating properly.\n\nRecommendation: send to review with a request for major revision. The authors should resolve the response-time contradiction and either obtain real event data or clearly limit their claims to simulated events.","headline":"A plausible multimodal fusion system with a useful new latency metric, but the paper's central 'millisecond-level' real-time claim is contradicted by its own mResponse numbers, which are over a second.","tokens_in":21642,"tokens_out":2203,"would_cite":false,"duration_ms":21234,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A hybrid network fusing event-camera streams with RGB frames detects driving anomalies at millisecond latency while holding accuracy at or near the top of published baselines.","keywords":["real-time anomaly detection","autonomous driving","event cameras","asynchronous graph neural network","multimodal fusion","response time","v2e synthetic events","traffic accident detection"],"falsifier":"Mount a real event camera alongside an RGB camera on a vehicle, drive or replay the ROL/DoTA-type sudden-appearance scenarios, and compare anomaly delay (mResponse and mTTA) and accuracy against the RGB-only baseline and against the same model fed v2e-converted video. If real event streams do not reproduce the inter-frame detection advantage, for instance if mResponse on real events is no better than frame-only processing or accuracy drops because the network trained on synthetic events does not generalize, then the central claim about asynchronous event processing fails.","tokens_in":20649,"feed_emoji":"🚗","tokens_out":9113,"duration_ms":84351,"temperature":0.7,"pith_summary":"This paper tries to establish that traffic anomaly detection for autonomous driving can be accurate and genuinely fast at the same time if event-camera streams are added to ordinary RGB video. The proposed multimodal asynchronous hybrid network routes the event stream through an asynchronous graph neural network and the RGB frames through a ResNet, fuses the two, and runs the fused object-level features through recurrent units; on the ROL and DoTA benchmarks it reports detection at roughly 579 frames per second with the lowest response delays among compared methods while matching or beating them on most accuracy metrics. The reason this matters is that an autonomous vehicle needs a warning in the milliseconds before a pedestrian darts out or a vehicle cuts in, and the event stream supplies motion cues between video frames that a frame-based detector cannot see. The paper also introduces a new latency metric, mResponse, that averages detection delay across many operating thresholds. Because no real event-camera dataset of driving anomalies exists, all event data are synthesized from ordinary video with the v2e converter, an assumption the authors test only partially.","feed_headline":"Event cameras slash driving-anomaly detection to milliseconds","feed_subtitle":"Fusing event streams with RGB lifts detection speed to ~579 FPS while keeping accuracy ahead of the field.","key_machinery":"The load-bearing object is the asynchronous event graph. Every brightness-change event becomes a node carrying normalized pixel coordinates and a scaled timestamp; edges link nodes within a spatial and temporal radius (up to 16 neighbors), and edge features encode relative spatial offsets. A deep asynchronous graph network with spline convolution aggregates these nodes, with RGB features from the ResNet branch sampled at each node's location and concatenated in, and the fusion is deliberately unidirectional so the GNN gains appearance context without making the CNN wait for event processing. Because events carry sub-frame timestamps, this graph can produce motion features between video frames, which is the mechanism behind the paper's inter-frame anomaly detection and its low response latency; downstream, GRUs accumulate object-level temporal evidence and an attention mechanism weights anomalous objects.","core_discovery":"The paper's central claim is that asynchronous event data and frame-based imagery are complementary enough, when fused in one network, to make anomaly detection both more accurate and much faster than frame-only methods. The architecture is a ResNet appearance branch plus a deep asynchronous graph network, DAGr, whose nodes are individual brightness-change events with normalized coordinates and scaled timestamps and whose edges join events that are close in space and time; each node's features are enriched with the RGB feature sampled at its location, and a GRU with object-level attention turns the fused features into risk scores. On ROL and DoTA the method reports AUC of 0.879 and 0.896, mean time-to-accident of 2.80 and 2.78 seconds, inference near 579 FPS, and mResponse of 1.17 and 1.21 seconds, outperforming all prior baselines on response time while staying at or near the top on accuracy; the one metric where a rival (TTHF) leads is frame-level AUC. The authors additionally show the event branch detects anomalies between consecutive frames, flagging fast-appearing objects before they are visible in the next image.","pith_inferences":["The decisive test the paper does not run is synthetic-to-real transfer: v2e fidelity is validated on classification and normal driving scenes only, so if a physical event camera's noise, bandwidth, or calibration differs in anomaly moments, the headline latency advantage could shrink on real hardware.","If the inter-frame advantage survives real hardware, event cameras look most plausible as a low-cost early-warning add-on to existing RGB-only stacks, targeted at sudden-appearance hazards, rather than as a replacement modality.","The mResponse idea generalizes: any time-critical perception output, from pedestrian warning to collision trigger, could report multi-threshold latency instead of a single time-to-event number, which would make latency comparisons meaningful across systems.","The 579 FPS figure assumes sparse event graphs; dense traffic at one to ten million events per second drives worst-case compute to roughly 87 TFLOPs, so the headline speed depends on event sparsity holding in congested scenes."],"forward_implications":["A detector that runs near 579 FPS and reports anomalies with sub-second mean response leaves room in the latency budget for braking and evasive planning, which is the paper's stated reason for measuring response time at all.","Because event streams carry timestamps between video frames, the model can raise an anomaly score before an abruptly appearing object is visible in the next RGB frame, an inter-frame detection capability the paper demonstrates on rush-out scenarios.","The mResponse metric, averaging detection delay across thresholds, gives a threshold-independent way to compare timeliness, and the experiments report it alongside FPS for every method.","In adverse weather and low-light subsets, the event branch keeps detection performance well above the best frame-based baselines, since events encode brightness change rather than absolute illumination.","The network is sized for on-board compute, with about 8.7 MFLOPs per event and roughly 87 TFLOPs worst case at high event rates, which the authors argue fits within Orin-class chip capability."],"supporting_citations":[{"why":"Supplies the DAGr asynchronous graph backbone with spline convolution that processes the event stream.","marker":"Gehrig & Scaramuzza, 2024"},{"why":"The v2e converter that generates all event data, since no real event-camera anomaly dataset exists.","marker":"Hu et al., 2021b"},{"why":"Provides the ROL dataset with temporal and spatial annotations and the AM-Net baseline.","marker":"Karim et al., 2023"},{"why":"Provides the DoTA dataset and the FOL family of unsupervised baselines.","marker":"Yao et al., 2022"},{"why":"The ResNet backbone that extracts spatial features from RGB frames.","marker":"He et al., 2016"},{"why":"Foundation for graph-based asynchronous event processing used in the event graph construction.","marker":"Li et al., 2021"},{"why":"The DSEC real-event driving dataset used to validate v2e fidelity, though only in normal scenes.","marker":"Gehrig et al., 2021"},{"why":"The online video anomaly detection method (MOVAD) compared in the real-time methods experiments.","marker":"Rossi et al., 2024"}],"fun_headline_variants":["Event+RGB fusion detects driving anomalies in milliseconds","Millisecond anomaly detection on road with event cameras","Asynchronous graph net + CNN: 579 FPS anomaly detection","Event cameras enable real-time anomaly detection at 579 FPS","Fusing event streams and RGB cuts anomaly detection to ms"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The model is trained and evaluated on event streams generated from ordinary video by the v2e converter rather than recorded by a real event camera, and the paper's own validation of that synthetic fidelity covers normal driving scenes, so the millisecond-level inter-frame detection advantage is assumed to transfer to real hardware in actual anomaly moments.","fun_headline_variants_meta":{"raw":{"variants":["Event+RGB fusion detects driving anomalies in milliseconds","Millisecond anomaly detection on road with event cameras","Asynchronous graph net + CNN: 579 FPS anomaly detection","Event cameras enable real-time anomaly detection at 579 FPS","Fusing event streams and RGB cuts anomaly detection to ms"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000723,"raw_usage":{"total_tokens":3231,"prompt_tokens":922,"completion_tokens":2309,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":538,"completion_tokens_details":{"reasoning_tokens":2229}},"tokens_in":538,"tokens_out":2309,"duration_ms":16595,"temperature":1.0,"reasoning_tokens":2229,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T19:08:13.431847+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Mount a real event camera alongside an RGB camera on a vehicle, drive or replay the ROL/DoTA-type sudden-appearance scenarios, and compare anomaly delay (mResponse and mTTA) and accuracy against the RGB-only baseline and against the same model fed v2e-converted video. If real event streams do not reproduce the inter-frame detection advantage, for instance if mResponse on real events is no better than frame-only processing or accuracy drops because the network trained on synthetic events does not generalize, then the central claim about asynchronous event processing fails.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the DoTA dataset and the FOL family of unsupervised baselines."},{"cited_title":"and Scaramuzza, D","cited_arxiv_id":null,"evidence_quote":"Supplies the DAGr asynchronous graph backbone with spline convolution that processes the event stream."},{"cited_title":"M., Yin, Z., and Qin, R","cited_arxiv_id":null,"evidence_quote":"Provides the ROL dataset with temporal and spatial annotations and the AM-Net baseline."},{"cited_title":"Dsec: A stereo event camera dataset for driving scenarios","cited_arxiv_id":null,"evidence_quote":"The DSEC real-event driving dataset used to validate v2e fidelity, though only in normal scenes."},{"cited_title":"Memory-augmented online video anomaly detection","cited_arxiv_id":null,"evidence_quote":"The online video anomaly detection method (MOVAD) compared in the real-time methods experiments."}],"review_version":1}