refs/tags/v0.12.0

skan v0.12.0

This release adds NumPy 2.0 compatibility (while remaining compatible with 1.x)
(#229). It also lays the groundwork for
new skeleton editing features with bidirectional Skeleton to NetworkX
conversion functions (#224.

We also have a minor deprecation that should improve quality of life in the
future: column names in the summary dataframe can now use _ as the separator
(instead of -), which allows one to use the pandas attribute access for
columns (for example, summary.branch_distance instead of
summary['branch-distance']. Use the separator='_' keyword argument to
summarize to take advantage of this feature (which will become the default in
a future version), or separator='-' to maintain the current behavior even
when new versions come out (#215).

The napari plugin now lets you make a Shapes layer fully backed by a Skeleton
dataset, including coloring the edges by features in the summary table
(#201).

Thanks to Neil Shephard,
James Ryan,
Jarod Hanko, and
Tim Monko for their contributions to this
release! 🙏 You can find the full list of changes below:

API changes

• #215: The separators used for column
  names are configurable, and will transition to _ in the future. This is to
  make it easier to use the dataframe attribute interface, e.g.
  summary.branch_distance

New features

• #229: NumPy 2 compatibility
• #224: Create a networkx summary graph
  from a Skeleton
• #201: Add napari widget to generate
  shapes layer from a skeletonized label layer

Improvements

• #220: Allow mean pixel value
  calculation from integer values, not just floats
• #212: Improved error reporting and
  tests for prune_paths methods

Bug fixes

• #221: Fix documentation builds
• #210: Cache skeleton_image shape for
  use by the path_label_image method

Documentation

• #231: Add 0.12 release notes

Misc

• #232: Use python -m build for wheel
  and sdist
• #218: Fix pyproject.toml metadata
  formatting
• #217: Migrate from setup.cfg to
  pyproject.toml

refs/tags/v0.11.0

skan v0.11.0

This release of skan incorporates several bug fixes, new API features, and
documentation improvements. It also finalizes an API change started in 0.10.0:
now junction points are always resolved using a minimum spanning tree, and the
uniquify_junctions and junction_mode arguments to Skeleton are
deprecated (see our FAQ). Finally, this is the first release
containing a napari plugin!
Currently all it does is skeletonize a Labels layer, but this is just the
beginning for GUI-based skeleton analysis.

Thanks to everyone who has helped make this release possible, including
Kushaan Gupta, Lucy
Liu, Ryan Ly,
James Ryan, and
Simon Savary! Not to speak of all the
contributors who make our upstream libraries possible! 🙏

API changes

• #143: the unique_junctions and
  junction_mode keyword arguments are removed. Junctions are always resolved
  by finding the minimum spanning tree of the junction pixels. This PR also
  speeds up building of the pixel graph.

New features

• #150,
  #164: add Sholl analysis. (Thanks to
  Kushaan Gupta for the collaboration that
  led to this feature!)
• #184: add napari plugin.

Bug fixes

• #152: Some pixel graphs had missing
  paths in their skeletons because of a mistake in how the graphs were
  traversed. Thanks Simon Savary for the detailed
  report that led to the fix! (#147)
• #193,
  #183: fix the calculation of the
  buffer size needed for the pixel path graph in the presence of 0-degree
  nodes (isolated pixels).
• #135: the unique_junctions keyword
  argument to the Skeleton class is deprecated. Use instead junction_mode.
  Note however that this option will be removed in 0.11, so you should pin your
  skan dependency if you need this behavior.
• #139: the skan GUI and corresponding
  skan.gui module and skan command have all been removed. A new, much more
  sophisticated napari plugin is in development at
  https://github.com/kevinyamauchi/napari-skeleton-curator and will be folded
  into a future version of skan (probably v0.11).

Documentation

• #155,
  #156,
  #159: Add documentation on 3D display
  of skeletons in napari.
• #173,
  #175,
  #177: support multiple versions of
  documentation. (!) (This series of PRs in particular is close to my heart
  because deprecations and API changes like those listed above are much more
  painful if the old versions are just erased! Thanks to Lucy
  Liu for her efforts and expertise here!)
• #194,
  #195: overhaul of documentation and
  build infrastructure.

Misc

• #167: drop Python 3.7 support.
• #188,
  #189,
  #190: update requirements.

v0.11.0rc1

This release of skan incorporates several bug fixes, new API features…

v0.10.0

skan v0.10.0rc0

This is a major release of skan that changes, removes, or deprecates much
functionality. As skan has grown in popularity, we've been working hard to
clean out the warts and kinks in the API, improve compatibility with libraries
such as dask, and fix several bugs reported by users. This has brought one
major change in how skan computes branch lengths
(#135): junctions are now cleaned up by
computing their minimum spanning tree rather than by computing their centroid
(see the FAQ). This change can be
reverted with a keyword argument in this version (junction_mode='centroid'),
but will be mandatory in upcoming versions. If you need to preserve the old
results, pin skan to <v0.11.

Thanks to Genevieve Buckley, Marianne
Corvellec, Zoltan
Csati, Marlene da Vitoria
Lobo, and Kevin
Yamauchi for their contributions!

API changes

• #135: the unique_junctions keyword
  argument to the Skeleton class is deprecated. Use instead junction_mode.
  Note however that this option will be removed in 0.11, so you should pin your
  skan dependency if you need this behavior.
• #139: the skan GUI and corresponding
  skan.gui module and skan command have all been removed. A new, much more
  sophisticated napari plugin is in development at
  https://github.com/kevinyamauchi/napari-skeleton-curator and will be folded
  into a future version of skan (probably v0.11).

Improvements

• skan tests now pass on GitHub Actions on all platforms
  (#139).
• skan documentation is now built and deployed on GitHub Actions
  (#140).
• skan releases are created using GitHub Actions
  (#141).
• the skan code base is now formatted by yapf
  (#136).
• skan is now easier to adapt for dask arrays (though there is still much work
  to be done here) ((#107,
  #112 and
  #123).

v0.10.0rc2

skan v0.10.0rc0

This is a major release of skan that changes, removes, or deprecates much
functionality. As skan has grown in popularity, we've been working hard to
clean out the warts and kinks in the API, improve compatibility with libraries
such as dask, and fix several bugs reported by users. This has brought one
major change in how skan computes branch lengths
(#135): junctions are now cleaned up by
computing their minimum spanning tree rather than by computing their centroid
(see the FAQ). This change can be
reverted with a keyword argument in this version (junction_mode='centroid'),
but will be mandatory in upcoming versions. If you need to preserve the old
results, pin skan to <v0.11.

Thanks to Genevieve Buckley, Marianne
Corvellec, Zoltan
Csati, Marlene da Vitoria
Lobo, and Kevin
Yamauchi for their contributions!

API changes

• #135: the unique_junctions keyword
  argument to the Skeleton class is deprecated. Use instead junction_mode.
  Note however that this option will be removed in 0.11, so you should pin your
  skan dependency if you need this behavior.
• #139: the skan GUI and corresponding
  skan.gui module and skan command have all been removed. A new, much more
  sophisticated napari plugin is in development at
  https://github.com/kevinyamauchi/napari-skeleton-curator and will be folded
  into a future version of skan (probably v0.11).

Improvements

• skan tests now pass on GitHub Actions on all platforms
  (#139).
• skan documentation is now built and deployed on GitHub Actions
  (#140).
• skan releases are created using GitHub Actions
  (#141).
• the skan code base is now formatted by yapf
  (#136).
• skan is now easier to adapt for dask arrays (though there is still much work
  to be done here) ((#107,
  #112 and
  #123).