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?

On Monday, 6 July 2015 at 13:48:53 UTC, Rikki Cattermole wrote:
> 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
>


> Use the Cartesian coordinates system using two (X and Y) size_t integers

Why not just int? There is preciously little addressable images beyond 2^31. size_t has a variable size and is a source of build breaking.
Also, please no unsigned integers! This create all manners of bugs because of how integer promotion work.


> A major concern for D is templated code. Template bloat as it is known is when there is large amounts of templates being initiated with vast array of compile time arguments. For this very reason, template usage must be constrained to the bare minimum. Keeping in line with other D code of highly reusable code, templates will be used. Be constrained to colors (usage not definition) and constructors as much as possible.

I don't think there is so much problems with Phobos levels of meta-programming. There are also way to reduce template instantiation with type-punning.

To me an image library should be based on a static interface with optionally a wrapper to auto-generate the dynamic interface much like in std.allocator. Is it the case? Your library seem to be based around the dynamic 'interface' instead.

On Monday, 6 July 2015 at 13:48:53 UTC, Rikki Cattermole wrote:
> 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.

For ImageStorage, why provide both pixelAt/pixelStoreAt (bad naming IMO) and opIndex/opIndexAssign?

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.

>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.
Yes it's not good idea, because you need one freeImage, I need gdal image support, but all of us need any standard graphical toolkit at last for simple tasks. So if std.image will help to get it a lot of people would very thanks full.

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.

I don't see some things that immediatly come to my mind as "usefull" when i think to the image class as it's been done elsewhere.

- Resampling API ?

 e.g the old trick to get AA: draw on double sized image canvas and resample to halh using an interpolator.

image.loadFromFile(...);
image.resize(horzRatio, vertRatio, Resampler.linear);
image.saveToFile(...);

- Canvas API ?

myImage.canvas.pen.color = RGBA!ubyte(...);
myImage.canvas.fillRect(...);
etc.

needed to programmatically generate an image.

On Mon, 06 Jul 2015 20:16:30 +0000, Baz 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.
> 
> I don't see some things that immediatly come to my mind as "usefull" when i think to the image class as it's been done elsewhere.
> 
> - Resampling API ?
> 
>   e.g the old trick to get AA: draw on double sized image canvas
> and resample to halh using an interpolator.
> 
> image.loadFromFile(...);
> image.resize(horzRatio, vertRatio, Resampler.linear);
> image.saveToFile(...);
> 
> - Canvas API ?
> 
> myImage.canvas.pen.color = RGBA!ubyte(...);
> myImage.canvas.fillRect(...);
> etc.
> 
> needed to programmatically generate an image.

i believe this is out of scope of the library. that is exactly the things that should be build latter with image library as foundation.

On Mon, 06 Jul 2015 13:48:51 +0000, Rikki Cattermole wrote:

> Please destroy!

have no real opinion, but for me everything is looking good. i don't really care about "ideal design", only about "usable design". and that seems usable.

> Some thoughts of mine:
> - std.zlib will need to support allocators

std.zlib need to stop being crap. i.e. it should be thrown away and completely rewritten. i did that several times, including pure D inflate and compress/decompress that using byte streams. never used std.zlib as is.

On 7/07/2015 3:34 a.m., ponce wrote:
> On Monday, 6 July 2015 at 13:48:53 UTC, Rikki Cattermole wrote:
>> 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
>>
>>
>
>
>> Use the Cartesian coordinates system using two (X and Y) size_t integers
>
> Why not just int? There is preciously little addressable images beyond
> 2^31. size_t has a variable size and is a source of build breaking.
> Also, please no unsigned integers! This create all manners of bugs
> because of how integer promotion work.

I've been sold on the unsigned vs signed type issue for and only for the x and y coordinates.
Although I'm a little concerned about not using ptrdiff_t instead of a specific integral type. For the time being, I'll alias it and use that instead. This will need to be decided later on.

Offsets will still be size_t. As it would be too limiting.

>> A major concern for D is templated code. Template bloat as it is known
>> is when there is large amounts of templates being initiated with vast
>> array of compile time arguments. For this very reason, template usage
>> must be constrained to the bare minimum. Keeping in line with other D
>> code of highly reusable code, templates will be used. Be constrained
>> to colors (usage not definition) and constructors as much as possible.
>
> I don't think there is so much problems with Phobos levels of
> meta-programming. There are also way to reduce template instantiation
> with type-punning.
>
> To me an image library should be based on a static interface with
> optionally a wrapper to auto-generate the dynamic interface much like in
> std.allocator. Is it the case? Your library seem to be based around the
> dynamic 'interface' instead.

I choose structs primarily for my types because it can be optimized away and also allocated on stack instead of the heap.
If people prefer classes they can and are more than welcome to use them. There are interfaces for just this purpose identical to ranges.
Only like ranges there is no point on just relying on it.

Instead I have SwappableImage struct. Which allows with no allocation to wrap up any image storage type you wish via the constructor. I am very proud of this. http://cattermole.co.nz/phobosImage/docs/html/std_experimental_image_interfaces.html#.SwappableImage

On 7/07/2015 4:55 a.m., Meta wrote:
> On Monday, 6 July 2015 at 13:48:53 UTC, Rikki Cattermole wrote:
>> 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.
>
> For ImageStorage, why provide both pixelAt/pixelStoreAt (bad naming IMO)
> and opIndex/opIndexAssign?

So it can be used here: http://cattermole.co.nz/phobosImage/docs/html/std_experimental_image_interfaces.html#.SwappableImage

Reasons why this could have been a problem:
http://cattermole.co.nz/phobosImage/docs/html/std_experimental_image_interfaces.html#.ImageStorage.opIndex
vs
http://cattermole.co.nz/phobosImage/docs/html/std_experimental_image_interfaces.html#.ImageStorageOffset.opIndex

In other words, overloads. Operator overloads here are just syntax candy which is required for everyday use. But the functions are required so they can be used as delegate pointers in other types.

If you want another name, please suggest them! After all, I only came up with it at like 3am.