Introduce Picture Stream abstraction that separates the capture pipeline into
composable layers: raw streams (display + capture engine + FPS) and processed
streams (source stream + postprocessing template). Devices reference a picture
stream instead of managing individual capture settings.
- Add PictureStream and PostprocessingTemplate data models and stores
- Add CRUD API endpoints for picture streams and postprocessing templates
- Add stream chain resolution in ProcessorManager for start_processing
- Add picture stream test endpoint with postprocessing preview support
- Add Stream Settings modal with border_width and interpolation_mode controls
- Add stream test modal with capture preview and performance metrics
- Add full frontend: Picture Streams tab, Processing Templates tab, stream
selector on device cards, test buttons on stream cards
- Add localization keys for all new features (en, ru)
- Migrate existing devices to picture streams on startup
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Move delete button to cross (✕) at top-right corner of custom template cards
- Display template config as table instead of raw JSON
- Add engine_type to TemplateUpdate schema so engine changes are saved
- Fix editTemplate crash on missing template-test-results element
- Fix get_template route to catch ValueError for 404 responses
- Move device URL to pill badge next to device name
- Remove display index indicator from device cards
- Remember last used display in Test Capture via localStorage
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Generate default templates (MSS, DXcam, WGC) in memory from EngineRegistry at startup
- Only persist user-created templates to JSON, skip defaults on load/save
- Add capture_template_id to Device model and DeviceCreate schema
- Remember last used template in localStorage, use it for new devices with fallback
- Split Device Settings dialog into General Settings and Capture Settings
- Add capture settings button (🎬) to device card
- Separate default and custom templates with visual separator in Templates tab
- Add capture engine integration to ProcessorManager
- Add CLAUDE.md with git commit/push policy and server restart instructions
- Add en/ru localization for all new UI elements
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- MSS and DXcam now auto-initialize on first capture_display() call, matching WGC behavior
- Remove engine.initialize() call from test endpoint to prevent WGC from initializing monitor 0 unnecessarily
- This fixes the issue where testing WGC with secondary monitor would show borders on both displays
Previously, calling engine.initialize() would initialize WGC's monitor 0 by default, then capture_display() would initialize the requested monitor, causing both to be active. Now all engines consistently auto-initialize only when needed.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Add engine.initialize() call in test endpoint to fix "Engine not initialized" error for MSS and DXcam
- Create template.py with CaptureTemplate dataclass for template data model
- Create template_store.py with TemplateStore class for template CRUD operations
- TemplateStore loads from capture_templates.json and provides get_all, create, get, update, delete methods
Fixes MSS capture test failing with "Engine not initialized" error. WGC worked because it auto-initializes in capture_display(), but MSS and DXcam require explicit initialization.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Refactored WGC engine to maintain separate capture instances per monitor
- Each monitor gets dedicated instance, control, frame storage, and events
- Supports simultaneous capture from multiple monitors using same template
- Fixed template test endpoint to avoid redundant monitor 0 initialization
- Removed monitor_index from WGC template configuration (monitor-agnostic)
This enables using the same WGC template for multiple devices capturing
from different monitors without conflicts or unexpected borders.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Replace segment-based calibration with core parameters (leds_top/right/bottom/left);
segments are now derived at runtime via lookup tables
- Fix clockwise/counterclockwise edge traversal order for all 8 start_position/layout
combinations (e.g. bottom_left+clockwise now correctly goes up-left first)
- Add pixel layout preview overlay with color-coded edges, LED index labels,
direction arrows, and start position marker
- Move "Add New Device" form into a modal dialog triggered by "+" button
- Add display index selector to device settings modal
- Migrate from requirements.txt to pyproject.toml for dependency management
- Update Dockerfile and docs to use `pip install .`
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Add background health checks (GET /json/info) with configurable interval per device
- Auto-detect LED count from WLED device on add (remove led_count from create API)
- Add calibration test mode: toggle edges on/off with colored LEDs via PUT endpoint
- Show WLED firmware version badge and LED count badge on device cards
- Add modal dirty tracking with discard confirmation on close/backdrop click
- Fix layout jump when modals open by compensating for scrollbar width
- Add state_check_interval to settings API and UI
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Updated get_displays() to use get_available_displays() function from screen_capture module
- Removed duplicate display detection code in routes.py
- Now properly returns refresh_rate field in display API responses
- Removed unused get_monitor_names import
This fixes the "undefinedHz" issue in the Web UI by ensuring the backend properly provides refresh rate data.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This is a complete WLED ambient lighting controller that captures screen border pixels
and sends them to WLED devices for immersive ambient lighting effects.
## Server Features:
- FastAPI-based REST API with 17+ endpoints
- Real-time screen capture with multi-monitor support
- Advanced LED calibration system with visual GUI
- API key authentication with labeled tokens
- Per-device brightness control (0-100%)
- Configurable FPS (1-60), border width, and color correction
- Persistent device storage (JSON-based)
- Comprehensive Web UI with dark/light themes
- Docker support with docker-compose
- Windows monitor name detection via WMI (shows "LG ULTRAWIDE" etc.)
## Web UI Features:
- Device management (add, configure, remove WLED devices)
- Real-time status monitoring with FPS metrics
- Settings modal for device configuration
- Visual calibration GUI with edge testing
- Brightness slider per device
- Display selection with friendly monitor names
- Token-based authentication with login/logout
- Responsive button layout
## Calibration System:
- Support for any LED strip layout (clockwise/counterclockwise)
- 4 starting position options (corners)
- Per-edge LED count configuration
- Visual preview with starting position indicator
- Test buttons to light up individual edges
- Smart LED ordering based on start position and direction
## Home Assistant Integration:
- Custom HACS integration
- Switch entities for processing control
- Sensor entities for status and FPS
- Select entities for display selection
- Config flow for easy setup
- Auto-discovery of devices from server
## Technical Stack:
- Python 3.11+
- FastAPI + uvicorn
- mss (screen capture)
- httpx (async WLED client)
- Pydantic (validation)
- WMI (Windows monitor detection)
- Structlog (logging)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
alexei.dolgolyov