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

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

Looks pretty good to me.

Quick question though. Do you handle endianness?
DPX might be a dead file format but it's main usage relies on 10bits packed RGB into 32 bits (last two bits are discarded or alpha) but it can be either little or big endian.

Good job on the library though!

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.

On 12 September 2016 at 18:09, 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
>
>
> Looks pretty good to me.
>
> Quick question though. Do you handle endianness?
> DPX might be a dead file format but it's main usage relies on 10bits packed
> RGB into 32 bits (last two bits are discarded or alpha) but it can be either
> little or big endian.
>
> Good job on the library though!

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.
>
> [...]

Looks great!

1. packedrgb has not enough docs to understand what it is.
2. colorFromString should have scope argument.

- Ilya

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

1. Maybe that the each package ddoc comment should mention that everything is always @safe nothrow @nogc...For me it wasn't directly clear:
- seen that there's opCast: Q: safe ?
- seen in the sources that opCast call a templatized function
- seen that the unittest for this function are not annotated
- then only seen that the leading "@safe nothrow @nogc:" at the beg of the package.

2. Q: is there anything to convert a color to grey scale ?

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.



1. http://dtest.thecybershadow.net/artifact/website-04a64e024cf75be39700bebd3a50d26f6c7bd163-7185c8ec7b15c9e785880cab6d512e6f/web/library-prerelease/std/experimental/color/packedrgb/buffer.html
2. https://en.wikipedia.org/wiki/CIE_1931_color_space#CIE_standard_observer

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?

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?

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.

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

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

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

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.

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.

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

-- 
Marco

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?

It's a setting some acquisition/graphic card allow.
https://wiki.videolan.org/VSG:Video:Color_washed_out/

From this page as well http://www.digitalpreservation.gov/formats/fdd/fdd000352.shtml

"Video and wide range. The ITU-R specifications support values for Y, Cb, and Cr that conform to what is sometimes called "video range," "legal range," or "studio swing" levels. Expressed in terms of 8-bit tonal range values, video range has a 16-235 levels for Y and 16-240 levels for Cr and Cb. The term video range is used to contrast with "wide range" or "super white " values from 0 to 255, sometimes used when video signals are created using computer-based graphics applications."

Am Mon, 12 Sep 2016 11:31:13 +0000
schrieb Guillaume Chatelet <chatelet.guillaume@gmail.com>:

> 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?
> 
> It's a setting some acquisition/graphic card allow. https://wiki.videolan.org/VSG:Video:Color_washed_out/
> 
>  [...]

Practically all video content is encoded with the limited
range, from VHS to HDTV, IIRC and HiFi equipment uses it as
well, only computers are not so familiar with it and when
connected to a TV over HDMI one or the other may think that
the other part thinks ... well colors are often washed out,
in effect.
On the other hand this luminance compression can apply to any
color format, so it is probably best to leave it to the user
to compress colors if the output is a video file.

-- 
Marco

On 12 September 2016 at 19:30, Basile B. 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'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
>
>
> 1. Maybe that the each package ddoc comment should mention that everything
> is always @safe nothrow @nogc...For me it wasn't directly clear:
> - seen that there's opCast: Q: safe ?
> - seen in the sources that opCast call a templatized function
> - seen that the unittest for this function are not annotated
> - then only seen that the leading "@safe nothrow @nogc:" at the beg of the
> package.

How do you think this should this look? (it's best to leave these
comments on the PR)


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