This is the developers corner. If you're not really familiar with programming and the C language, you may want to give this a miss. Real developers please note that I'm going to presume reasonable understanding of at least PNG, and more-or-less of MNG as well. If you're not up to scratch with the latest specification, I'd say this would be a good time to dig into it.

Allright. If you're still with me, we'll dive into the specifics. Here's a list of what I've aimed for:

• Must be platform-independant
• Must be fully ANSI C compatible
• Must be re-entrant (no global variables)
• Must be thread-safe
• Must have a single header
• Must be configurable for different environments
• Must hide low-level coding/decoding issues (zlib/jpeg)
• Must be able to read, write, create and/or display MNG/PNG/JNG
• Must encapsulate (as good as possible) internal variables

• Must provide adequate timing support
• Must be able to handle full-MNG, PNG and JNG
• Must be able to handle all bit_depths, color_types, compression_types, filter_methods and interlace_methods
• Must be able to handle transparency (cheap and full alpha-channel)
• Must be able to handle 8- and 16-bit images
• Must be able to handle bit_depth conversions
• Must be able to provide gamma correction
• Must be able to provide full error reporting
• Must be able to provide chunk access

• Should be light and fast (depending on environment configuration)
• Should provide full color-management
• Should provide dithering support where necessary
• Should contain internal tracing capability

Quite the list, eh? Well, just remember it says that it is what I'm aiming for. That doesn't necessarily mean it will be able to do all that on the first public release... But the intentions are there :-)

That being the requirements, let's have a look at the internal module structure. Applications only need to see libmng.h, all others are pretty much off-limits. If anyone needs access to something in the internals, then I haven't done my job right, or they're pushing it to the limit. The first case can be circumvented by adapting the HLAPI. The other case is a "too bad" scenario...

Click on the images to get the larger picture. You may want to print this out and frame it over your bed... (I didn't though, in case you're wondering)

This design is subject to changes. At some point during the development-cycle I may decide that certain modules may be combined or rather need to be split up. But as far as I can tell, this isn't too likely. Note that the effect for application developers is virtually nil, as everything is hidden through the main header file "libmng.h", which serves as the single reference point to external apps.