This is very cool. What are the performance implications of treating colour images as arrays of tuples rather than a flat array? For example, if I wanted to iterate through every channel of every pixel in an RGB image or modify the R channel of every pixel, could I generally expect the compiler to optimise the extra overhead away? Also, do you have any ideas on how you could vectorise code like this while still providing a nice API?

On Fri, Mar 21, 2014 at 12:04 PM, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:
> http://blog.thecybershadow.net/2014/03/21/functional-image-processing-in-d/
>
> Some highlights from a recent overhaul of the graphics package from my D library. It makes use of a number of D-specific language features, so I've tried to make the article accessible to people new to D as well.

The article is wonderful, very clear and a good introduction to many D idioms. I'd like to use your graphics package as well, but I don't see any documentation (ddoc, wiki?). Is there some somewhere?

On Saturday, 22 March 2014 at 13:35:01 UTC, Philippe Sigaud wrote:
> On Fri, Mar 21, 2014 at 12:04 PM, Vladimir Panteleev
> <vladimir@thecybershadow.net> wrote:
>> http://blog.thecybershadow.net/2014/03/21/functional-image-processing-in-d/
>>
>> Some highlights from a recent overhaul of the graphics package from my D
>> library. It makes use of a number of D-specific language features, so I've
>> tried to make the article accessible to people new to D as well.
>
> The article is wonderful, very clear and a good introduction to many D
> idioms. I'd like to use your graphics package as well, but I don't see
> any documentation (ddoc, wiki?). Is there some somewhere?

I think this is it:

https://github.com/CyberShadow/ae

Graham

On Sat, Mar 22, 2014 at 4:10 PM, Graham Fawcett <fawcett@uwindsor.ca> wrote:

> I think this is it:
>
> https://github.com/CyberShadow/ae

Hmm, there is the /demo directory, that can be useful. But I don't see any documentation per se.

On Saturday, 22 March 2014 at 13:35:01 UTC, Philippe Sigaud wrote:
> On Fri, Mar 21, 2014 at 12:04 PM, Vladimir Panteleev
> <vladimir@thecybershadow.net> wrote:
>> http://blog.thecybershadow.net/2014/03/21/functional-image-processing-in-d/
>>
>> Some highlights from a recent overhaul of the graphics package from my D
>> library. It makes use of a number of D-specific language features, so I've
>> tried to make the article accessible to people new to D as well.
>
> The article is wonderful, very clear and a good introduction to many D
> idioms. I'd like to use your graphics package as well, but I don't see
> any documentation (ddoc, wiki?). Is there some somewhere?

I don't have generated HTML documentation uploaded anywhere at the moment. However, most declarations are annotated with DDoc comments, and the unittest blocks work as examples.

On Saturday, 22 March 2014 at 11:25:05 UTC, Phil wrote:
> This is very cool. What are the performance implications of treating colour images as arrays of tuples rather than a flat array? For example, if I wanted to iterate through every channel of every pixel in an RGB image or modify the R channel of every pixel, could I generally expect the compiler to optimise the extra overhead away? Also, do you have any ideas on how you could vectorise code like this while still providing a nice API?

One might say that this approach has the innate benefit that the loop (to iterate over each channel) will be unrolled explicitly :)

However, if you need to perform operations on individual channels, it would probably be worthwhile to unpack a multi-channel image into several images with just one channel.

I'm not familiar enough with vector instruction sets of current CPUs to answer this confidently. E.g. if there exists an integer vector multiply-and-add operation, then that could be used for fast software alpha blending. That operation's restrictions would dictate the optimal memory layout of the image. E.g. if the operation requires that the bytes to multiply and add are contiguous in memory, then it follows that the image should be represented with each channel as a separate sub-image.

On Sunday, 23 March 2014 at 08:22:32 UTC, Vladimir Panteleev wrote:
> I'm not familiar enough with vector instruction sets of current CPUs to answer this confidently. E.g. if there exists an integer vector multiply-and-add operation, then that could be used for fast software alpha blending. That operation's restrictions would dictate the optimal memory layout of the image. E.g. if the operation requires that the bytes to multiply and add are contiguous in memory, then it follows that the image should be represented with each channel as a separate sub-image.

There is the PMADDWD instruction that can be used for 8-bit blending. I don't think it requires a particular layout from the implementation, blending would probably be dominated by memory accesses.

On Friday, 21 March 2014 at 11:16:31 UTC, Andrea Fontana wrote:
> Very interesting! Do you know http://www.antigrain.com/ ?
>
> It is (was?) a very efficent c++ 2d library, heavily based on templates. Something like this in D with templates and lazy ranges should be impressive.
>
>
> On Friday, 21 March 2014 at 11:04:58 UTC, Vladimir Panteleev wrote:
>> http://blog.thecybershadow.net/2014/03/21/functional-image-processing-in-d/
>>
>> Some highlights from a recent overhaul of the graphics package from my D library. It makes use of a number of D-specific language features, so I've tried to make the article accessible to people new to D as well.

I've got an AGG inspired 2D rasterizer on github.
https://github.com/finalpatch/dagger

it's not as template heavy or making extensive use of ranges as the OP's.

On Monday, 24 March 2014 at 01:36:26 UTC, finalpatch wrote:
> On Friday, 21 March 2014 at 11:16:31 UTC, Andrea Fontana wrote:
>> Very interesting! Do you know http://www.antigrain.com/ ?
>>
>> It is (was?) a very efficent c++ 2d library, heavily based on templates. Something like this in D with templates and lazy ranges should be impressive.
>>
>>
>> On Friday, 21 March 2014 at 11:04:58 UTC, Vladimir Panteleev wrote:
>>> http://blog.thecybershadow.net/2014/03/21/functional-image-processing-in-d/
>>>
>>> Some highlights from a recent overhaul of the graphics package from my D library. It makes use of a number of D-specific language features, so I've tried to make the article accessible to people new to D as well.
>
> I've got an AGG inspired 2D rasterizer on github.
> https://github.com/finalpatch/dagger
>
> it's not as template heavy or making extensive use of ranges as the OP's.

Looks very interesting. Please publish on DUB registry :)

On Friday, 21 March 2014 at 11:04:58 UTC, Vladimir Panteleev wrote:
> http://blog.thecybershadow.net/2014/03/21/functional-image-processing-in-d/
>
> Some highlights from a recent overhaul of the graphics package from my D library. It makes use of a number of D-specific language features, so I've tried to make the article accessible to people new to D as well.

The graphics package described in Vladimir's post has been separated in a stand-alone DUB package here:
https://github.com/p0nce/ae-graphics