color lib

[Manu via Digitalmars-d]

On 9 October 2016 at 23:36, Ilya Yaroshenko via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Sunday, 9 October 2016 at 13:18:22 UTC, Manu wrote:
>>
>> On 9 October 2016 at 15:34, Ilya Yaroshenko via Digitalmars-d
>> <digitalmars-d at puremagic.com> wrote:
>>>
>>> On Sunday, 9 October 2016 at 05:21:32 UTC, Manu wrote:
>>>>
>>>>
>>>> On 9 October 2016 at 14:03, Nicholas Wilson via Digitalmars-d
>>>> <digitalmars-d at puremagic.com> wrote:
>>>>>
>>>>>
>>>>> [...]
>>>>
>>>>
>>>>
>>>> Well the trouble is the lambda that you might give to 'map' won't work
>>>> anymore. Operators don't work on batches, you need to use a completely
>>>> different API, and I think that's unfortunate.
>>>
>>>
>>>
>>> Could you please give an example what type of operation should be
>>> vectorized?
>>
>>
>> Let's consider a super simple blend:
>>   dest = src.rgb * src.a + dest.rgb * (1-src.alpha);
>
>
> This code do not need transposition. And can be partially vectorised using
> mir.ndslice.algorithm.

How so?

Sorry, let me write the actual work in full:

  RGBA8[] src, dest; // allocate somehow

  zip(src, dest).map!((e) {
    ubyte r = cast(ubyte)clamp(((cast(int)e[0].r * e[0].a * 0x1011) >>
20) + ((cast(int)e[1].r * (255 - e[0].a) * 0x1011) >> 20), 0, 255);
    ubyte g = cast(ubyte)clamp(((cast(int)e[0].g * e[0].a * 0x1011) >>
20) + ((cast(int)e[1].g * (255 - e[0].a) * 0x1011) >> 20), 0, 255);
    ubyte b = cast(ubyte)clamp(((cast(int)e[0].b * e[0].a * 0x1011) >>
20) + ((cast(int)e[1].b * (255 - e[0].a) * 0x1011) >> 20), 0, 255);
    return RGBA8(r, g, b, e[0].a);
  }).copy(dest);

If you can coerce the auto-vectoriser to do the right thing with that,
I'll be shocked.


> To perform full vectorization image should be regrouped in memory channels.
> For example many computer vision algorithms work better with each channel
> regrouped in memory channels.

Yes, but many (most) applications just want to call a function, and
don't want to rearrange their data. Most people aren't researchers
writing high-tech computer vision software ;)
Also, most images in realtime software are textures, which are usually
compressed in some way, and don't generally work well split into
channels; that would be multiple textures (for each plane), and
multiple samples per texel (sample for each plane).
Image processing definitely needs to work without having the working
dataset pre-arranged into planes.


> Relevant issue for this type of optmizations:
> https://github.com/libmir/mir/issues/343
>
> Please comment on this issue and provide a set of functions you would like
> to be vectorised. --Ilya

I'll take a look.