Phobos colour module?

Manu via Digitalmars-d digitalmars-d at puremagic.com
Thu Jan 1 07:45:54 PST 2015


On 2 January 2015 at 01:09, ponce via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> 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.

Haha, it's surprisingly similar to what I already have! Except my
colour also has a colour space which is properly accounted when doing
casts or assignments.


>> Does it seem like something we should see added to phobos?
>>
>
> Image concept + planar bitmap implementing would be really nice.

Vladimir has already made a great start on that it seems.


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

That's why I don't want to deal with images to start with ;)
I think we can get a colour in there. Images will lead to massive debate.


> The number of color space is also astounding, and then do we store it as a
> template parameter or a runtime object?

I feel like the colour space should be attached to the colour. Why
would you make it a separate object?


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

Seems he's already done heaps of this work. Perhaps it would be best
for Vladimir to push on this stuff instead?


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

Exactly, it's highly debatable! ;)

I think image work in phobos needs to be taken in steps, and should
probably start with the simplest and most useful shared primitives
first.
Colour would offer massive bang-for-buck in terms of getting different
3rd party modules talking to eachother.


More information about the Digitalmars-d mailing list