Initial feedback for std.experimental.image

[Rikki Cattermole via Digitalmars-d]

On 7/07/2015 5:47 a.m., Tofu Ninja wrote:
> 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.

At the current design, as long as you import the implementation and then 
call the function related to it, you are good to go.

I.E.
import std.experimental.freeimage;
auto myImage = ...;
write("filename", myImage.asFreeImage().toBytes("png")); // ubyte[]

Or atleast that is the idea of it. Although it definitely would not be 
done in Phobos. The whole point is to give a common interface for the D 
community and to enable swapping these images around. Manipulating them 
as needed.