All reviews of published articles are made public. This includes manuscript files, peer review comments, author rebuttals and revised materials. Note: This was optional for articles submitted before 13 February 2023.
Peer reviewers are encouraged (but not required) to provide their names to the authors when submitting their peer review. If they agree to provide their name, then their personal profile page will reflect a public acknowledgment that they performed a review (even if the article is rejected). If the article is accepted, then reviewers who provided their name will be associated with the article itself.
Dear Author,
Your paper has been revised. It has been accepted for publication in PeerJ Computer Science. Thank you for your fine contribution.
[# PeerJ Staff Note - this decision was reviewed and approved by Xiangjie Kong, a PeerJ Section Editor covering this Section #]
-
-
-
The authors replied well to all my comments.
-
-
The revised version has answered the reviewer's comments and suggestions.
-
-
**PeerJ Staff Note:** Please ensure that all review, editorial, and staff comments are addressed in a response letter and that any edits or clarifications mentioned in the letter are also inserted into the revised manuscript where appropriate.
**Language Note:** The review process has identified that the English language must be improved. PeerJ can provide language editing services - please contact us at [email protected] for pricing (be sure to provide your manuscript number and title). Alternatively, you should make your own arrangements to improve the language quality and provide details in your response letter. – PeerJ Staff
1. The current version of the manuscript lacks logical coherence in the abstract section, which needs to be thoroughly rewritten.
2. The related work section lacks necessary analysis of existing studies, particularly recent works on traffic sign detection, such as TSD‐YOLO: Small traffic sign detection based on improved YOLO v8 and Traffic sign detection via improved sparse R‐CNN for autonomous vehicles. It is recommended to discuss and analyze these studies in this section.
3. Figures 7, 8, and 9 in the experimental section are suggested to be combined into a single figure to better illustrate the differences among various methods.
1. In the experimental section, the proposed method is only validated on a single dataset, which is insufficient to demonstrate its effectiveness. Evaluation on multiple datasets is necessary.
2. The experimental section lacks adequate analysis of the results, which should be supplemented.
3. The ablation study section does not include validation of the loss function, which is an essential component and should be addressed.
The contribution of this manuscript demonstrates limited innovation, and the performance improvement achieved is not significant.
-
-
-
Based on the research work “TS-YOLO: A lightweight real-time traffic sign detector in resource-constrained environments”, I have listed some comments and suggestions below. This proposed work is interesting and well-presented, with solid results and well-illustrated figures in the study of real real-time traffic sign detector.
1. How does the use of the RepCSP module in TS-YOLO compare with other lightweight backbone enhancements in terms of balancing computational efficiency and detection accuracy?
2. What are the limitations or potential risks of training TS-YOLO from scratch without pretraining on a large dataset like ImageNet, especially when generalizing to traffic signs beyond the CCTSDB2021 dataset?
3. While the paper reports excellent mAP scores under various challenging conditions, were these evaluations conducted using unseen or real-world external datasets to test generalizability?
4. The architecture modifications seem focused on YOLOv8n. Would similar performance gains be observed with larger YOLOv8 variants (e.g., YOLOv8s or m), and how would that affect real-time applicability?
5. The references are too few to convince the readers that this is a worthy and trusted manuscript. The reference list should be boosted to > 60 so that it’s a reliable and convincing one. I propose adding (doi:10.3390/electronics13030530) to classifying and localizing objects in images or videos on page 7, line 86 of the manuscript.
6. There should be a discussion section before the conclusion section.
7. Figures 8 and 9 subgraphs could be combined into a single graph axis with 4 different legend labels for better clarity.
8. What are the potential trade-offs between detection speed and accuracy when tuning parameters like image resolution, batch size, or model complexity within TS-YOLO’s training configuration?
9. Could the integration of synthetic data or data augmentation (e.g., via GANs) further improve detection robustness for rare or occluded traffic signs, and has this been considered in future work?
TS-YOLO is an interesting extension to YOLOv8n, but in its current state, the manuscript lacks sufficient experimental breadth and comparative insight to meet the standards of a good journal. The authors are encouraged to significantly improve the validation scope, include more comprehensive hardware evaluations, and polish the manuscript for clarity. In addition, the model is evaluated using CCTSDB2021, a Chinese traffic sign dataset. The goal is to strike a balance between accuracy and real-time inference efficiency, particularly for deployment in edge or resource-constrained environments. While the architectural design is well motivated and the experimental results show improvements over several baseline lightweight detectors, the current validation is limited in scope, especially because it relies on only a single dataset (CCTSDB2021) and lacks broader generalizability analysis. There are some suggestions for authors.
-
-
1. Although CCTSDB2021 is a high-quality dataset, it focuses on Chinese road sign contexts and does not represent broader traffic sign diversity (e.g., European, American, multi-language). This severely limits the external validity of the findings.
2. No hardware deployment or edge inference validation. The paper claims real-time and edge deployment suitability, but no test is conducted on actual devices. Please report real-world inference latency, memory usage, temperature, or FPS on at least one embedded platform to match the paper title.
3. Figure 1 currently shows general detection examples that do not highlight the 'special' or 'superior' performance of TS-YOLO in challenging scenarios, as mentioned in the text. Since Figure 10 provides a more detailed qualitative comparison intended to demonstrate TS-YOLO's robustness and performance against YOLOv8, Figure 1 offers limited additional value and may be seen as redundant. Consider removing Figure 1 to streamline the manuscript and emphasize the more impactful comparative results in Figure 10.
4. Figure 5 shows the architecture of TS-YOLO. However, many blocks in the figure are labeled with abbreviations (e.g., CBL, BN) that are not explained either within the figure or its caption, which might confuse readers. Additionally, some arrows connecting the 'Neck' to the 'Detect head' appear incomplete or lack clear origin points, making it hard to follow the data flow. Including a legend or clear notes directly within Figure 5 to define all abbreviations used for the architectural blocks (e.g., CBL, BN) would help. Also, ensure that all arrows indicating data flow, especially between the neck and detection head, are complete and clearly show their start and end points.
5. The manuscript presents results using metrics such as [email protected] and [email protected] without clearly explaining what these evaluation metrics mean. For readers less familiar with object detection literature, this lack of explanation may be confusing. Consider adding a subsection, within the 'Experiment' section or a new 'Evaluation Metrics' section, to define and clarify the meaning of mAP @ 0.5 and mAP @ 0.95. This will improve the clarity and make the paper more accessible to a wider audience.
6. While the text states that 'Figure 10 reveals that TS-YOLO demonstrates superior robustness and performance compared to YOLOv8,' the quantitative improvements shown in Table 3 (0.3% in [email protected] and 1.1% in [email protected]) are relatively small. This is an overclaim given the modest numerical differences. Additionally, the visual results in Figure 10 appear almost identical between YOLOv8 and TS-YOLO for each pair of images, and the numbers on the bounding boxes are difficult to read, making it hard to discern the claimed 'superior robustness and performance visually'.
7. The manuscript states that the CCTSDB2021 dataset contains three primary traffic sign categories (prohibitory, warning, and mandatory) but does not provide details on the class distribution within the dataset. Furthermore, the presented results (in Tables 3 and 5) only show overall accuracy metrics ([email protected] and [email protected]) and do not include per-class detection accuracy. To provide a more comprehensive understanding of the model's performance and the dataset's characteristics, please include:
8. A table or discussion detailing the class distribution (e.g., number of instances or images per class) of the CCTSDB2021 dataset.
9. Per-class accuracy results for TS-YOLO (and ideally for YOLOv8 as a baseline) to show how well the model performs on each traffic sign category."
10. Tables 3, 4, and 5 show various performance metrics. To improve readability and quickly highlight key findings, it would be helpful to bold the best result (e.g., lower for GFLOPs, higher for mAP) for each metric within the tables. To further emphasize the optimal values, include a note in each table's caption (e.g., 'Bold indicates the best performance for each metric.').
11. The manuscript states that TS-YOLO has more parameters (14.98M) and higher GFLOPs (10.4) compared to YOLOv8 (11.47M parameters, 8.1 GFLOPs), as shown in Table 3. Despite this increase in computational complexity, the paper claims that TS-YOLO maintains the same inference speed of 0.6 ms per image. This is counterintuitive because a higher GFLOPs count usually means a greater computational load and slower inference. While the 'RepVGGBlock' section discusses reparameterization to a single branch for inference, it does not clearly explain how an overall increase in GFLOPs (from 8.1 to 10.4) can still result in identical inference speeds. The authors should provide a more detailed explanation or analysis to clarify why TS-YOLO can keep the same inference speed despite having more parameters and GFLOPs than YOLOv8. This would significantly enhance the understanding of the model's efficiency.
All text and materials provided via this peer-review history page are made available under a Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.