Phobos colour module?

[Manu via Digitalmars-d]

On 2 January 2015 at 02:06, ponce via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Thursday, 1 January 2015 at 15:46:07 UTC, Manu via Digitalmars-d wrote:
>>
>> I feel like the colour space should be attached to the colour. Why would
>> you make it a separate object?
>>
>
> If the color space is a runtime object (eg from parsing a CC profile) then I
> would be wary of any additional memory it could use, hence necessity to pass
> it separately. For a single color value alone, not a problem.
> If it is a template parameter, no such problem exist, it would be attached
> as template argument to Color. But then, you can't parse CC profiles!
> Headache ensue.
>
> It's like we need a compile-time parameter that would be a runtime one
> sometimes, like in many D designs. Maybe there is an escape hatch with a
> template being some sort of std.variant of color-spaces.

Right, I see. Good idea, I'm sure there's a clear solution here.

I think possibly just some 'unspecified' colour space, and that would
cause no implicit colour space conversions to happen...?
It would be up to the user to make calls to appropriate conversion
functions according to whatever runtime data they have.

That said, as I see it, runtime colour space is not a concept that's
useful applied to single pixels; that would be horrendously slow or
memory consuming. It would need to be managed at the image level, and
pixels would have to have 'unspecified' colour space at compile time,
and rely on image level API's to perform runtime colour space
conversions.

I'm also a bit dubious about the usefulness of an 'unknown' colour
space at all... almost all tasks imply a specific colour space.
Reading/writing images from disk, rendering to displays, printing,
etc, are all operations that expect very particular colour space.
Image processing algorithms are usually quite dependant on particular
colour space. I can't imagine a generic image processing algorithm
that works with any runtime given colour space.
I think it would be known at compile time in almost all cases. I can't
imagine a case where it wouldn't.


>> 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.
>
>
> Be our cook :)

Well maybe Vladimir would like to get involved? It looks like he's put
a lot of time into this already.