gtaylor/python-colormath — pull request #35 by MichaelMauderer (2014-07-06 12:19:05+00:00)
Title: Refactored color space conversion routine and added graph based algorithm

This is a proposal for a simplification of the current way type conversions between color spaces are handled.

The current implementation has the problem, that for every new color space a lot of manual work is required as new conversions between all available color spaces need to be added.

My proposal would be to substitute this approach of manually defining paths by a registration approach where a conversion function is centrally registered (e.g., using a decorator) and conversion paths are algorithmically determined based on this information.

This is a potential implementation of this approach:

1. I added a decorator based registration mechanism for color space conversion functions that annotates them with start and target color space (e.g., `@color_conversion_function(LuvColor, XYZColor)`

2. I re-factored the current way a path between color spaces is determined so a `ColorConversionManager` is used instead of a global function, allowing easy swapping of implementations. (I moved the old implementation into the `CuratedConversionManager`)

3. I added a NetworkX based `GraphConversionManager` that builds a directed Graph of conversions and then can easily determine the shortest path between two color spaces.

Currently the old implementation is still present and used as a fall-back in case NetworkX can not be imported.

I am happy to take any comments.