www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.experimental.color, request reviews

reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
https://github.com/D-Programming-Language/phobos/pull/2845

I'm getting quite happy with it.
I think it's a good and fairly minimal but useful starting point.

It'd be great to get some reviews from here.
Jun 23 2015
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
Just a quick concern, I don't think a package.d should ever have 
anything except imports in it. Put all the actual aliases and 
color lists in some other submodule that can be imported 
independently with minimal dependencies.
Jun 23 2015
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 23 June 2015 at 15:01:59 UTC, Adam D. Ruppe wrote:

 Just a quick concern, I don't think a package.d should ever 
 have anything except imports in it. Put all the actual aliases 
 and color lists in some other submodule that can be imported 
 independently with minimal dependencies.


std/range/package.d and std/regex/package.d both have a bunch of 
stuff in. Why not?
Jun 23 2015
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 23 June 2015 at 15:24:44 UTC, John Colvin wrote:

 std/range/package.d and std/regex/package.d both have a bunch 
 of stuff in. Why not?


Those are also mistakes (well, probably just semi-migrated from 
the old big module). Suppose you want some of that stuff without 
the rest of the package. How do you get to it?

The biggest benefit of breaking up the big modules is so you can 
access some of it without requiring all of it. But when the part 
you want is in the package.d, you can't get it independently 
anymore; importing that also imports everything else, negating 
the reason it was split up in the first place.
Jun 23 2015
next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 24/06/2015 3:29 a.m., Adam D. Ruppe wrote:

 On Tuesday, 23 June 2015 at 15:24:44 UTC, John Colvin wrote:

 std/range/package.d and std/regex/package.d both have a bunch of stuff
 in. Why not?


 Those are also mistakes (well, probably just semi-migrated from the old
 big module). Suppose you want some of that stuff without the rest of the
 package. How do you get to it?


I use a file called defs for this. Works brilliantly.
Jun 23 2015
prev sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Tuesday, 23 June 2015 at 15:29:42 UTC, Adam D. Ruppe wrote:

 On Tuesday, 23 June 2015 at 15:24:44 UTC, John Colvin wrote:

 std/range/package.d and std/regex/package.d both have a bunch 
 of stuff in. Why not?


 Those are also mistakes (well, probably just semi-migrated from 
 the old big module). Suppose you want some of that stuff 
 without the rest of the package. How do you get to it?

 The biggest benefit of breaking up the big modules is so you 
 can access some of it without requiring all of it. But when the 
 part you want is in the package.d, you can't get it 
 independently anymore; importing that also imports everything 
 else, negating the reason it was split up in the first place.


But that's more an argument against putting anything _except_ the 
basic definitions into package.d, no? Then you can always exclude 
the more specific stuff whenever you need it, and those modules 
themselves can publicly import package.d.
Jun 23 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 23 June 2015 at 16:14:59 UTC, Marc Schütz wrote:

 But that's more an argument against putting anything _except_ 
 the basic definitions into package.d, no? Then you can always 
 exclude the more specific stuff whenever you need it, and those 
 modules themselves can publicly import package.d.


What if you want the basic definitions alone to build something 
off of?

If I want to write an image library that can share pixels with 
your image library, I might import std.color just to get the 
pixel format. I don't need the list of colors nor any algorithms, 
I just want to share the basic type so our two libraries can pass 
data back and forth.

So I write like

RGBA8[] readImage() {}

With the std.color functions, some other library can now take 
that pixel array and convert it or whatever they need to do. 
Great, you can use my thing pretty easily.

But I don't need any conversions myself. I don't do 
transformations. I don't use named colors, blending functions, or 
anything else. (Maybe my image format is extremely simple.)


So pulling the rest of the library would waste compile time and 
binary space. Especially if a user wanted my extremely simple 
image format exactly because they were short on time and space.



So ideally, my module would ONLY import std.color.basic_types or 
something like that.... but alas, RGBA8 is defined in package.d, 
so if I want it, whether I like it or not, I just pulled half the 
std.color library....

which just pulled std.traits and std.typecons, which, thankfully, 
didn't import anything else, but that's not the case for so many 
Phobos modules.



This layout isn't bad today, the std.color in the PR is pretty 
small and pretty lazy thanks to the templates and local imports 
in them, but I still want to set a precedent in Phobos of 
untangling the web of dependencies by moving as much independent 
code as reasonably possible to independent modules.
Jun 23 2015
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 23 June 2015 at 17:11:57 UTC, Adam D. Ruppe wrote:

 On Tuesday, 23 June 2015 at 16:14:59 UTC, Marc Schütz wrote:

 But that's more an argument against putting anything _except_ 
 the basic definitions into package.d, no? Then you can always 
 exclude the more specific stuff whenever you need it, and 
 those modules themselves can publicly import package.d.


 What if you want the basic definitions alone to build something 
 off of?

 If I want to write an image library that can share pixels with 
 your image library, I might import std.color just to get the 
 pixel format. I don't need the list of colors nor any 
 algorithms, I just want to share the basic type so our two 
 libraries can pass data back and forth.

 So I write like

 RGBA8[] readImage() {}

 With the std.color functions, some other library can now take 
 that pixel array and convert it or whatever they need to do. 
 Great, you can use my thing pretty easily.

 But I don't need any conversions myself. I don't do 
 transformations. I don't use named colors, blending functions, 
 or anything else. (Maybe my image format is extremely simple.)


 So pulling the rest of the library would waste compile time and 
 binary space. Especially if a user wanted my extremely simple 
 image format exactly because they were short on time and space.



 So ideally, my module would ONLY import std.color.basic_types 
 or something like that.... but alas, RGBA8 is defined in 
 package.d, so if I want it, whether I like it or not, I just 
 pulled half the std.color library....

 which just pulled std.traits and std.typecons, which, 
 thankfully, didn't import anything else, but that's not the 
 case for so many Phobos modules.



 This layout isn't bad today, the std.color in the PR is pretty 
 small and pretty lazy thanks to the templates and local imports 
 in them, but I still want to set a precedent in Phobos of 
 untangling the web of dependencies by moving as much 
 independent code as reasonably possible to independent modules.


Isn't this what selective imports are for? Admittedly it's not 
quite as convenient, but it does let you choose exactly what you 
want. You can even make a module that wraps a manually selected 
set of imports, e.g. you do your own basic_types module.

In the end, if you have specific requirements, you have to be 
specific.
Jun 23 2015
next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Tuesday, 23 June 2015 at 17:53:43 UTC, John Colvin wrote:

 Isn't this what selective imports are for? Admittedly it's not 
 quite as convenient, but it does let you choose exactly what 
 you want. You can even make a module that wraps a manually 
 selected set of imports, e.g. you do your own basic_types 
 module.

 In the end, if you have specific requirements, you have to be 
 specific.


Unfortunately, selective imports have been broken for 9 years.
Jun 23 2015
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 23 June 2015 at 17:59:48 UTC, Meta wrote:

 On Tuesday, 23 June 2015 at 17:53:43 UTC, John Colvin wrote:

 Isn't this what selective imports are for? Admittedly it's not 
 quite as convenient, but it does let you choose exactly what 
 you want. You can even make a module that wraps a manually 
 selected set of imports, e.g. you do your own basic_types 
 module.

 In the end, if you have specific requirements, you have to be 
 specific.


 Unfortunately, selective imports have been broken for 9 years.


There is hope: 
https://github.com/D-Programming-Language/dmd/pull/3407
Jun 23 2015
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/23/15 1:59 PM, Meta wrote:

 On Tuesday, 23 June 2015 at 17:53:43 UTC, John Colvin wrote:

 Isn't this what selective imports are for? Admittedly it's not quite
 as convenient, but it does let you choose exactly what you want. You
 can even make a module that wraps a manually selected set of imports,
 e.g. you do your own basic_types module.

 In the end, if you have specific requirements, you have to be specific.


 Unfortunately, selective imports have been broken for 9 years.


Even selective imports being fixed, the benefits in terms of separate 
compilation and encapsulation are worth it.

I agree with the idea to limit package.d to just public imports. I don't 
think it should be enforced by the compiler, but it should be something 
Phobos strives for and that we recommend.

-Steve
Jun 23 2015
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 23 June 2015 at 17:53:43 UTC, John Colvin wrote:

 Isn't this what selective imports are for?


Not quite the same thing: selective imports control which symbols 
you pull into the current namespace, but not which code gets 
pulled into the binary.

If you do `import foo : bar;`, the compiler processes all of foo 
(consider that it has to, just to find the name), generating the 
object file for it, but only exposes the name `bar` to you.

With smaller basic modules, if you only import the foundation, 
the compiler only has to look at that small file and only has to 
include its contents in the object file.
Jun 23 2015
prev sibling next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 24 June 2015 at 03:11, Adam D. Ruppe via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Tuesday, 23 June 2015 at 16:14:59 UTC, Marc Schütz wrote:

 But that's more an argument against putting anything _except_ the basic
 definitions into package.d, no? Then you can always exclude the more
 specific stuff whenever you need it, and those modules themselves can
 publicly import package.d.



 What if you want the basic definitions alone to build something off of?

 If I want to write an image library that can share pixels with your image
 library, I might import std.color just to get the pixel format. I don't need
 the list of colors nor any algorithms, I just want to share the basic type
 so our two libraries can pass data back and forth.

 So I write like

 RGBA8[] readImage() {}

 With the std.color functions, some other library can now take that pixel
 array and convert it or whatever they need to do. Great, you can use my
 thing pretty easily.


Right, and this was what I had in mind.
I think the average user would want to: import std.color, and that's
it. They will probably want RGB8 or RGBA8.
Most users will never touch anything else in the API, so using
package.d as an "import absolutely everything" doesn't seem useful at
all to me.
Also, a use cases involving the Lab colour space almost certianly has
absolutely nothing to do with an application involving Y'UV.
I think those advanced colour space users will happily import the
package they care about.


 But I don't need any conversions myself. I don't do transformations. I don't
 use named colors, blending functions, or anything else. (Maybe my image
 format is extremely simple.)


 So pulling the rest of the library would waste compile time and binary
 space. Especially if a user wanted my extremely simple image format exactly
 because they were short on time and space.



 So ideally, my module would ONLY import std.color.basic_types or something
 like that.... but alas, RGBA8 is defined in package.d, so if I want it,
 whether I like it or not, I just pulled half the std.color library....


Well, 'half' is a bit of an exaggeration. There will be a lot more
that's not visible now, and I don't expect package.d will ever do
anything more than it does now.
I'm in favour of trimming package.d though. What do you suggest?

Will those aliases for common colour types cause a significant
compiler performance hit if they are unreferenced? Surely the compiler
won't eagerly resolve those aliases and instantiate all those colour
types in the event they are never referenced?

RGB is the common case, and it could be that that's the only one
that's present in package.d... but RGB is tricky though; it's the one
that people will almost certainly want 95% of the time, but it's also
the most complicated by far, and has the most associated detail.
I don't know how to effectively trim that for the common use case, but
I was banking on the compiler not eagerly resolving all the conversion
stuff in the event the case operator is never actually invoked?
Am I wrong about the compiler? Is it more eager than I expect?



 which just pulled std.traits and std.typecons, which, thankfully, didn't
 import anything else, but that's not the case for so many Phobos modules.


I was very careful to limit run-away phobos dependencies.
I really care about this, and I've tried to limit import scope in all locations.



 This layout isn't bad today, the std.color in the PR is pretty small and
 pretty lazy thanks to the templates and local imports in them, but I still
 want to set a precedent in Phobos of untangling the web of dependencies by
 moving as much independent code as reasonably possible to independent
 modules.


I think I've (deliberately) done this to the best extent I am able. If
you can suggest improvements, I'm all ears.
Jun 23 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 24 June 2015 at 05:30:50 UTC, Manu wrote:

 Right, and this was what I had in mind.
 I think the average user would want to: import std.color, and 
 that's
 it. They will probably want RGB8 or RGBA8.
 Most users will never touch anything else in the API, so using
 package.d as an "import absolutely everything" doesn't seem 
 useful at all to me.



Hmm, yes, that's an interesting point.


 I'm in favour of trimming package.d though. What do you suggest?


Even if it doesn't actually import everything, I'd still prefer 
to keep the package.d pretty clear. Maybe move those bits out to 
std.color.common or std.color.foundation and public import that 
from the package?


On the other hand, if everybody is ok with the package.d itself 
being a minimal import, this isn't necessary, I am just really 
worried about it growing too big in the future.



 Surely the compiler won't eagerly resolve those aliases and 
 instantiate all those colour types in the event they are never 
 referenced?


It does:

struct Foo(T) { pragma(msg, T.stringof); }
alias foo = Foo!int;

dmd test.d
int

It printed the thing meaning the template did in fact get 
instantiated when the alias mentioned it.

Templates inside the type won't be instantiated, but regular 
methods will be - along with any templates *they* reference.


In the case of the color package, this is all pretty small and 
probably not a big deal, but I'm just trying to set expectations 
that others can follow too.


 I was very careful to limit run-away phobos dependencies.
 I really care about this, and I've tried to limit import scope 
 in all locations.


Indeed, you did well.
Jun 24 2015
parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 25 June 2015 at 05:59, Adam D. Ruppe via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Wednesday, 24 June 2015 at 05:30:50 UTC, Manu wrote:

 Right, and this was what I had in mind.
 I think the average user would want to: import std.color, and that's
 it. They will probably want RGB8 or RGBA8.
 Most users will never touch anything else in the API, so using
 package.d as an "import absolutely everything" doesn't seem useful at all
 to me.




 Hmm, yes, that's an interesting point.


 I'm in favour of trimming package.d though. What do you suggest?



 Even if it doesn't actually import everything, I'd still prefer to keep the
 package.d pretty clear. Maybe move those bits out to std.color.common or
 std.color.foundation and public import that from the package?


 On the other hand, if everybody is ok with the package.d itself being a
 minimal import, this isn't necessary, I am just really worried about it
 growing too big in the future.



 Surely the compiler won't eagerly resolve those aliases and instantiate
 all those colour types in the event they are never referenced?



 It does:

 struct Foo(T) { pragma(msg, T.stringof); }
 alias foo = Foo!int;

 dmd test.d
 int

 It printed the thing meaning the template did in fact get instantiated when
 the alias mentioned it.


Bugger! So an instantiation of the struct is one thing, will it also
instantiate all the members and functions too? If it leads to an
instantiation of the cast operator, then at that point, that's
basically everything... the whole library is pulled.

What selective imports? Do selective imports of a single symbol from a
module lead to the whole module being parsed and top level
instantiations?



 Templates inside the type won't be instantiated, but regular methods will be
 - along with any templates *they* reference.


Regular methods will be, but not template methods?
Good, that means the cast operator will not be instantiated until it
is referenced. This is critical, that's the point that leads to
basically everything.
Ideally conv.d would only have selective imports at the top (if
there's an advantage to that) and proper imports scoped within the
various cast functions. Would that be a win, or will the selective
imports from each module at the top negate the advantage?



 In the case of the color package, this is all pretty small and probably not
 a big deal, but I'm just trying to set expectations that others can follow
 too.


 I was very careful to limit run-away phobos dependencies.
 I really care about this, and I've tried to limit import scope in all
 locations.



 Indeed, you did well.
Jun 24 2015
prev sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
I probably didn't express myself very clearly, with the double 
negation...

What I wanted to suggest is to put into package.d _only_ the very 
minimum that you will always need, e.g. the basic structures. 
Example:

std/
   color/
Jun 24 2015
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 23-Jun-2015 18:24, John Colvin wrote:

 On Tuesday, 23 June 2015 at 15:01:59 UTC, Adam D. Ruppe wrote:

 Just a quick concern, I don't think a package.d should ever have
 anything except imports in it. Put all the actual aliases and color
 lists in some other submodule that can be imported independently with
 minimal dependencies.


 std/range/package.d and std/regex/package.d both have a bunch of stuff
 in. Why not?


Speaking of regex - it's temporary situation. The idea is to both expose 
more submodules and keep less cruft in package.d.

I'm not for public imports only but for minimizing the amount of code in 
package.d

-- 
Dmitry Olshansky
Jun 23 2015
prev sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Jun 23, 2015 at 03:24:41PM +0000, John Colvin via Digitalmars-d wrote:

 On Tuesday, 23 June 2015 at 15:01:59 UTC, Adam D. Ruppe wrote:

Just a quick concern, I don't think a package.d should ever have
anything except imports in it. Put all the actual aliases and color
lists in some other submodule that can be imported independently with
minimal dependencies.


 
 std/range/package.d and std/regex/package.d both have a bunch of stuff
 in.  Why not?


That's a temporary situation. When those packages were broken up, we
didn't want to make too extensive a change, so we left the less
important bits in package.d. Ideally, however, they should be moved into
their own subpackages.


T

-- 
EMACS = Extremely Massive And Cumbersome System
Jun 23 2015
prev sibling next sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 23.06.2015 um 16:58 schrieb Manu via Digitalmars-d:

 https://github.com/D-Programming-Language/phobos/pull/2845

 I'm getting quite happy with it.
 I think it's a good and fairly minimal but useful starting point.

 It'd be great to get some reviews from here.


 From a quick glance, looks very nice! If there was channel swizzling 
and an underlying (low dimensional) vector type, I could use it more or 
less as a drop-in replacement in my code.

One thing that I was wondering if it wouldn't make more sense overall 
for the color string representation to use RGBA instead of ARGB. The 
former is a lot more common outside of 3D APIs/hardware and arguably 
more intuitive.
Jun 23 2015
prev sibling next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Tuesday, 23 June 2015 at 14:58:35 UTC, Manu wrote:

 https://github.com/D-Programming-Language/phobos/pull/2845

 I'm getting quite happy with it.
 I think it's a good and fairly minimal but useful starting 
 point.

 It'd be great to get some reviews from here.


Swizzels would be a nice addition.
Jun 23 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
They work fine. Just cast between color structs with different component orders:

BGR8 a = Color.white;
RGB8 b = a; // <- did swizzle

Is there a specific api you miss?


On 24 June 2015 at 05:34, Tofu Ninja via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Tuesday, 23 June 2015 at 14:58:35 UTC, Manu wrote:

 https://github.com/D-Programming-Language/phobos/pull/2845

 I'm getting quite happy with it.
 I think it's a good and fairly minimal but useful starting point.

 It'd be great to get some reviews from here.



 Swizzels would be a nice addition.
Jun 23 2015
parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Wednesday, 24 June 2015 at 04:47:35 UTC, Manu wrote:

 They work fine. Just cast between color structs with different 
 component orders:

 BGR8 a = Color.white;
 RGB8 b = a; // <- did swizzle

 Is there a specific api you miss?


 On 24 June 2015 at 05:34, Tofu Ninja via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:

 On Tuesday, 23 June 2015 at 14:58:35 UTC, Manu wrote:

 https://github.com/D-Programming-Language/phobos/pull/2845

 I'm getting quite happy with it.
 I think it's a good and fairly minimal but useful starting 
 point.

 It'd be great to get some reviews from here.



 Swizzels would be a nice addition.




Ahh, I was thinking more about swizzling the color channels 
themselves, not just conversion to different color layouts.
RGB8 a = RGB8(0,1,2);
RGB8 b = a.rbg;
assert(b == RGB8(0,2,1));
Jun 24 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 24 June 2015 at 17:18, Tofu Ninja via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Wednesday, 24 June 2015 at 04:47:35 UTC, Manu wrote:

 They work fine. Just cast between color structs with different component
 orders:

 BGR8 a = Color.white;
 RGB8 b = a; // <- did swizzle

 Is there a specific api you miss?


 On 24 June 2015 at 05:34, Tofu Ninja via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Tuesday, 23 June 2015 at 14:58:35 UTC, Manu wrote:

 https://github.com/D-Programming-Language/phobos/pull/2845

 I'm getting quite happy with it.
 I think it's a good and fairly minimal but useful starting point.

 It'd be great to get some reviews from here.




 Swizzels would be a nice addition.





 Ahh, I was thinking more about swizzling the color channels themselves, not
 just conversion to different color layouts.
 RGB8 a = RGB8(0,1,2);
 RGB8 b = a.rbg;
 assert(b == RGB8(0,2,1));


Ah okay.
Yeah, it's an interesting idea. It's only applicable to RGB colours.
What's a bit awkward, is it's not entirely clear where the result of
the swizzle is assigned? Is the result of the swizzle assigned to the
colours present in the order of appearance in the current layout?
BGR8 a = Color.white;
BGR8 b = a.rbg;

is that: b=r, g=b, r=g, or is it r=r, g=b, b=g? Surely it's the
former, but that means you need to be conscious of the colour layout
whenever you perform a swizzle; ie, it will do different things for
different layouts...
Jun 24 2015
parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Wednesday, 24 June 2015 at 08:47:50 UTC, Manu wrote:

 Ah okay.
 Yeah, it's an interesting idea. It's only applicable to RGB 
 colours.
 What's a bit awkward, is it's not entirely clear where the 
 result of
 the swizzle is assigned? Is the result of the swizzle assigned 
 to the
 colours present in the order of appearance in the current 
 layout?
 BGR8 a = Color.white;
 BGR8 b = a.rbg;

 is that: b=r, g=b, r=g, or is it r=r, g=b, b=g? Surely it's the 
 former, but that means you need to be conscious of the colour 
 layout whenever you perform a swizzle; ie, it will do different 
 things for different layouts...


Ahh yes, I didn't think of that. I think for the 99% of people 
who are just using RGBA8 everywhere, it would still be valuable. 
But if it didn't get in I wouldn't be too disappointed.
Jun 24 2015
parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 25 June 2015 at 07:05, Tofu Ninja via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Wednesday, 24 June 2015 at 08:47:50 UTC, Manu wrote:

 Ah okay.
 Yeah, it's an interesting idea. It's only applicable to RGB colours.
 What's a bit awkward, is it's not entirely clear where the result of
 the swizzle is assigned? Is the result of the swizzle assigned to the
 colours present in the order of appearance in the current layout?
 BGR8 a = Color.white;
 BGR8 b = a.rbg;

 is that: b=r, g=b, r=g, or is it r=r, g=b, b=g? Surely it's the former,
 but that means you need to be conscious of the colour layout whenever you
 perform a swizzle; ie, it will do different things for different layouts...



 Ahh yes, I didn't think of that. I think for the 99% of people who are just
 using RGBA8 everywhere, it would still be valuable. But if it didn't get in
 I wouldn't be too disappointed.


Sadly not, windows used BGR in basically all OS api's.
Compatibility support usually required BGR too, since that was the
only color format supported by old video hardware for a long time.
Jun 24 2015
prev sibling next sibling parent reply "Mike" <none none.com> writes:
On Tuesday, 23 June 2015 at 14:58:35 UTC, Manu wrote:


 It'd be great to get some reviews from here.


I would like to see the packed implementatiin finished before 
this is pulled, but I won't stand in its way.

Mike
Jun 23 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 24 June 2015 at 08:46, Mike via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Tuesday, 23 June 2015 at 14:58:35 UTC, Manu wrote:


 It'd be great to get some reviews from here.



 I would like to see the packed implementatiin finished before this is
 pulled, but I won't stand in its way.


I just don't want to write all the others which will mirror this set
of API decisions almost verbatim until the API is stabilised.
Jun 23 2015
parent "Mike" <none none.com> writes:
On Wednesday, 24 June 2015 at 04:48:28 UTC, Manu wrote:


 I just don't want to write all the others which will mirror 
 this set of API decisions almost verbatim until the API is 
 stabilised.


A wise decision.  I understand.
Jun 23 2015
prev sibling next sibling parent reply "Andrea Fontana" <nospam example.com> writes:
On Tuesday, 23 June 2015 at 14:58:35 UTC, Manu wrote:

 https://github.com/D-Programming-Language/phobos/pull/2845

 I'm getting quite happy with it.
 I think it's a good and fairly minimal but useful starting 
 point.

 It'd be great to get some reviews from here.


Some points about blend/lerp:

- Using operation on rgb components usually doesn't give the 
expected result. It should be done, for example, blending hue 
saturation and brightness, rather than Red, Blue, Green (or at 
least using toLinear?)

- What happens if srcFactor + destFactor != 1? Maybe we should 
normalize srcFactor and destFactor on 0..1 using something like:
normSrcFactor = srcFactor/(srcFactor+DestFactor);
normDestFactor = destFactor/(srcFactor+DestFactor);

- Does it work with RGB only?
Jun 24 2015
parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 24 June 2015 at 17:58, Andrea Fontana via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Tuesday, 23 June 2015 at 14:58:35 UTC, Manu wrote:

 https://github.com/D-Programming-Language/phobos/pull/2845

 I'm getting quite happy with it.
 I think it's a good and fairly minimal but useful starting point.

 It'd be great to get some reviews from here.



 Some points about blend/lerp:

 - Using operation on rgb components usually doesn't give the expected
 result. It should be done, for example, blending hue saturation and
 brightness, rather than Red, Blue, Green (or at least using toLinear?)


Cast your input to a linear type (or whatever colourspace you prefer)
before lerping. User needs to make the trade-off between efficiency
(approximation) and precision (in linear space).



 - What happens if srcFactor + destFactor != 1? Maybe we should normalize
 srcFactor and destFactor on 0..1 using something like:
 normSrcFactor = srcFactor/(srcFactor+DestFactor);
 normDestFactor = destFactor/(srcFactor+DestFactor);


I don't see any reason they should require to add to one. HDR is a thing.
Lerp is a mathematical function, and while t=[0..1] is conventional,
it's not enforced, or even necessary. I think user should make a
decision to require normalisation.



 - Does it work with RGB only?


No, but like, kinda. Lab interpolates very well (by design).
Technically, all spaces lerp, just that results should be expected
with respect to the colour space you are working in.


I was thinking of removing those functions because they're a bit hard
to define concretely, for some of the reasons you say, and others.
I left them there to gather opinions and comments. Also to identify
missing functions if people find them to add value.
Jun 24 2015
prev sibling next sibling parent reply "Guillaume Chatelet" <chatelet.guillaume gmail.com> writes:
On Tuesday, 23 June 2015 at 14:58:35 UTC, Manu wrote:

 https://github.com/D-Programming-Language/phobos/pull/2845

 I'm getting quite happy with it.
 I think it's a good and fairly minimal but useful starting 
 point.

 It'd be great to get some reviews from here.


My experience (my previous job involved designing a GPU based 
color grading machine) is that the more you study colors, the 
more you realize how rich this domain is.

To me there are different features corresponding to different 
domains :
- spectral/multispectral colors (Satellite imagery, Medical 
imagery, Spectrometry), also useful for monitor calibration.
- vfx industry will want
  - sRGB, Adobe RGB with non linear gradation law (piecewise 
linear+gamma for sRGB)
  - camera colorspaces (Alexa, PanaLog, Gamma)
  - film colorspaces (density encoded, cineon / kodak log)
  - broadcast colorspaces YUV, YCbCr, YPbPr, DCI P3
  - physical color space XYZ (CGI rendering)
- print industry will want CMYK
- game industry will want alpha support with or without 
premultiplication, HSL
- academic will want perceptual colorspace (Lab, L*a*b*), 
distance expresses how different colors are perceived.
...

So to me there are several things to consider :
- the number of channels, their semantics, the type they use 
(8/10/16/32/64 bits, int, unsigned, float...)
- some format packs channels, most common form of DPX is RGB10A2 
bits packed in a 32 bit word (10bits red, 10bits green, 10 bits 
blue, 2 bits alpha) the word might be little/bigendian
- the gradation law for those channels (linear, sRGB, log, 
semilog, lookup table, ...)
- alpha is a special beast when composing colors
- when the signal is captured/displayed the gamut comes into play 
(space of colors the device can handle) the color value can be 
correlated with the characteristics of the light : white balance, 
signal quantification, white point, black point, channel 
characteristics (spectrum)
- moving between colorspaces is not necessary reversible (HSL <-> 
RGB). It involves non trivial logic (1D LUT, 3D LUT, matrix, 
piecewise functions, log/pow) that also makes the transformation 
lossy.

Manu, I understand that you don't want this library to handle 
very possible cases what is your rationale for what's useful / 
not necessary ? I suppose most users will simply manipulate sRGB 
jpeg/png.
Jun 24 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 24 June 2015 at 20:11, Guillaume Chatelet via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Tuesday, 23 June 2015 at 14:58:35 UTC, Manu wrote:

 https://github.com/D-Programming-Language/phobos/pull/2845

 I'm getting quite happy with it.
 I think it's a good and fairly minimal but useful starting point.

 It'd be great to get some reviews from here.



 My experience (my previous job involved designing a GPU based color grading
 machine) is that the more you study colors, the more you realize how rich
 this domain is.


Indeed, it's a very deep hole ;)
This is a library that could easily suffer literally endless feature
creep, I just want to keep it reasonable and practical to start with.

I've done CG for a decade or so, and some research related colour
activity (satelite,medical,thermal imagery; my current job)



 To me there are different features corresponding to different domains :
 - spectral/multispectral colors (Satellite imagery, Medical imagery,
 Spectrometry), also useful for monitor calibration.
 - vfx industry will want
  - sRGB, Adobe RGB with non linear gradation law (piecewise linear+gamma for
 sRGB)


Check, done.


  - camera colorspaces (Alexa, PanaLog, Gamma)


I don't think this will come up in the near term.


  - film colorspaces (density encoded, cineon / kodak log)


Likewise.


  - broadcast colorspaces YUV, YCbCr, YPbPr, DCI P3


On the short-list.


  - physical color space XYZ (CGI rendering)


Done.


 - print industry will want CMYK


This requires ICC interaction. There's OS involvement there.
It's a fair way down the list.


 - game industry will want alpha support with or without premultiplication,


I don't think pre-multiplied alpha is a detail that the colour itself
really needs to know about.
I thought about this, but I think it's a niche and unnecessary
complexity. Read; over-engineering.


 HSL


Easy, on the short list.


 - academic will want perceptual colorspace (Lab, L*a*b*), distance expresses
 how different colors are perceived.


On the short-ish list. This requires quite a lot of care, and it takes
time to get it just right.


 ...


I'm aware of all the points on your list. They aren't being overlooked.



 So to me there are several things to consider :
 - the number of channels, their semantics, the type they use (8/10/16/32/64
 bits, int, unsigned, float...)
 - some format packs channels, most common form of DPX is RGB10A2 bits packed
 in a 32 bit word (10bits red, 10bits green, 10 bits blue, 2 bits alpha) the
 word might be little/bigendian


Check. My background is realtime rendering ;)
I know what I'm doing here.


 - the gradation law for those channels (linear, sRGB, log, semilog, lookup
 table, ...)


All present or planned.


 - alpha is a special beast when composing colors


The colour type itself can't reasonably make any useful decision for
the user here, this is related to the functions that combine colours.


 - when the signal is captured/displayed the gamut comes into play (space of
 colors the device can handle) the color value can be correlated with the
 characteristics of the light : white balance, signal quantification, white
 point, black point, channel characteristics (spectrum)


On the mid-range-list. Chromatic adaptation is necessary for Lab at least.
This is mostly ancillary functionality though, it lives beside the
present offering.


 - moving between colorspaces is not necessary reversible (HSL <-> RGB). It
 involves non trivial logic (1D LUT, 3D LUT, matrix, piecewise functions,
 log/pow) that also makes the transformation lossy.


Yup. Can only do the best possible for each conversion. People making
use of those colour spaces and performing such conversions understand
these details.



 Manu, I understand that you don't want this library to handle very possible
 cases what is your rationale for what's useful / not necessary ? I suppose
 most users will simply manipulate sRGB jpeg/png.


Nothing is off the table. I start with RGB, since it's the 99% case.
That leads to XYZ for RGB conversions, and HSV is also very easy from
there. I had planned for that to be the initial offering.
I have made a start on Y'UV, Lab, and the compressed colour formats
typical in realtime gfx.
Advanced features are best driven by demand. There's no point
supporting scientific colour analysis if there's nobody to use it,
while a video professional sits waiting for broadcast related stuff...

I think the overwhelming use will be for loading+displaying images,
and rendering using opengl/dx/whatever.
Therefore, sRGB with all gamma conventions supported. Other RGB colour
spaces are easy from there; just definitions in a table (done, but
need tests).
PackedRGB is next (numerous requests already), then probably HSV.
After that, it's open to request. I'd like to work on some HDR related tools.

I can see a pretty clear distinction between what's *necessary* in a
standard colour library (ie, to facilitate other libraries), and
'would be nice' for niche or expert use :)
Don't worry, I'm an optics nerd!
Jun 24 2015
parent reply "Guillaume Chatelet" <chatelet.guillaume gmail.com> writes:
On Wednesday, 24 June 2015 at 11:02:04 UTC, Manu wrote:

 Don't worry, I'm an optics nerd!


Well I can tell by reading the PR already ;)
I just wanted to make sure :
- nothing important was overlooked
- what was the scope ot the proposal

Now I think my main concern is about conversions getting out of 
control (there's already quite a few static ifs).

Also do you plan on adding SIMD specializations ?

On a related note, I designed a player a few years ago which 
relied on GLSL shaders for the colorspace conversions, so it 
might be good to compare the implementations 
(https://github.com/mikrosimage/duke/blob/develop/src/duke/engine/
olorSpace.cpp#L38). My secret dream is to reimplement it in D : C++ simply is
too slow to develop with and it's a single person project so it's stale
basically...
Jun 24 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On a tangent, I need a name for the struct that will represent HSL/HSV/HSI/HCY.
They're all basically identical, and might as well be a parameter to a
shared type... but I can't think of a name for that type! >_<
I can't reasonably call it any of those or it would be confused,
rather, each of those would be an alias for an instantiation of each
type.
I'm thinking along the lines of PolarRGB? It's not really that though.
I can't think of any other good names.
alias HSL = PolarRGB!(Type.HSL);

Naming things is so hard!
Jun 24 2015
next sibling parent "Fool" <fool dlang.org> writes:
On Wednesday, 24 June 2015 at 16:05:31 UTC, Manu wrote:

 On a tangent, I need a name for the struct that will represent 
 HSL/HSV/HSI/HCY.
 They're all basically identical, and might as well be a 
 parameter to a
 shared type... but I can't think of a name for that type! >_<
 I can't reasonably call it any of those or it would be confused,
 rather, each of those would be an alias for an instantiation of 
 each
 type.
 I'm thinking along the lines of PolarRGB? It's not really that 
 though.
 I can't think of any other good names.
 alias HSL = PolarRGB!(Type.HSL);

 Naming things is so hard!


Since H(ue) seems to be the only shared property of all those RGB 
representations one of the following names might be acceptable:

HRGB
HueRGB
HueBasedRGB
HueOrientedRGB
HueTypeRGB

I'm not confident, though. :-(

Fool
Jun 24 2015
prev sibling parent reply "Guillaume Chatelet" <chatelet.guillaume gmail.com> writes:
On Wednesday, 24 June 2015 at 16:05:31 UTC, Manu wrote:

 On a tangent, I need a name for the struct that will represent 
 HSL/HSV/HSI/HCY.
 They're all basically identical, and might as well be a 
 parameter to a
 shared type... but I can't think of a name for that type! >_<
 I can't reasonably call it any of those or it would be confused,
 rather, each of those would be an alias for an instantiation of 
 each
 type.
 I'm thinking along the lines of PolarRGB? It's not really that 
 though.
 I can't think of any other good names.
 alias HSL = PolarRGB!(Type.HSL);

 Naming things is so hard!


I don't like PolarRGB since it doesn't have a lot to do with RGB.

HueSpace!(Type.HSL) ?
Jun 24 2015
parent reply "Guillaume Chatelet" <chatelet.guillaume gmail.com> writes:
On Wednesday, 24 June 2015 at 21:08:03 UTC, Guillaume Chatelet 
wrote:

 On Wednesday, 24 June 2015 at 16:05:31 UTC, Manu wrote:

 On a tangent, I need a name for the struct that will represent 
 HSL/HSV/HSI/HCY.
 They're all basically identical, and might as well be a 
 parameter to a
 shared type... but I can't think of a name for that type! >_<
 I can't reasonably call it any of those or it would be 
 confused,
 rather, each of those would be an alias for an instantiation 
 of each
 type.
 I'm thinking along the lines of PolarRGB? It's not really that 
 though.
 I can't think of any other good names.
 alias HSL = PolarRGB!(Type.HSL);

 Naming things is so hard!


 I don't like PolarRGB since it doesn't have a lot to do with 
 RGB.

 HueSpace!(Type.HSL) ?


OK I take that back. HSL expresses color in the RGB space you're 
right. Maybe CylindricalRGB ? It's a volume after all.
Jun 24 2015
next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 25 June 2015 at 07:14, Guillaume Chatelet via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Wednesday, 24 June 2015 at 21:08:03 UTC, Guillaume Chatelet wrote:

 On Wednesday, 24 June 2015 at 16:05:31 UTC, Manu wrote:

 On a tangent, I need a name for the struct that will represent
 HSL/HSV/HSI/HCY.
 They're all basically identical, and might as well be a parameter to a
 shared type... but I can't think of a name for that type! >_<
 I can't reasonably call it any of those or it would be confused,
 rather, each of those would be an alias for an instantiation of each
 type.
 I'm thinking along the lines of PolarRGB? It's not really that though.
 I can't think of any other good names.
 alias HSL = PolarRGB!(Type.HSL);

 Naming things is so hard!



 I don't like PolarRGB since it doesn't have a lot to do with RGB.

 HueSpace!(Type.HSL) ?



 OK I take that back. HSL expresses color in the RGB space you're right.
 Maybe CylindricalRGB ? It's a volume after all.


They're not cylindrical, they each represent a different shape;
cylinder, hexacone, double-hexacone,
weird-warped-crooked-cube-on-its-corner ;)
They really are polar coordinates of a sort, although even that's not
really a good description, since it's a hex rather than a circle.
Perhaps the word 'angular' is more fitting than polar in this case...
but that doesn't get me any closer to a good name! >_<
Jun 24 2015
prev sibling next sibling parent Danni Coy via Digitalmars-d <digitalmars-d puremagic.com> writes:
Wikipedia at least refer to these as cylindrical colour spaces


On Thu, Jun 25, 2015 at 2:05 PM, Manu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 25 June 2015 at 07:14, Guillaume Chatelet via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Wednesday, 24 June 2015 at 21:08:03 UTC, Guillaume Chatelet wrote:

 On Wednesday, 24 June 2015 at 16:05:31 UTC, Manu wrote:

 On a tangent, I need a name for the struct that will represent
 HSL/HSV/HSI/HCY.
 They're all basically identical, and might as well be a parameter to a
 shared type... but I can't think of a name for that type! >_<
 I can't reasonably call it any of those or it would be confused,
 rather, each of those would be an alias for an instantiation of each
 type.
 I'm thinking along the lines of PolarRGB? It's not really that though.
 I can't think of any other good names.
 alias HSL = PolarRGB!(Type.HSL);

 Naming things is so hard!



 I don't like PolarRGB since it doesn't have a lot to do with RGB.

 HueSpace!(Type.HSL) ?



 OK I take that back. HSL expresses color in the RGB space you're right.
 Maybe CylindricalRGB ? It's a volume after all.


 They're not cylindrical, they each represent a different shape;
 cylinder, hexacone, double-hexacone,
 weird-warped-crooked-cube-on-its-corner ;)
 They really are polar coordinates of a sort, although even that's not
 really a good description, since it's a hex rather than a circle.
 Perhaps the word 'angular' is more fitting than polar in this case...
 but that doesn't get me any closer to a good name! >_<
Jun 24 2015
prev sibling next sibling parent Danni Coy via Digitalmars-d <digitalmars-d puremagic.com> writes:
I would probably go with "perceptual" or something like it


On Thu, Jun 25, 2015 at 2:39 PM, Danni Coy <danni.coy gmail.com> wrote:

 Wikipedia at least refer to these as cylindrical colour spaces


 On Thu, Jun 25, 2015 at 2:05 PM, Manu via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 25 June 2015 at 07:14, Guillaume Chatelet via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Wednesday, 24 June 2015 at 21:08:03 UTC, Guillaume Chatelet wrote:

 On Wednesday, 24 June 2015 at 16:05:31 UTC, Manu wrote:

 On a tangent, I need a name for the struct that will represent
 HSL/HSV/HSI/HCY.
 They're all basically identical, and might as well be a parameter to a
 shared type... but I can't think of a name for that type! >_<
 I can't reasonably call it any of those or it would be confused,
 rather, each of those would be an alias for an instantiation of each
 type.
 I'm thinking along the lines of PolarRGB? It's not really that though.
 I can't think of any other good names.
 alias HSL = PolarRGB!(Type.HSL);

 Naming things is so hard!



 I don't like PolarRGB since it doesn't have a lot to do with RGB.

 HueSpace!(Type.HSL) ?



 OK I take that back. HSL expresses color in the RGB space you're right.
 Maybe CylindricalRGB ? It's a volume after all.


 They're not cylindrical, they each represent a different shape;
 cylinder, hexacone, double-hexacone,
 weird-warped-crooked-cube-on-its-corner ;)
 They really are polar coordinates of a sort, although even that's not
 really a good description, since it's a hex rather than a circle.
 Perhaps the word 'angular' is more fitting than polar in this case...
 but that doesn't get me any closer to a good name! >_<
Jun 24 2015
prev sibling next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 25 June 2015 at 15:18, Danni Coy via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 I would probably go with "perceptual" or something like it


That sounds like you're talking about Lab or CAM.



 On Thu, Jun 25, 2015 at 2:39 PM, Danni Coy <danni.coy gmail.com> wrote:

 Wikipedia at least refer to these as cylindrical colour spaces
Jun 24 2015
prev sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
How about HSx ? That's the best I've got! :P

On 25 June 2015 at 15:45, Manu <turkeyman gmail.com> wrote:

 On 25 June 2015 at 15:18, Danni Coy via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 I would probably go with "perceptual" or something like it


 That sounds like you're talking about Lab or CAM.



 On Thu, Jun 25, 2015 at 2:39 PM, Danni Coy <danni.coy gmail.com> wrote:

 Wikipedia at least refer to these as cylindrical colour spaces
Jun 25 2015
next sibling parent "Kagamin" <spam here.lot> writes:
On Thursday, 25 June 2015 at 13:36:57 UTC, Manu wrote:

 How about HSx ? That's the best I've got! :P


HueBased?
Jun 25 2015
prev sibling parent reply "Guillaume Chatelet" <chatelet.guillaume gmail.com> writes:
On Thursday, 25 June 2015 at 13:36:57 UTC, Manu wrote:

 How about HSx ? That's the best I've got! :P


Not too bad :-)

I'm not too excited about this but how about :
HS!L
HS!V
.,.

It could work with a good documentation.
Jun 25 2015
parent reply "Guillaume Chatelet" <chatelet.guillaume gmail.com> writes:
On Thursday, 25 June 2015 at 21:06:59 UTC, Guillaume Chatelet 
wrote:

 On Thursday, 25 June 2015 at 13:36:57 UTC, Manu wrote:

 How about HSx ? That's the best I've got! :P


 Not too bad :-)

 I'm not too excited about this but how about :
 HS!L
 HS!V
 .,.

 It could work with a good documentation.


Or just an obscure struct and some aliases :

alias HueSpace!(Type.xSL) HSL
Jun 25 2015
parent Danni Coy via Digitalmars-d <digitalmars-d puremagic.com> writes:
Huey (pronounced with an Australian Twang)?

HSx works


On Fri, Jun 26, 2015 at 7:11 AM, Guillaume Chatelet via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Thursday, 25 June 2015 at 21:06:59 UTC, Guillaume Chatelet wrote:

 On Thursday, 25 June 2015 at 13:36:57 UTC, Manu wrote:

 How about HSx ? That's the best I've got! :P



 Not too bad :-)

 I'm not too excited about this but how about :
 HS!L
 HS!V
 .,.

 It could work with a good documentation.



 Or just an obscure struct and some aliases :

 alias HueSpace!(Type.xSL) HSL
Jun 29 2015
prev sibling parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Tuesday, 23 June 2015 at 14:58:35 UTC, Manu wrote:

 https://github.com/D-Programming-Language/phobos/pull/2845

 I'm getting quite happy with it.
 I think it's a good and fairly minimal but useful starting 
 point.

 It'd be great to get some reviews from here.


Whats the status on this? This really should be easy to move into 
phobos, color is hard to mess up.
Aug 03 2015
next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 4 August 2015 at 05:47, Tofu Ninja via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Tuesday, 23 June 2015 at 14:58:35 UTC, Manu wrote:

 https://github.com/D-Programming-Language/phobos/pull/2845

 I'm getting quite happy with it.
 I think it's a good and fairly minimal but useful starting point.

 It'd be great to get some reviews from here.



 Whats the status on this? This really should be easy to move into phobos,
 color is hard to mess up.


I beg to differ; colour is VERY hard to mess up ;) .. I've never seen
an OS library, and even most proper gfx libraries don't get it right.
Aug 04 2015
parent reply "Suliman" <evermind live.ru> writes:
On Tuesday, 4 August 2015 at 11:01:58 UTC, Manu wrote:

 On 4 August 2015 at 05:47, Tofu Ninja via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:

 On Tuesday, 23 June 2015 at 14:58:35 UTC, Manu wrote:

 https://github.com/D-Programming-Language/phobos/pull/2845

 I'm getting quite happy with it.
 I think it's a good and fairly minimal but useful starting 
 point.

 It'd be great to get some reviews from here.



 Whats the status on this? This really should be easy to move 
 into phobos, color is hard to mess up.


 I beg to differ; colour is VERY hard to mess up ;) .. I've 
 never seen an OS library, and even most proper gfx libraries 
 don't get it right.


Where is this lib can be helpful?
Aug 04 2015
parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 4 August 2015 at 22:13, Suliman via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Tuesday, 4 August 2015 at 11:01:58 UTC, Manu wrote:

 On 4 August 2015 at 05:47, Tofu Ninja via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Tuesday, 23 June 2015 at 14:58:35 UTC, Manu wrote:

 https://github.com/D-Programming-Language/phobos/pull/2845

 I'm getting quite happy with it.
 I think it's a good and fairly minimal but useful starting point.

 It'd be great to get some reviews from here.




 Whats the status on this? This really should be easy to move into phobos,
 color is hard to mess up.



 I beg to differ; colour is VERY hard to mess up ;) .. I've never seen an
 OS library, and even most proper gfx libraries don't get it right.



 Where is this lib can be helpful?


There's a mirror here: https://github.com/TurkeyMan/color
But it's not up to date. The PR in the OP is the latest code.
Aug 04 2015
prev sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 4 August 2015 at 21:01, Manu <turkeyman gmail.com> wrote:

 On 4 August 2015 at 05:47, Tofu Ninja via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Tuesday, 23 June 2015 at 14:58:35 UTC, Manu wrote:

 https://github.com/D-Programming-Language/phobos/pull/2845

 I'm getting quite happy with it.
 I think it's a good and fairly minimal but useful starting point.

 It'd be great to get some reviews from here.



 Whats the status on this? This really should be easy to move into phobos,
 color is hard to mess up.


 I beg to differ; colour is VERY hard to mess up [...]


*** I mean, VERY hard to _get right_!
Aug 04 2015
parent "Guillaume Chatelet" <chatelet.guillaume gmail.com> writes:
On Tuesday, 4 August 2015 at 14:24:47 UTC, Manu wrote:

 On 4 August 2015 at 21:01, Manu <turkeyman gmail.com> wrote:

 On 4 August 2015 at 05:47, Tofu Ninja via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:

 On Tuesday, 23 June 2015 at 14:58:35 UTC, Manu wrote:

 https://github.com/D-Programming-Language/phobos/pull/2845

 I'm getting quite happy with it.
 I think it's a good and fairly minimal but useful starting 
 point.

 It'd be great to get some reviews from here.



 Whats the status on this? This really should be easy to move 
 into phobos, color is hard to mess up.


 I beg to differ; colour is VERY hard to mess up [...]


 *** I mean, VERY hard to _get right_!


+1
Aug 04 2015