View mode: basic / threaded / horizontal-split · Log in · Help
June 17, 2012
Re: JPG and PNG decoder
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.
June 17, 2012
Re: JPG and PNG decoder
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.
June 17, 2012
Re: JPG and PNG decoder
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
June 17, 2012
Re: JPG and PNG decoder
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.
June 17, 2012
Re: JPG and PNG decoder
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.
June 17, 2012
Re: JPG and PNG decoder
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
June 18, 2012
Re: JPG and PNG decoder
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.
June 21, 2012
Re: JPG and PNG decoder
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.
June 21, 2012
Re: JPG and PNG decoder
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.
June 21, 2012
Re: JPG and PNG decoder
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/
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home