alexei.dolgolyov
8fe9c6489b
- New CameraEngine using OpenCV VideoCapture for webcam capture - HAS_OWN_DISPLAYS class attribute on CaptureEngine base to distinguish engines with their own device lists from desktop monitor engines - Display picker renders device list for cameras/scrcpy, spatial layout for desktop monitors - Engine-aware display label formatting (camera name vs monitor index) - Stream modal properly loads engine-specific displays on template change, edit, and clone - Camera backend config rendered as dropdown (auto/dshow/msmf/v4l2) - Remove offline label from device cards (healthcheck indicator suffices) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
64 lines
5.2 KiB
Markdown
64 lines
5.2 KiB
Markdown
# Pending Features & Issues
|
|
|
|
Priority: `P1` quick win · `P2` moderate · `P3` large effort
|
|
|
|
## Processing Pipeline
|
|
|
|
- [x] `P1` **Noise gate** — Suppress small color changes below threshold, preventing shimmer on static content
|
|
- [x] `P1` **Color temperature filter** — Already covered by existing Color Correction filter (2000-10000K)
|
|
- [ ] `P1` **Zone grouping** — Merge adjacent LEDs into logical groups sharing one averaged color
|
|
- Complexity: medium — doesn't fit the PP filter model (operates on extracted LED colors, not images); needs a new param on calibration/color-strip-source config + PixelMapper changes
|
|
- Impact: high — smooths out single-LED noise, visually cleaner ambilight on sparse strips
|
|
- [x] `P2` **Palette quantization** — Force output to match a user-defined palette (preset or custom hex)
|
|
- [x] `P2` **Drag-and-drop filter ordering** — Reorder postprocessing filter chains visually
|
|
- [ ] `P3` **Transition effects** — Crossfade, wipe, or dissolve between sources/profiles instead of instant cut
|
|
- Complexity: large — requires a new transition layer concept in ProcessorManager; must blend two live streams simultaneously during switch, coordinating start/stop timing
|
|
- Impact: medium — polishes profile switching UX but ambient lighting rarely switches sources frequently
|
|
|
|
## Output Targets
|
|
|
|
- [ ] `P1` **Rename `picture-targets` to `output-targets`** — Rename API endpoints and internal references for clarity
|
|
- Complexity: low — mechanical rename across routes, schemas, store, frontend fetch calls; no logic changes, but many files touched (~20+), needs care with stored JSON migration
|
|
- Impact: low-medium — improves API clarity for future integrations (OpenRGB, Art-Net)
|
|
- [x] `P2` **OpenRGB** — Control PC peripherals (keyboard, mouse, RAM, fans) as ambient targets
|
|
- [ ] `P2` **Art-Net / sACN (E1.31)** — Stage/theatrical lighting protocols, DMX controllers
|
|
- Complexity: medium — UDP-based protocols with well-documented specs; similar architecture to DDP client; needs DMX universe/channel mapping UI
|
|
- Impact: medium — opens stage/theatrical use case, niche but differentiating
|
|
|
|
## Automation & Integration
|
|
|
|
- [ ] `P2` **Webhook/MQTT trigger** — Let external systems activate profiles without HA integration
|
|
- Complexity: low-medium — webhook: simple FastAPI endpoint calling SceneActivator; MQTT: add `asyncio-mqtt` dependency + subscription loop
|
|
- Impact: high — key integration point for home automation users without Home Assistant
|
|
- [ ] `P2` **WebSocket event bus** — Broadcast all state changes over a single WS channel
|
|
- Complexity: low-medium — ProcessorManager already emits events; add a WS endpoint that fans out JSON events to connected clients
|
|
- Impact: medium — enables real-time dashboards, mobile apps, and third-party integrations
|
|
- [ ] `P3` **Notification reactive** — Flash/pulse on OS notifications (optional app filter)
|
|
- Complexity: large — OS-level notification listener (platform-specific: Win32 `WinToast`/`pystray`, macOS `pyobjc`); needs a new "effect source" type that triggers color pulses
|
|
- Impact: low-medium — fun but niche; platform-dependent maintenance burden
|
|
|
|
## Multi-Display
|
|
|
|
- [ ] `P2` **Investigate multimonitor support** — Research and plan support for multi-monitor setups
|
|
- Complexity: research — audit DXGI/MSS capture engine's display enumeration; test with 2+ monitors; identify gaps in calibration UI (per-display config)
|
|
- Impact: high — many users have multi-monitor setups; prerequisite for multi-display unification
|
|
- [ ] `P3` **Multi-display unification** — Treat 2-3 monitors as single virtual display for seamless ambilight
|
|
- Complexity: large — virtual display abstraction stitching multiple captures; edge-matching calibration between monitors; significant UI changes
|
|
- Impact: high — flagship feature for multi-monitor users, but depends on investigation results
|
|
|
|
## Capture Engines
|
|
|
|
- [ ] `P3` **SCRCPY capture engine** — Implement SCRCPY-based screen capture for Android devices
|
|
- Complexity: large — external dependency on scrcpy binary; need to manage subprocess lifecycle, parse video stream (ffmpeg/AV pipe), handle device connect/disconnect
|
|
- Impact: medium — enables phone screen mirroring to ambient lighting; appeals to mobile gaming use case
|
|
- [x] `P3` **Camera / webcam** — Border-sampling from camera feed for video calls or room-reactive lighting
|
|
|
|
## UX
|
|
|
|
- [ ] `P2` **Tags / groups for cards** — Assign tags to devices, targets, and sources; filter and group cards by tag
|
|
- Complexity: medium — new `tags: List[str]` field on all card entities; tag CRUD API; filter bar UI per section; tag badge rendering on cards; persistence migration
|
|
- Impact: medium-high — essential for setups with many devices/targets; enables quick filtering (e.g. "bedroom", "desk", "gaming")
|
|
- [ ] `P3` **PWA / mobile layout** — Mobile-first layout + "Add to Home Screen" manifest
|
|
- Complexity: medium-large — responsive CSS overhaul for all tabs; service worker for offline caching; manifest.json; touch-friendly controls (larger tap targets, swipe gestures)
|
|
- Impact: high — phone control is a top user request; current desktop-first layout is unusable on mobile
|