colour lib needs reviewers

Mon Sep 12 07:37:22 PDT 2016

On 12 September 2016 at 21:28, Marco Leise via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> Am Mon, 12 Sep 2016 14:14:27 +1000
> schrieb Manu via Digitalmars-d <digitalmars-d at 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.