Initial feedback for std.experimental.image

[Tofu Ninja via Digitalmars-d]

On Monday, 6 July 2015 at 13:48:53 UTC, Rikki Cattermole wrote:
> So as part of my testing of std.experimental.color I began 
> writing an image ala ae.graphics style.
> It's now ready for very initial feedback.
> There is not many image manipulation functions or storage 
> types. Let alone image loading/exporting. In fact there is no 
> image file format actually working at this point.
> Only the shell for a PNG one is so far written.
>
> I believe it is ready for initial feedback because I feel it is 
> moving towards "controversial" territory in its design. With 
> the file format support.
> I just need to know that I am going in the right direction as 
> of now. There is no point in continuing the image 
> reading/writing support like it is, if nobody likes it.
>
> Docs: http://cattermole.co.nz/phobosImage/docs/html/
> Source: http://cattermole.co.nz/phobosImage/
>
> If reviewing the code itself is too much of a hassel, please 
> review the specification document. 
> http://cattermole.co.nz/phobosImage/docs/html/std_experimental_image_specification.html
>
> Like ae.graphics it supports ranges for manipulating of image 
> storage types.
> However it does also use std.experimental.allocator.
>
> Please destroy!
>
>
> Some thoughts of mine:
> - std.zlib will need to support allocators
> - Can std.experimental.allocator be @nogc pleaseeeee?

For my uses, the only thing that I really care about is file 
saving and loading. Personally I would prefer if the lib depended 
on something that already works well for image loading and 
storing like freeImage. It has way more file types that have been 
proven to work than I would reasonably expect would be 
implemented if they were done in pure D. If people reject the 
idea of the std lib depending on an outside lib, then I would at 
least ask that the design be such that an outside lib could be 
easily used in conjunction with std.image.