Article: Functional image processing in D

[Jakob Ovrum]

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.