|
| 1 | +--- |
| 2 | +blogpost: true |
| 3 | +date: Dec 5, 2024 |
| 4 | +author: Niko Sirmpilatze |
| 5 | +location: London, England |
| 6 | +category: release |
| 7 | +language: English |
| 8 | +--- |
| 9 | + |
| 10 | +# Release v0.0.21 and next steps |
| 11 | + |
| 12 | +_This is our inaugaural blogpost, containing a summary of the `v0.0.21` release and a preview of what's coming next in 2025._ |
| 13 | + |
| 14 | +## What's new in movement v0.0.21? |
| 15 | + |
| 16 | +:::{tip} |
| 17 | +See our [installation guide](target-installation) for instructions on how to |
| 18 | +install the latest version or upgrade from an existing installation. |
| 19 | +::: |
| 20 | + |
| 21 | +__Input/Output__ |
| 22 | + |
| 23 | +- We have added the {func}`movement.io.load_poses.from_multiview_files` function to support loading pose tracking data from multiple camera views. |
| 24 | +- We have made several small improvements to reading bounding boxes tracks. See our new {ref}`example <sphx_glr_examples_load_and_upsample_bboxes.py>` to learn more about working with bounding boxes. |
| 25 | +- We have added a new {ref}`example <sphx_glr_examples_convert_file_formats.py>` on using `movement` to convert pose tracking data between different file formats. |
| 26 | + |
| 27 | +__Kinematics__ |
| 28 | + |
| 29 | +The {mod}`kinematics <movement.kinematics>` module has been moved from `movement.analysis.kinematics` to `movement.kinematics` and packs a number of new functions: |
| 30 | +- {func}`compute_forward_vector <movement.kinematics.compute_forward_vector>` |
| 31 | +- {func}`compute_head_direction_vector <movement.kinematics.compute_head_direction_vector>` |
| 32 | +- {func}`compute_pairwise_distances <movement.kinematics.compute_pairwise_distances>` |
| 33 | +- {func}`compute_speed <movement.kinematics.compute_speed>` |
| 34 | +- {func}`compute_path_length <movement.kinematics.compute_path_length>` |
| 35 | + |
| 36 | +__Breaking changes__ |
| 37 | + |
| 38 | +- We have dropped support for using filtering and |
| 39 | +kinematic functions via the `move` accessor syntax, |
| 40 | +because we've found the concept hard to convey to new users. All functions are henceforth solely accessible by importing them from the relevant modules. Having one way of doing things simplifies the mental model for users and reduces the maintenance effort on our side. See an example below: |
| 41 | + |
| 42 | + ```python |
| 43 | + # Instead of: |
| 44 | + position_filt = ds.move.median_filter(window=5) |
| 45 | + velocity = ds.move.compute_velocity() |
| 46 | + |
| 47 | + # Use: |
| 48 | + from movement.filtering import median_filter |
| 49 | + from movement.kinematics import compute_velocity |
| 50 | + |
| 51 | + position_filt = median_filter(ds.position, window=5) |
| 52 | + velocity = compute_velocity(ds.position) |
| 53 | + ``` |
| 54 | +- We have slightly modified the [structure of movement datasets](target-poses-and-bboxes-dataset), by changing the order of dimensions. This should have no effect when indexing data by dimension names, i.e. using the {meth}`xarray.Dataset.sel` or {meth}`xarray.Dataset.isel` methods. However, you may need to update your code if you are using Numpy-style indexing, for example: |
| 55 | + |
| 56 | + ```python |
| 57 | + # Indexing with dimension names (recommended, works always) |
| 58 | + position = ds.position.isel( |
| 59 | + individuals=0, keypoints=-1 # first individual, last keypoint |
| 60 | + ) |
| 61 | + |
| 62 | + # Numpy-style indexing with the old dimension order (will no longer work) |
| 63 | + position = ds.position[:, 0, -1, :] # time, individuals, keypoints, space |
| 64 | + |
| 65 | + # Numpy-style indexing with the updated dimension order (use this instead) |
| 66 | + position = ds.position[:, :, -1, 0] # time, space, keypoints, individuals |
| 67 | + ``` |
| 68 | + |
| 69 | + |
| 70 | +## Looking to v0.1 and beyond |
| 71 | + |
| 72 | +Over the last 1.5 years, we have gradually built up the core functionalities we envisioned for `movement` version `v0.1`, |
| 73 | +as described in our [roadmap](target-roadmaps). |
| 74 | +These have included [input/output support](target-io) for a few popular animal tracking frameworks, as well as methods for data cleaning and computing kinematic variables. |
| 75 | + |
| 76 | +What we're still missing is a [napari](napari:) plugin for `movement`, which we envision both as an interactive visualisation framework for motion tracking data as well as a graphical user interface for `movement`. |
| 77 | +We have been working on a minimal version of this plugin for a while and are expecting to ship it as part of the `v0.1` release in early 2025. |
| 78 | + |
| 79 | +After `v0.1`, we'll be switching to [semantic versioning](https://semver.org/), as it applies to MINOR (new features) and PATCH (bug fixes) versions. Until we are ready for a `v1` MAJOR version, we cannot commit to backward compatibility, but any breaking changes will be clearly communicated in the release notes. |
| 80 | + |
| 81 | +## Announcing movement Community Calls |
| 82 | + |
| 83 | +We are committed to fostering openness, transparency, and a strong sense of |
| 84 | +community within the `movement` project. |
| 85 | +Starting next year, we will host regular Community Calls via Zoom. |
| 86 | + |
| 87 | +The calls will take place every second Friday from **11:00 to 11:45 GMT**, |
| 88 | +beginning on **10 January 2025**. |
| 89 | +These calls are open to anyone interested in contributing to `movement` or |
| 90 | +sharing feedback on the project's progress and direction. |
| 91 | + |
| 92 | +A few days before each call, we will post an announcement on Zulip with the Zoom link and agenda. |
| 93 | +We encourage everyone who's interested in |
| 94 | +joining to follow this [Zulip topic](movement-community-calls:) |
| 95 | +to stay updated. |
0 commit comments