v0.2.6

Keep autocrop crop_area fixed at 0° reference

• keep public crop_area stable across 0/90/180/270 rotations
• preserve crop-once then rotate-image behavior
• align mvcrender with valetudo_map_parser calibration contract
• update autocrop regression tests for fixed crop_area invariant
• bump version to 0.2.6

Full Changelog: v.0.2.5...v0.2.5

v.0.2.5 correct swapped trim_up and trim_left in _init_auto_crop

What's Changed

• Bump actions/checkout from 4 to 6 by @dependabot[bot] in #6
• Bump actions/download-artifact from 4 to 8 by @dependabot[bot] in #7
• Bump actions/upload-artifact from 4 to 7 by @dependabot[bot] in #8
• Bump actions/setup-python from 5 to 6 by @dependabot[bot] in #9
• Bump docker/setup-qemu-action from 3 to 4 by @dependabot[bot] in #12
• Bump pypa/gh-action-pypi-publish from 1.13.0 to 1.14.0 by @dependabot[bot] in #13
• Bump softprops/action-gh-release from 2 to 3 by @dependabot[bot] in #14
• Bump pypa/cibuildwheel from 3.3.1 to 3.4.1 by @dependabot[bot] in #15
• fix(autocrop): correct swapped trim_up and trim_left in _init_auto_crop by @IT-BAER in #10

New Contributors

• @IT-BAER made their first contribution in #10

Full Changelog: v0.2.4...v.0.2.5

bump: v0.2.4 — upgrade cibuildwheel to v3.3.1 for cp314-musllinux wheels

bump: v0.2.4 — upgrade cibuildwheel to v3.3.1 for cp314-musllinux wheels

• pyproject.toml: bump version 0.2.3 → 0.2.4

• .github/workflows/wheels-and-publish.yml: cibuildwheel v2.21.3 → v3.3.1

• .github/workflows/pr-wheels.yml: cibuildwheel v2.21.3 → v3.3.1

• .github/dependabot.yml: add Dependabot for GitHub Actions (monthly)

• build_armv7_wheel.sh: add ARMv7 wheel build script

survive numpy C-ext sandbox failure during egg_info / metadata collection On aarch64-linux-musl (Alpine / HA addon build env) numpy's .so files cannot be dlopen'd ("Operation not permitted"). This caused setup.py's finalize_options to crash during get_requires_for_build_wheel, before any compilation even started. - Add _get_numpy_include() with importlib.util.find_spec fallback: locates numpy headers by path without executing numpy's __init__.py - Relax numpy constraint to >=2.0.0 in both build-system and deps (HA 2026.3 pins numpy==2.3.2 via package_constraints.txt) - Align CIBW_BUILD to cp312-* cp313-* cp314-* across all platforms (HA 2026.3 moved to Python 3.14) - Remove cp311-* / cp311t-* (not supported by requires-python >=3.12) - Add CIBW_BEFORE_BUILD numpy install to pr-wheels.yml Bumps version to 0.2.2. **Full Changelog**: https://github.com/sca075/mvcrender/compare/v0.2.1...v0.2.2

On aarch64-linux-musl (Alpine / HA addon build env) numpy's .so files
cannot be dlopen'd ("Operation not permitted"). This caused setup.py's
finalize_options to crash during get_requires_for_build_wheel, before
any compilation even started.

• Add _get_numpy_include() with importlib.util.find_spec fallback:
  locates numpy headers by path without executing numpy's init.py
• Relax numpy constraint to >=2.0.0 in both build-system and deps
  (HA 2026.3 pins numpy==2.3.2 via package_constraints.txt)
• Align CIBW_BUILD to cp312-* cp313-* cp314-* across all platforms
  (HA 2026.3 moved to Python 3.14)
• Remove cp311-* / cp311t-* (not supported by requires-python >=3.12)
• Add CIBW_BEFORE_BUILD numpy install to pr-wheels.yml

Bumps version to 0.2.2.
Full Changelog: v0.2.1...v0.2.2

bump: version 0.2.0 → 0.2.1 to bypass PyPI filename uniqueness policy

bump: version 0.2.0 → 0.2.1 to bypass PyPI filename uniqueness policy

The 0.2.0 release was deleted from PyPI but cannot be re-uploaded
with the same wheel filename. Bumping to 0.2.1 resolves this.
No code changes — wheel content is identical to 0.2.0.

Revert Auto Crop and bump Numpy

• Reverted Auto Crop to known version working version on 0.0.9.

• Fix NumPy import pattern to support Python 3.14 build environments

  • Move NumPy import from module level to BuildExt.finalize_options()
  • Prevents "Error importing numpy from source directory" build failures
  • Implements modern setuptools pattern with custom build_ext class

• Pin NumPy to version 2.3.2 to match Home Assistant requirements

  • Ensures binary compatibility with Home Assistant OS (Alpine/musl)
  • Fixes "Operation not permitted" errors in musl environments
  • Changed from numpy>=2.1 to numpy==2.3.2 in build and runtime deps

• Add Python 3.14 classifier and support

  • Home Assistant 2026.x requires Python 3.14.2+
  • Explicitly declare support for Python 3.12, 3.13, and 3.14

Files modified:

• setup.py: Custom BuildExt class for delayed NumPy import
• pyproject.toml: NumPy version pinning and Python 3.14 classifier

Fixes compatibility with Home Assistant 2026.x and valetudo-map-parser 0.2.6
Full Changelog: v0.1.0...v0.2.0

v0.1.0

Full Changelog: v0.0.10...v0.1.0

feat: implement crop_area rotation logic for rotated images (v0.1.0)

Implemented proper crop_area coordinate rotation in async_rotate_the_image()
to reflect the rotated numpy array's coordinate system.

Changes:

• crop_area indices now rotate with image rotation:
  • 0°: [left, up, right, down]
  • 90°: [down, left, up, right]
  • 180°: [right, down, left, up]
  • 270°: [up, right, down, left]
• Added PyObject_SetAttrString() to sync self->crop_area to handler.crop_area
• auto_crop remains unchanged with original coordinates
• Bumped version from 0.0.10 to 0.1.0

This ensures crop_area accurately represents pixel coordinates in the rotated
image's coordinate system, fixing coordinate mismatches when processing
rotated vacuum maps.

Files modified:

• src/mvcrender/autocrop/_native.c
• pyproject.toml

Tests: All pytest tests pass ✅
Visual verification: Generated rotated images show correct cropping with
only 1.87% background pixels (acceptable margin)

some issue with the calibration points on pi4

fix(autocrop): revert trim parameter order to [up, left, right, down] -> [left, up, right, down]

update python version

home assistant uses 3.12

v0.0.8

Bug Fixes

AutoCrop - Critical Parameter Order Fix

Fixed a critical bug in the AutoCrop C extension where trim_up and trim_left
parameters were swapped when creating the auto_crop list from predefined trim values.

What was broken:

• When using predefined trim values from shared.trims, the crop boundaries
  were calculated incorrectly
• The left and up values were swapped, causing misaligned cropping

What's fixed:

• Corrected parameter order in make_list4() call (line 468)
• Crop boundaries now correctly follow [left, up, right, down] order
• Auto-detection mode (trims=0) was never affected

Impact:

• Users with custom trim configurations will now see correct crop boundaries
• No impact on users relying on auto-detection

Test Improvements

• Standardized trim dictionary key order across test files for consistency
• No functional changes, purely for code readability
  Full Changelog: v0.0.7...v0.0.8