On 3 September 2016 at 03:25, Marco Leise via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > Am Fri, 2 Sep 2016 15:58:05 +1000 > schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>: > >> I wonder, should NormalizedInt be a module beneath the color package, >> or should it be a separate module in its own right? >> I don't know of uses for that type outside packed colours, but it >> could theoretically be used for anything... > > I guess audio sample would be a perfect match for signed and > unsigned normalized integers.
Perfect! I moved out outside the colour package. Contention resolved :) >> > Surely adding sRGB(22,22,22) + sRGB(11,11,11) gives sRGB(28, 28, 28), >> > with a higher precision while performing the addition and then >> > rounding back. >> >> Umm, no. I think operations should be within their own colourspace, >> otherwise what's the point of selecting your working colourspace? >> You need to be able to do operations in gamma space too. If you want >> to do a linear operation, cast to a linear type before doing the >> operation. > > So it is not a library that unifies color spaces into working > with light intensities That's a design goal, and it's very easy to cast to a linear type to do that work. > but more of a library to perform > linear blending directly in the color-space. This is another goal. A colour implementation in the std library is a little tricky, it needs to be both correct AND efficient for the different use cases where the trade-off lines are drawn differently. The only reasonable way I can think to support this is to do operations within the typed colourspace, and let the user cast to the colourspace desired for their operations. So the meat of the lib is really about convenient colourspace conversion, and making the colourspaces easy to describe, particularly for non-experts. I'm feeling like it's getting pretty close to my intent. Naturally, image processing libs would tend to do linear conversions internally. So it shouldn't be a detail that reaches the end-user very often. Remember that when doing linear conversions of colours, you tend to also need to use float colour channels, since floats naturally express the same non-linear precision curve that the gamma curves exist to compensate for. Linear RGB8 will severely lose precision and band very badly. > That means when I add two HSV colors of the same ubyte hue > = 200, the result will have hue == 144, right ? Yes, it would necessarily be that. If it didn't behave that way, you wouldn't be able to express a lerp in HSV space. Additive colour blending in HSV doesn't really make sense. It works as expected if you're adding deltas. Ideally, hue would be expressed with a circular angle type (rather than NormalizedInt as I've used for the other channels), which is something we don't have in phobos, and I'm not motivated to write one just for this one color channel... >> > Anything requiring multiple operations on an >> > image should use a higher precision linear color space from >> > the start. >> >> Right, I think you would typically cast from the storage type to the >> working type before doing some work. But there are so many cases, and >> various levels of tradeoff between efficiency and correct-ness, the >> lib can't make presumptions. >> The way it is currently, the operations are done in the typed >> colourspace. Simple as that. If you want to do linear operations, cast >> to a linear type first. > > Ok, might be worth it for people new to color spaces to > highlight the fact that RGB is not linear and what that means > for operations like brightness or contrast change. I've seen a > hobbyist write a 3D engine and after he had deferred > rendering, flash lights & shadows, scripting and animations, > he stumbled over an article about screen gamma and why it > matters. My first attempts at image manipulation show the same > ignorance. I understand this pattern very, very well. I've worked in games my whole career ;) This is precisely why the std library needs to be batteries-included with respect to knowledge about colourspaces and conversions, but that doesn't mean every operation can do it properly behind the scenes. Colours are a fairly low-level primitive, and appear in low-level/high-frequency code. The std library offering wouldn't be very useful if it were so slow from doing linear conversions every time you do any operation. That's a lot of int<->float conversions, and pow's! I think the presence of all this colour space information as type arguments should nudge users in the right direction. They'll be all "I've never seen this parameter before..." and google it... maybe. I don't think it's the std lib doco's job to give users a lesson in colour theory...? :/