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 :)

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!

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?).

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.

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 :)

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.

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.

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.

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

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