# Colour 0.4.7 and the long discipline of a scientific Python library

> A NumFOCUS affiliated package of colour science algorithms and datasets that ships on a single hard numpy dependency, keeps everything else optional, and still declares itself alpha.

**colour-science/colour** — Colour Science for Python

- Repository: https://github.com/colour-science/colour
- Website: https://www.colour-science.org
- Stars: 2,674 · Forks: 297
- Language: Python
- License: BSD-3-Clause
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/colour-science-colour

## A NumFOCUS package with a disciplined release process

Colour is a Python package providing algorithms and datasets for colour science, distributed under BSD-3-Clause terms. It is affiliated with NumFOCUS, the 501(c)(3) nonprofit that provides fiscal sponsorship and governance support for scientific Python projects, and it carries a Zenodo DOI for archival citation.

The repository metadata describes it accurately and without inflation: Colour Science for Python, 2,654 stars, 291 forks, 94 open issues, not archived, with the default branch set to develop. The topics list is a useful map of what the package actually covers, spanning colour science and colour space terminology, datasets, and spectral data in both the British and American spellings, which is sensible for a domain where both spellings appear in the underlying standards literature.

The default branch being develop rather than main or master is the first structural signal. Published releases are cut from develop, and the README keeps draft release notes for that branch at a linked gist so contributors can read what is in flight before it ships. This is a library that treats release notes as a living document rather than a changelog written after the fact.

The tree reinforces that this is a research-grade project rather than a utility script. There is a BIBLIOGRAPHY.bib, which means the documentation cites academic sources properly rather than linking blog posts. There is CODE_OF_CONDUCT.md, CONTRIBUTING.rst, CONTRIBUTORS.rst, and a THIRD_PARTY file for vendored or attributed material. There is a GRANTS file, a TODO.rst, a CHANGES.rst, and a SPONSORS.rst. Documentation infrastructure includes a Read the Docs config and a pre-commit config, and coverage is tracked with a coveragerc alongside a conftest.py at the root.

Build and release automation runs through a root-level tasks.py, and the pinned dependency set lives in a requirements.txt explicitly marked as autogenerated by uv via `uv export --no-hashes --all-extras`. Generating the lock rather than maintaining it by hand is what keeps a package with a dozen optional dependencies reproducible.

## One required dependency and twelve optional ones

The dependency design is the clearest statement of the project's philosophy. The pyproject declares exactly one hard runtime requirement: numpy at 2.1.0 or newer, below 3. That is the whole floor.

Everything else lives in an optional extra. The `optional` group carries imageio, matplotlib, networkx, onnxruntime, opencolorio, openimageio, pandas, pydot, scipy, tqdm, trimesh, and xxhash. The `docs` group carries the documentation toolchain including Sphinx and the pydata theme. A third group, `array-api`, pulls in array-api-compat and array-api-extra.

The move that made this possible is recorded in the 0.4.7 release notes: SciPy became an optional dependency, as did imageio. In 0.4.7, published 2025-12-06, the project added Python 3.14 support and dropped its typing-extensions requirement, while raising the minimum versions of the scientific stack it does use. numpy needs 2.0.0 or newer, SciPy 1.13.0, matplotlib 3.9, networkx 3.3, and pandas 2.2.

Making SciPy optional is the change with the widest blast radius, because SciPy is where interpolation lives, and interpolation is unavoidable in spectral work. Users who relied on interpolation being present after a plain install now need to install the extra. In exchange, everyone who never touches interpolation stops paying for it.

Python support is bounded rather than open-ended, at 3.11 through 3.14. Bounding the range means the maintainers can test a specific set of interpreter versions against a specific set of numpy releases, which is the difference between a supported package and an incidentally working one.

```toml
requires-python = ">=3.11,<3.15"
dependencies = [
    "numpy>=2.1.0,<3",
]
```

One conditional dependency is worth noting inside that optional group: opencolorio is required only below Python 3.14. Environmental markers like this are how a package supports a native library whose Python 3.14 wheels do not yet exist.

## What 0.4.7 actually changed

Version 0.4.7 is an alpha milestone release, and its notes are organized by category in the way a scientific package should be. Dependency work leads, followed by documentation, then module-level changes, with each item traced to an issue number and contributor.

On dependencies, 0.4.7 added Python 3.14 support, made SciPy and imageio optional, and dropped typing-extensions. On documentation, every documented object was passed through an automated docstring processor, a script kept in the project's separate meta repository, to improve consistency and correct typos and mistakes. The notes credit the work to the maintainer alongside Claude Code, which is a notable thing to see stated plainly in a release log for a scientific library, where documentation precision carries real weight.

The Array API extras are the strategically interesting item. The array-api-compat and array-api-extra dependencies exist so Colour can execute its array operations against backends other than numpy, meaning a GPU array library or an alternative tensor implementation. For a package full of matrix operations on spectral data, where the computational cost is genuinely high, that is a substantive capability rather than a compliance checkbox.

Looking backward at 0.4.6, published 2024-10-11, shows the maintenance cost of the dependency cleanup. The 0.4.6 notes record that trimesh had been incorrectly added as a required dependency during a migration to uv. This is a small, honest bug report about packaging: a tool migration silently changed what users had to install, and the fix was to move trimesh into the optional group where it belonged.

That pair of releases tells the real story of the project. Over roughly fourteen months, the package corrected a packaging regression, then made two heavy scientific dependencies optional, added a new interpreter version, and opened a path to non-numpy array backends. None of that is glamorous, and all of it is what maintaining a widely used scientific library actually consists of.

```toml
array-api = [
    "array-api-compat>=1,<2",
    "array-api-extra>=0.7,<1",
]
```

## Alpha status, open issues, and documentation culture

The pyproject classifiers declare the development status as Alpha. For a package with sixteen years of releases, an affiliated NumFOCUS project, and a Zenodo DOI, that label deserves explanation rather than alarm.

The 94 open issues are the visible half of that story. A scientific library that implements published algorithms and ships reference datasets accumulates a long tail of requests that are genuinely ambiguous: a request to add a colour space from a 2024 paper, a report that a dataset disagrees with a specific reference implementation, a question about whether a particular delta-E variant should be included. None of those are bugs with an obvious fix, and closing them requires judgment rather than effort.

The BIBLIOGRAPHY.bib and the citation-aware documentation build explain the documentation approach. Sphinx with the pydata theme and a BibTeX extension means the API documentation and the theory behind each function are generated from the same sources that the field cites. For colour science, where several functions exist to implement equations from specific papers, having those equations traceable matters more than it would in a typical library.

The contributor-facing files point the same direction. CONTRIBUTING.rst, CODE_OF_CONDUCT.md, CONTRIBUTORS.rst, and a GRANTS file together suggest a project that treats its academic and community process as part of the artifact. The GRANTS file in particular records funding provenance, which is unusual and useful for a project that accepts sponsorship.

The sponsorship structure is a three-tier OpenCollective arrangement, with gold, silver, and bronze levels alongside an explicit invitation to join as a sponsor. The named gold sponsors are makeup.land, Joseph Goldstone, and Colorhythm. Silver includes Nick Shaw of antlerpost. Bronze includes Sean Cooper and caveacademy. Several slots in the rendered tables are placeholders, which is how the project signals it is open to more sponsors.

Coverage is tracked through Coveralls and code quality through Codacy, and the README badges are wired to the develop branch rather than a release tag. That detail is small but meaningful: the badges report the state of unreleased work, so a green badge describes tomorrow's release rather than the one you have installed.

## What the repository layout says about the work itself

The tree is short, and every entry is load-bearing. The `colour` directory is the package itself. `docs` holds the documentation sources. `utilities` holds maintenance and data-preparation tooling, separated from the library so it is not imported at runtime.

Separating `utilities` from `colour` is a decision worth noticing. Dataset work in colour science involves downloading, parsing, and reformatting reference measurements from a variety of source formats, and that tooling changes on a different schedule than the algorithms. Keeping it out of the import path means the library has no optional-tooling imports to guard against, which matters in a package that has just spent a release making its dependencies optional.

The root-level test infrastructure is minimal by design: conftest.py at the root, a coveragerc, and a pre-commit config. There is no sprawling test directory in the tree, which suggests tests live inside the package alongside the code they cover, following the standard scientific Python layout where test modules sit next to their subjects.

Two files describe intent rather than code. TODO.rst is a public statement of what is not yet done, and CHANGES.rst is the release history. Publishing a TODO at the root is a small act of respect for users, because it lets someone decide whether a missing feature is a known gap or an oversight.

Finally, the theme of the repository is dual naming. The project is called Colour and the import is `colour`, while the package on PyPI is `colour-science`. The topic list includes both spellings throughout. For a domain where the CIE and IEC standards use one convention and much of the software ecosystem uses the other, carrying both names consistently is a deliberate compatibility choice rather than inconsistency, and it is why searches for either spelling land on the right package.

## Conclusion

The most instructive number in this repository is not the star count or the dataset catalog. It is the 94 open issues sitting against a package that its own maintainers still label alpha. Most projects resolve that tension by quietly dropping to beta or describing themselves as stable. Colour has kept the strict label in its pyproject classifiers instead, which is a more honest way to handle the gap between "works on my machine" and "guaranteed."

For anyone depending on it, three things are worth acting on. Install with the `optional` extra rather than importing SciPy-dependent modules on a bare install, because that extra now carries twelve libraries the core deliberately does not. Pin to 0.4.7 or later rather than 4.1-era assumptions about hard requirements, since SciPy and imageio stopped being mandatory. And if you are considering the Array API extras, test them against your numpy version, because the `array-api` group exists precisely to let the package run on non-numpy backends and that path has far less production history than the numpy one.

## FAQ

### What is the Colour package for Python?

Colour is an open-source Python package providing a broad set of algorithms and datasets for colour science, distributed under BSD-3-Clause. It is affiliated with NumFOCUS, the 501(c)(3) nonprofit that provides fiscal sponsorship and governance for scientific Python projects. The import name is `colour` while the PyPI distribution is `colour-science`, and the repository carries topics under both the British and American spellings so either search term finds it.

### How do I install Colour and its optional dependencies?

The core install needs only numpy, with the project requiring numpy 2.1.0 or newer below 3, and Python 3.11 through 3.14. The heavier scientific stack is optional: SciPy, matplotlib, pandas, networkx, imageio, openimageio, opencolorio, onnxruntime, trimesh, pydot, tqdm, and xxhash all live in the `optional` extra. Since 0.4.7, SciPy and imageio are no longer installed by default, so install that extra if you rely on interpolation or image IO.

### What changed in Colour 0.4.7?

Version 0.4.7, published 2025-12-06 as an alpha milestone, added Python 3.14 support, made SciPy and imageio optional dependencies, and dropped the typing-extensions requirement. It raised minimum versions for the scientific stack, including numpy 2.0.0, SciPy 1.13.0, matplotlib 3.9, networkx 3.3, and pandas 2.2. It also added Array API extras so the package can run its array operations on backends other than numpy.

### Why does Colour still declare itself Alpha?

The pyproject classifiers set the development status to Alpha, and the repository shows 94 open issues against 2,654 stars. A library that implements published algorithms and ships reference datasets accumulates requests that require judgment rather than a mechanical fix, such as adding a colour space from recent literature or reconciling a dataset with a reference implementation. The project keeps the strict label rather than quietly promoting itself, and points contributors at a public TODO.rst for known gaps.

### Does Colour support hardware acceleration or non-numpy array backends?

Partly. The `array-api` extra installs array-api-compat and array-api-extra, which let Colour execute array operations against backends other than numpy, so a GPU array library or alternative tensor implementation can be used for the matrix-heavy work in spectral processing. The optional group also includes onnxruntime and opencolorio for model inference and colour management. The numpy path remains the one with the longest production history, so treat the alternatives as paths worth testing rather than settled ground.

## Sources

- [colour-science/colour on GitHub](https://github.com/colour-science/colour)
- [License: BSD-3-Clause](https://github.com/colour-science/colour/blob/develop/LICENSE)
- [Project website](https://www.colour-science.org)
- [README](https://github.com/colour-science/colour/blob/develop/README.md)
- [Releases](https://github.com/colour-science/colour/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/colour-science-colour