www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Phobos colour module?

reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.

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

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?
Dec 31 2014
next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 1/01/2015 7:38 p.m., 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.

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

 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?


Please do.
This was part of my goal with Devisualization.Image just without the 
phobos part.
Dec 31 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-01-01 07:38, 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.

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


I basically know nothing about this, but would this be compatible with 
the various image/graphics C libraries out there?

-- 
/Jacob Carlborg
Jan 01 2015
parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 1 January 2015 at 20:28, Jacob Carlborg via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 2015-01-01 07:38, 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.

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



 I basically know nothing about this, but would this be compatible with the
 various image/graphics C libraries out there?


That would absolutely be a critical design goal. Fortunately, colours
in C are usually expressed in very common ways.

I'm toying over exactly how I want the API should look, and if people
are behind this, then maybe I'll bring the discussion public?
Jan 01 2015
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 1 January 2015 at 06:38:41 UTC, Manu via 
Digitalmars-d wrote:

 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.


Colourspaces is a tricky area, it would be nice with a templated 
conversion tool, but you also need to deal with stuff like gamut 
compression if you want it to be a generic solution.

http://www.colorwiki.com/wiki/Gamut_Compression
Jan 01 2015
parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 1 January 2015 at 21:30, via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Thursday, 1 January 2015 at 06:38:41 UTC, Manu via Digitalmars-d wrote:

 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.



 Colourspaces is a tricky area, it would be nice with a templated conversion
 tool, but you also need to deal with stuff like gamut compression if you
 want it to be a generic solution.

 http://www.colorwiki.com/wiki/Gamut_Compression


Sure, that would definitely be a function offered. Ie, compress one
colour space into another, as opposed to doing a direct colour space
conversion, which could lead to clipping or unused headroom.

CMYK is a bit tricky, since it usually relies on OS registered colour
profiles; I'd probably leave CMYK conversion to a printing module.
Other colour spaces are not hardware or OS specific, and should all be
easy to support.
Jan 01 2015
prev sibling next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
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.

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


I think it would be a nice addition, but might seem a bit lonely 
on its own, without an image library. Maybe just put it on 
code.dlang for now, and then add it together with an image 
library later?
Jan 01 2015
next sibling parent reply "Phil" <phil.j.ellison gmail.com> writes:
 I think it would be a nice addition, but might seem a bit 
 lonely on its own, without an image library. Maybe just put it 
 on code.dlang for now, and then add it together with an image 
 library later?


This would be helpful to me even without an accompanying image
library. I have no idea about criteria for including in Phobos
though.
Jan 01 2015
parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 1 January 2015 at 22:43, Phil via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 I think it would be a nice addition, but might seem a bit lonely on its
 own, without an image library. Maybe just put it on code.dlang for now, and
 then add it together with an image library later?



 This would be helpful to me even without an accompanying image
 library. I have no idea about criteria for including in Phobos
 though.


I guess, people agree on it's necessity, and the design is approved?
Jan 01 2015
prev sibling next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 1 January 2015 at 22:39, Peter Alexander via Digitalmars-d
<digitalmars-d 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.

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



 I think it would be a nice addition, but might seem a bit lonely on its own,
 without an image library. Maybe just put it on code.dlang for now, and then
 add it together with an image library later?


I expect that would come after. The thing about an image library
though is it's a lot more debatable how it should look. Colours don't
really have much room for argument; it's complete and efficient, or
it's not.
At very least, once we have colours in phobos, then we can add modules
to read/write image files, which is quite a sore vacancy. We should
also be able to interact with OS calls that deal with image data more
conveniently.
Jan 01 2015
prev sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Thursday, 1 January 2015 at 12:39:37 UTC, Peter Alexander 
wrote:

 Maybe just put it on code.dlang for now, and then add it 
 together with an image library later?


This should imho be the standard way of submitting code to Phobos 
these days anyway. Put it up on code.dlang.org, have a couple of 
people actually use and review it there, and then (and only then) 
submit it for std.experimental.

This way, we can hopefully avoid the epic discussions from 
previous review threads where people first comment on small 
details and only later discover that the library has major design 
defects that would inhibit real-world use. (That's not to say 
that I haven't been guilty of contributing to such threads too.)

David
Jan 02 2015
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
Something that creates an API bridge between different external 
libraries is naturally a good fit for Phobos and exactly type of 
additions I'd like to see there. I think only concern is where 
exactly to put it : std.media.image.colour sounds like a most 
fitting qualified path to me but that is quite the hierarchy for 
a single module :)
Jan 01 2015
parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 2 January 2015 at 00:59, Dicebot via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Something that creates an API bridge between different external libraries is
 naturally a good fit for Phobos and exactly type of additions I'd like to
 see there. I think only concern is where exactly to put it :
 std.media.image.colour sounds like a most fitting qualified path to me but
 that is quite the hierarchy for a single module :)


It would be good to start fleshing that tree out!
Jan 01 2015
prev sibling next sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
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?).
Jan 01 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 2 January 2015 at 01:09, ponce via Digitalmars-d
<digitalmars-d 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.
Jan 01 2015
parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Thursday, 1 January 2015 at 15:46:07 UTC, Manu via 
Digitalmars-d wrote:

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


Yes, this one is pretty much untyped.



 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.


Agreed.


 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?


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.


 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 :)
Jan 01 2015
parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 2 January 2015 at 02:06, ponce via Digitalmars-d
<digitalmars-d 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.
Jan 01 2015
prev sibling next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Thursday, 1 January 2015 at 06:38:41 UTC, Manu via 
Digitalmars-d wrote:

 [snip]
 Thoughts?


I don't think something like this belongs in phobos. It's not 
universal enough to warrant all the extra work it would require 
to add and maintain in phobos.

There are significant advantages to doing it as a dub project:

- Not being locked into phobo's irregular update cycle
- Making use of other third party libraries
- Easier to control how it is built (the distributed phobos isn't 
even built with inlining enabled currently)
- Easier to accept pull requests for cases where the author isn't 
a phobos committer
- Much more freedom to break code while still letting people use 
an old version if they can't do the necessary updates for 
whatever reason

I'd love having access to something like this though. My own 
color stuff is always cobbled together from code gathered from 
random websites and I'm rarely confident I implemented them 
correctly or efficiently.
Jan 01 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 2 January 2015 at 08:21, Brad Anderson via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Thursday, 1 January 2015 at 06:38:41 UTC, Manu via Digitalmars-d wrote:

 [snip]
 Thoughts?



 I don't think something like this belongs in phobos. It's not universal
 enough to warrant all the extra work it would require to add and maintain in
 phobos.


Not universal enough? Colours are not exactly niche. Loads of system
api's, image readers/writers, icons, they all use pixel buffers.
A full-blown image library will require a lot more design work, sure,
but I can see room for that in Phobos too. There are a lot of tasks
that you can't really just download D and get to work on, particularly
in the realm of UI and multimedia, which are important tasks.



 There are significant advantages to doing it as a dub project:

 - Not being locked into phobo's irregular update cycle
 - Making use of other third party libraries
 - Easier to control how it is built (the distributed phobos isn't even built
 with inlining enabled currently)
 - Easier to accept pull requests for cases where the author isn't a phobos
 committer
 - Much more freedom to break code while still letting people use an old
 version if they can't do the necessary updates for whatever reason

 I'd love having access to something like this though. My own color stuff is
 always cobbled together from code gathered from random websites and I'm
 rarely confident I implemented them correctly or efficiently.


Yeah, it's probably actually the hardest part of image processing
jobs, and it's also the least debatable about what's 'right'. The
layers that could be built on top could be varied and remain fairly
lean.
Jan 02 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 2 January 2015 at 08:46:25 UTC, Manu via Digitalmars-d 
wrote:

 Not universal enough? Colours are not exactly niche. Loads of 
 system
 api's, image readers/writers, icons, they all use pixel buffers.
 A full-blown image library will require a lot more design work, 
 sure,
 but I can see room for that in Phobos too.


I feel Phobos need to be broken up. There is too much esoteric 
stuff in there and too much essential stuff missing. I think some 
kind of "extra" hierarchy is needed for more application specific 
functionality.

But I agree that colour theory is solid enough to be considered 
stable and that it would be a great benefit to have a single 
library used across multiple projects. It is also very suitable 
for templated types.

A standard image library would have to be templated with optional 
compiler-specific optimizations (SIMD) for the most usual 
combination. There are too many representations used in different 
types of image processing to find common ground (unless you limit 
yourself and just select PNG as your design base).
Jan 05 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 5 January 2015 at 15:57:32 UTC, Ola Fosheim Grøstad 
wrote:

 But I agree that colour theory is solid enough to be considered 
 stable and that it would be a great benefit to have a single 
 library used across multiple projects. It is also very suitable 
 for templated types.


Yeah, in my misc repo, there used to be stand along image.d and 
simpledisplay.d. Now, they both depend on color.d. Even just a 
basic definition we can use elsewhere is nice to have so other 
libs can interop on that level without annoying casts or 
pointless conversions just to please the type system when the 
contents are identical.

I went with struct Color { ubyte r,g,b,a; } .... not perfect, 
probably not good enough for like a Photoshop, and sometimes the 
bytes need to be shuffled for different formats, but eh it works 
for me.
Jan 05 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 5 January 2015 at 16:08:27 UTC, Adam D. Ruppe wrote:

 Yeah, in my misc repo, there used to be stand along image.d and 
 simpledisplay.d. Now, they both depend on color.d. Even just a 
 basic definition we can use elsewhere is nice to have so other 
 libs can interop on that level without annoying casts or 
 pointless conversions just to please the type system when the 
 contents are identical.


Yes, that too. I was more thinking about the ability to create an 
adapter that extracts colour information from an existing data 
structure and adds context information such as gamma. Then let  
you build a function that say reads floats from 3 LAB pointers 
and finally returns a tuple with a 16 bit RGB pixel with gamma 
correction and the residue in a specified format suitable for 
dithering... ;-]

It is quite common error to do computations on colours that are 
ignorant of gamma (or do it wrong) which results in less accurate 
imaging. E.g. When dithering you need to make sure that the 
residue that is left when doing bit truncation is added to the 
neighbouring pixels in a "linear addition" (without gamma). 
Making stuff like that less tedious would make it a very useful 
library.
Jan 05 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 6 January 2015 at 04:11, via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Monday, 5 January 2015 at 16:08:27 UTC, Adam D. Ruppe wrote:

 Yeah, in my misc repo, there used to be stand along image.d and
 simpledisplay.d. Now, they both depend on color.d. Even just a basic
 definition we can use elsewhere is nice to have so other libs can interop on
 that level without annoying casts or pointless conversions just to please
 the type system when the contents are identical.



 Yes, that too. I was more thinking about the ability to create an adapter
 that extracts colour information from an existing data structure and adds
 context information such as gamma. Then let  you build a function that say
 reads floats from 3 LAB pointers and finally returns a tuple with a 16 bit
 RGB pixel with gamma correction and the residue in a specified format
 suitable for dithering... ;-]

 It is quite common error to do computations on colours that are ignorant of
 gamma (or do it wrong) which results in less accurate imaging. E.g. When
 dithering you need to make sure that the residue that is left when doing bit
 truncation is added to the neighbouring pixels in a "linear addition"
 (without gamma). Making stuff like that less tedious would make it a very
 useful library.


I have thought about how to handle residue from lossy-encoding, but I
haven't thought of an API I like for that yet.
Dithering operates on neighbourhoods of pixels, so in some ways I feel
it is beyond the scope of colour.d, but residue is an important detail
to enable dithering that should probably be expressed while encoding.

Currently, I have a colour template which can be arbitrarily typed and
components defined in some user-specified order. It binds the
colourspace to colours. 'CTo to(CTo, CFrom)(CFrom colour)' is defined
and performs arbitrary conversions between colours.

I'm finding myself at a constant struggle between speed and
maximizing-precision. I feel like a lib should maximise precision, but
the trouble then is that it's not actually useful to me...
Very few applications care about colour precision beyond ubyte, so I
feel like using double for much of the processing is overkill :/
I'm not sure what the right balance would look like exactly.
I can make fast-paths for common formats, like ubyte conversions
between sRGB/Linear, etc use tables. Performing colourspace
conversions in fixed point (where both sides of conversion are integer
types) might be possible without significant loss of precision, but
it's tricky... I just pipe through double now, and that's way
overkill.

I'll make a PR tonight some time for criticism.
Jan 05 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 5 January 2015 at 23:39:17 UTC, Manu via Digitalmars-d 
wrote:

 I'm finding myself at a constant struggle between speed and
 maximizing-precision. I feel like a lib should maximise 
 precision, but
 the trouble then is that it's not actually useful to me...


If you create a "pixel" converter that aims for speed, the 
programmer might also want it to generate a shader (as text 
string) with exactly the same properties.  It makes less and less 
sense to create a performant imaging library that is CPU only.

I suggest reducing the scope to:

1. Provide generic accurate conversion and iterators for colours 
(or more general; for arrays of spectral values). Useful for 
doing batch like stuff or initialization.

2. Provide fast colour support for transforms that are simple 
enough to not warrant GPU processing, but where you accept the 
cost of building lookup tables before processing. (Build tables 
using (1).)


 Very few applications care about colour precision beyond ubyte, 
 so I
 feel like using double for much of the processing is overkill :/
 I'm not sure what the right balance would look like exactly.


I think a precise reference implementation using double is a good 
start. People creating PDFs, SVGs or some other app that does not 
have real time requirements probably want that. It is also useful 
for building LUTs.

One thing to consider is that you also might want to handle 
colour compontents that have negative values or values larger 
than 1.0:

-  it is useful in non-realistic rendering as "darklights" ( 
http://www.glassner.com/wp-content/uploads/2014/04/Darklights.pdf 
)

- with negative values you can then have a unique representation 
of a single colour in CIE (the theoretical base for RGB that was 
developed in the 1930s).

- it allows the programmer to do his own gamut compression after 
conversion
Jan 06 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 6 January 2015 at 08:52:06 UTC, Ola Fosheim Grøstad 
wrote:

 - with negative values you can then have a unique 
 representation of a single colour in CIE (the theoretical base 
 for RGB that was developed in the 1930s).


Actually, what I refer to here is a model of how humans perceive 
colour:

http://en.wikipedia.org/wiki/CIE_1931_color_space#CIE_standard_observer
Jan 06 2015
prev sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 5 January 2015 at 23:39:17 UTC, Manu via Digitalmars-d 
wrote:

 On 6 January 2015 at 04:11, via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Monday, 5 January 2015 at 16:08:27 UTC, Adam D. Ruppe wrote:

 Yeah, in my misc repo, there used to be stand along image.d 
 and
 simpledisplay.d. Now, they both depend on color.d. Even just 
 a basic
 definition we can use elsewhere is nice to have so other libs 
 can interop on
 that level without annoying casts or pointless conversions 
 just to please
 the type system when the contents are identical.



 Yes, that too. I was more thinking about the ability to create 
 an adapter
 that extracts colour information from an existing data 
 structure and adds
 context information such as gamma. Then let  you build a 
 function that say
 reads floats from 3 LAB pointers and finally returns a tuple 
 with a 16 bit
 RGB pixel with gamma correction and the residue in a specified 
 format
 suitable for dithering... ;-]

 It is quite common error to do computations on colours that 
 are ignorant of
 gamma (or do it wrong) which results in less accurate imaging. 
 E.g. When
 dithering you need to make sure that the residue that is left 
 when doing bit
 truncation is added to the neighbouring pixels in a "linear 
 addition"
 (without gamma). Making stuff like that less tedious would 
 make it a very
 useful library.


 I have thought about how to handle residue from lossy-encoding, 
 but I
 haven't thought of an API I like for that yet.
 Dithering operates on neighbourhoods of pixels, so in some ways 
 I feel
 it is beyond the scope of colour.d, but residue is an important 
 detail
 to enable dithering that should probably be expressed while 
 encoding.

 Currently, I have a colour template which can be arbitrarily 
 typed and
 components defined in some user-specified order. It binds the
 colourspace to colours. 'CTo to(CTo, CFrom)(CFrom colour)' is 
 defined
 and performs arbitrary conversions between colours.

 I'm finding myself at a constant struggle between speed and
 maximizing-precision. I feel like a lib should maximise 
 precision, but
 the trouble then is that it's not actually useful to me...
 Very few applications care about colour precision beyond ubyte, 
 so I
 feel like using double for much of the processing is overkill :/
 I'm not sure what the right balance would look like exactly.
 I can make fast-paths for common formats, like ubyte conversions
 between sRGB/Linear, etc use tables. Performing colourspace
 conversions in fixed point (where both sides of conversion are 
 integer
 types) might be possible without significant loss of precision, 
 but
 it's tricky... I just pipe through double now, and that's way
 overkill.

 I'll make a PR tonight some time for criticism.


What's wrong with old-fashioned `Fast` postfixes on entry points 
where a faster but less precise method is available? Or template 
arguments like std.algorithm.SortStrategy?
Jan 06 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 6 January 2015 at 09:19:46 UTC, John Colvin wrote:

 What's wrong with old-fashioned `Fast` postfixes on entry 
 points where a faster but less precise method is available? Or 
 template arguments like std.algorithm.SortStrategy?


If this is for phobos it should follow a common model. But since 
a fast implementation might involve an object which builds a 
table before processing....

Another problem is that "precise" is a very loose term if the 
conversion is for display or for composition in a shader. What 
you want depends on the kind of post processing that happens 
after this and how it affects the nonlinearities of human 
perception.
Jan 06 2015
next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 6 January 2015 at 19:31, via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Tuesday, 6 January 2015 at 09:19:46 UTC, John Colvin wrote:

 What's wrong with old-fashioned `Fast` postfixes on entry points where a
 faster but less precise method is available? Or template arguments like
 std.algorithm.SortStrategy?



 If this is for phobos it should follow a common model. But since a fast
 implementation might involve an object which builds a table before
 processing....

 Another problem is that "precise" is a very loose term if the conversion is
 for display or for composition in a shader. What you want depends on the
 kind of post processing that happens after this and how it affects the
 nonlinearities of human perception.


I think an important facet of 'fast' image processing is in the loop
that processes batches of pixels, rather than in the api that
processes a single pixel.
I've gone with accurate; that's the strategy throughout phobos.

I can't create look-up-tables at the moment, since '^^' doesn't work
in CTFE! >_<

Here's a PR to see where I'm at:
https://github.com/D-Programming-Language/phobos/pull/2845
Jan 06 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 6 January 2015 at 14:28:52 UTC, Manu via 
Digitalmars-d wrote:

 I think an important facet of 'fast' image processing is in the 
 loop
 that processes batches of pixels, rather than in the api that
 processes a single pixel.
 I've gone with accurate; that's the strategy throughout phobos.


Yeah, I agree. For fast on the CPU you want to use simd, and 
maybe one register for red, another for green, using saturating 
instructions, doing it differently on ARM vs x86 etc...

Besides, an accurate reference implementation is a good starting 
point and also very useful for unit testing a faster 
batch-oriented version later on.


 Here's a PR to see where I'm at:
 https://github.com/D-Programming-Language/phobos/pull/2845


Nice start. Most libraries use US-English "color", though. I 
guess phobos should try to be internally consistent (pick either 
UK or US vocabulary).
Jan 06 2015
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/6/15 6:28 AM, Manu via Digitalmars-d wrote:

 I can't create look-up-tables at the moment, since '^^' doesn't work
 in CTFE! >_<


Assuming the exponent is integral, could you write a naive pow() 
function that works in ctfe? -- Andrei
Jan 06 2015
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Jan 06, 2015 at 09:52:57AM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:

 On 1/6/15 6:28 AM, Manu via Digitalmars-d wrote:

I can't create look-up-tables at the moment, since '^^' doesn't work
in CTFE! >_<


 
 Assuming the exponent is integral, could you write a naive pow()
 function that works in ctfe? -- Andrei


I thought std.math already has an overload for pow() that works with
integral exponents?

In any case, a naïve CTFE implementation would be as simple as:

	T pow(T, U)(T t, U exp)
		if (isIntegral!U)
	{
		T result = 1;
		foreach (_; 0 .. abs(exp))
			result *= t;
		return (exp < 0) ? 1 / result : result;
	}

It's the non-integral exponents that require the currently-non-CTFE-able
code, right?

In any case, pow() itself isn't the cause of non-CTFE-ability, since
Iain has so kindly provided "native" D implementations of pow() (and
most (all?) other standard math functions) in std.math; it's just that
floating-point primitives like isInfinite currently can't be CTFE'd
because they require access to the bit representation of the floats
which CTFE currently doesn't allow.

Implementing union painting in CTFE would singlehandedly solve (almost?)
all of std.math CTFE issues, AFAICT.


T

-- 
Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen
Jan 06 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 6 January 2015 at 18:09:19 UTC, H. S. Teoh via 
Digitalmars-d wrote:

 It's the non-integral exponents that require the 
 currently-non-CTFE-able
 code, right?


http://en.wikipedia.org/wiki/Gamma_correction
Jan 06 2015
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Jan 06, 2015 at 06:28:03PM +0000, via Digitalmars-d wrote:

 On Tuesday, 6 January 2015 at 18:09:19 UTC, H. S. Teoh via Digitalmars-d
 wrote:

It's the non-integral exponents that require the
currently-non-CTFE-able code, right?


 
 http://en.wikipedia.org/wiki/Gamma_correction


Right, integral exponents aren't the interesting (useful) case here.


T

-- 
Valentine's Day: an occasion for florists to reach into the wallets of nominal
lovers in dire need of being reminded to profess their hypothetical love for
their long-forgotten.
Jan 06 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/6/2015 10:07 AM, H. S. Teoh via Digitalmars-d wrote:

 Implementing union painting in CTFE would singlehandedly solve (almost?)
 all of std.math CTFE issues, AFAICT.


I thought it did allow painting of the form *(cast(T*)&t).
Jan 06 2015
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Jan 06, 2015 at 10:44:38AM -0800, Walter Bright via Digitalmars-d wrote:

 On 1/6/2015 10:07 AM, H. S. Teoh via Digitalmars-d wrote:

Implementing union painting in CTFE would singlehandedly solve
(almost?) all of std.math CTFE issues, AFAICT.


 
 I thought it did allow painting of the form *(cast(T*)&t).


Was that a recent addition? I don't remember that working last year.

In any case, the current std.math code tries to achieve repainting via
unions, which currently doesn't work in CTFE:

	ulong ctfeFunc(double d) {
		union U {
			double f;
			ulong  ul;
		}
		U u;
		u.f = d;
		return u.ul;	// <--- CTFE error
	}
	enum x = ctfeFunc(3.141592);


Maybe I remembered wrong, but the original std.math code relied on
*(cast(T*)&t) to work, but was rewritten to use union repainting, IIRC
because union painting is considered more likely to be implemented in
CTFE (? -- my guess; I could be wrong).

In any case, it's great news that repainting is now supported in CTFE.
Hopefully this means more of std.math will be usable at compile-time
soon!


T

-- 
"The whole problem with the world is that fools and fanatics are always so
certain of themselves, but wiser people so full of doubts." -- Bertrand
Russell. "How come he didn't put 'I think' at the end of it?" -- Anonymous
Jan 06 2015
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Walter Bright"  wrote in message news:m8haem$29hc$1 digitalmars.com... 


 I thought it did allow painting of the form *(cast(T*)&t).


Only for float and double, not real.
Jan 06 2015
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Jan 07, 2015 at 04:52:25PM +1100, Daniel Murphy via Digitalmars-d wrote:

 "Walter Bright"  wrote in message news:m8haem$29hc$1 digitalmars.com...
 

I thought it did allow painting of the form *(cast(T*)&t).


 
 Only for float and double, not real.


Ahhh now I remember what the problem was... there is no 80-bit integer
type, so using union painting is the only way to work with reals in
CTFE.

Of course, this *could* be construed to be a nail in the real coffin,
seeing that real is purportedly slower on modern hardware due to x87
being gradually phased out...


T

-- 
Trying to define yourself is like trying to bite your own teeth. -- Alan Watts
Jan 06 2015
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"H. S. Teoh via Digitalmars-d"  wrote in message 
news:mailman.4232.1420610973.9932.digitalmars-d puremagic.com...


 Ahhh now I remember what the problem was... there is no 80-bit integer
 type, so using union painting is the only way to work with reals in
 CTFE.


I would rather we added intrinsics instead of using non-portable 
unions/casts.
Jan 06 2015
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Jan 07, 2015 at 05:33:47PM +1100, Daniel Murphy via Digitalmars-d wrote:

 "H. S. Teoh via Digitalmars-d"  wrote in message
 news:mailman.4232.1420610973.9932.digitalmars-d puremagic.com...
 

Ahhh now I remember what the problem was... there is no 80-bit
integer type, so using union painting is the only way to work with
reals in CTFE.


 
 I would rather we added intrinsics instead of using non-portable
 unions/casts.


If you can convince Walter, the more power to you!


T

-- 
Your inconsistency is the only consistent thing about you! -- KD
Jan 06 2015
prev sibling next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 7 January 2015 at 15:52, Daniel Murphy via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 "Walter Bright"  wrote in message news:m8haem$29hc$1 digitalmars.com...

 I thought it did allow painting of the form *(cast(T*)&t).



 Only for float and double, not real.


Wait up... aren't those function's heavily overloaded? I'm calling
with doubles, why would it call the real version?
Jan 06 2015
prev sibling next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 7 January 2015 at 16:07, H. S. Teoh via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Wed, Jan 07, 2015 at 04:52:25PM +1100, Daniel Murphy via Digitalmars-d
wrote:

 "Walter Bright"  wrote in message news:m8haem$29hc$1 digitalmars.com...


I thought it did allow painting of the form *(cast(T*)&t).


 Only for float and double, not real.


 Ahhh now I remember what the problem was... there is no 80-bit integer
 type, so using union painting is the only way to work with reals in
 CTFE.

 Of course, this *could* be construed to be a nail in the real coffin,
 seeing that real is purportedly slower on modern hardware due to x87
 being gradually phased out...


At very least, I would *really* like a compiler flag to disable real,
or alias real=double to match other architectures.
I have never had a use for real, it can only lead to problems for me,
especially portability problems.
Jan 06 2015
prev sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Jan 07, 2015 at 04:13:37PM +1000, Manu via Digitalmars-d wrote:

 On 7 January 2015 at 15:52, Daniel Murphy via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 "Walter Bright"  wrote in message news:m8haem$29hc$1 digitalmars.com...

 I thought it did allow painting of the form *(cast(T*)&t).



 Only for float and double, not real.


 
 Wait up... aren't those function's heavily overloaded? I'm calling
 with doubles, why would it call the real version?


It isn't, it's probably failing because even the non-real version uses
union painting to manipulate the bits, which CTFE currently doesn't
support.


T

-- 
Кто везде - тот нигде.
Jan 06 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
For inspiration:

http://golang.org/pkg/image/color/
Jan 06 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 7 January 2015 at 09:22, via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 For inspiration:

 http://golang.org/pkg/image/color/


Umm, is there something about this that you like? This looks... really terrible.
Jan 06 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 7 January 2015 at 00:30:20 UTC, Manu via 
Digitalmars-d wrote:

 On 7 January 2015 at 09:22, via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 For inspiration:

 http://golang.org/pkg/image/color/


 Umm, is there something about this that you like? This looks... 
 really terrible.


Not particularly like, but it is the colour module for a 
comparable language. It reflects what they needed to implement 
other modules for image file formats. JPEG uses  YCbCr:

http://www.w3.org/Graphics/JPEG/jfif3.pdf

I think it might be a good idea to do a survey of what other 
libraries provide and figure out why the provide it. That should 
give good "coverage".
Jan 07 2015
prev sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 7 January 2015 at 00:28, Manu <turkeyman gmail.com> wrote:

 On 6 January 2015 at 19:31, via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Tuesday, 6 January 2015 at 09:19:46 UTC, John Colvin wrote:

 What's wrong with old-fashioned `Fast` postfixes on entry points where a
 faster but less precise method is available? Or template arguments like
 std.algorithm.SortStrategy?



 If this is for phobos it should follow a common model. But since a fast
 implementation might involve an object which builds a table before
 processing....

 Another problem is that "precise" is a very loose term if the conversion is
 for display or for composition in a shader. What you want depends on the
 kind of post processing that happens after this and how it affects the
 nonlinearities of human perception.


 I think an important facet of 'fast' image processing is in the loop
 that processes batches of pixels, rather than in the api that
 processes a single pixel.
 I've gone with accurate; that's the strategy throughout phobos.

 I can't create look-up-tables at the moment, since '^^' doesn't work
 in CTFE! >_<

 Here's a PR to see where I'm at:
 https://github.com/D-Programming-Language/phobos/pull/2845


I'd like to get some ideas from people what basic colour operations
people would like/expect to see.

I'm also pondering which operators should be supported.
Do people think it makes any sense to support unary -? They're only
really useful in cases like normal maps, and don't make sense on
unsigned+normalised colour types.
What about unary ~? Bitwise not doesn't really have any meaning in
terms of colour, but it might make sense for the operator to calculate
the negative colour... although that kinda feels like operator abuse
to me.

What should happen when operators are applied to colours of differing
colour space? I kinda feel like denying operators on colour space
mismatch. It's not clear which format (left/right hand side) should be
the preferred format for the operation/result...

I'm also questioning whether implicit assignment colour conversion
should be allowed (and this kinda relates to restricting operators to
like-types. Alternatively I can limit conversion to explicit cast
operator or to!.

What about scalar operators, ie, to scale a colour? should the scalar
argument be expected to match the datatype, or support float against
all types for scaling? (slow! int->float->int conversion for a basic
mul!)

What details have I missed?
Jan 06 2015
prev sibling next sibling parent Xavier Bigand <flamaros.xavier gmail.com> writes:
Le 01/01/2015 07:38, Manu via Digitalmars-d a écrit :

 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.

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

 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?


I will enjoy to see a colour/image module in phobos a day.
There is some filters very usefull that are almost unknow like the 
per-multiplied alpha bleeding need to be democratized to improve GUI 
rendering quality.
There is so much issues on images data when rendering on GPU that have 
common fix make me think phobos is a great place for such modules.

Some explainations :
https://www.youtube.com/watch?v=dU9AXzCabiM
Jan 04 2015
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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.


Indeed, I stop you right there: I did one as well in the past, 
but definitively not high quality enough to be interesting for 
3rd party.


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


Yes.
Jan 05 2015
parent reply Xavier Bigand <flamaros.xavier gmail.com> writes:
I think it can be interesting to provide some string formats can be 
directly converted into color structures.

For example :
  - plain color names : "red", "blue", "light gray",...
  - hexadecimal : "#FF3CBB", "#FF3CBBAA" (same with alpha)
  - decimal : "255, 158, 200", "255, 158, 200, 170"
...

I think to that cause I saw many times tools using pretty close syntax 
for color definitions but with boring variations (generally for the 
alpha position).
Jan 07 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 7 January 2015 at 20:57:51 UTC, Xavier Bigand wrote:

 I think it can be interesting to provide some string formats 
 can be directly converted into color structures.

 For example :
  - plain color names : "red", "blue", "light gray",...
  - hexadecimal : "#FF3CBB", "#FF3CBBAA" (same with alpha)
  - decimal : "255, 158, 200", "255, 158, 200, 170"
 ...

 I think to that cause I saw many times tools using pretty close 
 syntax for color definitions but with boring variations 
 (generally for the alpha position).


It is defined in a w3c standard and refined in a draft, but 
probably does not belong in the colour module, but a media-file 
parser module?

However, the at least the following colour spaces are mentioned 
as supported in w3c documents:

L*ab, L*CHab, HSL, HWB

http://www.w3.org/TR/SVGColorPrimer12/

http://dev.w3.org/csswg/css-color/
Jan 07 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
Ah yeah, supporting w3c standards is probably a sensible move.
On 08/01/2015 9:55 am, "via Digitalmars-d" <digitalmars-d puremagic.com>
wrote:


 On Wednesday, 7 January 2015 at 20:57:51 UTC, Xavier Bigand wrote:


 I think it can be interesting to provide some string formats can be
 directly converted into color structures.

 For example :
  - plain color names : "red", "blue", "light gray",...
  - hexadecimal : "#FF3CBB", "#FF3CBBAA" (same with alpha)
  - decimal : "255, 158, 200", "255, 158, 200, 170"
 ...

 I think to that cause I saw many times tools using pretty close syntax
 for color definitions but with boring variations (generally for the alpha
 position).


 It is defined in a w3c standard and refined in a draft, but probably does
 not belong in the colour module, but a media-file parser module?

 However, the at least the following colour spaces are mentioned as
 supported in w3c documents:

 L*ab, L*CHab, HSL, HWB

 http://www.w3.org/TR/SVGColorPrimer12/

 http://dev.w3.org/csswg/css-color/
Jan 07 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 8 January 2015 at 02:56:36 UTC, Manu via 
Digitalmars-d wrote:

 L*ab, L*CHab, HSL, HWB





is related to HSV. In computer vision a variant is HSI.

http://en.wikipedia.org/wiki/HSL_and_HSV

Java has a separate colour space type with quite extensive 
support, I guess that is a good reference for what is useful:

http://docs.oracle.com/javase/7/docs/api/java/awt/color/ColorSpace.html

http://docs.oracle.com/javase/7/docs/api/java/awt/Color.html
Jan 08 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
And for completeness:

http://en.wikipedia.org/wiki/CIECAM02
Jan 08 2015
prev sibling parent "MrSmith" <mrsmith33 yandex.ru> writes:
You can take a look at what color formats does freeimage supports.
Jan 09 2015