Input Types¶

The sort of data passed as stream can be one of three forms:

string

If an ordinary scalar (string) is passed, it is assumed to be a file name (either absolute or relative to the current working directory of the process) and is searched for and opened (if found) as the source of data. Possible error messages (see DIAGNOSTICS below) may include file-access problems.

scalar reference

If the passed-in stream is a scalar reference, it is interpreted as pointing to an in-memory buffer containing the image data.

        # Assume that &read_data gets data somewhere (WWW, etc.)
        $img = &read_data;
        ($x, $y, $id) = imgsize(\$img);
        # $x and $y are dimensions, $id is the type of the image
    

Open file handle

The third option is to pass in an open filehandle (such as an object of the "IO::File" class, for example) that has already been associated with the target image file. The file pointer will necessarily move, but will be restored to its original position before subroutine end.

        # $fh was passed in, is IO::File reference:
        ($x, $y, $id) = imgsize($fh);
        # Same as calling with filename, but more abstract.
    

Recognized Formats¶

Image::Size natively understands and sizes data in the following formats:

GIF

JPG

XBM

XPM

PPM family (PPM/PGM/PBM)

XV thumbnails

PNG

MNG

TIF

BMP

PSD (Adobe PhotoShop)

SWF (ShockWave/Flash)

CWS (FlashMX, compressed SWF, Flash 6)

PCD (Kodak PhotoCD, see notes below)

EMF (Windows Enhanced Metafile Format)

WEBP

ICO (Microsoft icon format)

CUR (Microsoft mouse cursor format)

Additionally, if the Image::Magick module is present, the file types supported by it are also supported by Image::Size. See also "CAVEATS".

When using the "imgsize" interface, there is a third, unused value returned if the programmer wishes to save and examine it. This value is the identity of the data type, expressed as a 2-3 letter abbreviation as listed above. This is useful when operating on open file handles or in-memory data, where the type is as unknown as the size. The two support routines ignore this third return value, so those wishing to use it must use the base "imgsize" routine.

Note that when the Image::Magick fallback is used (for all non-natively supported files), the data type identity comes directly from the 'format' parameter reported by Image::Magick, so it may not meet the 2-3 letter abbreviation format. For example, a WBMP file might be reported as 'Wireless Bitmap (level 0) image' in this case.

Information Caching and $NO_CACHE¶

When a filename is passed to any of the sizing routines, the default behavior of the library is to cache the resulting information. The modification-time of the file is also recorded, to determine whether the cache should be purged and updated. This was originally added due to the fact that a number of CGI applications were using this library to generate attributes for pages that often used the same graphical element many times over.

However, the caching can lead to problems when the files are generated dynamically, at a rate that exceeds the resolution of the modification-time value on the filesystem. Thus, the optionally-importable control variable $NO_CACHE has been introduced. If this value is anything that evaluates to a non-false value (be that the value 1, any non-null string, etc.) then the cacheing is disabled until such time as the program re-enables it by setting the value to false.

The parameter $NO_CACHE may be imported as with the imgsize routine, and is also imported when using the import tag ":all". If the programmer chooses not to import it, it is still accessible by the fully-qualified package name, $Image::Size::NO_CACHE.

Sharing the Cache Between Processes¶

If you are using Image::Size in a multi-thread or multi-process environment, you may wish to enable sharing of the cached information between the processes (or threads). Image::Size does not natively provide any facility for this, as it would add to the list of dependencies.

To make it possible for users to do this themselves, the %CACHE hash-table that Image::Size uses internally for storage may be imported in the use statement. The user may then make use of packages such as IPC::MMA (IPC::MMA) that can "tie" a hash to a shared-memory segment:

    use Image::Size qw(imgsize %CACHE);
    use IPC::MMA;
    ...
    tie %CACHE, 'IPC::MM::Hash', $mmHash; # $mmHash via mm_make_hash
    # Now, forked processes will share any changes made to the cache

Sizing PhotoCD Images¶

With version 2.95, support for the Kodak PhotoCD image format is included. However, these image files are not quite like the others. One file is the source of the image in any of a range of pre-set resolutions (all with the same aspect ratio). Supporting this here is tricky, since there is nothing inherent in the file to limit it to a specific resolution.

The library addresses this by using a scale mapping, and requiring the user (you) to specify which scale is preferred for return. Like the $NO_CACHE setting described earlier, this is an importable scalar variable that may be used within the application that uses Image::Size. This parameter is called $PCD_SCALE, and is imported by the same name. It, too, is also imported when using the tag ":all" or may be referenced as $Image::Size::PCD_SCALE.

The parameter should be set to one of the following values:

        base/16
        base/4
        base
        base4
        base16
        base64

Note that not all PhotoCD disks will have included the "base64" resolution. The actual resolutions are not listed here, as they are constant and can be found in any documentation on the PCD format. The value of $PCD_SCALE is treated in a case-insensitive manner, so "base" is the same as "Base" or "BaSe". The default scale is set to "base".

Also note that the library makes no effort to read enough of the PCD file to verify that the requested resolution is available. The point of this library is to read as little as necessary so as to operate efficiently. Thus, the only real difference to be found is in whether the orientation of the image is portrait or landscape. That is in fact all that the library extracts from the image file.

Controlling Behavior with GIF Images¶

GIF images present a sort of unusual situation when it comes to reading size. Because GIFs can be a series of sub-images to be played as an animated sequence, what part does the user want to get the size for?

When dealing with GIF files, the user may control the behavior by setting the global value $Image::Size::GIF_BEHAVIOR. Like the PCD setting, this may be imported when loading the library. Three values are recognized by the GIF-handling code:

0

This is the default value. When this value is chosen, the returned dimensions are those of the "screen". The "screen" is the display area that the GIF declares in the first data block of the file. No sub-images will be greater than this in size; if they are, the specification dictates that they be cropped to fit within the box.

This is also the fastest method for sizing the GIF, as it reads the least amount of data from the image stream.

1

If this value is set, then the size of the first sub-image within the GIF is returned. For plain (non-animated) GIF files, this would be the same as the screen (though it doesn't have to be, strictly-speaking).

When the first image descriptor block is read, the code immediately returns, making this only slightly-less efficient than the previous setting.

2

If this value is chosen, then the code loops through all the sub-images of the animated GIF, and returns the dimensions of the largest of them.

This option requires that the full GIF image be read, in order to ensure that the largest is found.

Any value outside this range will produce an error in the GIF code before any image data is read.

The value of dimensions other than the view-port ("screen") is dubious. However, some users have asked for that functionality.

Pre-Caching Image Data¶

One approach is to include code in an Apache start-up script that reads the information on all images ahead of time. A script loaded via "PerlRequire", for example, becomes part of the server memory before child processes are created. When the children are created, they come into existence with a pre-primed cache already available.

The shortcoming of this approach is that you have to plan ahead of time for which image files you need to cache. Also, if the list is long-enough it can slow server start-up time.

The advantage is that it keeps the information centralized in one place and thus easier to manage and maintain. It also requires no additional CPAN modules.

Shared Memory Caching¶

Another approach is to introduce a shared memory segment that the individual processes all have access to. This can be done with any of a variety of shared memory modules on CPAN.

Probably the easiest way to do this is to use one of the packages that allow the tying of a hash to a shared memory segment. You can use this in combination with importing the hash table variable that is used by Image::Size for the cache, or you can refer to it explicitly by full package name:

    use IPC::Shareable;
    use Image::Size;
    tie %Image::Size::CACHE, 'IPC::Shareable', 'size', { create => 1 };

That example uses IPC::Shareable (see IPC::Shareable) and uses the option to the "tie" command that tells IPC::Shareable to create the segment. Once the initial server process starts to create children, they will all share the tied handle to the memory segment.

Another package that provides this capability is IPC::MMA (see IPC::MMA), which provides shared memory management via the mm library from Ralf Engelschall (details available in the documentation for IPC::MMA):

    use IPC::MMA;
    use Image::Size qw(%CACHE);
    my $mm = mm_create(65536, '/tmp/test_lockfile');
    my $mmHash = mm_make_hash($mm);
    tie %CACHE, 'IPC::MM::Hash', $mmHash;

As before, this is done in the start-up phase of the webserver. As the child processes are created, they inherit the pointer to the existing shared segment.