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.