Pelee: A Real-Time Object Detection System on Mobile Devices
An increasing need of running Convolutional Neural Network (CNN) models on mobile devices with limited computing power and memory resource encourages studies on efficient model design. A number of efficient architectures have been proposed in recent years, for example, MobileNet, ShuffleNet, and MobileNetV2. However, all these models are heavily dependent on depthwise separable convolution which lacks efficient implementation in most deep learning frameworks. In this study, we propose an efficient architecture named PeleeNet, which is built with conventional convolution instead. On ImageNet ILSVRC 2012 dataset, our proposed PeleeNet achieves a higher accuracy and over 1.8 times faster speed than MobileNet and MobileNetV2 on NVIDIA TX2. Meanwhile, PeleeNet is only 66% of the model size of MobileNet. We then propose a real-time object detection system by combining PeleeNet with Single Shot MultiBox Detector (SSD) method and optimizing the architecture for fast speed. Our proposed detection system 2 , named Pelee, achieves 76.4% mAP (mean average precision) on PASCAL VOC2007 and 22.4 mAP on MS COCO dataset at the speed of 23.6 FPS on iPhone 8 and 125 FPS on NVIDIA TX2. The result on COCO outperforms YOLOv2 in consideration of a higher precision, 13.6 times lower computational cost and 11.3 times smaller model size.
The authors proposes a new network backbone and applied it to improve object detection model speed and accuracy under constrained computation budget. The backbone is modified from densenet and detection architecture modified from SSD. The authors compare their backbone model in their own dataset and ImageNet, and detection model in PASCAL VOC and COCO.  Strengths: - The proposed method is described in detail and evaluated at component level and end-to-end.  - Proposed detection model improves AP by ~4% compared with mobilenetSSD, which is significant.  - Authors also compared the runtime in actual device, which is more convincing than just counting FLOPs.  Weaknesses:  - Although authors have proposed a set of modifications to their baseline DenseNet + SSD model, the novelty on each modification is limited. - Section 2.2.3. The experiment comparing PeleeNet with other network architecture is flawed. The author says "we can evaluate a model pre-trained on ILSVRC 2012 on this dataset", but the whole ImageNet has 1000 object classes but Stanford Dogs dataset only has 120 dog classes. Although some features can be shared in lower layers, comparing a model trained for a variety of categories with a model for dogs only is not fair. Also Table 3, PeleeNet shows big improvement on stanford dogs (~7% top-1 gain over mobilenet) but only 0.6% on the full Imagenet also suggests this experiment is not solid.  Some additional comments:  - It makes a lot of sense separable conv has an advantage in FLOP counts but doesn't run as fast in actual devices, due to bad memory access pattern. However the final Pelee model (which uses conventional conv) has similar MACs with mobilenet SSD and similar runtime too. Additional analysis / profiling could make this paper stronger.  -  Section 1, paragraph 3: "the layer uses a small kernel size (3x3), which is good enough to capture small-size objects": 3x3 is a standard practice for most modern NNs. It is arguable 3x3 is "good enough". Also smaller kernel is not very relevant  with small objects? What matters more is better spatial resolution in conv feature maps, which is usually decided by the stride of conv kernels rather than its size.  - Section 1, paragraph "Composite Function": "post-activation" is referring to BN before ReLU, this name is a bit confusing... better call it "BN before activation" / "BN after activation"?   - Same paragraph: experiment (Table 2) does show BN before ReLU hurt performance. The authors argue BN can be folded into conv this way, but BN after ReLU can be folded into next Conv op, because all activation in the same conv feature map shares the same mean / var / scale / offset in BN implementation?  - The proposed architecture drops 38x38 feature map which would hurt on small objects? Usually small objects would cost more budget to capture and they don't give good improvement on overall mAP. It would be more convincing to analyze how the proposed model works for small / medium / large size objects.  - [Minor] Section 2.1. The proposed model uses avg pool with stride 2. Conv with stride 2 could potentially be a good alternative?  - [Minor] Section 3.1: SSD feature map used in this paper is very similar to [5]. Dropping 2x2 map has limited impact on speed / accuracy.   Meanwhile, Mobilenet V1 / V2 + SSD lite (https://arxiv.org/pdf/1801.04381.pdf) presents similar performance but with smaller size / FLOPs. However it is reasonable to assume this paper to be concurrent work.