On 13 September 2016 at 01:30, John Colvin via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> 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?

I think, yes?
So, the logic here is, if you cast, and then cast back, you will have
the same thing barring loss of precision.
Casts in this lib just change format (+precision), they don't change
value at all. I feel it's compatible with casting an int to a float...
it's the same sort of conversion.


> Seems to me that a function that takes a target type would be more obvious for the user.

Really? I like the cast this way. There is an explicit function in package.d though...

On Monday, 12 September 2016 at 14:12:35 UTC, Manu wrote:
> 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.

As someone who had to write lots of code involving such video color spaces, I'd say to don't bother.
- Video engineers will write their own highly-optimized version anyway,
- Dynamic range is indeed very often 16-235 / 16-240 but often with no meta-date allowing to know if this is the case,
- you often don't want clamping on each intermediate results

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.
>
>
> - Manu

My thoughts:
- I've wanted a function like colorFromString many times. It's especially nice with the added #RGBA and #RRGGBBAA syntax that eg. SVG lacks.
- The knowledge encoded in this library is great in itself.
- This could form the basis of the next-gen DbI image library so it is much needed.
=> I would certainly vote for inclusion.

On Monday, 12 September 2016 at 19:55:57 UTC, Guillaume Piolat wrote:
> - I've wanted a function like colorFromString many times. It's especially nice with the added #RGBA and #RRGGBBAA syntax that eg. SVG lacks.

What happens when the string is invalid? Does it throw an error?

On Monday, 12 September 2016 at 19:59:58 UTC, Edwin van Leeuwen wrote:
> On Monday, 12 September 2016 at 19:55:57 UTC, Guillaume Piolat wrote:
>> - I've wanted a function like colorFromString many times. It's especially nice with the added #RGBA and #RRGGBBAA syntax that eg. SVG lacks.
>
> What happens when the string is invalid? Does it throw an error?

It throws an Exception, like it should.

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.
>
> - Manu

Hi. I'm just a random forum lurker, but here's my feedback.

It needs more docs/examples for the basic usage cases (i.e. how to skip docs and start working).

Now at first glance it looks like working with RGBA (most common case (with srgb)) is complicated and while reading the docs I kind of felt like I'd just write my own.

Few basic things I'd be interested in (examples):
1. How to pack/unpack color into uint/rgba channels. Also can I swizzle channels directly? How would I extract a single channel from color?
2. Can I just cast an array of bytes into a RGBA array and operate on that?
3. How to scale color channels e.g. 5 bits to 8 bits and vice versa. How to convert color formats? Can I combine scale/conversion with single channel or channel swizzling?
4. Which way are RGBA format names defined ("byte array order" r is first byte or "uint order" r is in high bits)?
5. Is it the same for packed rgba formats?
I'm not sure if packedrgb is a necessary distinction. Aren't they all kind of packed (small structs)? There's no guarantee that 1 byte is not just a part of a bigger field.

Btw. Your RGBA8 example is a bit weird:
static assert(RGBA8("0x908000FF") == RGBA8(0x80,0x00,0xFF,0x90));
I'd assume RGBA8(r,g,b,a) would be either "uint order" r(0x90), g(0x80), b(0x00), a(0xFF) or "byte array order" (le) r(0xFF), g(0x00), b(0x80), a(0x90)

6. Perhaps you should define all the usual color formats, since everybody and their cat has their own preference for rgba channel orders.
In my experience all these 4 variants for RGBA8888 are pretty common:
RGBA8888
BGRA8888
ARGB8888
ABGR8888
and their X and 24bit variants.

For 16 bits fairly common are:
RGB565 and RGBA5551, also sometimes you see one of RGBA4444 permutations (like RGBA8 above).
Also L16 is pretty common for heightfields or other data images/textures.

I guess there are also planar formats, but I think those are more of a Image problem space.

Just as a completely random idea - How about aliases for HDR formats like HDR10 and Dolby Vision? Kind of looks like they're just combinations what you already have.

Am Tue, 13 Sep 2016 00:37:22 +1000
schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>:
> 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).

Additive color components can work like that, but the alpha
component just doesn't represent an amount of light. Don't try
too hard to make the arithmetics make sense, when the
practical use lies in 100% alpha by default. Converting every
color to full transparent is not helpful when you want to save
a 24-bit BMP as 32-bit PNG or get an RGBA color from an RGB
texture.
I don't know who declared that 100% alpha means opaque. For
what it's worth it could have been the other way around and
all the (1-a) and (a) in blending functions swapped.
And a blending function is what is needed here to give any
meaning at all to arithmetics on alpha. An additive one may be:

  color = color_dst + color_src * alpha_src
  alpha = alpha_dst

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

I fully agree with the first line, I just think that for
practical uses alpha is considered to be 100% in pixel formats
without alpha channel. Otherwise the most popular blending
functions would do nothing on RGB colors.
SDL for example also uses 100% alpha by default: "If the
specified pixel format has an alpha component it will be
returned as all 1 bits (fully opaque)."

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

Will do!

> > 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... :/

Yeah I thought that the common formats would be the IEEE ones, especially f16 and that anything less are very niche custom formats that come and go and need verbose descriptions. Well, either way works.

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

Alright, but hybrid gamma is really not something that can be googled. Or rather I end up at Toyota's Gamma Hybrid product page. :D

And as always, don't let the turkeys get you down.

-- 
Marco

On Monday, 12 September 2016 at 19:59:58 UTC, Edwin van Leeuwen wrote:
> On Monday, 12 September 2016 at 19:55:57 UTC, Guillaume Piolat wrote:
>> - I've wanted a function like colorFromString many times. It's especially nice with the added #RGBA and #RRGGBBAA syntax that eg. SVG lacks.
>
> What happens when the string is invalid? Does it throw an error?

It should be integrated with std.conv.parse and std.conv.to and follow their conventions.

On 9/11/2016 9:14 PM, 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.

I have zero expertise in color programming, and have no idea what a color library might do or what it would be used for.

I looked at the front page of the documentation. I would like to see some sort of explanation of who, what, where, why and how of a color library. Like what is a color space, etc. Maybe add some links to explanatory Wikipedia pages?

"Set of colors defined by X11, adopted by the W3C, SVG, and other popular libraries."

Would be a great place to add clickable links for the relevant X11, W3C, SVG, etc. specification pages.

It really, really needs a "References:" section, with links like:

    https://en.wikipedia.org/wiki/RGB_color_model

Are there any definitive books on the topic?

What is a BGR color type? What is a UV color type? What is a UVW color type? What is an alpha color type? What is luminance?

"This module implements HSV, HSL, HSI, HCY, HWB, HCG color types."
"angular color spaces"

Some references to what these are would be nice.

Contrast with:

    http://dlang.org/phobos/std_regex.html

where general information is given and links for more are provided (although that is weak and could be improved).

-------

My last comment is what can I do with a color library that would not require some additional library?

On 9/12/2016 8:06 AM, Manu via Digitalmars-d wrote:
> 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.

Thanks for the rationale. I'm glad to see you're planning follow-on libraries! I'd use a graph/plot library myself. Some of the rationale above should go into the documentation for the library.