Alien-FreeImage
view release on metacpan or search on metacpan
src/Source/LibJPEG/libjpeg.txt view on Meta::CPAN
Compression details
-------------------
Here we revisit the JPEG compression outline given in the overview.
1. Allocate and initialize a JPEG compression object.
A JPEG compression object is a "struct jpeg_compress_struct". (It also has
a bunch of subsidiary structures which are allocated via malloc(), but the
application doesn't control those directly.) This struct can be just a local
variable in the calling routine, if a single routine is going to execute the
whole JPEG compression sequence. Otherwise it can be static or allocated
from malloc().
You will also need a structure representing a JPEG error handler. The part
of this that the library cares about is a "struct jpeg_error_mgr". If you
are providing your own error handler, you'll typically want to embed the
jpeg_error_mgr struct in a larger structure; this is discussed later under
"Error handling". For now we'll assume you are just using the default error
handler. The default error handler will print JPEG error/warning messages
on stderr, and it will call exit() if a fatal error occurs.
You must initialize the error handler structure, store a pointer to it into
the JPEG object's "err" field, and then call jpeg_create_compress() to
initialize the rest of the JPEG object.
Typical code for this step, if you are using the default error handler, is
struct jpeg_compress_struct cinfo;
struct jpeg_error_mgr jerr;
...
cinfo.err = jpeg_std_error(&jerr);
jpeg_create_compress(&cinfo);
jpeg_create_compress allocates a small amount of memory, so it could fail
if you are out of memory. In that case it will exit via the error handler;
that's why the error handler must be initialized first.
2. Specify the destination for the compressed data (eg, a file).
As previously mentioned, the JPEG library delivers compressed data to a
"data destination" module. The library includes one data destination
module which knows how to write to a stdio stream. You can use your own
destination module if you want to do something else, as discussed later.
If you use the standard destination module, you must open the target stdio
stream beforehand. Typical code for this step looks like:
FILE * outfile;
...
if ((outfile = fopen(filename, "wb")) == NULL) {
fprintf(stderr, "can't open %s\n", filename);
exit(1);
}
jpeg_stdio_dest(&cinfo, outfile);
where the last line invokes the standard destination module.
WARNING: it is critical that the binary compressed data be delivered to the
output file unchanged. On non-Unix systems the stdio library may perform
newline translation or otherwise corrupt binary data. To suppress this
behavior, you may need to use a "b" option to fopen (as shown above), or use
setmode() or another routine to put the stdio stream in binary mode. See
cjpeg.c and djpeg.c for code that has been found to work on many systems.
You can select the data destination after setting other parameters (step 3),
if that's more convenient. You may not change the destination between
calling jpeg_start_compress() and jpeg_finish_compress().
3. Set parameters for compression, including image size & colorspace.
You must supply information about the source image by setting the following
fields in the JPEG object (cinfo structure):
image_width Width of image, in pixels
image_height Height of image, in pixels
input_components Number of color channels (samples per pixel)
in_color_space Color space of source image
The image dimensions are, hopefully, obvious. JPEG supports image dimensions
of 1 to 64K pixels in either direction. The input color space is typically
RGB or grayscale, and input_components is 3 or 1 accordingly. (See "Special
color spaces", later, for more info.) The in_color_space field must be
assigned one of the J_COLOR_SPACE enum constants, typically JCS_RGB or
JCS_GRAYSCALE.
JPEG has a large number of compression parameters that determine how the
image is encoded. Most applications don't need or want to know about all
these parameters. You can set all the parameters to reasonable defaults by
calling jpeg_set_defaults(); then, if there are particular values you want
to change, you can do so after that. The "Compression parameter selection"
section tells about all the parameters.
You must set in_color_space correctly before calling jpeg_set_defaults(),
because the defaults depend on the source image colorspace. However the
other three source image parameters need not be valid until you call
jpeg_start_compress(). There's no harm in calling jpeg_set_defaults() more
than once, if that happens to be convenient.
Typical code for a 24-bit RGB source image is
cinfo.image_width = Width; /* image width and height, in pixels */
cinfo.image_height = Height;
cinfo.input_components = 3; /* # of color components per pixel */
cinfo.in_color_space = JCS_RGB; /* colorspace of input image */
jpeg_set_defaults(&cinfo);
/* Make optional parameter settings here */
4. jpeg_start_compress(...);
After you have established the data destination and set all the necessary
source image info and other parameters, call jpeg_start_compress() to begin
a compression cycle. This will initialize internal state, allocate working
storage, and emit the first few bytes of the JPEG datastream header.
Typical code:
src/Source/LibJPEG/libjpeg.txt view on Meta::CPAN
* If you want to re-use the JPEG object, call jpeg_abort_compress(), or call
jpeg_abort() which works on both compression and decompression objects.
This will return the object to an idle state, releasing any working memory.
jpeg_abort() is allowed at any time after successful object creation.
Note that cleaning up the data destination, if required, is your
responsibility; neither of these routines will call term_destination().
(See "Compressed data handling", below, for more about that.)
jpeg_destroy() and jpeg_abort() are the only safe calls to make on a JPEG
object that has reported an error by calling error_exit (see "Error handling"
for more info). The internal state of such an object is likely to be out of
whack. Either of these two routines will return the object to a known state.
Decompression details
---------------------
Here we revisit the JPEG decompression outline given in the overview.
1. Allocate and initialize a JPEG decompression object.
This is just like initialization for compression, as discussed above,
except that the object is a "struct jpeg_decompress_struct" and you
call jpeg_create_decompress(). Error handling is exactly the same.
Typical code:
struct jpeg_decompress_struct cinfo;
struct jpeg_error_mgr jerr;
...
cinfo.err = jpeg_std_error(&jerr);
jpeg_create_decompress(&cinfo);
(Both here and in the IJG code, we usually use variable name "cinfo" for
both compression and decompression objects.)
2. Specify the source of the compressed data (eg, a file).
As previously mentioned, the JPEG library reads compressed data from a "data
source" module. The library includes one data source module which knows how
to read from a stdio stream. You can use your own source module if you want
to do something else, as discussed later.
If you use the standard source module, you must open the source stdio stream
beforehand. Typical code for this step looks like:
FILE * infile;
...
if ((infile = fopen(filename, "rb")) == NULL) {
fprintf(stderr, "can't open %s\n", filename);
exit(1);
}
jpeg_stdio_src(&cinfo, infile);
where the last line invokes the standard source module.
WARNING: it is critical that the binary compressed data be read unchanged.
On non-Unix systems the stdio library may perform newline translation or
otherwise corrupt binary data. To suppress this behavior, you may need to use
a "b" option to fopen (as shown above), or use setmode() or another routine to
put the stdio stream in binary mode. See cjpeg.c and djpeg.c for code that
has been found to work on many systems.
You may not change the data source between calling jpeg_read_header() and
jpeg_finish_decompress(). If you wish to read a series of JPEG images from
a single source file, you should repeat the jpeg_read_header() to
jpeg_finish_decompress() sequence without reinitializing either the JPEG
object or the data source module; this prevents buffered input data from
being discarded.
3. Call jpeg_read_header() to obtain image info.
Typical code for this step is just
jpeg_read_header(&cinfo, TRUE);
This will read the source datastream header markers, up to the beginning
of the compressed data proper. On return, the image dimensions and other
info have been stored in the JPEG object. The application may wish to
consult this information before selecting decompression parameters.
More complex code is necessary if
* A suspending data source is used --- in that case jpeg_read_header()
may return before it has read all the header data. See "I/O suspension",
below. The normal stdio source manager will NOT cause this to happen.
* Abbreviated JPEG files are to be processed --- see the section on
abbreviated datastreams. Standard applications that deal only in
interchange JPEG files need not be concerned with this case either.
It is permissible to stop at this point if you just wanted to find out the
image dimensions and other header info for a JPEG file. In that case,
call jpeg_destroy() when you are done with the JPEG object, or call
jpeg_abort() to return it to an idle state before selecting a new data
source and reading another header.
4. Set parameters for decompression.
jpeg_read_header() sets appropriate default decompression parameters based on
the properties of the image (in particular, its colorspace). However, you
may well want to alter these defaults before beginning the decompression.
For example, the default is to produce full color output from a color file.
If you want colormapped output you must ask for it. Other options allow the
returned image to be scaled and allow various speed/quality tradeoffs to be
selected. "Decompression parameter selection", below, gives details.
If the defaults are appropriate, nothing need be done at this step.
Note that all default values are set by each call to jpeg_read_header().
If you reuse a decompression object, you cannot expect your parameter
settings to be preserved across cycles, as you can for compression.
You must set desired parameter values each time.
5. jpeg_start_decompress(...);
Once the parameter values are satisfactory, call jpeg_start_decompress() to
src/Source/LibJPEG/libjpeg.txt view on Meta::CPAN
If you don't use a suspending data source, it is safe to assume that
jpeg_read_scanlines() reads at least one scanline per call, until the
bottom of the image has been reached.
If you use a buffer larger than one scanline, it is NOT safe to assume that
jpeg_read_scanlines() fills it. (The current implementation returns only a
few scanlines per call, no matter how large a buffer you pass.) So you must
always provide a loop that calls jpeg_read_scanlines() repeatedly until the
whole image has been read.
7. jpeg_finish_decompress(...);
After all the image data has been read, call jpeg_finish_decompress() to
complete the decompression cycle. This causes working memory associated
with the JPEG object to be released.
Typical code:
jpeg_finish_decompress(&cinfo);
If using the stdio source manager, don't forget to close the source stdio
stream if necessary.
It is an error to call jpeg_finish_decompress() before reading the correct
total number of scanlines. If you wish to abort decompression, call
jpeg_abort() as discussed below.
After completing a decompression cycle, you may dispose of the JPEG object as
discussed next, or you may use it to decompress another image. In that case
return to step 2 or 3 as appropriate. If you do not change the source
manager, the next image will be read from the same source.
8. Release the JPEG decompression object.
When you are done with a JPEG decompression object, destroy it by calling
jpeg_destroy_decompress() or jpeg_destroy(). The previous discussion of
destroying compression objects applies here too.
Typical code:
jpeg_destroy_decompress(&cinfo);
9. Aborting.
You can abort a decompression cycle by calling jpeg_destroy_decompress() or
jpeg_destroy() if you don't need the JPEG object any more, or
jpeg_abort_decompress() or jpeg_abort() if you want to reuse the object.
The previous discussion of aborting compression cycles applies here too.
Mechanics of usage: include files, linking, etc
-----------------------------------------------
Applications using the JPEG library should include the header file jpeglib.h
to obtain declarations of data types and routines. Before including
jpeglib.h, include system headers that define at least the typedefs FILE and
size_t. On ANSI-conforming systems, including <stdio.h> is sufficient; on
older Unix systems, you may need <sys/types.h> to define size_t.
If the application needs to refer to individual JPEG library error codes, also
include jerror.h to define those symbols.
jpeglib.h indirectly includes the files jconfig.h and jmorecfg.h. If you are
installing the JPEG header files in a system directory, you will want to
install all four files: jpeglib.h, jerror.h, jconfig.h, jmorecfg.h.
The most convenient way to include the JPEG code into your executable program
is to prepare a library file ("libjpeg.a", or a corresponding name on non-Unix
machines) and reference it at your link step. If you use only half of the
library (only compression or only decompression), only that much code will be
included from the library, unless your linker is hopelessly brain-damaged.
The supplied makefiles build libjpeg.a automatically (see install.txt).
While you can build the JPEG library as a shared library if the whim strikes
you, we don't really recommend it. The trouble with shared libraries is that
at some point you'll probably try to substitute a new version of the library
without recompiling the calling applications. That generally doesn't work
because the parameter struct declarations usually change with each new
version. In other words, the library's API is *not* guaranteed binary
compatible across versions; we only try to ensure source-code compatibility.
(In hindsight, it might have been smarter to hide the parameter structs from
applications and introduce a ton of access functions instead. Too late now,
however.)
On some systems your application may need to set up a signal handler to ensure
that temporary files are deleted if the program is interrupted. This is most
critical if you are on MS-DOS and use the jmemdos.c memory manager back end;
it will try to grab extended memory for temp files, and that space will NOT be
freed automatically. See cjpeg.c or djpeg.c for an example signal handler.
It may be worth pointing out that the core JPEG library does not actually
require the stdio library: only the default source/destination managers and
error handler need it. You can use the library in a stdio-less environment
if you replace those modules and use jmemnobs.c (or another memory manager of
your own devising). More info about the minimum system library requirements
may be found in jinclude.h.
ADVANCED FEATURES
=================
Compression parameter selection
-------------------------------
This section describes all the optional parameters you can set for JPEG
compression, as well as the "helper" routines provided to assist in this
task. Proper setting of some parameters requires detailed understanding
of the JPEG standard; if you don't know what a parameter is for, it's best
not to mess with it! See REFERENCES in the README file for pointers to
more info about JPEG.
It's a good idea to call jpeg_set_defaults() first, even if you plan to set
all the parameters; that way your code is more likely to work with future JPEG
libraries that have additional parameters. For the same reason, we recommend
you use a helper routine where one is provided, in preference to twiddling
cinfo fields directly.
The helper routines are:
jpeg_set_defaults (j_compress_ptr cinfo)
This routine sets all JPEG parameters to reasonable defaults, using
only the input image's color space (field in_color_space, which must
already be set in cinfo). Many applications will only need to use
this routine and perhaps jpeg_set_quality().
jpeg_set_colorspace (j_compress_ptr cinfo, J_COLOR_SPACE colorspace)
Sets the JPEG file's colorspace (field jpeg_color_space) as specified,
and sets other color-space-dependent parameters appropriately. See
src/Source/LibJPEG/libjpeg.txt view on Meta::CPAN
into it, as illustrated above. Ditto for Huffman tables, of course.)
You might want to read the tables from a tables-only file, rather than
hard-wiring them into your application. The jpeg_read_header() call is
sufficient to read a tables-only file. You must pass a second parameter of
FALSE to indicate that you do not require an image to be present. Thus, the
typical scenario is
create JPEG decompression object
set source to tables-only file
jpeg_read_header(&cinfo, FALSE);
set source to abbreviated image file
jpeg_read_header(&cinfo, TRUE);
set decompression parameters
jpeg_start_decompress(&cinfo);
read data...
jpeg_finish_decompress(&cinfo);
In some cases, you may want to read a file without knowing whether it contains
an image or just tables. In that case, pass FALSE and check the return value
from jpeg_read_header(): it will be JPEG_HEADER_OK if an image was found,
JPEG_HEADER_TABLES_ONLY if only tables were found. (A third return value,
JPEG_SUSPENDED, is possible when using a suspending data source manager.)
Note that jpeg_read_header() will not complain if you read an abbreviated
image for which you haven't loaded the missing tables; the missing-table check
occurs later, in jpeg_start_decompress().
It is possible to read a series of images from a single source file by
repeating the jpeg_read_header() ... jpeg_finish_decompress() sequence,
without releasing/recreating the JPEG object or the data source module.
(If you did reinitialize, any partial bufferload left in the data source
buffer at the end of one image would be discarded, causing you to lose the
start of the next image.) When you use this method, stored tables are
automatically carried forward, so some of the images can be abbreviated images
that depend on tables from earlier images.
If you intend to write a series of images into a single destination file,
you might want to make a specialized data destination module that doesn't
flush the output buffer at term_destination() time. This would speed things
up by some trifling amount. Of course, you'd need to remember to flush the
buffer after the last image. You can make the later images be abbreviated
ones by passing FALSE to jpeg_start_compress().
Special markers
---------------
Some applications may need to insert or extract special data in the JPEG
datastream. The JPEG standard provides marker types "COM" (comment) and
"APP0" through "APP15" (application) to hold application-specific data.
Unfortunately, the use of these markers is not specified by the standard.
COM markers are fairly widely used to hold user-supplied text. The JFIF file
format spec uses APP0 markers with specified initial strings to hold certain
data. Adobe applications use APP14 markers beginning with the string "Adobe"
for miscellaneous data. Other APPn markers are rarely seen, but might
contain almost anything.
If you wish to store user-supplied text, we recommend you use COM markers
and place readable 7-bit ASCII text in them. Newline conventions are not
standardized --- expect to find LF (Unix style), CR/LF (DOS style), or CR
(Mac style). A robust COM reader should be able to cope with random binary
garbage, including nulls, since some applications generate COM markers
containing non-ASCII junk. (But yours should not be one of them.)
For program-supplied data, use an APPn marker, and be sure to begin it with an
identifying string so that you can tell whether the marker is actually yours.
It's probably best to avoid using APP0 or APP14 for any private markers.
(NOTE: the upcoming SPIFF standard will use APP8 markers; we recommend you
not use APP8 markers for any private purposes, either.)
Keep in mind that at most 65533 bytes can be put into one marker, but you
can have as many markers as you like.
By default, the IJG compression library will write a JFIF APP0 marker if the
selected JPEG colorspace is grayscale or YCbCr, or an Adobe APP14 marker if
the selected colorspace is RGB, CMYK, or YCCK. You can disable this, but
we don't recommend it. The decompression library will recognize JFIF and
Adobe markers and will set the JPEG colorspace properly when one is found.
You can write special markers immediately following the datastream header by
calling jpeg_write_marker() after jpeg_start_compress() and before the first
call to jpeg_write_scanlines(). When you do this, the markers appear after
the SOI and the JFIF APP0 and Adobe APP14 markers (if written), but before
all else. Specify the marker type parameter as "JPEG_COM" for COM or
"JPEG_APP0 + n" for APPn. (Actually, jpeg_write_marker will let you write
any marker type, but we don't recommend writing any other kinds of marker.)
For example, to write a user comment string pointed to by comment_text:
jpeg_write_marker(cinfo, JPEG_COM, comment_text, strlen(comment_text));
If it's not convenient to store all the marker data in memory at once,
you can instead call jpeg_write_m_header() followed by multiple calls to
jpeg_write_m_byte(). If you do it this way, it's your responsibility to
call jpeg_write_m_byte() exactly the number of times given in the length
parameter to jpeg_write_m_header(). (This method lets you empty the
output buffer partway through a marker, which might be important when
using a suspending data destination module. In any case, if you are using
a suspending destination, you should flush its buffer after inserting
any special markers. See "I/O suspension".)
Or, if you prefer to synthesize the marker byte sequence yourself,
you can just cram it straight into the data destination module.
If you are writing JFIF 1.02 extension markers (thumbnail images), don't
forget to set cinfo.JFIF_minor_version = 2 so that the encoder will write the
correct JFIF version number in the JFIF header marker. The library's default
is to write version 1.01, but that's wrong if you insert any 1.02 extension
markers. (We could probably get away with just defaulting to 1.02, but there
used to be broken decoders that would complain about unknown minor version
numbers. To reduce compatibility risks it's safest not to write 1.02 unless
you are actually using 1.02 extensions.)
When reading, two methods of handling special markers are available:
1. You can ask the library to save the contents of COM and/or APPn markers
into memory, and then examine them at your leisure afterwards.
2. You can supply your own routine to process COM and/or APPn markers
on-the-fly as they are read.
The first method is simpler to use, especially if you are using a suspending
data source; writing a marker processor that copes with input suspension is
src/Source/LibJPEG/libjpeg.txt view on Meta::CPAN
passes is in total_passes, and the number of passes already completed is in
completed_passes. Thus the fraction of work completed may be estimated as
completed_passes + (pass_counter/pass_limit)
--------------------------------------------
total_passes
ignoring the fact that the passes may not be equal amounts of work.
When decompressing, pass_limit can even change within a pass, because it
depends on the number of scans in the JPEG file, which isn't always known in
advance. The computed fraction-of-work-done may jump suddenly (if the library
discovers it has overestimated the number of scans) or even decrease (in the
opposite case). It is not wise to put great faith in the work estimate.
When using the decompressor's buffered-image mode, the progress monitor work
estimate is likely to be completely unhelpful, because the library has no way
to know how many output passes will be demanded of it. Currently, the library
sets total_passes based on the assumption that there will be one more output
pass if the input file end hasn't yet been read (jpeg_input_complete() isn't
TRUE), but no more output passes if the file end has been reached when the
output pass is started. This means that total_passes will rise as additional
output passes are requested. If you have a way of determining the input file
size, estimating progress based on the fraction of the file that's been read
will probably be more useful than using the library's value.
Memory management
-----------------
This section covers some key facts about the JPEG library's built-in memory
manager. For more info, please read structure.txt's section about the memory
manager, and consult the source code if necessary.
All memory and temporary file allocation within the library is done via the
memory manager. If necessary, you can replace the "back end" of the memory
manager to control allocation yourself (for example, if you don't want the
library to use malloc() and free() for some reason).
Some data is allocated "permanently" and will not be freed until the JPEG
object is destroyed. Most data is allocated "per image" and is freed by
jpeg_finish_compress, jpeg_finish_decompress, or jpeg_abort. You can call the
memory manager yourself to allocate structures that will automatically be
freed at these times. Typical code for this is
ptr = (*cinfo->mem->alloc_small) ((j_common_ptr) cinfo, JPOOL_IMAGE, size);
Use JPOOL_PERMANENT to get storage that lasts as long as the JPEG object.
Use alloc_large instead of alloc_small for anything bigger than a few Kbytes.
There are also alloc_sarray and alloc_barray routines that automatically
build 2-D sample or block arrays.
The library's minimum space requirements to process an image depend on the
image's width, but not on its height, because the library ordinarily works
with "strip" buffers that are as wide as the image but just a few rows high.
Some operating modes (eg, two-pass color quantization) require full-image
buffers. Such buffers are treated as "virtual arrays": only the current strip
need be in memory, and the rest can be swapped out to a temporary file.
If you use the simplest memory manager back end (jmemnobs.c), then no
temporary files are used; virtual arrays are simply malloc()'d. Images bigger
than memory can be processed only if your system supports virtual memory.
The other memory manager back ends support temporary files of various flavors
and thus work in machines without virtual memory. They may also be useful on
Unix machines if you need to process images that exceed available swap space.
When using temporary files, the library will make the in-memory buffers for
its virtual arrays just big enough to stay within a "maximum memory" setting.
Your application can set this limit by setting cinfo->mem->max_memory_to_use
after creating the JPEG object. (Of course, there is still a minimum size for
the buffers, so the max-memory setting is effective only if it is bigger than
the minimum space needed.) If you allocate any large structures yourself, you
must allocate them before jpeg_start_compress() or jpeg_start_decompress() in
order to have them counted against the max memory limit. Also keep in mind
that space allocated with alloc_small() is ignored, on the assumption that
it's too small to be worth worrying about; so a reasonable safety margin
should be left when setting max_memory_to_use.
If you use the jmemname.c or jmemdos.c memory manager back end, it is
important to clean up the JPEG object properly to ensure that the temporary
files get deleted. (This is especially crucial with jmemdos.c, where the
"temporary files" may be extended-memory segments; if they are not freed,
DOS will require a reboot to recover the memory.) Thus, with these memory
managers, it's a good idea to provide a signal handler that will trap any
early exit from your program. The handler should call either jpeg_abort()
or jpeg_destroy() for any active JPEG objects. A handler is not needed with
jmemnobs.c, and shouldn't be necessary with jmemansi.c or jmemmac.c either,
since the C library is supposed to take care of deleting files made with
tmpfile().
Memory usage
------------
Working memory requirements while performing compression or decompression
depend on image dimensions, image characteristics (such as colorspace and
JPEG process), and operating mode (application-selected options).
As of v6b, the decompressor requires:
1. About 24K in more-or-less-fixed-size data. This varies a bit depending
on operating mode and image characteristics (particularly color vs.
grayscale), but it doesn't depend on image dimensions.
2. Strip buffers (of size proportional to the image width) for IDCT and
upsampling results. The worst case for commonly used sampling factors
is about 34 bytes * width in pixels for a color image. A grayscale image
only needs about 8 bytes per pixel column.
3. A full-image DCT coefficient buffer is needed to decode a multi-scan JPEG
file (including progressive JPEGs), or whenever you select buffered-image
mode. This takes 2 bytes/coefficient. At typical 2x2 sampling, that's
3 bytes per pixel for a color image. Worst case (1x1 sampling) requires
6 bytes/pixel. For grayscale, figure 2 bytes/pixel.
4. To perform 2-pass color quantization, the decompressor also needs a
128K color lookup table and a full-image pixel buffer (3 bytes/pixel).
This does not count any memory allocated by the application, such as a
buffer to hold the final output image.
The above figures are valid for 8-bit JPEG data precision and a machine with
32-bit ints. For 9-bit to 12-bit JPEG data, double the size of the strip
buffers and quantization pixel buffer. The "fixed-size" data will be
somewhat smaller with 16-bit ints, larger with 64-bit ints. Also, CMYK
or other unusual color spaces will require different amounts of space.
The full-image coefficient and pixel buffers, if needed at all, do not
have to be fully RAM resident; you can have the library use temporary
files instead when the total memory usage would exceed a limit you set.
( run in 0.811 second using v1.01-cache-2.11-cpan-64ef6c95b5d )