Hi! Is there any progress?
On 03/09/15 10:28 PM, Suliman wrote:
Hi! Is there any progress?
Indeed!
Quite a bit really.
https://github.com/rikkimax/alphaPhobos/tree/master/source/std/experimental/graphic/image
PNG should now be import/exportable. I have not ehh tested this just yet
however.
Building a test framework
On Thursday, 3 September 2015 at 10:28:50 UTC, Suliman wrote:
Hi! Is there any progress?
Update, during todays stream.
Instead of adding scew manipulation instead adding range clever
support functions (createImageFrom and assignTo).
ImageImpl image1; // input
ImageImpl[2] image2; // buffers
On 22/07/2015 4:01 a.m., ponce wrote:
On Friday, 10 July 2015 at 05:27:21 UTC, rikki cattermole wrote:
What we need is a unsigned integer type **of word size**
Sorry for being picky there.
At least in x86, machine word size aka 64-bit integers in 64-bit are
generally not faster.
- first,
On Friday, 10 July 2015 at 05:27:21 UTC, rikki cattermole wrote:
What we need is a unsigned integer type **of word size**
Sorry for being picky there.
At least in x86, machine word size aka 64-bit integers in 64-bit
are generally not faster.
- first, all operations are operating on 32-bit
On Tuesday, 21 July 2015 at 16:27:33 UTC, Rikki Cattermole wrote:
So in your view, I should ask the compiler devs of e.g. ldc/gdc
of what would be the better way to go for production code in
this instance?
Why not, this wasn't about std.experimental.image specifically. I
just wanted to point
Bumpity bump.
Updated.
Includes most of the PNG implementation for loading of images.
http://cattermole.co.nz/phobosImage/docs/html/std_experimental_image_fileformats_png.html
I've also added a little bit more to the specification document.
Next stream I'll be tackling IDAT chunk loading (not
On 13/07/2015 1:43 a.m., Gregor =?UTF-8?B?TcO8Y2tsIg==?=
gregormue...@gmx.de wrote:
On Thursday, 9 July 2015 at 15:05:12 UTC, Rikki Cattermole wrote:
On 10/07/2015 2:07 a.m., Gregor =?UTF-8?B?TcO8Y2tsIg==?=
gregormue...@gmx.de wrote:
On Thursday, 9 July 2015 at 04:09:11 UTC, Rikki Cattermole
On Thursday, 9 July 2015 at 15:05:12 UTC, Rikki Cattermole wrote:
On 10/07/2015 2:07 a.m., Gregor =?UTF-8?B?TcO8Y2tsIg==?=
gregormue...@gmx.de wrote:
On Thursday, 9 July 2015 at 04:09:11 UTC, Rikki Cattermole
wrote:
On 9/07/2015 6:07 a.m., Gregor =?UTF-8?B?TcO8Y2tsIg==?=
gregormue...@gmx.de
On Friday, 10 July 2015 at 05:27:21 UTC, rikki cattermole wrote:
What we need is a unsigned integer type of word size that can
have an out of bounds value aka negative. While also supporting
calculations that is both signed and unsigned.
So basically a unsigned integer behaving like a signed
On Friday, 10 July 2015 at 23:21:02 UTC, ketmar wrote:
On Thu, 09 Jul 2015 23:35:00 +, Vladimir Panteleev wrote:
On Tuesday, 7 July 2015 at 03:39:00 UTC, Rikki Cattermole
wrote:
I've been sold on the unsigned vs signed type issue for and
only for the x and y coordinates.
The first
On Friday, 10 July 2015 at 23:23:32 UTC, ketmar wrote:
On Fri, 10 Jul 2015 03:59:29 +, Tofu Ninja wrote:
On Friday, 10 July 2015 at 03:00:57 UTC, Rikki Cattermole
wrote:
getPixel/putPixel or a variation of such? This is the most
common name for such functions.
Fine by me.
This is
On Fri, 10 Jul 2015 03:59:29 +, Tofu Ninja wrote:
On Friday, 10 July 2015 at 03:00:57 UTC, Rikki Cattermole wrote:
getPixel/putPixel or a variation of such? This is the most common name
for such functions.
Fine by me.
This is honestly just nitpicking, but I see setPixel more than
On Thu, 09 Jul 2015 23:35:00 +, Vladimir Panteleev wrote:
On Tuesday, 7 July 2015 at 03:39:00 UTC, Rikki Cattermole wrote:
I've been sold on the unsigned vs signed type issue for and only for
the x and y coordinates.
The first version of ae.utils.graphics had unsigned coordinates. As I
On Sat, 11 Jul 2015 00:49:25 +, Meta wrote:
i'm using `setPixel` to change pixel unconditionally (think of it as
set rgb), and `putPixel` to blend pixel (think of it as do rgba
color mix).
Wouldn't that better be called blendPixel?
as Tofu said, `blendPixel` should then be
On Sat, 11 Jul 2015 01:51:41 +, Vladimir Panteleev wrote:
giving that `int` and `uint` are freely interchangeable... `uint` is
better, as it allows only one bound check in `if`, and without casts.
;-)
That's a poor reason. Optimizing x=0 x100 to an unsigned check is
such a basic
On Saturday, 11 July 2015 at 00:49:27 UTC, Meta wrote:
Wouldn't that better be called blendPixel?
Also wouldn't a blendPixel need to know the blending scheme,
alpha, premultiplied, additive, ect...
On 10/07/2015 2:07 a.m., Gregor =?UTF-8?B?TcO8Y2tsIg==?=
gregormue...@gmx.de wrote:
On Thursday, 9 July 2015 at 04:09:11 UTC, Rikki Cattermole wrote:
On 9/07/2015 6:07 a.m., Gregor =?UTF-8?B?TcO8Y2tsIg==?=
gregormue...@gmx.de wrote:
On Monday, 6 July 2015 at 13:48:53 UTC, Rikki Cattermole
On Thursday, 9 July 2015 at 04:09:11 UTC, Rikki Cattermole wrote:
On 9/07/2015 6:07 a.m., Gregor =?UTF-8?B?TcO8Y2tsIg==?=
gregormue...@gmx.de wrote:
On Monday, 6 July 2015 at 13:48:53 UTC, Rikki Cattermole wrote:
Please destroy!
You asked for it! :)
As a reference to a library that is
On Thursday, 9 July 2015 at 15:05:12 UTC, Rikki Cattermole wrote:
On 10/07/2015 2:07 a.m., Gregor =?UTF-8?B?TcO8Y2tsIg==?=
gregormue...@gmx.de wrote:
On Thursday, 9 July 2015 at 04:09:11 UTC, Rikki Cattermole
wrote:
On 9/07/2015 6:07 a.m., Gregor =?UTF-8?B?TcO8Y2tsIg==?=
gregormue...@gmx.de
I drafted a reply to this, then had time to think about it. So
new answer here.
On Thursday, 9 July 2015 at 16:10:28 UTC, Márcio Martins wrote:
On Thursday, 9 July 2015 at 15:05:12 UTC, Rikki Cattermole
wrote:
On 10/07/2015 2:07 a.m., Gregor =?UTF-8?B?TcO8Y2tsIg==?=
gregormue...@gmx.de wrote:
On Friday, 10 July 2015 at 04:56:53 UTC, rikki cattermole wrote:
On Thursday, 9 July 2015 at 23:35:02 UTC, Vladimir Panteleev
wrote:
On Tuesday, 7 July 2015 at 03:39:00 UTC, Rikki Cattermole
wrote:
I've been sold on the unsigned vs signed type issue for and
only for the x and y coordinates.
On Friday, 10 July 2015 at 04:52:54 UTC, Vladimir Panteleev wrote:
On Friday, 10 July 2015 at 04:35:51 UTC, rikki cattermole wrote:
write(output.png, image
.flipHorizontalRange
.flipVerticalRange
.rotate90Range
.copyInto(new TheImage!RGB8(2, 2))
.asPNG().toBytes);
Why the Range suffix for
On Monday, 6 July 2015 at 13:48:53 UTC, Rikki Cattermole wrote:
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.
On Friday, 10 July 2015 at 04:26:49 UTC, Vladimir Panteleev wrote:
On Monday, 6 July 2015 at 13:48:53 UTC, Rikki Cattermole wrote:
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
On Friday, 10 July 2015 at 04:35:51 UTC, rikki cattermole wrote:
write(output.png, image
.flipHorizontalRange
.flipVerticalRange
.rotate90Range
.copyInto(new TheImage!RGB8(2, 2))
.asPNG().toBytes);
Why the Range suffix for functions? Aren't most functions going
to be lazy, and thus have a
On Thursday, 9 July 2015 at 23:35:02 UTC, Vladimir Panteleev
wrote:
On Tuesday, 7 July 2015 at 03:39:00 UTC, Rikki Cattermole wrote:
I've been sold on the unsigned vs signed type issue for and
only for the x and y coordinates.
The first version of ae.utils.graphics had unsigned
coordinates.
On Thursday, 9 July 2015 at 23:44:06 UTC, Vladimir Panteleev
wrote:
On Tuesday, 7 July 2015 at 03:46:55 UTC, Rikki Cattermole wrote:
write(filename, myImage.asFreeImage().toBytes(png)); //
Um, does this line mean that code to support ALL image formats
in the library is going to end up in the
On Friday, 10 July 2015 at 03:59:32 UTC, Tofu Ninja wrote:
On Friday, 10 July 2015 at 03:00:57 UTC, Rikki Cattermole wrote:
getPixel/putPixel or a variation of such? This is the most
common name
for such functions.
Fine by me.
This is honestly just nitpicking, but I see setPixel more than
On Friday, 10 July 2015 at 05:01:57 UTC, Vladimir Panteleev wrote:
On Friday, 10 July 2015 at 04:56:53 UTC, rikki cattermole wrote:
On Thursday, 9 July 2015 at 23:35:02 UTC, Vladimir Panteleev
wrote:
On Tuesday, 7 July 2015 at 03:39:00 UTC, Rikki Cattermole
wrote:
I've been sold on the
On 10/07/2015 11:41 a.m., Vladimir Panteleev wrote:
On Tuesday, 7 July 2015 at 03:41:59 UTC, Rikki Cattermole wrote:
On 7/07/2015 4:55 a.m., Meta wrote:
For ImageStorage, why provide both pixelAt/pixelStoreAt (bad naming IMO)
If you want another name, please suggest them! After all, I only
On Friday, 10 July 2015 at 03:00:57 UTC, Rikki Cattermole wrote:
getPixel/putPixel or a variation of such? This is the most
common name
for such functions.
Fine by me.
This is honestly just nitpicking, but I see setPixel more than
putPixel I think.
On Tuesday, 7 July 2015 at 03:39:00 UTC, Rikki Cattermole wrote:
I've been sold on the unsigned vs signed type issue for and
only for the x and y coordinates.
The first version of ae.utils.graphics had unsigned coordinates.
As I found out, this was a mistake.
A rule of thumb I discovered is
On Tuesday, 7 July 2015 at 03:46:55 UTC, Rikki Cattermole wrote:
write(filename, myImage.asFreeImage().toBytes(png)); //
Um, does this line mean that code to support ALL image formats in
the library is going to end up in the executable? Selecting which
image formats are supported by the
On Tuesday, 7 July 2015 at 03:41:59 UTC, Rikki Cattermole wrote:
On 7/07/2015 4:55 a.m., Meta wrote:
For ImageStorage, why provide both pixelAt/pixelStoreAt (bad
naming IMO)
If you want another name, please suggest them! After all, I
only came up with it at like 3am.
getPixel/putPixel or a
On Monday, 6 July 2015 at 13:48:53 UTC, Rikki Cattermole wrote:
Please destroy!
You asked for it! :)
As a reference to a library that is used to handle images on a
professional level (VFX industry), I'd encourage you to look at
the feature set and interfaces of OpenImageIO. Sure, it's a
On 9/07/2015 6:07 a.m., Gregor =?UTF-8?B?TcO8Y2tsIg==?=
gregormue...@gmx.de wrote:
On Monday, 6 July 2015 at 13:48:53 UTC, Rikki Cattermole wrote:
Please destroy!
You asked for it! :)
As a reference to a library that is used to handle images on a
professional level (VFX industry), I'd
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.
On 7 July 2015 at 12:33, ketmar via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Mon, 06 Jul 2015 13:48:51 +, 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
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
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
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
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
On Tue, 07 Jul 2015 18:54:45 +1000, Manu via Digitalmars-d wrote:
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
On Tue, 07 Jul 2015 15:54:15 +1200, Rikki Cattermole wrote:
In that case, ketmar is now in charge of writing a new std.compression
module for Phobos! Since he already knows these algos well.
i don't think that i'm ready to code for phobos. coding style can be
fixed with dfmt (yet it will
On Tue, 07 Jul 2015 15:51:13 +1200, Rikki Cattermole wrote:
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.
so
On Tue, 07 Jul 2015 12:10:07 +, ponce wrote:
Signed indices optimize better in loops because signed overflow is
undefined behaviour.
one of the reasons i dropped C. luckily, in D it's defined.
signature.asc
Description: PGP signature
On Tuesday, 7 July 2015 at 14:02:53 UTC, David Nadlinger wrote:
Only in C/C++. In D, they are defined to overflow according to
two's complement.
— David
Thanks for the correction.
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
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
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
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
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
On Mon, 06 Jul 2015 13:48:51 +, 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
On Mon, 06 Jul 2015 20:16:30 +, 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
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
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
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
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
On 7/07/2015 2:33 p.m., ketmar wrote:
On Mon, 06 Jul 2015 13:48:51 +, 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:
-
On 7/07/2015 2:28 p.m., ketmar wrote:
On Mon, 06 Jul 2015 20:16:30 +, 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
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
62 matches
Mail list logo
