feat: add support of overwriting signals if harsh backlight is detected

[ktro2828]

Description

In the case of backlight, current traffic light classifier outputs incorrect color signals as video below.

original.mp4

In this PR, I added support of overwriting signals with unknown if the backlight is detected.
Check each RoI image whether backlight is and overwrite the signal with unknown corresponding to the RoI image.

According to my analysis, in the case of harsh backlight, the intensity values become higher. (RED: mean, CYAN: stddev)

Related links

TIER IV INTERNAL LINK

Tests performed

The result of backlight_threshold=0.85(default) in [0.0, 1.0].

output.mp4

Notes for reviewers

Interface changes

Effects on system behavior

Pre-review checklist for the PR author

The PR author must check the checkboxes below when creating the PR.

• I've confirmed the contribution guidelines.
• The PR follows the pull request guidelines.

In-review checklist for the PR reviewers

The PR reviewers must check the checkboxes below before approval.

• The PR follows the pull request guidelines.
• The PR has been properly tested.
• The PR has been reviewed by the code owners.

Post-review checklist for the PR author

The PR author must check the checkboxes below before merging.

• There are no open discussions or they are tracked via tickets.
• The PR is ready for merge.

After all checkboxes are checked, anyone who has write access can merge the PR.

[yukkysaito]

What camera did you use?

[ktro2828]

@yukkysaito Leopard Imaging LI-IMX490 was used in this rosbag

[yukkysaito]

@ktro2828

Understood. While this feature seems promising, I'll note an alternative approach here:

• Implementing HDR for camera support.
• Enhancing training accuracy by avoiding detection if not achievable with the fine detector.
• Training the classifier to recognize "unknown" classes.

Since the parameters here may change depending on the camera, the thresholds should be very generous.

[ktro2828]

@ktro2828

Understood. While this feature seems promising, I'll note an alternative approach here:

• Implementing HDR for camera support.
• Enhancing training accuracy by avoiding detection if not achievable with the fine detector.
• Training the classifier to recognize "unknown" classes.

@yukkysaito Yes, the points you mentioned are reasonable, and there is a movement aiming to improve with the way like these in our team.

Since the parameters here may change depending on the camera, the thresholds should be very generous.

I agree with you. In terms of this PR, I think current default threshold is higher enough as far as I experimented.

[codecov]

Codecov Report

Attention: 18 lines in your changes are missing coverage. Please review.

Comparison is base (2edd55e) 15.29% compared to head (e6cb61b) 15.26%.
Report is 9 commits behind head on main.

Files	Patch %	Lines
...erception/traffic_light_classifier/src/nodelet.cpp	0.00%	18 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5852      +/-   ##
==========================================
- Coverage   15.29%   15.26%   -0.03%     
==========================================
  Files        1750     1753       +3     
  Lines      120566   120741     +175     
  Branches    36783    36783              
==========================================
  Hits        18435    18435              
- Misses      81465    81640     +175     
  Partials    20666    20666              

Flag	Coverage Δ		*Carryforward flag
differential	0.00% <0.00%> (?)
total	15.29% <ø> (+<0.01%)	⬆️	Carriedforward from 2edd55e

*This pull request uses carry forward flags. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[miursh]

LGTM