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.

On 7/07/2015 6:04 a.m., Suliman wrote:
>> 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.
>

My end goal is at least by the end of next year is to have Devisualization.Window moved into Phobos. From there it is only a matter of time till somebody comes up with a GUI toolkit.
After all they have the ability to create windows + context on all three main platforms and can draw anything they like.

On 7/07/2015 2:28 p.m., ketmar wrote:
> 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.

Resizing the likes suggested are manipulation functions. Not out of scope, I most likely will not be implementing them.
My goal is only to do the simpler image manipulation functions as I would have to implement them twice each. One to work with ranges the other to whole sale modify the image to be that way and may allocate in the process.

Canvas is definitely and 100% out of scope however. It's a great idea and something we need long term. Just not something I can do right now.
Also need to add that to specification document as a follow on work and out of scope.

On 7/07/2015 2:33 p.m., ketmar wrote:
> 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.

In that case, ketmar is now in charge of writing a new std.compression module for Phobos! Since he already knows these algos well.

We can sort out who does the PR itself into Phobos. Most likely I'll have to. We can do reviews on the N.G. instead of on Github just so that he can be responsible for it ;)

And yes, I'll happily add it as a dependency.

On 7 July 2015 at 01:34, ponce via Digitalmars-d <digitalmars-d@puremagic.com> 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.

size_t doesn't quietly cast to int. Most iterators are already size_t.
Indexes shoulds be size_t for conventions sake, otherwise you case
everywhere.
Indices should be unsigned, otherwise you need to do 2 tests for
validity, rather than just one; (x >= 0 && x < length) rather than
just (x < length).

On 7 July 2015 at 12:33, ketmar via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> 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.

What's wrong with zlib? Surely it's possible to produce a d interface
for zlib that's nice?
Thing is, zlib is possibly the single most popular library in the
world, and it gets way more testing, and improvements + security fixes
from time to time. Why wouldn't you want to link to the real thing?

On Tuesday, 7 July 2015 at 08:54:57 UTC, Manu wrote:
> On 7 July 2015 at 12:33, ketmar via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> [...]
>
> What's wrong with zlib? Surely it's possible to produce a d interface
> for zlib that's nice?
> Thing is, zlib is possibly the single most popular library in the
> world, and it gets way more testing, and improvements + security fixes
> from time to time. Why wouldn't you want to link to the real thing?

D community suffers from NIH syndrome

On 7/07/2015 8:50 p.m., Manu via Digitalmars-d wrote:
> On 7 July 2015 at 01:34, ponce via Digitalmars-d
> <digitalmars-d@puremagic.com> 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.
>
> size_t doesn't quietly cast to int. Most iterators are already size_t.
> Indexes shoulds be size_t for conventions sake, otherwise you case
> everywhere.
> Indices should be unsigned, otherwise you need to do 2 tests for
> validity, rather than just one; (x >= 0 && x < length) rather than
> just (x < length).

Well you both have very valid points.
In this case, lets go with: It's already written, let's not change it just because it might solve a few bugs while potentially adding others.

On Tuesday, 7 July 2015 at 08:50:45 UTC, Manu wrote:

> Most iterators are already size_t.

.length should have been int but it's too late.
It's not because it's a "size" that it should be size_t.


> Indexes shoulds be size_t for conventions sake, otherwise you cast everywhere.

Disagree. I think it's the other way around.
And image coordinates are not especially indices.

> Indices should be unsigned, otherwise you need to do 2 tests for
> validity, rather than just one; (x >= 0 && x < length) rather than
> just (x < length).

You can force an unsigned comparison with (cast(uint)x < length).

Signed indices optimize better in loops because signed overflow is undefined behaviour.

http://stackoverflow.com/questions/18795453/why-prefer-signed-over-unsigned-in-c

On Tuesday, 7 July 2015 at 12:10:10 UTC, ponce wrote:
> Signed indices optimize better in loops because signed overflow is undefined behaviour.
>
> http://stackoverflow.com/questions/18795453/why-prefer-signed-over-unsigned-in-c

Only in C/C++. In D, they are defined to overflow according to two's complement.

 — David