We are evaluating the pretrained EfficientDet-Lite0 object detector
in an Android application using LiteRT.
Observation
The detector generally produces higher “cell phone” confidence when
the smartphone’s front/display side is visible. Confidence is much
lower, or the detection is missing, when the rear side with the camera
lenses is visible.
This refers to the orientation of the object being detected, not
switching between the capturing device’s front and rear cameras.
We need to detect smartphone presence; we are not asking the model
to determine whether the smartphone is actively recording.
Configuration
- Model: Google EfficientDet-Lite0 quantized,
DetectionPostProcess variant
- Runtime: com.google.ai.edge.litert:litert:1.4.2
- API: org.tensorflow.lite.Interpreter
- Input: UINT8 RGB [1, 320, 320, 3]
- Preprocessing: NV21-to-RGB conversion, rotation correction,
aspect-ratio-preserving resize and padding
- CPU threads: 2; no explicit GPU/NPU delegate
- Application confidence threshold: 0.60
- Device / Android version: [Android OS 17]
- Actual camera resolution: [640 x 480]
Reproduction
1. Run inference with the smartphone’s display side visible.
2. Repeat with its rear side visible under matched conditions.
3. Compare the postprocessed model outputs before application
confidence/label filtering.
Results and attachments
[front/display side] [rear side]
[front/display measurement results]
person=0.852, cell phone=0.500, tie=0.078, clock=0.055, tv=0.031
person=0.738, remote=0.293, bed=0.078, book=0.078, clock=0.047
person=0.852, cell phone=0.586, clock=0.102, book=0.094, tie=0.074
person=0.828, cell phone=0.523, book=0.078, chair=0.078, laptop=0.059
person=0.816, cell phone=0.477, chair=0.078, clock=0.059, mouse=0.031
person=0.871, cell phone=0.586, clock=0.051, chair=0.043, tv=0.043
person=0.883, cell phone=0.605, chair=0.047, clock=0.031, mouse=0.031
person=0.891, cell phone=0.668, chair=0.102, laptop=0.078, clock=0.039
person=0.871, cell phone=0.688, laptop=0.055, chair=0.047, keyboard=0.031
person=0.883, cell phone=0.668, chair=0.043, book=0.039, clock=0.039
person=0.891, cell phone=0.648, chair=0.031, clock=0.031
person=0.871, cell phone=0.668, clock=0.031, book=0.027
person=0.891, cell phone=0.648, chair=0.043, book=0.039, clock=0.039
person=0.871, cell phone=0.688, chair=0.059, book=0.023, clock=0.020
person=0.883, cell phone=0.629, chair=0.051
person=0.871, cell phone=0.629, chair=0.051, clock=0.035
person=0.828, cell phone=0.477, chair=0.199, laptop=0.066, clock=0.059
=> ‘cell phone’ object score range : 0.477 ~ 0.688 (average 0.6055)
[rear side measurement results]
person=0.801, cell phone=0.313, chair=0.172, remote=0.074, traffic light=0.063
person=0.801, cell phone=0.293, chair=0.184, remote=0.160, clock=0.063
person=0.789, cell phone=0.242, chair=0.160, remote=0.086, clock=0.055
person=0.816, chair=0.211, cell phone=0.199, traffic light=0.109, remote=0.078
person=0.816, cell phone=0.414, remote=0.148, chair=0.086, tv=0.066
person=0.816, book=0.277, cell phone=0.137, chair=0.078, tv=0.074
person=0.816, book=0.332, remote=0.199, cell phone=0.137, chair=0.094
person=0.801, book=0.293, remote=0.172, cell phone=0.160, chair=0.094
person=0.816, book=0.277, cell phone=0.117, chair=0.102, remote=0.094
person=0.789, book=0.371, chair=0.102, remote=0.102, sports ball=0.078
person=0.816, book=0.211, cell phone=0.129, chair=0.109, tv=0.074
person=0.828, tv=0.172, book=0.160, chair=0.148, cell phone=0.137
person=0.801, chair=0.137, traffic light=0.137, book=0.129, cell phone=0.078
person=0.816, book=0.313, chair=0.160, dining table=0.066, remote=0.063
person=0.801, book=0.242, chair=0.137, cell phone=0.094, sports ball=0.059
person=0.801, cell phone=0.277, remote=0.117, chair=0.102, laptop=0.066
person=0.801, cell phone=0.277, remote=0.117, chair=0.094, sports ball=0.059
=> ‘cell phone’ object score range : 0.078 ~ 0.414 (average 0.2003)
Questions
1. Is this an expected limitation of the pretrained model?
2. Are there preprocessing checks we should perform to rule out
an integration issue?
3. Is there a recommended model or fine-tuning approach for
rear-view smartphone detection?
4. Are any rear-view-specific evaluation results available?
We have not yet established whether this is a model-generalization
limitation or an integration/runtime issue.