Phobos colour module?

[ponce via Digitalmars-d]

On Thursday, 1 January 2015 at 06:38:41 UTC, Manu via 
Digitalmars-d wrote:
> I've been working on a pretty comprehensive module for dealing 
> with
> colours in various formats and colour spaces and conversions 
> between
> all of these.
> It seems like a hot area for duplicated effort, since anything 
> that
> deals with multimedia will need this, and I haven't seen a 
> really
> comprehensive implementation.

There is such an effort in 
https://github.com/CyberShadow/ae/blob/master/utils/graphics/color.d
Could give some ideas for a more general solution.

>
> Does it seem like something we should see added to phobos?
>

Image concept + planar bitmap implementing would be really nice.

There is a lot of complications because images can be stored 
interleaved, with various pitch, also in video there exist cases 
where the several planes have different dimension (2x or 4x 
smaller) and this would be nice to account, albeit not an 
absolute necessity.
The number of color space is also astounding, and then do we 
store it as a template parameter or a runtime object?

> My colours can be used as high-level colour values for precise 
> numeric
> work, or specify encodings such that they are directly useful to
> represent pixels in images of basically any format/layout for
> rendering use.
>
> Unlike a full-blown image library which will often be 
> implemented in
> different ways for different uses, I can't imagine 
> colours/pixels
> could have a great number of implementation styles where 
> different
> API's would have any reason to compete, and as such, it seems 
> like a
> nice thing to standardise. Standardised colours would make it 
> *much*
> easier for competing image libraries to interact.
>
> With standard colours, image libraries would tend to distinguish
> themselves in terms of memory management, data layout, image
> processing patterns and api, etc. Those are all valid cases for
> different designs, but I can't imagine any reason for distinct 
> colour
> api's.
>
> Comprehensive colour-space management and minimum-loss encoding 
> is a
> lot of work, and almost every implementation ignores facets of 
> the
> puzzle that aren't obviously relevant.
>
> It would give a good foundation for other std.image related 
> libraries
> to be built on top.
> I'm also working on a graphing lib, and that requires to output 
> images.

> It would be *really* nice to support common image format
> readers/writers in the std library which need to handle pixel 
> data.
>
> Thoughts?

Currently one can separate readers/writers from data structure 
using AE graphics module. I woudln't mind something at least as 
good :)

Standardizing on std.color first looks like a good first step 
towards std.image (or shouldn't it be: std.multidimarray?).