Technical design

Here is the functional design translated to actual C-modules.

Note that some blocks do not have headers and that others consist only of headers. This is inherent to the functional design. Eg. the implementation of the main header file is split in 4 different modules. Now you could argue to put them in a single file, but I felt it more logical to split them up. In other cases the functional block only results in specification rather than implementation. Hence the result is a header-file only.

Also note that the layout of the image doesn't necessarily enforce certain dependancies. Eg. "libmng_read" calls functions in "libmng_chunk_io" which in turn calls functions in "libmng_zlib" which in turn calls functions in "libmng_pixels". "libmng_chunk_io" also calls functions in "libmng_display" which in turn calls functions in "libmng_pixels". It's a web, I know. C'est la vie! The general tendency however is top-to-bottom.

• "libmng.h"
  

  The main interface header. This is an application's link to the High Level API (HLAPI) functions of the library. Applications need only this header.
  

• "libmng_types.h"
  

  This header defines platform-dependant stuff and some other tid-bits that are not required in the main header file, but are quite handy to have around at the top-level. So "libmng.h" simply includes this file. This keeps the main interface clear and concise. This is also the place of the callback prototypes.
  

• "libmng_data.h"
  

  To obtain the requirements to be re-entrant and thread-safe the library needs to store its internal state variables in a dynamic buffer. This buffer is created when the app initializes the library. The pointer to the buffer is then returned to the app as a handle. While this virtually hides the underlying data-structure(s), it is still possible for the app to mess with the data.
  To all developers: DO NOT ACCESS THE DATA DIRECTLY; USE THE GET&SET FUNCTIONS!!!!
  The data-structure(s) may change over time and your app will be broken. Be sensible please!
  

• "libmng_hlapi.c"
  

  This baby contains the main functions such as "initialize", "reset", "cleanup", "read", "display", etc, etc.
  

• "libmng_callback_xs.c"
  

  Here you'll find the GET/SET functions for the callbacks. libmng makes extensive use of callback functions. I'll explain on the next page.
  

• "libmng_prop_xs.c"
  

  This contains the GET/SET functions for internal variables that may be of interest to the application.
  

• "libmng_chunk_xs.c"
  

  This defines the functions for access at the chunk level. Shame on you if you don't know what a chunk is (back to the basics for you then!).
  

• "libmng_read.h" & "libmng_read.c"
  

  Here's where the generic read-logic is housed. This module uses the read callback to get data from the input, identifies it and sends it to the appropriate chunk-read-processing function. Note that this is also the routine called for the read&display HLAPI function. The chunk-read-processing routines also know how to handle the display functionality of a chunk.
  

• "libmng_write.h" & "libmng_write.c"
  

  This module handles the output of a MNG.
  

• "libmng_display.h" & "libmng_display.c"
  

  The module that handles displaying of a MNG. Note that most basic MNG display applications will simply use the read&display HLAPI function.
  

• "libmng_objects.h"
  

  This header defines the internal structures used for storing and maintaining internal objects, including the objects and object-buffers mentioned in the MNG specification.
  

• "libmng_object_prc.h" & "libmng_object_prc.c"
  

  Here are the functions that deal with the internal objects. They provide initialization, cleanup, 'cloning' and display processing.
  

• "libmng_chunks.h"
  

  This contains the structures for storing chunks.
  

• "libmng_chunk_prc.h" & "libmng_chunk_prc.c"
  

  These contain the chunk initialization and cleanup functions.
  

• "libmng_chunk_io.h" & "libmng_chunk_io.c"
  

  Here are the chunk read & write logic, but you will also find display-processing in the read-bits.
  

• "libmng_memory.h"
  

  This header defines the memory management functions. It's basically just a set of macros.
  

• "libmng_error.h" & "libmng_error.c"
  

  The error-handling functions. Called from basically every module in case of problems.
  

• "libmng_trace.h" & "libmng_trace.c"
  

  The trace function. This is basically just the low-level interface to the trace callback.
  

• "libmng_pixels.h" & "libmng_pixels.c"
  

  Here's where it's happening. This module contains all the low-level pixel juggling. Bit-depth conversions, interlacing and filtering processing. All functions are actually internal callbacks, called from various other modules through the main data-structure.
  

• "libmng_filter.h" & "libmng_filter.c"
  

  This contains the actual filter routines. Called only from pixel-processing.
  

• "libmng_dither.h" & "libmng_dither.c"
  

  The module responsible for dithering.
  

• "libmng_zlib.h" & "libmng_zlib.c"
  

  This defines the low-level interface to the external zlib package.
  

• "libmng_jpeg.h" & "libmng_jpeg.c"
  

  The low-level interface to the Independant JPEG Group (IJG) jpgsrc.
  

• "libmng_cms.h" & "libmng_cms.c"
  

  This is where all color-correction is handled. Interfaces with lcms ("little cms" by Marti Maria Saguer) and holds the gamma-only correction functionality.