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 nave 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
C#'s and Java's colour struct provides what they call HSB which 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