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?).

Reply via email to