www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - PNG libraries

reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
There's been some talk about image format libraries.  And the odd specific 
PNG library.

I've thought a bit about specific PNG libraries lately, considering such 
things as the extensibility of the format, which I'm thinking of making use 
of.

Libpng is the reference implementation of PNG.  The C-based API seems on the 
cumbersome side.  I've a recollection of hearing that libpng has an OO C++ 
interface, but if there is an official one then I can't seem to find it.  I 
have, however, found png++, which is a layer over libpng but seems to be at 
an early stage of development.

http://savannah.nongnu.org/projects/pngpp

The other one I've noticed is Lodepng, which was written in C++ but has been 
ported to D.  It supports a small handful of ancillary chunks, but still 
doesn't provide access to any chunks it doesn't understand or even preserve 
them between loading and saving.

I think D could benefit from a full-featured PNG editing library.  I can see 
a few possible approaches:

(a) Get together some bindings for libpng, and write an OO layer in D on top 
of it.  OOTB, libpng uses setjmp for error handling - we'd need to change 
this.

(b) Improve one of the libraries such as Lodepng.  I don't know to what 
extent that would work.

(c) Write a PNG library from scratch, designed from the start to support 
editing rather than merely loading and saving the image data itself.  I've 
got some design ideas already.  We could still use existing compression and 
CRC implementations.

FWIW I've written a program of just under 200 lines that generates a PNG. 
The encoding logic itself is less than 100 lines (with the help of 
std.zlib), but that's only to encode 24-bit RGB.  Obviously a PNG library of 
any sort would need to support the whole range of colour models and depths.

Thoughts?

Stewart.
Sep 11 2007
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Stewart,


 The other one I've noticed is Lodepng, which was written in C++ but
 has been ported to D.  It supports a small handful of ancillary
 chunks, but still doesn't provide access to any chunks it doesn't
 understand or even preserve them between loading and saving.
 


[...]

 
 (b) Improve one of the libraries such as Lodepng.  I don't know to
 what extent that would work.


If you'd like to take a crack at that I'll give you SVN access to scrapple 
so you can.
Sep 11 2007
parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"BCS" <ao pathlink.com> wrote in message 
news:ce0a33431dc838c9c276cf872d5c news.digitalmars.com...

 Reply to Stewart,


<snip>

 (b) Improve one of the libraries such as Lodepng.  I don't know to
 what extent that would work.


 If you'd like to take a crack at that I'll give you SVN access to scrapple 
 so you can.


That probably would be helpful....

Stewart.
Sep 15 2007
parent reply BCS <ao pathlink.com> writes:
Reply to Stewart,


 "BCS" <ao pathlink.com> wrote in message
 news:ce0a33431dc838c9c276cf872d5c news.digitalmars.com...
 

 Reply to Stewart,
 


 <snip>
 

 (b) Improve one of the libraries such as Lodepng.  I don't know to
 what extent that would work.
 


 If you'd like to take a crack at that I'll give you SVN access to
 scrapple so you can.
 


 That probably would be helpful....
 
 Stewart.
 


I'll need your dsource user name.
Sep 15 2007
parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"BCS" <ao pathlink.com> wrote in message 
news:ce0a334320b6e8c9c5f5aa912084 news.digitalmars.com...

 I'll need your dsource user name.


smjg
Sep 16 2007
parent BCS <ao pathlink.com> writes:
Reply to Stewart,

Have fun. "Beee Gooood."* <G> 


* http://i2.photobucket.com/albums/y36/kellysx4/septebay07001.jpg
Sep 16 2007
prev sibling next sibling parent Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Stewart Gordon wrote:


 There's been some talk about image format libraries.  And the odd specific
 PNG library.
 
 I've thought a bit about specific PNG libraries lately, considering such
 things as the extensibility of the format, which I'm thinking of making
 use of.
 
 Libpng is the reference implementation of PNG.  The C-based API seems on
 the
 cumbersome side.  I've a recollection of hearing that libpng has an OO C++
 interface, but if there is an official one then I can't seem to find it. 
 I have, however, found png++, which is a layer over libpng but seems to be
 at an early stage of development.
 
 http://savannah.nongnu.org/projects/pngpp
 
 The other one I've noticed is Lodepng, which was written in C++ but has
 been
 ported to D.  It supports a small handful of ancillary chunks, but still
 doesn't provide access to any chunks it doesn't understand or even
 preserve them between loading and saving.
 
 I think D could benefit from a full-featured PNG editing library.  I can
 see a few possible approaches:
 
 (a) Get together some bindings for libpng, and write an OO layer in D on
 top
 of it.  OOTB, libpng uses setjmp for error handling - we'd need to change
 this.
 
 (b) Improve one of the libraries such as Lodepng.  I don't know to what
 extent that would work.
 
 (c) Write a PNG library from scratch, designed from the start to support
 editing rather than merely loading and saving the image data itself.  I've
 got some design ideas already.  We could still use existing compression
 and CRC implementations.
 
 FWIW I've written a program of just under 200 lines that generates a PNG.
 The encoding logic itself is less than 100 lines (with the help of
 std.zlib), but that's only to encode 24-bit RGB.  Obviously a PNG library
 of any sort would need to support the whole range of colour models and
 depths.
 
 Thoughts?
 
 Stewart.


Reading this post made me upload some old code I have laying around. It's
yet another PNG decoder written in D...

Well... Really it's a few libraries. a D image decoder library with PNG, JPG
(through tinyjpeg), basic TGA and broken PCX support.
Also it is static convertions of some of derelict. Namely SDL, OpenGL and
FreeType. The OpenGL binding is not including the extensions. Yet.

Maybe it can be useful to someone so here it is :)

http://code.google.com/p/lindlibs/

(I have been wanting to try out googles project hosting, but eventually this
may be moved to dsource)
Sep 11 2007
prev sibling next sibling parent Downs <default_357-line yahoo.de> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If you need a basis to start from, the GPL'd freelink project has a
small, self-contained, feature-poor, but otoh fully written in D PNG
decoder in its SVN repo.

http://www.google.com/codesearch?hl=en&q=show:MEb5n-B0IBE:_xOOCWbOM4A:oA0k1lfnvvo
or
http://freelink.googlecode.com/svn/trunk/src/png.d

Have fun!
 --downs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG5vmMpEPJRr05fBERAmI4AKCMkKnq3er+r69nxrd+jVmbdI/e2gCdGgcT
MN61V9AykLdF2rdtJqE0iJc=
=Ez5T
-----END PGP SIGNATURE-----
Sep 11 2007
prev sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Lodepng was designed not to do everything the PNG format is capable of 
since that makes it easier to do what png is most used for: image 
loading / saving. However, the way the recent iteration is coded will 
make it easy, with a few minor changes, to implement an extensible api. 
It does have the benefit of supporting the full range of color formats 
and generally being spec compliant already.

If you are interested in making use of lodepng or extending it to an 
editor, I'm open to discussion and willing to help.
Sep 11 2007
parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Lutger" <lutger.blijdestijn gmail.com> wrote in message 
news:fc711f$ocl$1 digitalmars.com...

 Lodepng was designed not to do everything the PNG format is capable of 
 since that makes it easier to do what png is most used for: image loading 
 / saving. However, the way the recent iteration is coded will make it 
 easy, with a few minor changes, to implement an extensible api. It does 
 have the benefit of supporting the full range of color formats and 
 generally being spec compliant already.

 If you are interested in making use of lodepng or extending it to an 
 editor, I'm open to discussion and willing to help.


Now I think the question is how much can be done without making your library 
too complex for its purpose.

Preserving unknown chunks should be fairly simple to implement - we 
basically just need a data structure or two to hold them and the order of 
all chunks in the file.  (Obviously, this behaviour should be optional.) 
Given this, it would also be straightforward to allow the library user to 
add private chunks.

But to allow the user to manipulate the range of public ancillary chunks 
available, there's the added complication of chunk ordering rules to 
consider, at least if we want to protect the user against inadvertently 
creating a PNG file that's invalid because the chunks are in the wrong 
order.

On this basis, what do you reckon?

Stewart.
Sep 12 2007
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Stewart Gordon wrote:

 "Lutger" <lutger.blijdestijn gmail.com> wrote in message 
 news:fc711f$ocl$1 digitalmars.com...

 Lodepng was designed not to do everything the PNG format is capable of 
 since that makes it easier to do what png is most used for: image 
 loading / saving. However, the way the recent iteration is coded will 
 make it easy, with a few minor changes, to implement an extensible 
 api. It does have the benefit of supporting the full range of color 
 formats and generally being spec compliant already.

 If you are interested in making use of lodepng or extending it to an 
 editor, I'm open to discussion and willing to help.


 
 Now I think the question is how much can be done without making your 
 library too complex for its purpose.
 
 Preserving unknown chunks should be fairly simple to implement - we 
 basically just need a data structure or two to hold them and the order 
 of all chunks in the file.  (Obviously, this behaviour should be 
 optional.) Given this, it would also be straightforward to allow the 
 library user to add private chunks.


Lodepng has a Chunk type which contains the type of the chunk and holds 
a slice into the buffer containing the data. There is a Chunk iterator, 
which could be used to implement a delegate oriented interface with a 
few changes.


 But to allow the user to manipulate the range of public ancillary chunks 
 available, there's the added complication of chunk ordering rules to 
 consider, at least if we want to protect the user against inadvertently 
 creating a PNG file that's invalid because the chunks are in the wrong 
 order.


This is not a problem since the Chunk type implements opCmp by which an 
array of chunks can be sorted in the right order.


 On this basis, what do you reckon?
 
 Stewart.


What could be done is making a low-level interface for getting and 
saving chunks, along with some utility routines (most are already there) 
which allow the user to filter / (de)compress / convert / deinterlace / 
etc. in a controlled manner. This does not have to conflict with the 
current simplicity, it just exposes the implementation in a controlled 
and friendly manner as an additional api. I'm not sure it is necessary, 
but an object-oriented interface could be built on top of that.

Implementing streaming / progressive display and saving interlaced 
images will complicate matters though, not sure if that would fit in. 
Conversion to anything else than 8 bits per color channel is also not 
implemented, but would not be much work.

Here is a link to the source, lodepng is in scrapple: 
http://www.dsource.org/projects/scrapple/browser/trunk/lodepng/lodepng

Perhaps we should take further discussion to email or at the scrapple 
forum at dsource?

my email: lutger.blijdestijn _AT_ gmail _DOT_ com
Sep 12 2007
parent "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Lutger" <lutger.blijdestijn gmail.com> wrote in message 
news:fc9ii8$25jf$1 digitalmars.com...

 Stewart Gordon wrote:


<snip>

 But to allow the user to manipulate the range of public ancillary chunks 
 available, there's the added complication of chunk ordering rules to 
 consider, at least if we want to protect the user against inadvertently 
 creating a PNG file that's invalid because the chunks are in the wrong 
 order.


 This is not a problem since the Chunk type implements opCmp by which an 
 array of chunks can be sorted in the right order.


Well, at the moment it seems both buggy and unused - so here's already 
something to look at.

Still, the ordering rules in the PNG spec don't produce a total ordering 
relation.  Still,  "must come before" and "must come after" are relations we 
can implement (which I'm guessing is what you intended to do in Chunk.opCmp) 
and would probably be sufficient.

<snip>

 What could be done is making a low-level interface for getting and saving 
 chunks, along with some utility routines (most are already there) which 
 allow the user to filter / (de)compress / convert / deinterlace / etc. in 
 a controlled manner.


That's more or less how my library would work were I to write it.

<snip>

 Implementing streaming / progressive display and saving interlaced images 
 will complicate matters though, not sure if that would fit in. Conversion 
 to anything else than 8 bits per color channel is also not implemented, 
 but would not be much work.


Streaming and progressive display are among the things I'd like to support 
in my library.

Of course, improving Lodepng and writing a new library from scratch needn't 
be mutually exclusive.  Lodepng can be improved to do more within its design 
constraints, while writing a new PNG library is something that could be 
undertaken as a larger project given the time.


 Here is a link to the source, lodepng is in scrapple: 
 http://www.dsource.org/projects/scrapple/browser/trunk/lodepng/lodepng


Yes, I've found that already.


 Perhaps we should take further discussion to email or at the scrapple 
 forum at dsource?


We could continue the discussion on dsource if you like.

Stewart.
Sep 12 2007