mirror of
https://github.com/ZoneMinder/zoneminder.git
synced 2026-09-23 02:55:44 -04:00
The alarmed/filtered pixel check methods handed Overlay() the raw GRAY8 scoring mask. Overlay keys on a non-zero source pixel and copies that byte, so the highlight took whatever shape one byte has in the destination format: the red channel on an RGB32 monitor, which is the whole reason alarms have always come out red; all three channels on RGB24, giving white; luma alone on YUV420. The zone's configured Alarm Colour was honoured only on the blob path, which goes through HighlightEdges. Generalise HighlightEdges into BuildHighlight, which takes an edges_only flag and otherwise fills every marked pixel, and build the highlight for the pixel methods the same way the blob path already builds its outline: in the capture's own pixel format, carrying alarm_rgb, once scoring is finished with the GRAY8 mask. HighlightEdges stays as a thin wrapper so the blob path and its callers are unchanged. This is a behaviour change: monitors left on the default red see no difference, but a zone configured with any other Alarm Colour now paints that colour instead of red or white. Reverting the zone hunk fails the new test in all three of its sections. Full suite: 148 cases, 12535 assertions. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WBHBB95RBX7D9p8ge2WDZb