On 12 September 2016 at 21:31, Guillaume Chatelet via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 12 September 2016 at 04:14:27 UTC, Manu wrote:
>>
>> I think I'm about as happy with my colour lib as I'm going to be. It really needs reviews.
>>
>> I added packed-RGB support, including weird micro-float and
>> shared-exponent formats.
>> They're important for interacting with any real-time rendering libraries.
>> There is only one texture format I'm aware of that isn't supported,
>> and that is u7e3 floats, only available on Xbox360 ;)
>>
>> Chromatic adaptation functions are in.
>> I've done a tidy/reorg pass.
>>
>> I'm not sure what else should be in the scope of this lib.
>>
>> PR: https://github.com/dlang/phobos/pull/2845
>> dub: https://code.dlang.org/packages/color
>> docs:
>> http://dtest.thecybershadow.net/artifact/website-04a64e024cf75be39700bebd3a50d26f6c7bd163-7185c8ec7b15c9e785880cab6d512e6f/web/library-prerelease/std/experimental/color.html
>>
>> - Manu
>
>
> And also, do you handle limited (16-235) to full dynamic range (0-255)
> conversions?

Actually, I spent quite some time stressing about dynamic range.
Trouble is, there's no real format spec's relating to dynamic range,
it tends to be by convention.
I'm not sure what the API would look like, so I haven't approached that problem.
It's very easy to do the transform yourself, I don't really think it
needs to be part of the type, particularly since there's no
conventional way to express it.

Note also that I didn't do any YUV formats (this case you discuss is usually related to older broadcast formats)... didn't know if they'd be particularly useful to people. At least, it's not in my initial offering.

On Monday, 12 September 2016 at 14:12:35 UTC, Manu wrote:
> On 12 September 2016 at 21:31, Guillaume Chatelet via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> [...]
>
> Actually, I spent quite some time stressing about dynamic range.
> Trouble is, there's no real format spec's relating to dynamic range,
> it tends to be by convention.
> I'm not sure what the API would look like, so I haven't approached that problem.
> It's very easy to do the transform yourself, I don't really think it
> needs to be part of the type, particularly since there's no
> conventional way to express it.
>
> Note also that I didn't do any YUV formats (this case you discuss is usually related to older broadcast formats)... didn't know if they'd be particularly useful to people. At least, it's not in my initial offering.

Yes I agree, as you and Marco said: I think it's best to leave it to clients of the API.

On 12 September 2016 at 21:28, Marco Leise via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Am Mon, 12 Sep 2016 14:14:27 +1000
> schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>:
>
>> I think I'm about as happy with my colour lib as I'm going to be. It really needs reviews.
>>
>> I added packed-RGB support, including weird micro-float and
>> shared-exponent formats.
>> They're important for interacting with any real-time rendering libraries.
>> There is only one texture format I'm aware of that isn't supported,
>> and that is u7e3 floats, only available on Xbox360 ;)
>>
>> Chromatic adaptation functions are in.
>> I've done a tidy/reorg pass.
>>
>> I'm not sure what else should be in the scope of this lib.
>>
>> PR: https://github.com/dlang/phobos/pull/2845
>> dub: https://code.dlang.org/packages/color
>> docs: http://dtest.thecybershadow.net/artifact/website-04a64e024cf75be39700bebd3a50d26f6c7bd163-7185c8ec7b15c9e785880cab6d512e6f/web/library-prerelease/std/experimental/color.html
>>
>> - Manu
>
> Nice work. What's u7e3? 3*10-bit-floats + 2-bit padding?

Yup.


> In the example for convert color you show that converting from a color space without alpha (XYZ) to one with alpha (RGBA) turns the pixel transparent. I believe you meant this as something to lookout for when converting colors. What's the reasoning for not setting maximum alpha as a more useful and natural default?

I flip-flopped on this multiple times.
It's not so simple.
1. Alpha doesn't necessarily mean transparently, that's just one
(extremely common) use
2. 1 is the multiplication identity, but 0 is the additive identity. I
cant find either addition or multiplication to take precedence over
eachother.
3. With those 2 points above already making me feel a bit worried
about it, I think that appearing numbers out of nowhere is just
generally bad, so I went with a=0.

If alpha defaults to 1, then a*b works as expected (object does not
become transparent by this operation).
If alpha defaults to 0, then b-a works as expected (object does not
become transparent by this operation).
With that in mind, you realise alpha will *always* require explicit
handling... so I think 0 is a better default at that stage. It may be
possible to convince me otherwise ;)


> Cool stuff there in the colorspace module, to get started with getting photos or DV/MPEG into a linear color space. Should BT.709 also have prefab conversion methods? It would seem HD video is more wide spread nowadays.

BT.709's gamma func isn't changed from 601. Rec.2020 introduced a higher precision version.


> There is a typo in "Function that converts a linear luminance
> to gamme space." (colorspace.d)

Thx. But please log comments like this on the PR so I don't lose track of them? :)


> I like how RGB color spaces are described as primaries in xyY + gamma functions.

Seems natural :)

So, I was initially planning to make that struct the RGB template
argument, but then I realised that would make the symbols gigantic
(heaps of CS data in the symbol names), so I introduced the enum...
sadly though, this means you can't define a custom colour without
introducing a new custom-colour type to do what I originally intended.
I'm upset about this either way...
I think I should leave it how it is... custom colours are probably
more rare than gigantic symbol names ;)


> It seems inconsistent that you can specify all kinds of exponents when the exponent is shared but are forced to 5 bit exponents when mixed into each component, while the mantissa can still be adjusted. Would m7e3 have worked? (With f* being the IEEE standard formats.)

I was thinking that, and mentioned as such in the comments near those lines ;)
Thing is, there are no realtime small floats with exponent != 5bits
except the unique 7e3 format on xbox 360.
I can extend this in an unbreaking way.
I might: f## =  ieee-like, s##e# = signed float, (u)##e# = unsgned float.
It's just pretty verbose is all: "rgb_11e5_11e5_10e5". I mean, it's
fine... but maybe people wouldn't find this intuitive? Many
programmers don't know what an 'exponent' or 'mantissa' is... :/


> The final package should contain a fair amount of documentation, in my opinion also on the topics of sRGB vs. linear and what "hybrid gamma" is.

Yeah, but is it really my job to teach someone about colour space?
Wikipedia can do that much better than I can... :/
I agree, but I don't really know where to draw the line, or how to organise it.

Perhaps people with strong opinions on how this should be presented can create a PR?


> What is your stance on pixel formats that are arranged in planes? I assume that e.g. YUV is handled by a single channel "sRGB luminance" + 2 signed 8-bit color planes? It may be worth adding some hints in that direction.

I haven't supported YUV, but it is as you say. Nitpick: most of those YUV sinals are probably broadcast signals, with rec.601 luminance ;) YUV is a pretty big family, I'll do it if it's requested... There are a lot of micro-permutations. It's easy to get carried away (ie; as you can see in HSx).

I don't think 'types' can really express bitplanes well. We need to
express array operations to support them.
I want to extend this to support efficient array operations, but I
don't  really know how to work this into D's ranges efficiently, and
my other topic on the matter died before anything worthwhile emerged.


> All in all good work with a scientific feel to it.

Thanks, I struggled with this balance a lot. I'm fairly happy with it now.

On 09/12/2016 12:14 AM, Manu via Digitalmars-d wrote:
> I think I'm about as happy with my colour lib as I'm going to be.
> It really needs reviews.

Upon a quick look it seems to have the right amount of "notes", as Emperor Joseph II would say. Well balanced, nothing jumping at you. Nice work. Regarding Phobos suitability: One thing I'd like to hear from the community is the applicability of this work. I know very little about colors (only the RGB was familiar from HTML etc, but then there was no YUL), but that doesn't mean much. The library is quite isolated from the rest of Phobos, e.g. a stronger case would be made if there were some std.experimental.canvas package which uses the color package. Or at least a std.experimental.terminal package or something. A good case for inclusion would motivate the presence of the library as a catalyst for many user-level abstractions. -- Andrei

On 12 September 2016 at 21:13, Guillaume Chatelet via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 12 September 2016 at 09:09:29 UTC, Manu wrote:
>>
>> I thought about it, but it added (even more) complexity, and I'm not really sure it's the MO of a color lib to worry about the endian-ness of storage.
>>
>> I could support "_le"/"_be" suffix on the PackedRGB format string, but
>> then you have to also specify the word size, ie, is the packed color
>> 32bit words (eg, 11,11,10) or 16bit words (16f,16f,16f,16f)?
>> It's only really practically applicable to PackedRGB, so I wonder why
>> just one color type should worry about it, but not all the others...
>>
>> Consider an unpacked RGB with 16bit elements... that may also suffer endian problems, but RGB is a runtime type, not a storage type, which means it doesn't have a pack/unpack process... so there's no meaningful palace to do it.
>
>
> Yep I totally understand the rationale - I've been there too :)
> I don't think it belong to Color but maybe Buffer(1) could be templated on
> endianness? Buffer is indeed the place where you deal with storage.
> If you don't want to add it to the library I think you should add a
> paragraph in the documentation explaining why it's not in there and how
> people can overcome it (copy + change endianness or use an adapter?).
>
> Also, it would be nice to have some code snippets in the documentation.
>
> Last thing, for the white points you didn't specify which CIE standard observer(2) version you used: CIE 1931 2° Standard Observer or CIE 1964 10° Standard Observer? IIRC the standard illuminant are not the same depending on the observer.

That's very true. The data is all CIE 1931 reference. I haven't seen deployed use of the updated standard... I don't know why.

On 13 September 2016 at 00:37, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 09/12/2016 12:14 AM, Manu via Digitalmars-d wrote:
>>
>> I think I'm about as happy with my colour lib as I'm going to be. It really needs reviews.
>
>
> Upon a quick look it seems to have the right amount of "notes", as Emperor Joseph II would say. Well balanced, nothing jumping at you. Nice work.

Thanks. It has taken a lot more work than I actually expected to make this not suck!

> Regarding Phobos suitability: One thing I'd like to hear from the community is the applicability of this work. I know very little about colors (only the RGB was familiar from HTML etc, but then there was no YUL), but that doesn't mean much. The library is quite isolated from the rest of Phobos, e.g. a stronger case would be made if there were some std.experimental.canvas package which uses the color package. Or at least a std.experimental.terminal package or something. A good case for inclusion would motivate the presence of the library as a catalyst for many user-level abstractions. -- Andrei

So, the main reason I wanted to push for this in phobos is because
it's an enabler.
There is no multimedia in phobos at all. I think that's a shame, and
this is a starting point. Any conceivable image based work depends on
this as foundation. If pixel format types are phobos-supplied, then D
image libraries will naturally be compatible, as opposed to naturally
incompatible since every image library will otherwise re-implement
their own colour types (and almost always incorrectly).
The thing about colours is, they're HARD to get right, but more
importantly, most programmers have no idea that it's actually a hard
problem and won't tend to go looking for a lib for a colour type (Ie,
struct { ubyte r, g, b;}... simple! *cough*). They probably will use
it if it's in phobos though for compatibility reasons.
Image processing is super easy by contrast.

One of my first port-of-calls after this work would be a graph/plot library... I'd use the hell out of that. I constantly want to output data visualisations!

It also enables seamless interaction with realtime rendering api's. Ie, if OpenGL/D3D/Vulkan bindings support phobos supplied colour types, then image decoding libraries, and other sources of image data become easy to render without any requirement for adaptation. Rendering libs and image/video data source libs are almost always separate, independent libraries. We need to maximise probability that they are compatible out of the gate.

I didn't want to touch 'images' in this work, because there are countless subjective designs to present those API's, but I don't think there's many competing designs for a colour library, so it felt it was the best and most bang-for-buck starting place overall.

Also, I think this has very high synergy with ndslice. I think ndslice +  color is the foundation for image processing, or at least image data transport.

On Monday, 12 September 2016 at 15:06:29 UTC, Manu wrote:
> So, the main reason I wanted to push for this in phobos is because it's an enabler.

Indeed. I know there's a window library that was waiting on this work to try for Phobos.

Also, worth noting that the one module I import more than any other in my libs is.... color.d. Image load/save depends on it. Windowing display depends on it. Graphing depends on one or the other, GUI depends on windowing, terminal I managed to keep independent... but it is REALLY tempting to make it depend on color too.

It is a very useful base building block, and moreover, having it in Phobos means User X's graphing lib and my image libs could conceivably be able to interchange data with ease since we both use the same underlying data structure!

On Monday, 12 September 2016 at 15:06:29 UTC, Manu wrote:
> One of my first port-of-calls after this work would be a graph/plot library... I'd use the hell out of that. I constantly want to output data visualisations!

Just for your information. ggplotd currently uses an old version of your library on the backend. I'm planning on porting it soon to the latest (dub) version.

On Monday, 12 September 2016 at 13:04:49 UTC, Manu wrote:
>
>> 2. Q: is there anything to convert a color to grey scale ?
>
> This isn't a short-answer question :) .. There are many ways depending on the job.
>
> A simple way might be:
>   L8 grey = cast(L8)RGB8(r, g, b); // L8 is luminance only, casting
> will do the right thing
>
> This is the 'normal' way, but there are better ways...
>
> A superior way if you want a top-quality result would be to use the Lab luminance value, since Lab is perceptually uniform, when you desaturate, it maintains the colors relative luminance correctly, something like:
>
>   Lab!float lab = cast(Lab!float)RGB8(r, g, b); // cast your color to Lab
>   lab.a = 0; // eliminate saturation on a axis
>   lab.b = 0; // eliminate saturation on b axis
>   // lab.L is now pure luminance
>   RGB8 c = cast(RGB8)lab; // cast it back to RGB, and your RGB will be
> greyscale, but with more perceptually correct conversion.
>
> Lots of pow's in that conversion, so it's slower.
>
> This link demonstrates some competing techniques:
> https://en.wikipedia.org/wiki/HSL_and_HSV#/media/File:Fire-breather_CIELAB_L*.jpg
> Press left/right to cycle through them.
> The first method (cast to L8) is: Rec. 601 luma Y′.  (or more
> accurately, my code above would be: sRGB luma Y')
> The second method (Lab.L) is: CIELAB L*.
>
> L* performs much better in low light.

Is there some uniform policy w.r.t. casts here? If I take one colour type and cast it to another will it always do something unambiguously right or not compile? Seems to me that a function that takes a target type would be more obvious for the user.

I think the multiple different meanings of cast are a mistake in D. We can't go back now, but I wish there was only reinterpet_cast and everything else was a function.

On Monday, 12 September 2016 at 15:06:29 UTC, Manu wrote:
> On 13 September 2016 at 00:37, Andrei Alexandrescu via
>> Regarding Phobos suitability: One thing I'd like to hear from the community is the applicability of this work. I know very little about colors (only the RGB was familiar from HTML etc, but then there was no YUL), but that doesn't mean much. The library is quite isolated from the rest of Phobos, e.g. a stronger case would be made if there were some std.experimental.canvas package which uses the color package. Or at least a std.experimental.terminal package or something. A good case for inclusion would motivate the presence of the library as a catalyst for many user-level abstractions. -- Andrei
>
> So, the main reason I wanted to push for this in phobos is because
> it's an enabler.
> There is no multimedia in phobos at all. I think that's a shame, and
> this is a starting point. Any conceivable image based work depends on
> this as foundation. If pixel format types are phobos-supplied, then D
> image libraries will naturally be compatible, as opposed to naturally
> incompatible since every image library will otherwise re-implement
> their own colour types (and almost always incorrectly).
> The thing about colours is, they're HARD to get right, but more
> importantly, most programmers have no idea that it's actually a hard
> problem and won't tend to go looking for a lib for a colour type (Ie,
> struct { ubyte r, g, b;}... simple! *cough*). They probably will use
> it if it's in phobos though for compatibility reasons.
> Image processing is super easy by contrast.
>
> One of my first port-of-calls after this work would be a graph/plot library... I'd use the hell out of that. I constantly want to output data visualisations!
>
> It also enables seamless interaction with realtime rendering api's. Ie, if OpenGL/D3D/Vulkan bindings support phobos supplied colour types, then image decoding libraries, and other sources of image data become easy to render without any requirement for adaptation. Rendering libs and image/video data source libs are almost always separate, independent libraries. We need to maximise probability that they are compatible out of the gate.
>
> I didn't want to touch 'images' in this work, because there are countless subjective designs to present those API's, but I don't think there's many competing designs for a colour library, so it felt it was the best and most bang-for-buck starting place overall.
>
> Also, I think this has very high synergy with ndslice. I think ndslice +  color is the foundation for image processing, or at least image data transport.

+1

It's simply amazing how the concept of color is well understood by everyone and yet utterly hard to understand in the details.

Color is a Universe in itself! Just have a look at Metamerism(1) (colors that look the same but aren't), Human Tetrachromacy(2) (some people - mostly women - perceive more colors than others). I'm not even scratching the surface: it connects with everything: Physics, Physiology, Art, Entertainement, Evolution(3)...

Having a high quality Color API in Phobos is a differentiator and an enabler: think Raytracer, image batch processing, scientific analysis, interactions with GUI or rendering APIs.
I think it's an important addition to Phobos - I might be biased though :-P

1. https://en.wikipedia.org/wiki/Metamerism_(color)
2. https://en.wikipedia.org/wiki/Tetrachromacy#Humans
3. https://www.youtube.com/watch?v=qrKZBh8BL_U