Партнёры:
Хостинг:
Image::Size - read the dimensions of an image in several popular formats
use Image::Size;
# Get the size of globe.gif
($globe_x, $globe_y) = imgsize("globe.gif");
# Assume X=60 and Y=40 for remaining examples
use Image::Size 'html_imgsize';
# Get the size as 'width="X" height="Y"' for HTML generation
$size = html_imgsize("globe.gif");
# $size == 'width="60" height="40"'
use Image::Size 'attr_imgsize';
# Get the size as a list passable to routines in CGI.pm
@attrs = attr_imgsize("globe.gif");
# @attrs == ('-width', 60, '-height', 40)
use Image::Size;
# Get the size of an in-memory buffer
($buf_x, $buf_y) = imgsize(\$buf);
# Assuming that $buf was the data, imgsize() needed a reference to a scalar
Image::Size provides three interfaces for possible import:
By default, only "imgsize()" is exported. Any one or combination of the three may be explicitly imported, or all three may be with the tag :all.
# 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
# $fh was passed in, is IO::File reference:
($x, $y, $id) = imgsize($fh);
# Same as calling with filename, but more abstract.
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.
However, the cacheing 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.
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.
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:
This is also the fastest method for sizing the GIF, as it reads the least amount of data from the image stream.
When the first image descriptor block is read, the code immediately returns, making this only slightly-less efficient than the previous setting.
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.
The other two routines simply return undef in the case of error.
$image = $widget->Photo(-file => $img_path, attr_imgsize($img_path));
Since the "Tk::Image" classes use dashed option names as "CGI" does, no further translation is needed.
This package is also well-suited for use within an Apache web server context. File sizes are cached upon read (with a check against the modified time of the file, in case of changes), a useful feature for a mod_perl environment in which a child process endures beyond the lifetime of a single request. Other aspects of the mod_perl environment cooperate nicely with this module, such as the ability to use a sub-request to fetch the full pathname for a file within the server space. This complements the HTML generation capabilities of the CGI module, in which "CGI::img" wants a URL but "attr_imgsize" needs a file path:
# Assume $Q is an object of class CGI, $r is an Apache request object.
# $imgpath is a URL for something like "/img/redball.gif".
$r->print($Q->img({ -src => $imgpath,
attr_imgsize($r->lookup_uri($imgpath)->filename) }));
The advantage here, besides not having to hard-code the server document root, is that Apache passes the sub-request through the usual request lifecycle, including any stages that would re-write the URL or otherwise modify it.
As Image::Magick operates on file names, not handles, the use of it is restricted to cases where the input to "imgsize" is provided as file name.
Some bug fixes submitted by Bernd Leibing (bernd.leibing@rz.uni-ulm.de). PPM/PGM/PBM sizing code contributed by Carsten Dominik (dominik@strw.LeidenUniv.nl). Tom Metro (tmetro@vl.com) re-wrote the JPG and PNG code, and also provided a PNG image for the test suite. Dan Klein (dvk@lonewolf.com) contributed a re-write of the GIF code. Cloyce Spradling (cloyce@headgear.org) contributed TIFF sizing code and test images. Aldo Calpini (a.calpini@romagiubileo.it) suggested support of BMP images (which I really should have already thought of :-) and provided code to work with. A patch to allow html_imgsize to produce valid output for XHTML, as well as some documentation fixes was provided by Charles Levert (charles@comm.polymtl.ca). The ShockWave/Flash support was provided by Dmitry Dorofeev (dima@yasp.com). Though I neglected to take note of who supplied the PSD (PhotoShop) code, a bug was identified by Alex Weslowski <aweslowski@rpinteractive.com>, who also provided a test image. PCD support was adapted from a script made available by Phil Greenspun, as guided to my attention by Matt Mueller mueller@wetafx.co.nz. A thorough read of the documentation and source by Philip Newton Philip.Newton@datenrevision.de found several typos and a small buglet. Ville SkyttД (ville.skytta@iki.fi) provided the MNG and the Image::Magick fallback code.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |