On 04/09/2016 5:44 AM, Marco Leise wrote:
> Am Sat, 3 Sep 2016 16:01:26 +1200
> schrieb rikki cattermole <rikki@cattermole.co.nz>:
>> Something[0] along this line perhaps?
>>
>> Overview of the choices and scope along with reasoning.
>>
>> [0]
>> https://github.com/rikkimax/alphaPhobos/blob/master/source/std/experimental/graphic/image/specification.dd
>
> I have not found text about color spaces there, but it is an
> interesting collection of API design rationales. "If it
> mutates it may throw. If it doesn't mutate it shouldnt." I
> never thought about it that way.

I was using my image specification as an example for something Manu could do for color (I use Manu's color implementation as my image library is a "test" of it).

On 4 September 2016 at 03:44, Marco Leise via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Am Sat, 3 Sep 2016 16:01:26 +1200
> schrieb rikki cattermole <rikki@cattermole.co.nz>:
>
>> On 03/09/2016 12:17 PM, Manu via Digitalmars-d wrote: ...snip...
>>
>> > 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...? :/
>
> :D Just a short paragraph. "Note: The common sRGB color
> space used in computer screens or JPEGs from digicams does not
> evenly distribute brightness along the pixel values.
> Multiplying an sRGB pixel by two, wont double its intensity!
> To perform accurate image manipulations, you are advised
> to always convert to a high precision linear color-space like
> [insert name] first.
>
> More information on the history of sRGB and the formulas used can be found here: https://www.w3.org/Graphics/Color/sRGB"

Sure, we can and should add something like that to the docs.


> If I really wanted to make you pull your hair I'd say: "Man this NormalizedInt stuff would so benefit from MMX. Imagine we don't use float but ushort as linear RGB value and then use a single PADDUSW to add two colors."

I've been stressing about this for ages actually.
I initially tried to write efficient batch-processing functions at the
same time, but I realised that I was just biting off WAY more than it
was reasonable to chew in one bite, so I deleted all that and just
presented a simple API offering as a first installment. There's enough
here to review and argue about already! :P
What's here now should be flexible and correct (necessary for std lib
acceptance). Not fast; that can come after, but it depends on a lot of
design decisions regarding batch processing api's and usage patterns.

Efficient batch processing is something that needs to come up on the
forum anyway. Algorithms like map are inefficient by design because
they operate on single elements in series.
We should be able to do:
  srgb_image.map!(c => cast(LinearRGB)c).copy(linear_image);

And it should be possible to implement that efficiently, but current design doesn't work that way.