view release on metacpan or  search on metacpan

src/Source/LibJPEG/structure.txt  view on Meta::CPAN

*** Memory manager internal structure ***

To isolate system dependencies as much as possible, we have broken the
memory manager into two parts.  There is a reasonably system-independent
"front end" (jmemmgr.c) and a "back end" that contains only the code
likely to change across systems.  All of the memory management methods
outlined above are implemented by the front end.  The back end provides
the following routines for use by the front end (none of these routines
are known to the rest of the JPEG code):

jpeg_mem_init, jpeg_mem_term	system-dependent initialization/shutdown

jpeg_get_small, jpeg_free_small	interface to malloc and free library routines
				(or their equivalents)

jpeg_get_large, jpeg_free_large	interface to FAR malloc/free in MSDOS machines;
				else usually the same as
				jpeg_get_small/jpeg_free_small

jpeg_mem_available		estimate available memory

jpeg_open_backing_store		create a backing-store object

read_backing_store,		manipulate a backing-store object
write_backing_store,
close_backing_store

On some systems there will be more than one type of backing-store object
(specifically, in MS-DOS a backing store file might be an area of extended
memory as well as a disk file).  jpeg_open_backing_store is responsible for
choosing how to implement a given object.  The read/write/close routines
are method pointers in the structure that describes a given object; this
lets them be different for different object types.

It may be necessary to ensure that backing store objects are explicitly
released upon abnormal program termination.  For example, MS-DOS won't free
extended memory by itself.  To support this, we will expect the main program
or surrounding application to arrange to call self_destruct (typically via
jpeg_destroy) upon abnormal termination.  This may require a SIGINT signal
handler or equivalent.  We don't want to have the back end module install its
own signal handler, because that would pre-empt the surrounding application's
ability to control signal handling.

The IJG distribution includes several memory manager back end implementations.
Usually the same back end should be suitable for all applications on a given
system, but it is possible for an application to supply its own back end at
need.


*** Implications of DNL marker ***

Some JPEG files may use a DNL marker to postpone definition of the image
height (this would be useful for a fax-like scanner's output, for instance).
In these files the SOF marker claims the image height is 0, and you only
find out the true image height at the end of the first scan.

We could read these files as follows:
1. Upon seeing zero image height, replace it by 65535 (the maximum allowed).
2. When the DNL is found, update the image height in the global image
   descriptor.
This implies that control modules must avoid making copies of the image
height, and must re-test for termination after each MCU row.  This would
be easy enough to do.

In cases where image-size data structures are allocated, this approach will
result in very inefficient use of virtual memory or much-larger-than-necessary
temporary files.  This seems acceptable for something that probably won't be a
mainstream usage.  People might have to forgo use of memory-hogging options
(such as two-pass color quantization or noninterleaved JPEG files) if they
want efficient conversion of such files.  (One could improve efficiency by
demanding a user-supplied upper bound for the height, less than 65536; in most
cases it could be much less.)

The standard also permits the SOF marker to overestimate the image height,
with a DNL to give the true, smaller height at the end of the first scan.
This would solve the space problems if the overestimate wasn't too great.
However, it implies that you don't even know whether DNL will be used.

This leads to a couple of very serious objections:
1. Testing for a DNL marker must occur in the inner loop of the decompressor's
   Huffman decoder; this implies a speed penalty whether the feature is used
   or not.
2. There is no way to hide the last-minute change in image height from an
   application using the decoder.  Thus *every* application using the IJG
   library would suffer a complexity penalty whether it cared about DNL or
   not.
We currently do not support DNL because of these problems.

A different approach is to insist that DNL-using files be preprocessed by a
separate program that reads ahead to the DNL, then goes back and fixes the SOF
marker.  This is a much simpler solution and is probably far more efficient.
Even if one wants piped input, buffering the first scan of the JPEG file needs
a lot smaller temp file than is implied by the maximum-height method.  For
this approach we'd simply treat DNL as a no-op in the decompressor (at most,
check that it matches the SOF image height).

We will not worry about making the compressor capable of outputting DNL.
Something similar to the first scheme above could be applied if anyone ever
wants to make that work.