On Sun, Jun 17, 2012 at 3:25 PM, Stewart Gordon <smjg_1998@yahoo.com> wrote:
>
> FWIW a while ago I wrote a simple experimental program that generates an image and encodes it as a PNG.  And I've just tweaked it and updated it to D2 (attached).  It supports only truecolour with 8 bits per sample, but it supports filtering, though it isn't adaptive (you just specify the filter to use when you run the program).

Nice one, works OK here! (DMD 2.059, Linux 32bits)

(DMD -property asks for '@property' after IHDR bigEndian())

You two should fuse it into one module, to give us loading/writing. That would be quite cool.

I have a simple png writer too if that's of use to you

https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff

image.d and png.d. Somewhat suboptimal to use, since I
ported some of my old C code almost directly to it, and it
still works like C.

On Sunday, 17 June 2012 at 12:15:36 UTC, bearophile wrote:
> Suggestions on the code:
> - Try to use final switches.
> - switch cases don't need (), so instead of case(foo):  write case foo:
> - Try to add const/immutable/pure/nothrow where possible.
>
> Bye,
> bearophile

Problem with final switches in this context is that images may be corrupt or badly encoded or something, which the decoder should just handle gracefully through a default I think, without crashing. The case statements though I will change, and though I have worlds of trouble with const-ness, I will endeavour to add those guarantees :)

Thanks for looking through

On Sunday, 17 June 2012 at 12:35:41 UTC, David wrote:
> Cool so I don't need to use my stb_image binding ( https://bitbucket.org/dav1d/gl-utils/src/0b97f77c14d7/stb_image ) anylonger!

I used stb_image with C++ opengl projects, and it was great. stb_truetype is another gem, I would love to write a truetype loader, but I think the payoff is not worth the effort given the freetype bindings.

On 17/06/2012 14:38, Philippe Sigaud wrote:
> On Sun, Jun 17, 2012 at 3:25 PM, Stewart Gordon <smjg_1998@yahoo.com> wrote:
>>
>> FWIW a while ago I wrote a simple experimental program that generates an
>> image and encodes it as a PNG.  And I've just tweaked it and updated it to
>> D2 (attached).  It supports only truecolour with 8 bits per sample, but it
>> supports filtering, though it isn't adaptive (you just specify the filter to
>> use when you run the program).
>
> Nice one, works OK here! (DMD 2.059, Linux 32bits)
>
> (DMD -property asks for '@property' after IHDR bigEndian())

Good catch.  It's probably time we deprecated using property syntax on non-properties.

> You two should fuse it into one module, to give us loading/writing.
> That would be quite cool.

I don't know how much of the code will need rewriting in order to support interlacing or all PNG colour types/depths.

But I also began writing a PNG library a while back - with the intention that it will be a full PNG editing library, not just encoding/decoding of the image data.  But I haven't had much time to work on it recently.  And it would help a lot if we could have the replacement for std.stream some time soon.

Stewart.

On Sunday, 17 June 2012 at 23:17:54 UTC, Stewart Gordon wrote:
>> You two should fuse it into one module, to give us loading/writing.
>> That would be quite cool.
>
> I don't know how much of the code will need rewriting in order to support interlacing or all PNG colour types/depths.
>
> But I also began writing a PNG library a while back - with the intention that it will be a full PNG editing library, not just encoding/decoding of the image data.  But I haven't had much time to work on it recently.  And it would help a lot if we could have the replacement for std.stream some time soon.
>
> Stewart.

I just pushed an update which implements a PNG encoder. It is implemented in the Image class as a write method. If you have a raw buffer, and want to encode it, you can do something like this:

ubyte[] data = some data;
Image img = new Img!(Px.R8G8B8)(width, height, data);
img.write("mypng.png");

It uses adaptive filtering, and should work with the pixel formats supported by the image class (except for the 16 bit ones I've just realised). I've only tested it on images that I have previously loaded in however.

Stewart, I used your makepng.d as a template for this, can I add you to the author list?

Also, if preferred, I can keep the master branch as a single merged module, just let me know.

Cheers,
cal

On Sunday, 17 June 2012 at 20:10:28 UTC, cal wrote:
> though I have worlds of trouble with const-ness, I will endeavour to add those guarantees :)

What I usually do, unless it's just an obvious case, is write code without concern for const-ness, then write a thorough test and step through one function/whatever at a time and apply const/inout/pure/nothrow/etc, do any apparent refactoring, and check the test.  Writing the test helps me grok as many imaginable cases as possible, and doing it incrementally avoids massive "error cascades" from the compiler.

On 18/06/2012 00:49, cal wrote:
<snip>
> ubyte[] data = some data;
> Image img = new Img!(Px.R8G8B8)(width, height, data);

Image?  Img?

> img.write("mypng.png");
>
> It uses adaptive filtering, and should work with the pixel formats supported by the image
> class (except for the 16 bit ones I've just realised). I've only tested it on images that
> I have previously loaded in however.

Does it always take in a ubyte[], or does that depend on the bit depth?

> Stewart, I used your makepng.d as a template for this, can I add you to the author list?
<snip>

By all means.

I look forward to seeing what you've come up with.

Stewart.

On Thursday, 21 June 2012 at 17:58:47 UTC, Stewart Gordon wrote:
> On 18/06/2012 00:49, cal wrote:
> <snip>
>> ubyte[] data = some data;
>> Image img = new Img!(Px.R8G8B8)(width, height, data);
>
> Image?  Img?
>
>> img.write("mypng.png");

Image is the interface, Img the templated class that does all the work. It is parameterized by the pixel format. It may not be the best strategy (or naming scheme!) but enumerating the formats and templating based on that limited the number of cases I had to think about.

> Does it always take in a ubyte[], or does that depend on the bit depth?

It currently just takes a ubyte, and doesn't do any rearranging of the array, so it will only work for 8-bit depths. If you had 4-bit greyscale tightly packed into your ubyte (two pixels per byte) then it would not be correctly interpreted, nor would 16 bit. The reason was I didn't want to have the Image class 'own' the passed-in array. If it did own it, then it would be free to unpack the smaller bit depths the way it does when decoding. I will fix this when I have time to think about it a bit more.

it's not that hard to write a baseline jpeg encoder. it's not harder than decoding.
there are many tutorials and examples online.




Am 17.06.2012, 09:55 Uhr, schrieb cal <callumenator@gmail.com>:

> On Sunday, 17 June 2012 at 07:07:35 UTC, Philippe Sigaud wrote:
>> Still, I'm interested in writing a JPEG/PNG to disk from a
>> ubyte[3][][], or whatever.
>
> Do you mean that you want to encode a ubyte array to disk as JPEG/PNG? Encoding a JPEG would be a bit of work I think, the format's kind of a monster. PNG should be easier, depending on how good you want the compression to be. If you don't care too much about compression level, you simply zlib compress the data, write it out by image row/scanline, include appropriate header and chunk info, and you're done. I'll give a simple encoder a go if you think you could use it.
>
> Cheers,
> cal
>


-- 
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/