daffodil, a D image processing library

[Relja Ljubobratovic via Digitalmars-d-announce]

On Friday, 1 July 2016 at 14:30:17 UTC, Benjamin Schaaf wrote:
> The problem with not knowing bit depth at compile time, is that 
> you're now forced to store the image internally as plain bytes. 
> So if you wanted to add two colors, you end up with ubyte[4] + 
> ubyte[4] instead of int + int. At some point you're going to 
> have to use a proper numerical representation (ie. long), or be 
> faced with slow calculations (ie. bigint).
>
> Other libraries (eg. ImageMagick) get around this by just using 
> longs as the internal representation. Daffodil allows you to 
> control this. So if you know you will never use more than 4 
> bytes per color, you don't have to pay for anything more. If 
> you don't know, you can just use 8 and essentially have the 
> same behaviour as ImageMagick.

Yes, I'm aware of that problem. But if you store the type 
information in the image (as enum field), later on you can do the 
casting to correct types and perform arithmetics the right way. 
This is how opencv's cv::Mat works under the hood, also I believe 
numpy.ndarray's c implementation performs the same way.

Don't get me wrong, I'm not saying your way is not correct. :) 
Just explaining my viewpoint. I believe your way is a lot easier 
- if you could show that it works well in production environment, 
I'd be glad to adopt it!

Cheers,
Relja