PNG libraries

[Lutger]

Stewart Gordon wrote:
> "Lutger" <lutger.blijdestijn at gmail.com> wrote in message 
> news:fc711f$ocl$1 at 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