www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Article: Functional image processing in D

reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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.
Mar 21 2014
next sibling parent reply "Andrea Fontana" <nospam example.com> writes:
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.
Mar 21 2014
parent reply "finalpatch" <fengli gmail.com> writes:
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.
Mar 23 2014
parent "ponce" <contact gam3sfrommars.fr> writes:
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 :)
Mar 24 2014
prev sibling next sibling parent reply "Rikki Cattermole" <alphaglosined gmail.com> writes:
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.
Are you planning on adding a font rasterizer and can it work at CTFE? If it does both I have some neat ideas for exporting of UML diagrams.
Mar 21 2014
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Friday, 21 March 2014 at 12:27:57 UTC, Rikki Cattermole wrote:
 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.
Are you planning on adding a font rasterizer
Parsing vector font files is a big undertaking. I'd likely use a text rendering library, such as FreeType. Hardcoding a small bitmap font for ASCII only is also a possibility.
 and can it work at CTFE?
This program almost works: string drawSmiley() { import std.range; import std.math; import ae.utils.graphics.draw; import ae.utils.graphics.image; auto smiley = Image!char(20, 20); smiley.fill(' '); smiley.fillCircle(10, 10, 10, '#'); smiley.fillCircle( 6, 6, 2, ' '); smiley.fillCircle(14, 6, 2, ' '); smiley.fillSector(10, 10, 6, 8, 0, PI, ' '); return smiley.h.iota.map!(y => smiley.scanline(y)).join("\n").idup; } pragma(msg, drawSmiley); "almost" because fillSector calls atan2, which doesn't work in CTFE. :( (And yeah, I totally did just declare an image with a colorspace of "char".)
Mar 21 2014
parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Friday, 21 March 2014 at 13:54:25 UTC, Vladimir Panteleev 
wrote:
 On Friday, 21 March 2014 at 12:27:57 UTC, Rikki Cattermole 
 wrote:
 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.
Are you planning on adding a font rasterizer
Parsing vector font files is a big undertaking. I'd likely use a text rendering library, such as FreeType. Hardcoding a small bitmap font for ASCII only is also a possibility.
Yeah it is quite a big one. But it may be well worth it to have it generate code at CTFE per font. Would be more efficient probably.
 and can it work at CTFE?
This program almost works: string drawSmiley() { import std.range; import std.math; import ae.utils.graphics.draw; import ae.utils.graphics.image; auto smiley = Image!char(20, 20); smiley.fill(' '); smiley.fillCircle(10, 10, 10, '#'); smiley.fillCircle( 6, 6, 2, ' '); smiley.fillCircle(14, 6, 2, ' '); smiley.fillSector(10, 10, 6, 8, 0, PI, ' '); return smiley.h.iota.map!(y => smiley.scanline(y)).join("\n").idup; } pragma(msg, drawSmiley); "almost" because fillSector calls atan2, which doesn't work in CTFE. :( (And yeah, I totally did just declare an image with a
Yeah I've noticed that some of phobos wasn't really designed with CTFE in mind *grumbles*. Maybe one day I'll look into getting that sorted out.
 colorspace of "char".)
Mar 21 2014
prev sibling next sibling parent "Atila Neves" <atila.neves gmail.com> writes:
Wow, great stuff here. If anybody else asks me "What is D good
for?" again I'll point them to this.

Atila

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.
Mar 21 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Vladimir Panteleev:

 http://blog.thecybershadow.net/2014/03/21/functional-image-processing-in-d/
It looks nice. I suggest to not pack too much the code of the examples, so I suggest to put spaces around operators, etc. It can be useful to add some benchmarks to compare its performance to equivalent regular foreach-based processing code in C/D. Bye, bearophile
Mar 21 2014
prev sibling next sibling parent "ponce" <contact gam3sfrommars.fr> writes:
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.
This is great work and much needed.
Mar 21 2014
prev sibling next sibling parent "Meta" <jared771 gmail.com> writes:
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.
That's awesome. When I see examples of some of the amazing stuff you can do with D, I wonder if D is the new Lisp. Hugely under-appreciated and immensely powerful. Now if we can just correct the former...
Mar 21 2014
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/21/14, 4:04 AM, 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.
Great piece. Vote up!! http://www.reddit.com/r/programming/comments/2101ti/functional_image_processing_in_d/ https://news.ycombinator.com/newest (find the article on the page then vote) https://www.facebook.com/dlang.org/posts/10202167415040354?stream_ref=10 https://twitter.com/D_Programming/status/447030249914519552 Andrei
Mar 21 2014
parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 http://www.reddit.com/r/programming/comments/2101ti/functional_image_processing_in_d/
But I have suggested some improvements of the article :-( Bye, bearophile
Mar 21 2014
prev sibling next sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
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.
That's really cool. I have some notes though: * All the function templates separate the template declaration from the function declaration, when they can just use the function template syntax. * Any type is accepted for the colour type, even though certain basic assumptions are made, such as the colour type being assignable to itself. * Image.w/h/pixels should probably be read-only properties in the public interface. * Any particular reason that coordinate integers are signed? `isView` seems to prefer `size_t`. * `Warp` should probably have a `if (isView!V)` constraint. * `warp` exclusively uses string expression arguments... * I'd recommend sticking to structs (often with AliasThis) over mixins for as far as it goes, as it's much more structured, thus easier to read and reason with. * The most common style for template parameter names (Phobos uses it, too) is just `Color`, not `COLOR`. * I know "w" and "h" are common abbreviations used in C, but they seem unnecessary in D - detrimental rather - if your code examples are anything to go by. It's always nice to know examples of high performance range-based code. I noticed that the `View` concept does not have the concept of stride or access to pixels using a single absolute coordinate; maybe if that was the case, the `blitTo` algorithm could be optimized to its conclusion, instead of copying scanlines one by one.
Mar 21 2014
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Friday, 21 March 2014 at 16:21:18 UTC, Jakob Ovrum wrote:
 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.
That's really cool. I have some notes though: * All the function templates separate the template declaration from the function declaration, when they can just use the function template syntax.
Where this is done, it is on purpose. For example, the "invert" declaration as it appears in the article wouldn't be possible with the shorthand function template syntax.
  * Any particular reason that coordinate integers are signed?
Yes. I've tried using unsigned coordinates in the past. It was awful. My conclusion is that if you ever need to subtract values, you should use signed types.
 `isView` seems to prefer `size_t`.
int implicitly casts to size_t but not the other way around.
  * `warp` exclusively uses string expression arguments...
Yeah. A lambda would need to receive x, y, w and h, and we don't have naryFun in Phobos. (It's there but commented out for some reason.) To a small extent, I made some compromises for the first iteration for the sake of code looking good for the article, and maybe with the help of feedback improve on that. For example, a problem I've struggled with is avoiding having two overloads for almost every function in image.d. I've tried multiple approaches: default arguments (in the form of *new Image!COLOR), templates, string mixins, UDAs, pointers, but they all were rather ugly or impractical. Some related compiler issues are 8074, 12386, 12425 and 12426 - fixing those might make some of those approaches more feasible.
  * I'd recommend sticking to structs (often with AliasThis) 
 over mixins for as far as it goes, as it's much more 
 structured, thus easier to read and reason with.
That doesn't work if you need two-way communication. Although you can pass outer methods as aliases to the inner struct, but then you have to use crazy tricks to make methods of the inner struct static in respect to the inner struct but bound to the outer one via the alias. I've played with this quite a bit for ae.utils.serialization, but I don't think it fits here. Unless I'm missing something?
 It's always nice to know examples of high performance 
 range-based code. I noticed that the `View` concept does not 
 have the concept of stride or access to pixels using a single 
 absolute coordinate; maybe if that was the case, the `blitTo` 
 algorithm could be optimized to its conclusion, instead of 
 copying scanlines one by one.
That's what my previous design used. But ultimately, unless you're dealing with very narrow images, I don't think there will be a noticeable difference in performance. This design is more flexible, though (e.g. vjoiner can serve scanlines from different sources). Thanks for the feedback.
Mar 21 2014
parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Friday, 21 March 2014 at 17:03:17 UTC, Vladimir Panteleev 
wrote:
 Where this is done, it is on purpose. For example, the "invert" 
 declaration as it appears in the article wouldn't be possible 
 with the shorthand function template syntax.
Right, I only skimmed over the various aliases. It looks like only `parallel` does not use such an alias in the article, but as a higher order algorithm it's perfectly justified to use the separated style, especially when all the other higher order algorithms do it.
 Yes. I've tried using unsigned coordinates in the past. It was 
 awful.

 My conclusion is that if you ever need to subtract values, you 
 should use signed types.
What happens if negative values sneak into the code? Sounds dangerous.
 Yeah. A lambda would need to receive x, y, w and h, and we 
 don't have naryFun in Phobos. (It's there but commented out for 
 some reason.)

 To a small extent, I made some compromises for the first 
 iteration for the sake of code looking good for the article, 
 and maybe with the help of feedback improve on that.
Bleh, I hope we can figure out some notion of lambda equality soon; string lambdas are terrible in so many ways.
 For example, a problem I've struggled with is avoiding having 
 two overloads for almost every function in image.d. I've tried 
 multiple approaches: default arguments (in the form of *new 
 Image!COLOR), templates, string mixins, UDAs, pointers, but 
 they all were rather ugly or impractical. Some related compiler 
 issues are 8074, 12386, 12425 and 12426 - fixing those might 
 make some of those approaches more feasible.
Referring to the overload sets with the `target` parameter? (Looking at the source I also noticed some `isInputRange` checks are missing; `ElementType` only checks for a `front` property.)
 That doesn't work if you need two-way communication. Although 
 you can pass outer methods as aliases to the inner struct, but 
 then you have to use crazy tricks to make methods of the inner 
 struct static in respect to the inner struct but bound to the 
 outer one via the alias. I've played with this quite a bit for 
 ae.utils.serialization, but I don't think it fits here. Unless 
 I'm missing something?
Aye, to be a sane hierarchy it would need to be redesigned so there are no circular dependencies, which does look rather non-trivial.
 That's what my previous design used. But ultimately, unless 
 you're dealing with very narrow images, I don't think there 
 will be a noticeable difference in performance. This design is 
 more flexible, though (e.g. vjoiner can serve scanlines from 
 different sources).
Maybe parallelized blitting makes sense, though it would really require a use case where blit speed is a bottleneck to matter in the first place.
Mar 21 2014
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Friday, 21 March 2014 at 17:24:02 UTC, Jakob Ovrum wrote:
 What happens if negative values sneak into the code? Sounds 
 dangerous.
Well, working with unsigned values correctly complicates the code by a good deal, for one. For example, if you want to draw a circle at (x,y) with radius r, then the first column of the bounding box is max(x-r,0). If you use unsigned coordinates, you have to write x-min(r,x) instead, which is a lot less intuitive. Not to mention, that it makes sense to draw a circle with negative center coordinates (you'll only see the fragment with non-negative coordinates). There's also tricky bits like if you ever need to subtract a value from another, divide the result, then add something back. With a signed type you can get the expected positive number, even if the number being divided was negative. With an unsigned type, the subtraction can cause an underflow, with the (unsigned) division interpreting the result with a very large positive number instead of a small negative one.
 For example, a problem I've struggled with is avoiding having 
 two overloads for almost every function in image.d. I've tried 
 multiple approaches: default arguments (in the form of *new 
 Image!COLOR), templates, string mixins, UDAs, pointers, but 
 they all were rather ugly or impractical. Some related 
 compiler issues are 8074, 12386, 12425 and 12426 - fixing 
 those might make some of those approaches more feasible.
Referring to the overload sets with the `target` parameter?
Yes.
 (Looking at the source I also noticed some `isInputRange` 
 checks are missing; `ElementType` only checks for a `front` 
 property.)
Thanks.
 That's what my previous design used. But ultimately, unless 
 you're dealing with very narrow images, I don't think there 
 will be a noticeable difference in performance. This design is 
 more flexible, though (e.g. vjoiner can serve scanlines from 
 different sources).
Maybe parallelized blitting makes sense, though it would really require a use case where blit speed is a bottleneck to matter in the first place.
I agree, I think in most cases it makes sense to parallelize on a higher level. Searching the web for "parallel memcpy" seems to confirm my suspicion that it's not practical, at least not for conventional CPUs.
Mar 21 2014
prev sibling next sibling parent Justin Whear <justin economicmodeling.com> writes:
On Fri, 21 Mar 2014 11:04:57 +0000, 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.
Good writeup. Excellent job linking to the Phobos docs and other articles. I can see people clicking through to "Voldemort Types", etc., making your article a gateway to the world of interesting things that D has to offer.
Mar 21 2014
prev sibling next sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
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.
One more remarks: Have you considered "infinite" View which, much like infinite InputRanges would lack lacking the w and h property? It would allow: - infinite procedural() - support different border-modes when sampling outside of the allowed rectangle (eg. mirror, repeat, clamp_to_edge like OpenGL does with textures). This could be done with a function taking a View and returning an infinite View from it. - probably other uses I don't think of
Mar 21 2014
next sibling parent "ponce" <contact gam3sfrommars.fr> writes:
On Friday, 21 March 2014 at 18:40:10 UTC, ponce wrote:
 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.
One more remarks: Have you considered "infinite" View which, much like infinite InputRanges would lack lacking the w and h property? It would allow: - infinite procedural() - support different border-modes when sampling outside of the allowed rectangle (eg. mirror, repeat, clamp_to_edge like OpenGL does with textures). This could be done with a function taking a View and returning an infinite View from it. - probably other uses I don't think of
Erm, so much typos. Corrected. --- One more remark: Have you considered an "infinite" View which, much like infinite InputRanges would lack the w and h properties? It would allow: - infinite procedural() View - support for different border-modes when sampling outside of the allowed rectangle (eg. mirror, repeat, clamp_to_edge like OpenGL does with textures). This could be done with a function taking a View and returning an infinite View from it. - probably other uses I don't think of. ---
Mar 21 2014
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Friday, 21 March 2014 at 18:40:10 UTC, ponce wrote:
 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.
One more remarks: Have you considered "infinite" View which, much like infinite InputRanges would lack lacking the w and h property? It would allow: - infinite procedural() - support different border-modes when sampling outside of the allowed rectangle (eg. mirror, repeat, clamp_to_edge like OpenGL does with textures). This could be done with a function taking a View and returning an infinite View from it. - probably other uses I don't think of
I've thought about it. Ultimately you'll want to crop it at some point or another, so I think it makes sense if there were operations you'd want to do on an infinite view where cropping will get in the way. The library has a tiling view, which is infinite in concept but currently in effect it immediately crops the infinite view it creates. I would probably have to rename the isView template to isFiniteView, and many operations expect a finite view...
Mar 21 2014
parent reply "Phil" <Theotherphil hotmail.com> writes:
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?
Mar 22 2014
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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.
Mar 23 2014
parent "ponce" <contact gam3sfrommars.fr> writes:
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.
Mar 23 2014
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/21/2014 4:04 AM, 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.
Very, very nice.
Mar 21 2014
prev sibling next sibling parent reply Philippe Sigaud <philippe.sigaud gmail.com> writes:
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?
Mar 22 2014
next sibling parent reply "Graham Fawcett" <fawcett uwindsor.ca> writes:
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
Mar 22 2014
parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
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.
Mar 22 2014
prev sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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.
Mar 23 2014
prev sibling parent "ponce" <contact gam3sfrommars.fr> writes:
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
May 24 2014