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.
