{"id":"72f60fc4-8f44-46dd-9c7a-afacbed1a91e","arxiv_id":"1908.08994","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"FaSTExt combines SegLink's segment-and-link architecture with MobileNetV2-style bottleneck blocks to detect text at 37.5 FPS using only 1.58 million parameters, at the cost of lower accuracy on hard benchmark datasets.","lead":"The paper proposes FaSTExt, a compact neural network for detecting words in photos, with 1.6 to 10.6 million parameters and speeds up to 37.5 frames per second on a desktop GPU. It targets camera-based text detection where words appear centered and reasonably large.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"IC13 evaluation protocol appears to be ICDAR 2015's one-to-many/many-to-one matching, so Table V numbers may not be comparable to cited single-scale SOTA results that used the official IC13 metric.","rationale":"The reader's weakest assumption concerns the fixed five-scale design and the absence of ablation, which limits the method's generality to a controlled scenario. That is a legitimate limitation, but the paper itself explicitly restricts its claims to that scenario in Sections IV and V ('we expect the camera pointed to a text area...'). The central quantitative claim that makes the paper notable is the IC13 comparison: a 10.59M-parameter network reaching 0.897 F-measure and surpassing single-scale versions of larger networks. That comparison is only meaningful if all numbers come from the same evaluation protocol. The manuscript's protocol description in Section IV.B exactly matches the ICDAR 2015 challenge (footnote ch=2), with one-to-many and many-to-one matches, while ICDAR 2013's official evaluation uses one-to-one matching. The cited SOTA numbers were published under the official IC13 metric. The difference between FaSTExt alpha=2 (0.897) and Liu et al. single-scale (0.8823) is 0.0147, well within the range where a protocol change can affect F-measure. Without detections, code, or a clear statement of the exact evaluation script, the claim is not independently checkable. Solving the protocol question is a prerequisite for any acceptance. This is more load-bearing than the scale ablation issue because it targets the headline result itself, not the peripheral generality claims. I therefore recommend UNVERDICTED until the authors provide official-metric IC13 numbers and the evaluation code.","tokens_in":7760,"tokens_out":8182,"duration_ms":72694,"concrete_test":"Re-evaluate the FaSTExt detections on ICDAR 2013 with the official ICDAR 2013 evaluation code (https://rrc.cvc.uab.es/?ch=2&com=eval&task=1) and compare the resulting F-measure to Table V. Also verify which protocol was used by the cited papers (Shi et al., Liu et al.) for their IC13 numbers. If the official-metric F-measure of FaSTExt alpha=2 falls below 0.8823 or the ranking reverses, the headline comparison is an artifact of protocol mismatch.","verdict_should_be":"UNVERDICTED","load_bearing_attack":"The most load-bearing concern is the evaluation protocol used to produce the headline IC13 numbers. Section IV.B states: 'We follow the evaluation protocol of the Robust Reading Competition which considers a detection as a match if it overlaps a ground truth bounding box by more than 50%. Some datasets mark every word separately, others may include several words in the ground truth box. To reflect possible variations, we combine three types of detections: one-to-one ... one-to-many ... many-to-one.' The footnote links to ch=2, which is the ICDAR 2015 challenge. That protocol (with one-to-many/many-to-one matching) is different from the official ICDAR 2013 evaluation, which uses one-to-one matching. Table V compares FaSTExt (0.897 F for alpha=2) to published single-scale results (e.g., Shi et al. 0.853, Liu et al. 0.8823) that were almost certainly obtained with the official IC13 metric. If FaSTExt's numbers were produced with the IC15 protocol, they are not directly comparable, and the margin over Liu et al. single-scale (0.897 vs 0.8823) is small enough that a protocol difference could invert the ranking. The paper does not disclose that it used a different protocol for IC13, and it does not provide detections or code to re-evaluate. This threatens the central claim of outperforming state-of-the-art on IC13.","agreement_with_reader":"disagree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The manuscript proposes FaSTExt, a fully convolutional scene-text detector built from MobileNetV2-style inverted residual blocks. It predicts per-pixel text segments, their geometry, within-scale links, and cross-scale links at five output scales (8x8 to 128x128) and reconstructs word boxes with a DFS-based post-processing step. The authors pretrain on SynthText and fine-tune on ICDAR 2013, ICDAR 2015, and MSRA-TD500; with width multipliers alpha=0.75, 1, and 2 they obtain 1.58, 2.87, and 10.59 million parameters and report F-measures of 0.8716, 0.8765, and 0.8970 on IC13, with 37.5, 35.2, and 18.2 FPS on a GTX 1080 Ti. They conclude that the method is suited to camera-captured images in which text is roughly centered and not too small, and they explicitly acknowledge that performance degrades on IC15 and TD500.","tokens_in":8063,"tokens_out":5464,"duration_ms":48838,"significance":"If the headline results are taken at face value, the paper makes a useful empirical contribution: it demonstrates that a compact MobileNetV2-style detector can reach competitive F-measure on a standard benchmark while using substantially fewer parameters than VGG- or ResNet-based competitors, and it reports speed measurements on identical hardware. The architecture is described in sufficient detail to reimplement, the parameter-count and timing tables are useful, and the paper honestly states its scope limitations. However, the strength of the significance claim depends on the validity of the IC13 comparison, the absence of variability estimates, and the support for the five-scale design choice. The manuscript would be strengthened by releasing evaluation code or per-image detections and by reporting official IC13 metrics.","major_comments":[{"comment":"The evaluation protocol described in Section IV.B, with one-to-one, one-to-many, and many-to-one matching and a footnote linking to the ICDAR 2015 challenge (ch=2), is not the official ICDAR 2013 evaluation protocol, which uses one-to-one matching. The single-scale comparison numbers in Table V (Shi et al. 0.853, Liu et al. 0.8823, Liao et al. 0.81) were reported by their authors with the official IC13 metric. Therefore the FaSTExt IC13 F-measures may not be directly comparable, and the claimed advantage over Liu et al. (0.8970 vs 0.8823) could be an artifact of the more permissive matching. The authors should re-evaluate FaSTExt with the official IC13 evaluation code or with the same code used for the cited baselines, and report both metrics, or remove the head-to-head comparisons.","section":"Section IV.B, Table V"},{"comment":"All reported F-measures come from a single training run per configuration. The differences between configurations are small (0.8716, 0.8765, and 0.8970 on IC13), and the margin over the closest cited single-scale baseline is 0.0147; without repeated runs or a variance estimate, the claims that alpha=2 'outperforms' and that smaller versions are 'on par with' state of the art are not statistically supported. At minimum, report means and standard deviations over multiple runs, or provide per-image scores and a matched-pair test.","section":"Section IV.C, Tables V-VII"},{"comment":"The five-scale design and the 512-pixel input resolution are load-bearing assumptions. Section III states that five scales at about 0.3 megapixels was 'a rational tradeoff' but reports no ablation of the number of scales, the scale range, or the input resolution; Section IV.C attributes the IC15 and TD500 failures to small or rotated text, which is precisely the regime these choices control. The authors should add an ablation (for example, remove the 8x8 or 128x128 scale, change the input resolution, or vary the scale count) to support the claim, or explicitly temper the claim about the generality of the tradeoff.","section":"Section III, Section IV.C"}],"minor_comments":[{"comment":"The sentence 'The evaluation is done per ground truth quadrangle and detected one, not per image' is unclear; specify whether this means per-element matching in the official protocol and how the aggregate precision and recall are computed.","section":"Section IV.B"},{"comment":"The 'Extra blocks' column is ambiguous; for example, the entry 'bottleneck5 32 1 2 8' should be explained in the caption as meaning two extra bottleneck blocks leading to the 8x8 output.","section":"Table I"},{"comment":"There is a typo: 'pretraininig' should be 'pretraining'; also clarify whether the stated 20 days per alpha covers only SynthText pretraining or the full training pipeline.","section":"Section IV.A"},{"comment":"In the first row, the text says FaSTExt 'could successfully detect the full word' where the ground truth did not include the region; relative to the given ground truth this is an over-detection and should be phrased accordingly.","section":"Figure 2"},{"comment":"The notation 2/3Nh is ambiguous; if the intended denominator is 3 times the number of hard negatives, write it as 2/(3N_h) explicitly.","section":"Equation (1)"},{"comment":"The abstract does not mention the centered-text and not-too-small-text limitation that the conclusion states; adding this caveat would make the scoped claim clearer to readers.","section":"Abstract"}],"recommendation":"major_revision","confidential_remarks":"The protocol mismatch is my main concern; if the authors re-evaluate with the official IC13 metric and the advantage over single-scale baselines remains, I would support publication after the other revisions. The single-run statistics and missing ablations are also fixable. The contribution is modest but real, and the paper's limited scope is stated honestly in the conclusion."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick read: this is a useful engineering paper, not a scientific breakthrough. The genuinely new bit is the specific architecture: MobileNetV2 inverted residuals used as the backbone for a SegLink-style segment-and-link detector, plus a five-scale output scheme with cross-layer links. That combination is practical, and the parameter counts (1.58–10.59M) are real and worth having. The paper also earns credit for documenting where the method fails—IC15 and TD500 results are clearly worse, and the conclusion openly restricts the method to centered, reasonably large text. That scoped honesty is refreshing.\n\nThe central claim—that a small network can detect centered, reasonably large text at high speed—holds up. The IC13 F-measure of 0.897 for the largest variant is plausible, and the smaller variants are competitive. I considered the stress-test concern about the evaluation protocol. On reading the paper, the protocol description in Section IV.B lists one-to-one, one-to-many, and many-to-one matching; that matches the DetEval-style protocol historically used for IC13, not something obviously foreign. The footnote pointing to ch=2 is ambiguous, but I don't think this kills the comparison. However, it would be a non-issue if the authors released evaluation code or detection files. Instead, no code, weights, or full hyperparameters are provided, so independent verification is impossible.\n\nThe real soft spots are the missing scale ablation and the lack of error bars. The authors assert that five scales at approximately 0.3 megapixels were a rational tradeoff, but they provide no experiment varying the scale count, scale range, or input resolution. That matters because the network's failure on IC15/TD500 is attributed to scale. This is a load-bearing assumption, and without the ablation it remains hand-waving. The FPS numbers are also from their own Keras implementation on a single GPU, and without code the timing comparisons to published methods are weak. For a conference paper, these omissions are normal, but they do cap the paper's reliability.\n\nThe citation pattern looks fair: SegLink, EAST, FOTS, MobileNetV2 are all properly credited. The paper does not oversell itself, and the limitation statement in Section V matches the evidence.\n\nWho is this for? People building embedded OCR or camera-based text extraction systems where speed and small model size matter more than beating the leaderboard. A serious referee should engage with it, because the architecture is sound and the scope is clearly defined. Revisions should ask for the scale ablation, repeated-run statistics, and at least one released model or evaluation script.\n\nMy recommendation: send it to peer review. It deserves referee time, and the authors have the opportunity to close the reproducibility gap.","headline":"A well-scoped lightweight text detector with a genuinely new architecture and honest reporting; the main gaps are missing code, no ablation of the five-scale design, and a protocol footnote that invites confusion.","tokens_in":8566,"tokens_out":4114,"would_cite":false,"duration_ms":39304,"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":"FaSTExt claims a compact text detector can match larger networks on camera-centred scenes by predicting segments and links at five scales.","keywords":["scene text detection","segments and links","depthwise separable convolution","inverted residual","linear bottleneck","multi-scale prediction","lightweight CNN","real-time text extraction"],"falsifier":"A reader could settle the claim by cropping ICDAR 2015 words so they are centred and as large as ICDAR 2013 text and rerunning the same FaSTExt checkpoint; the scale-range explanation predicts F-measure should recover to near 0.897, while a representation or data explanation predicts it stays near 0.5.","tokens_in":7569,"feed_emoji":"🔤","tokens_out":5847,"duration_ms":53014,"temperature":0.7,"pith_summary":"FaSTExt is a bid to show that a small convolutional network can serve as a practical scene-text detector for camera-based use, where text is roughly centred, upright, and not tiny. The network predicts word segments and the links that join them at five output scales, and its parameter count stays between 1.58 and 10.59 million by building on MobileNetV2 bottleneck blocks. On ICDAR 2013 the largest variant reaches F-measure 0.897, beating single-scale SegLink and EAST implementations, while the smallest variant still scores 0.872 at 37.5 frames per second. What would matter if true: real-time text extraction on devices that cannot run the multi-million-parameter detectors now common in the literature, at least inside the stated operating envelope.","feed_headline":"10-million-parameter net tops larger text detectors","feed_subtitle":"FaSTExt uses five-scale segment-and-link prediction to hit 0.897 F-measure on ICDAR 2013 while running at 18 frames per second.","key_machinery":"The architecture is a fully convolutional segment-and-link detector built from MobileNetV2 bottleneck blocks: depthwise separable convolutions, linear bottlenecks (no activations on the compressed channels), and inverted residuals with shortcuts. The network outputs, at five scales from 8x8 to 128x128 receptive fields, 31-channel predictions per scale: two text/non-text classes, five geometry values, sixteen within-scale links to eight neighbours, and eight cross-layer links to the finer scale; the first scale omits cross-layer links. Segments and links are assembled by depth-first search into word bounding boxes, following the SegLink postprocessing. The MobileNetV2 blocks are the key complexity-reduction mechanism, and the five-scale output is the mechanism claimed to prevent losing small and large symbols.","core_discovery":"The central claim is that replacing a heavy VGG backbone with MobileNetV2 bottleneck blocks, in a fully convolutional segment-and-link architecture, yields a text detector whose accuracy-versus-speed tradeoff beats larger single-scale networks on the dataset that matches its intended use. Concretely, with a width multiplier alpha=2 the network has 10.59 million parameters, runs at 18.2 FPS on a GTX 1080 Ti, and achieves 0.897 F-measure on ICDAR 2013, above the reported single-scale results of SegLink (0.853) and the authors' EAST implementation (0.787). With alpha=0.75, 1.58 million parameters still give 0.872 F-measure at 37.5 FPS. The same design does not transfer to ICDAR 2015 or MSRA-TD500, where text is small, rotated, or shadowed; there FaSTExt's F-measure drops to roughly 0.48-0.65, and the authors attribute this to the fixed five-scale detection range and the centred-text operating assumption.","pith_inferences":["The paper leaves implicit that its five-scale choice is also a claim about the deployment camera: as long as the user frames the text, the same architecture should generalise to other fixed-size objects such as barcodes, QR codes, or signage without architectural change.","Because no ablation varies the number of scales or the input resolution, a direct follow-up would be to retrain with six or seven scales and larger inputs on ICDAR 2015; the paper's rational-tradeoff assertion predicts only marginal gains, which would separate a scale limitation from a representation limitation.","The authors' observation that alpha=0.75 beats alpha=2 on harder datasets because larger models need more data suggests a testable prediction: with a much larger training set, the alpha=2 network should narrow the ICDAR 2015 gap, since the architecture, not the capacity, is the stated bottleneck."],"forward_implications":["If FaSTExt's claim holds, a 10.59-million-parameter detector can match or beat single-scale SegLink and EAST on ICDAR 2013, so model size alone need not cost accuracy on centred camera text.","The 1.58-million-parameter variant gives 37.5 frames per second with F-measure 0.872, making real-time text extraction plausible on embedded GPUs.","The segment-and-link formulation with cross-scale links removes the need for separate region proposal or character detection stages for moderate-size text.","The fixed five-scale range sets a hard limit: small, rotated, or shadowed text, as in ICDAR 2015 and MSRA-TD500, is outside the method's effective operating conditions."],"supporting_citations":[{"why":"Supplies the segment-and-link representation and the depth-first-search bounding-box reconstruction algorithm that FaSTExt adopts.","marker":"[2]"},{"why":"Supplies the MobileNetV2 bottleneck blocks - depthwise separable convolution, linear bottlenecks, and inverted residuals - that shrink the parameter count.","marker":"[10]"},{"why":"Provides the SynthText pretraining corpus of more than 800,000 images used to train the network before fine-tuning.","marker":"[12]"},{"why":"Provides the ICDAR 2013 benchmark whose centred, moderate-size text matches the assumed camera scenario and supports the main accuracy claim.","marker":"[13]"},{"why":"Supplies the EAST baseline whose single-scale implementation FaSTExt outperforms on ICDAR 2013.","marker":"[3]"},{"why":"Provides the heavier FOTS real-time detector with 29 million parameters used as a comparison point on ICDAR 2013.","marker":"[8]"},{"why":"Provides the ICDAR 2015 benchmark where small, shadowed, edge-located text exposes the limits of the five-scale range.","marker":"[14]"},{"why":"Provides the MSRA-TD500 benchmark showing the method's weaker performance on rotated and multilingual text.","marker":"[15]"}],"fun_headline_variants":["Tiny text detector outperforms larger nets on ICDAR 2013","FaSTExt: 1.58M parameters detect text at 37.5 FPS","Five-scale CNN crams text detection into 1.58M params","FaSTExt hits 0.897 F1 on ICDAR 2013 at 18 FPS","Small network beats big on text, but only for centered words"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing assumption is that five fixed output scales from 8x8 to 128x128 at roughly 0.3-megapixel input cover every text size in the camera-centred scenario, a choice the paper justifies only by experience and never tests by ablation.","fun_headline_variants_meta":{"raw":{"variants":["Tiny text detector outperforms larger nets on ICDAR 2013","FaSTExt: 1.58M parameters detect text at 37.5 FPS","Five-scale CNN crams text detection into 1.58M params","FaSTExt hits 0.897 F1 on ICDAR 2013 at 18 FPS","Small network beats big on text, but only for centered words"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001124,"raw_usage":{"total_tokens":4660,"prompt_tokens":912,"completion_tokens":3748,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":528,"completion_tokens_details":{"reasoning_tokens":3642}},"tokens_in":528,"tokens_out":3748,"duration_ms":28950,"temperature":1.0,"reasoning_tokens":3642,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T13:20:14.572260+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"A reader could settle the claim by cropping ICDAR 2015 words so they are centred and as large as ICDAR 2013 text and rerunning the same FaSTExt checkpoint; the scale-range explanation predicts F-measure should recover to near 0.897, while a representation or data explanation predicts it stays near 0.5.","supporting_citations":[{"cited_title":"Detecting oriented text in natural images by linking segments,","cited_arxiv_id":null,"evidence_quote":"Supplies the segment-and-link representation and the depth-first-search bounding-box reconstruction algorithm that FaSTExt adopts."},{"cited_title":"Mobilenetv2: Inverted residuals and linear bottlenecks,","cited_arxiv_id":null,"evidence_quote":"Supplies the MobileNetV2 bottleneck blocks - depthwise separable convolution, linear bottlenecks, and inverted residuals - that shrink the parameter count."},{"cited_title":"Synthetic data for text localisation in natural images,","cited_arxiv_id":null,"evidence_quote":"Provides the SynthText pretraining corpus of more than 800,000 images used to train the network before fine-tuning."},{"cited_title":"Icdar 2013 robust reading competition,","cited_arxiv_id":null,"evidence_quote":"Provides the ICDAR 2013 benchmark whose centred, moderate-size text matches the assumed camera scenario and supports the main accuracy claim."},{"cited_title":"East: An efficient and accurate scene text detector,","cited_arxiv_id":null,"evidence_quote":"Supplies the EAST baseline whose single-scale implementation FaSTExt outperforms on ICDAR 2013."},{"cited_title":"Fots: Fast oriented text spotting with a unified network,","cited_arxiv_id":null,"evidence_quote":"Provides the heavier FOTS real-time detector with 29 million parameters used as a comparison point on ICDAR 2013."},{"cited_title":"Icdar 2015 competition on robust reading,","cited_arxiv_id":null,"evidence_quote":"Provides the ICDAR 2015 benchmark where small, shadowed, edge-located text exposes the limits of the five-scale range."},{"cited_title":"Detecting texts of arbitrary orientations in natural images,","cited_arxiv_id":null,"evidence_quote":"Provides the MSRA-TD500 benchmark showing the method's weaker performance on rotated and multilingual text."}],"review_version":1}