Jump to page: 1 26  
Page
Thread overview
Phobos colour module?
Jan 01, 2015
Manu
Jan 01, 2015
Rikki Cattermole
Jan 01, 2015
Jacob Carlborg
Jan 01, 2015
Manu
Jan 01, 2015
Manu
Jan 01, 2015
Peter Alexander
Jan 01, 2015
Phil
Jan 01, 2015
Manu
Jan 01, 2015
Manu
Jan 02, 2015
David Nadlinger
Jan 01, 2015
Dicebot
Jan 01, 2015
Manu
Jan 01, 2015
ponce
Jan 01, 2015
Manu
Jan 01, 2015
ponce
Jan 01, 2015
Manu
Jan 01, 2015
Brad Anderson
Jan 02, 2015
Manu
Jan 05, 2015
Adam D. Ruppe
Jan 05, 2015
Manu
Jan 06, 2015
John Colvin
Jan 06, 2015
Manu
Jan 06, 2015
H. S. Teoh
Jan 06, 2015
H. S. Teoh
Jan 06, 2015
Walter Bright
Jan 06, 2015
H. S. Teoh
Jan 07, 2015
Daniel Murphy
Jan 07, 2015
H. S. Teoh
Jan 07, 2015
Daniel Murphy
Jan 07, 2015
H. S. Teoh
Jan 07, 2015
Manu
Jan 07, 2015
Manu
Jan 07, 2015
H. S. Teoh
Jan 07, 2015
Manu
Jan 07, 2015
Manu
Jan 04, 2015
Xavier Bigand
Jan 05, 2015
deadalnix
Jan 07, 2015
Xavier Bigand
Jan 08, 2015
Manu
Jan 09, 2015
MrSmith
January 01, 2015
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?
January 01, 2015
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.

January 01, 2015
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
January 01, 2015
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
January 01, 2015
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?
January 01, 2015
>
> 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.
January 01, 2015
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?
January 01, 2015
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.
January 01, 2015
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?
January 01, 2015
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.
« First   ‹ Prev
1 2 3 4 5 6