color library

ZombineDev via Digitalmars-d digitalmars-d at puremagic.com
Tue Jun 23 18:47:08 PDT 2015


On Monday, 22 June 2015 at 12:52:36 UTC, ponce wrote:
> On Monday, 22 June 2015 at 08:21:44 UTC, Mike wrote:
>> Anti-Grain Geometry is not a solid graphic library and it's 
>> not very easy to use. I consider AGG as a “tool to create 
>> other tools”. It means that there's no “Graphics” object or 
>> something like that, instead, AGG consists of a number of 
>> loosely coupled algorithms that can be used together or 
>> separately. All of them have well defined interfaces and 
>> absolute minimum of implicit or explicit dependencies."
>>
>> It's architecture is what makes it so beautiful.  You can 
>> configure your own graphics pipeline simply by passing the 
>> right template arguments.  It would be an excellent showcase 
>> for D.
>>
>> Mike
>
> Thankfully we already have it: 
> http://blog.thecybershadow.net/2014/03/21/functional-image-processing-in-d/
> Data structures separated from algorithms with lazy range-like 
> computations.
>
> It's just a matter of using it and improving on it.

Another cool library that separates images from algorithms (ala 
STL) is Boost GIL (Generic Image Library) [1]. It was developed 
internally by Adobe and then they open-sourced it and moved it to 
Boost. They used concepts quite extensively in their code 
(emulated with C++03/11 features, eww) so leveraging D's features 
to the same will be much more natural. I haven't used it, so I am 
not sure how featured it is, but key point is that the 
abstractions are really solid and generic/algorithmic (not some 
inflexible java-style OOP). Like many good designs in D it tries 
to use as much as possiple of the types system to propagate 
information about the properties of the types (like color spaces, 
iterator categories, etc) at compile-time.

I wanted to make a D image library, based on the same ideas, but 
so far I haven't had enogh time to do this.
The ae.graphics library design is quite effective (flexible and 
easy to use/apply) and is all about getting the job done. On the 
other hand Boost GIL is more about systematic abstraction of the 
domain area, i.e. more academic. I'm not sure if a more pragmatic 
or more theoretical approach is better, but even only porting GIL 
to D would be great showcase of D's modeling power.

Here's a video [2] and a design guide [3] that exaplain the 
motivation behind GIL:
[1]: http://www.boost.org/doc/libs/1_58_0/libs/gil/doc/index.html
[2]: 
http://www.boost.org/doc/libs/1_58_0/libs/gil/doc/html/gildesignguide.html
[3]: http://stlab.adobe.com/gil/presentation/index.htm (video, 
requires Flash, couldn't find one that's Flash-free)


More information about the Digitalmars-d mailing list