print join " ", keys %Imager::formats;
This will include some other information identifying libraries rather
-than file formats. For new code you might find the L</read_types> or
-L</write_types> methods useful.
+than file formats. For new code you might find the L</read_types()>
+or L</write_types()> methods useful.
=over
-=item read
+=item read()
Reading writing to and from files is simple, use the C<read()>
method to read an image:
or die "Cannot read $filename: ", $img->errstr;
In most cases Imager can auto-detect the file type, so you can just
-supply the filename:
+supply the file name:
$img->read(file => $filename)
or die "Cannot read $filename: ", $img->errstr;
-The read() method accepts the C<allow_partial> parameter. If this is
-non-zero then read() can return true on an incomplete image and set
+The read() method accepts the C<allow_incomplete> parameter. If this
+is non-zero then read() can return true on an incomplete image and set
the C<i_incomplete> tag.
From Imager 0.68 you can supply most read() parameters to the new()
my $img = Imager->new(file => $filename)
or die "Cannot read $filename: ", Imager->errstr;
-=item write
+=item write()
and the C<write()> method to write an image:
$img->write(file=>$filename, type=>$type)
or die "Cannot write $filename: ", $img->errstr;
-=item read_multi
+=item read_multi()
If you're reading from a format that supports multiple images per
file, use the C<read_multi()> method:
As with the read() method, Imager will normally detect the C<type>
automatically.
-=item write_multi
+=item write_multi()
and if you want to write multiple images to a single file use the
C<write_multi()> method:
Imager->write_multi({ file=> $filename, type=>$type }, @images)
or die "Cannot write $filename: ", Imager->errstr;
-=item read_types
+=item read_types()
This is a class method that returns a list of the image file types
that Imager can read.
attempting to read a file, which may modify the list of available read
types.
-=item write_types
+=item write_types()
This is a class method that returns a list of the image file types
that Imager can write.
=back
-When writing, if the I<filename> includes an extension that Imager
-recognizes, then you don't need the I<type>, but you may want to
+When writing, if the C<filename> includes an extension that Imager
+recognizes, then you don't need the C<type>, but you may want to
provide one anyway. See L</Guessing types> for information on
controlling this recognition.
=item *
-file - The C<file> parameter is the name of the image file to be
+C<file> - The C<file> parameter is the name of the image file to be
written to or read from. If Imager recognizes the extension of the
file you do not need to supply a C<type>.
=item *
-fh - C<fh> is a file handle, typically either returned from
+C<fh> - C<fh> is a file handle, typically either returned from
C<<IO::File->new()>>, or a glob from an C<open> call. You should call
C<binmode> on the handle before passing it to Imager.
=item *
-fd - C<fd> is a file descriptor. You can get this by calling the
+C<fd> - C<fd> is a file descriptor. You can get this by calling the
C<fileno()> function on a file handle, or by using one of the standard
file descriptor numbers.
=item *
-data - When reading data, C<data> is a scalar containing the image
+C<data> - When reading data, C<data> is a scalar containing the image
file data, when writing, C<data> is a reference to the scalar to save
-the image file data too. For GIF images you will need giflib 4 or
-higher, and you may need to patch giflib to use this option for
+the image file data too. For GIF images you will need C<giflib> 4 or
+higher, and you may need to patch C<giflib> to use this option for
writing.
my $data;
=item *
-callback - Imager will make calls back to your supplied coderefs to
-read, write and seek from/to/through the image file.
+C<callback>, C<readcb>, C<writecb>, C<seekcb>, C<closecb> - Imager
+will make calls back to your supplied coderefs to read, write and seek
+from/to/through the image file. See L</"I/O Callbacks"> below for details.
-When reading from a file you can use either C<callback> or C<readcb>
-to supply the read callback, and when writing C<callback> or
-C<writecb> to supply the write callback.
+=item *
-When writing you can also supply the C<maxbuffer> option to set the
-maximum amount of data that will be buffered before your write
-callback is called. Note: the amount of data supplied to your
-callback can be smaller or larger than this size.
+C<io> - an L<Imager::IO> object.
-The read callback is called with 2 parameters, the minimum amount of
-data required, and the maximum amount that Imager will store in it's C
-level buffer. You may want to return the minimum if you have a slow
-data source, or the maximum if you have a fast source and want to
-prevent many calls to your perl callback. The read data should be
-returned as a scalar.
+=back
-Your write callback takes exactly one parameter, a scalar containing
-the data to be written. Return true for success.
+X<buffering>X<unbuffered>By default Imager will use buffered I/O when
+reading or writing an image. You can disabled buffering for output by
+supplying a C<< buffered => 0 >> parameter to C<write()> or
+C<write_multi()>.
-The seek callback takes 2 parameters, a I<POSITION>, and a I<WHENCE>,
-defined in the same way as perl's seek function.
+=head2 I/O Callbacks
-You can also supply a C<closecb> which is called with no parameters
-when there is no more data to be written. This could be used to flush
-buffered data.
+When reading from a file you can use either C<callback> or C<readcb>
+to supply the read callback, and when writing C<callback> or
+C<writecb> to supply the write callback.
+
+Whether reading or writing a C<TIFF> image, C<seekcb> and C<readcb>
+are required.
+
+If a file handler attempts to use C<readcb>, C<writecb> or C<seekcb>
+and you haven't supplied one, the call will fail, failing the image
+read or write, returning an error message indicating that the callback
+is missing:
+
+ # attempting to read a TIFF image without a seekcb
+ open my $fh, "<", $filename or die;
+ my $rcb = sub {
+ my $val;
+ read($fh, $val, $_[0]) or return "";
+ return $val;
+ };
+ my $im = Imager->new(callback => $rcb)
+ or die Imager->errstr
+ # dies with (wrapped here):
+ # Error opening file: (Iolayer): Failed to read directory at offset 0:
+ # (Iolayer): Seek error accessing TIFF directory: seek callback called
+ # but no seekcb supplied
+
+You can also provide a C<closecb> parameter called when writing the
+file is complete. If no C<closecb> is supplied the default will
+succeed silently.
# contrived
my $data;
Imager->write_multi({ callback => \&mywrite, type => 'gif'}, @images)
or die Imager->errstr;
-Note that for reading you'll almost always need to provide a
-C<seekcb>.
+=head3 C<readcb>
+
+The read callback is called with 2 parameters:
+
+=over
+
+=item *
+
+C<size> - the minimum amount of data required.
+
+=item *
+
+C<maxsize> - previously this was the maximum amount of data returnable
+- currently it's always the same as C<size>
+
+=back
+
+Your read callback should return the data as a scalar:
+
+=over
+
+=item *
+
+on success, a string containing the bytes read.
+
+=item *
+
+on end of file, an empty string
+
+=item *
+
+on error, C<undef>.
=back
+If your return value contains more data than C<size> Imager will
+panic.
+
+Your return value must not contain any characters over C<\xFF> or
+Imager will panic.
+
+=head3 C<writecb>
+
+Your write callback takes exactly one parameter, a scalar containing
+the data to be written.
+
+Return true for success.
+
+=head3 C<seekcb>
+
+The seek callback takes 2 parameters, a I<POSITION>, and a I<WHENCE>,
+defined in the same way as perl's seek function.
+
+Previously you always needed a C<seekcb> callback if you called
+Imager's L</read()> or L</read_multi()> without a C<type> parameter,
+but this is no longer necessary unless the file handler requires
+seeking, such as for TIFF files.
+
+Returns the new position in the file, or -1 on failure.
+
+=head3 C<closecb>
+
+You can also supply a C<closecb> which is called with no parameters
+when there is no more data to be written. This could be used to flush
+buffered data.
+
+Return true on success.
+
=head2 Guessing types
+X<FORMATGUESS>
When writing to a file, if you don't supply a C<type> parameter Imager
-will attempt to guess it from the filename. This is done by calling
+will attempt to guess it from the file name. This is done by calling
the code reference stored in C<$Imager::FORMATGUESS>. This is only
-done when write() or write_multi() is called with a C<file> parameter.
+done when write() or write_multi() is called with a C<file> parameter,
+or if read() or read_multi() can't determine the type from the file's
+header.
The default function value of C<$Imager::FORMATGUESS> is
C<\&Imager::def_guess_type>.
=over
-=item def_guess_type
+=item def_guess_type()
+X<methods, def_guess_type()>
This is the default function Imager uses to derive a file type from a
file name. This is a function, not a method.
-Accepts a single parameter, the filename and returns the type or
+Accepts a single parameter, the file name and returns the type or
undef.
=back
identifying information. The current implementation attempts to
detect the following image types beyond those supported by Imager:
+=for stopwords Photoshop
+
=over
-xpm, mng, jng, SGI RGB, ilbm, pcx, fits, psd (Photoshop), eps, Utah
-RLE
+C<xpm>, C<mng>, C<jng>, C<ilbm>, C<pcx>, C<fits>, C<psd> (Photoshop), C<eps>, Utah
+C<RLE>.
=back
=over
-=item set_file_limits
+=item set_file_limits()
In some cases you will be receiving images from an untested source,
such as submissions via CGI. To prevent such images from consuming
You can pass any or all of the limits above, any limits you do not
pass are left as they were.
-Any limit of zero is treated as unlimited.
+Any limit of zero for width or height is treated as unlimited.
+
+A limit of zero for bytes is treated as one gigabyte, but higher bytes
+limits can be set explicitly.
-By default, all of the limits are zero, or unlimited.
+By default, the width and height limits are zero, or unlimited. The
+default memory size limit is one gigabyte.
-You can reset all of the limited to their defaults by passing in the
-reset parameter as a true value:
+You can reset all limits to their defaults with the reset parameter:
# no limits
Imager->set_file_limits(reset=>1);
# only bytes is limited
Imager->set_file_limits(reset=>1, bytes=>10_000_000);
-=item get_file_limits
+=item get_file_limits()
You can get the current limits with the get_file_limits() method:
my ($max_width, $max_height, $max_bytes) =
Imager->get_file_limits();
+=item check_file_limits()
+X<class methods, check_file_limits()>X<check_file_limits()>
+
+Intended for use by file handlers to check that the size of a file is
+within the limits set by C<set_file_limits()>.
+
+Parameters:
+
+=over
+
+=item *
+
+C<width>, C<height> - the width and height of the image in pixels.
+Must be a positive integer. Required.
+
+=item *
+
+C<channels> - the number of channels in the image, including the alpha
+channel if any. Must be a positive integer between 1 and 4
+inclusive. Default: 3.
+
+=item *
+
+C<sample_size> - the number of bytes stored per sample. Must be a
+positive integer or C<"float">. Note that this should be the sample
+size of the Imager image you will be creating, not the sample size in
+the source, eg. if the source has 32-bit samples this should be
+C<"float"> since Imager doesn't have 32-bit/sample images.
+
+=back
+
=back
=head1 TYPE SPECIFIC INFORMATION
At some point in the future these obsolete options will no longer be
supported.
+=for stopwords aNy PixMaps BitMap
+
=head2 PNM (Portable aNy Map)
-Imager can write PGM (Portable Gray Map) and PPM (Portable PixMaps)
-files, depending on the number of channels in the image. Currently
-the images are written in binary formats. Only 1 and 3 channel images
-can be written, including 1 and 3 channel paletted images.
+Imager can write C<PGM> (Portable Gray Map) and C<PPM> (Portable
+PixMaps) files, depending on the number of channels in the image.
+Currently the images are written in binary formats. Only 1 and 3
+channel images can be written, including 1 and 3 channel paletted
+images.
$img->write(file=>'foo.ppm') or die $img->errstr;
-Imager can read both the ASCII and binary versions of each of the PBM
-(Portable BitMap), PGM and PPM formats.
+Imager can read both the ASCII and binary versions of each of the
+C<PBM> (Portable BitMap), C<PGM> and C<PPM> formats.
$img->read(file=>'foo.ppm') or die $img->errstr;
=item *
-X<pnm_maxval>pnm_maxval - the maxvals number from the PGM/PPM header.
-Always set to 2 for a PBM file.
+X<pnm_maxval>C<pnm_maxval> - the C<maxvals> number from the PGM/PPM header.
+Always set to 2 for a C<PBM> file.
=item *
-X<pnm_type>pnm_type - the type number from the PNM header, 1 for ASCII
-PBM files, 2 for ASCII PGM files, 3 for ASCII PPM files, 4 for binary
-PBM files, 5 for binary PGM files, 6 for binary PPM files.
+X<pnm_type>C<pnm_type> - the type number from the C<PNM> header, 1 for ASCII
+C<PBM> files, 2 for ASCII C<PGM> files, 3 for ASCII c<PPM> files, 4 for binary
+C<PBM> files, 5 for binary C<PGM> files, 6 for binary C<PPM> files.
=back
=item *
X<pnm_write_wide_data>pnm_write_wide_data - if this is non-zero then
-write() can write PGM/PPM files with 16-bits/sample. Some
+write() can write C<PGM>/C<PPM> files with 16-bits/sample. Some
applications, for example GIMP 2.2, and tools can only read
8-bit/sample binary PNM files, so Imager will only write a 16-bit
image when this tag is non-zero.
=head2 JPEG
+=for stopwords composited
+
You can supply a C<jpegquality> parameter (0-100) when writing a JPEG
file, which defaults to 75%. If you write an image with an alpha
-channel to a jpeg file then it will be composited against the
+channel to a JPEG file then it will be composited against the
background set by the C<i_background> parameter (or tag).
$img->write(file=>'foo.jpg', jpegquality=>90) or die $img->errstr;
-Imager will read a grayscale JPEG as a 1 channel image and a color
+Imager will read a gray scale JPEG as a 1 channel image and a color
JPEG as a 3 channel image.
$img->read(file=>'foo.jpg') or die $img->errstr;
=over
-=item jpeg_density_unit
+=item *
-The value of the density unit field in the JFIF header. This is
-ignored on writing if the C<i_aspect_only> tag is non-zero.
+C<jpeg_density_unit> - The value of the density unit field in the
+C<JFIF> header. This is ignored on writing if the C<i_aspect_only>
+tag is non-zero.
The C<i_xres> and C<i_yres> tags are expressed in pixels per inch no
matter the value of this tag, they will be converted to/from the value
stored in the JPEG file.
-=item jpeg_density_unit_name
+=item *
+
+C<jpeg_density_unit_name> - This is set when reading a JPEG file to
+the name of the unit given by C<jpeg_density_unit>. Possible results
+include C<inch>, C<centimeter>, C<none> (the C<i_aspect_only> tag is
+also set reading these files). If the value of C<jpeg_density_unit>
+is unknown then this tag isn't set.
-This is set when reading a JPEG file to the name of the unit given by
-C<jpeg_density_unit>. Possible results include C<inch>,
-C<centimeter>, C<none> (the C<i_aspect_only> tag is also set reading
-these files). If the value of jpeg_density_unit is unknown then this
-tag isn't set.
+=item *
+
+C<jpeg_comment> - Text comment.
-=item jpeg_comment
+=item *
-Text comment.
+C<jpeg_progressive> - Whether the JPEG file is a progressive
+file. (Imager 0.84)
=back
JPEG supports the spatial resolution tags C<i_xres>, C<i_yres> and
C<i_aspect_only>.
-If an APP1 block containing EXIF information is found, then any of the
-following tags can be set:
+=for stopwords EXIF
+
+If an C<APP1> block containing EXIF information is found, then any of the
+following tags can be set when reading a JPEG image:
=over
=back
-The following derived tags can also be set:
+The following derived tags can also be set when reading a JPEG image:
=over
0
Auto exposure
+Imager will not write EXIF tags to any type of image, if you need more
+advanced EXIF handling, consider L<Image::ExifTool>.
+
+=for stopwords IPTC
+
=over
-=item parseiptc
+=item parseiptc()
Historically, Imager saves IPTC data when reading a JPEG image, the
parseiptc() method returns a list of key/value pairs resulting from a
=back
-=head2 GIF (Graphics Interchange Format)
+=head2 GIF
When writing one of more GIF images you can use the same
L<Quantization Options|Imager::ImageTypes> as you can when converting
=item *
-gif_background - The index in the global colormap of the logical
+gif_background - The index in the global color map of the logical
screen's background color. This is only set if the current image uses
-the global colormap. You can set this on write too, but for it to
+the global color map. You can set this on write too, but for it to
choose the color you want, you will need to supply only paletted
images and set the C<gif_eliminate_unused> tag to 0.
=item *
-gif_trans_index - The index of the color in the colormap used for
+gif_trans_index - The index of the color in the color map used for
transparency. If the image has a transparency then it is returned as
a 4 channel image with the alpha set to zero in this palette entry.
This value is not used when writing. ("Transparent Color Index")
=item *
gif_trans_color - A reference to an Imager::Color object, which is the
-colour to use for the palette entry used to represent transparency in
-the palette. You need to set the transp option (see L<Quantization
-options>) for this value to be used.
+color to use for the palette entry used to represent transparency in
+the palette. You need to set the C<transp> option (see
+L<Imager::ImageTypes/"Quantization options">) for this value to be
+used.
=item *
=item *
-gif_comment - the first block of the first gif comment before each
+gif_comment - the first block of the first GIF comment before each
image.
=item *
=back
-Where applicable, the ("name") is the name of that field from the GIF89
+Where applicable, the ("name") is the name of that field from the C<GIF89>
standard.
-The following gif writing options are obsolete, you should set the
+The following GIF writing options are obsolete, you should set the
corresponding tag in the image, either by using the tags functions, or
by supplying the tag and value as options.
=item *
-gif_each_palette - Each image in the gif file has it's own palette if
-this is non-zero. All but the first image has a local colour table
-(the first uses the global colour table.
+gif_each_palette - Each image in the GIF file has it's own palette if
+this is non-zero. All but the first image has a local color table
+(the first uses the global color table.
Use C<gif_local_map> in new code.
gif_loop_count - If this is non-zero the Netscape loop extension block
is generated, which makes the animation of the images repeat.
-This is currently unimplemented due to some limitations in giflib.
+This is currently unimplemented due to some limitations in C<giflib>.
=back
$image->read(file=>"example.gif", page=>1)
or die "Cannot read second page: ",$image->errstr,"\n";
-Before release 0.46, Imager would read multi-image GIF image files
+Before release 0.46, Imager would read multiple image GIF image files
into a single image, overlaying each of the images onto the virtual
GIF screen.
As of 0.46 the default is to read the first image from the file, as if
called with C<< page => 0 >>.
-You can return to the previous behaviour by calling read with the
+You can return to the previous behavior by calling read with the
C<gif_consolidate> parameter set to a true value:
$img->read(file=>$some_gif_file, gif_consolidate=>1);
=head2 TIFF (Tagged Image File Format)
Imager can write images to either paletted or RGB TIFF images,
-depending on the type of the source image. Currently if you write a
-16-bit/sample or double/sample image it will be written as an
-8-bit/sample image. Only 1 or 3 channel images can be written.
+depending on the type of the source image.
+
+When writing direct color images to TIFF the sample size of the
+output file depends on the input:
+
+=over
+
+=item *
+
+double/sample - written as 32-bit/sample TIFF
+
+=item *
+
+16-bit/sample - written as 16-bit/sample TIFF
+
+=item *
+
+8-bit/sample - written as 8-bit/sample TIFF
+
+=back
+
+For paletted images:
+
+=over
+
+=item *
+
+C<< $img->is_bilevel >> is true - the image is written as bi-level
+
+=item *
+
+otherwise - image is written as paletted.
+
+=back
If you are creating images for faxing you can set the I<class>
parameter set to C<fax>. By default the image is written in fine
mode, but this can be overridden by setting the I<fax_fine> parameter
to zero. Since a fax image is bi-level, Imager uses a threshold to
decide if a given pixel is black or white, based on a single channel.
-For greyscale images channel 0 is used, for color images channel 1
+For gray scale images channel 0 is used, for color images channel 1
(green) is used. If you want more control over the conversion you can
use $img->to_paletted() to product a bi-level image. This way you can
use dithering:
=over
-=item class
+=item *
-If set to 'fax' the image will be written as a bi-level fax image.
+C<class> - If set to 'fax' the image will be written as a bi-level fax
+image.
-=item fax_fine
+=item *
-By default when I<class> is set to 'fax' the image is written in fine
-mode, you can select normal mode by setting I<fax_fine> to 0.
+C<fax_fine> - By default when C<class> is set to 'fax' the image is
+written in fine mode, you can select normal mode by setting
+C<fax_fine> to 0.
=back
Imager should be able to read any TIFF image you supply. Paletted
TIFF images are read as paletted Imager images, since paletted TIFF
images have 16-bits/sample (48-bits/color) this means the bottom
-8-bits are lost, but this shouldn't be a big deal. Currently all
-direct color images are read at 8-bits/sample.
+8-bits are lost, but this shouldn't be a big deal.
TIFF supports the spatial resolution tags. See the
C<tiff_resolutionunit> tag for some extra options.
=item *
-16-bit grey, RGB, or CMYK image, including a possible alpha channel as
+8-bit/sample gray, RGB or CMYK images, including a possible alpha
+channel as an 8-bit/sample image.
+
+=item *
+
+16-bit gray, RGB, or CMYK image, including a possible alpha channel as
a 16-bit/sample image.
=item *
-32-bit grey, RGB image, including a possible alpha channel as a
+32-bit gray, RGB image, including a possible alpha channel as a
double/sample image.
=item *
tiled paletted images are now handled correctly
+=item *
+
+other images are read using C<tifflib>'s RGBA interface as
+8-bit/sample images.
+
=back
The following tags are set in a TIFF image when read, and can be set
=over
-=item tiff_compression
+=item *
-When reading an image this is set to the numeric value of the TIFF
-compression tag.
+C<tiff_compression> - When reading an image this is set to the numeric
+value of the TIFF compression tag.
On writing you can set this to either a numeric compression tag value,
or one of the following values:
sense, eg. C<jpeg> will be ignored for compression if the image is
being written as bilevel.
-Imager attempts to check that your build of libtiff supports the given
-compression, and will fallback to C<packbits> if it isn't enabled.
-eg. older distributions didn't include LZW compression, and JPEG
-compression is only available if libtiff is configured with libjpeg's
-location.
+=for stopwords LZW
+
+Imager attempts to check that your build of C<libtiff> supports the
+given compression, and will fallback to C<packbits> if it isn't
+enabled. eg. older distributions didn't include LZW compression, and
+JPEG compression is only available if C<libtiff> is configured with
+C<libjpeg>'s location.
$im->write(file => 'foo.tif', tiff_compression => 'lzw')
or die $im->errstr;
-=item tiff_jpegquality
+=item *
-If I<tiff_compression> if C<jpeg> then this can be a number from 1 to
-100 giving the JPEG compression quality. High values are better
-quality and larger files.
+C<tags, tiff_jpegquality>C<tiff_jpegquality> - If C<tiff_compression>
+is C<jpeg> then this can be a number from 1 to 100 giving the JPEG
+compression quality. High values are better quality and larger files.
-=item tiff_resolutionunit
+=item *
-The value of the ResolutionUnit tag. This is ignored on writing if
-the i_aspect_only tag is non-zero.
+X<tags, tiff_resolutionunit>C<tiff_resolutionunit> - The value of the
+C<ResolutionUnit> tag. This is ignored on writing if the
+i_aspect_only tag is non-zero.
The C<i_xres> and C<i_yres> tags are expressed in pixels per inch no
matter the value of this tag, they will be converted to/from the value
stored in the TIFF file.
-=item tiff_resolutionunit_name
+=item *
-This is set when reading a TIFF file to the name of the unit given by
+X<tags, tiff_resolutionunit_name>C<tiff_resolutionunit_name> - This is
+set when reading a TIFF file to the name of the unit given by
C<tiff_resolutionunit>. Possible results include C<inch>,
C<centimeter>, C<none> (the C<i_aspect_only> tag is also set reading
these files) or C<unknown>.
-=item tiff_bitspersample
-
-Bits per sample from the image. This value is not used when writing
-an image, it is only set on a read image.
-
-=item tiff_photometric
-
-Value of the PhotometricInterpretation tag from the image. This value
-is not used when writing an image, it is only set on a read image.
-
-=item tiff_documentname
-
-=item tiff_imagedescription
-
-=item tiff_make
-
-=item tiff_model
-
-=item tiff_pagename
+=item *
-=item tiff_software
+X<tags, tiff_bitspersample>C<tiff_bitspersample> - Bits per sample
+from the image. This value is not used when writing an image, it is
+only set on a read image.
-=item tiff_datetime
+=item *
-=item tiff_artist
+X<tags, tiff_photometric>C<tiff_photometric> - Value of the
+C<PhotometricInterpretation> tag from the image. This value is not
+used when writing an image, it is only set on a read image.
-=item tiff_hostcomputer
+=item *
-Various strings describing the image. tiff_datetime must be formatted
-as "YYYY:MM:DD HH:MM:SS". These correspond directly to the mixed case
-names in the TIFF specification. These are set in images read from a
-TIFF and saved when writing a TIFF image.
+C<tiff_documentname>, C<tiff_imagedescription>, C<tiff_make>,
+C<tiff_model>, C<tiff_pagename>, C<tiff_software>, C<tiff_datetime>,
+C<tiff_artist>, C<tiff_hostcomputer> - Various strings describing the
+image. C<tiff_datetime> must be formatted as "YYYY:MM:DD HH:MM:SS".
+These correspond directly to the mixed case names in the TIFF
+specification. These are set in images read from a TIFF and saved
+when writing a TIFF image.
=back
$image->read(file=>"example.tif", page=>1)
or die "Cannot read second page: ",$image->errstr,"\n";
-Note: Imager uses the TIFF*RGBA* family of libtiff functions,
-unfortunately these don't support alpha channels on CMYK images. This
-will result in a full coverage alpha channel on CMYK images with an
-alpha channel, until this is implemented in libtiff (or Imager's TIFF
-implementation changes.)
-
If you read an image with multiple alpha channels, then only the first
alpha channel will be read.
-Currently Imager's TIFF support reads all direct color images as 8-bit
-RGB images, this may change in the future to reading 16-bit/sample
-images.
+When reading a C<TIFF> image with callbacks, the C<seekcb> callback
+parameter is also required.
+
+When writing a C<TIFF> image with callbacks, the C<seekcb> and
+C<readcb> parameters are also required.
-Currently tags that control the output color type and compression are
-ignored when writing, this may change in the future. If you have
-processes that rely upon Imager always producing packbits compressed
-RGB images, you should strip any tags before writing.
+C<TIFF> is a random access file format, it cannot be read from or
+written to unseekable streams such as pipes or sockets.
-=head2 BMP (BitMaP)
+=head2 BMP (Windows Bitmap)
Imager can write 24-bit RGB, and 8, 4 and 1-bit per pixel paletted
Windows BMP files. Currently you cannot write compressed BMP files
Windows BMP files. There is some support for reading 16-bit per pixel
images, but I haven't found any for testing.
-BMP has no support for multi-image files.
+BMP has no support for multiple image files.
BMP files support the spatial resolution tags, but since BMP has no
support for storing only an aspect ratio, if C<i_aspect_only> is set
The type of compression, if any. This can be any of the following
values:
+=for stopwords RLE
+
=over
=item BI_RGB (0)
=back
-=head2 TGA (TarGA)
+=for stopwords Targa
+
+=head2 TGA (Targa)
-When storing targa images rle compression can be activated with the
-'compress' parameter, the 'idstring' parameter can be used to set the
-targa comment field and the 'wierdpack' option can be used to use the
-15 and 16 bit targa formats for rgb and rgba data. The 15 bit format
+When storing Targa images RLE compression can be activated with the
+C<compress> parameter, the C<idstring> parameter can be used to set the
+Targa comment field and the C<wierdpack> option can be used to use the
+15 and 16 bit Targa formats for RGB and RGBA data. The 15 bit format
has 5 of each red, green and blue. The 16 bit format in addition
allows 1 bit of alpha. The most significant bits are used for each
channel.
-
Tags:
=over
=head2 RAW
When reading raw images you need to supply the width and height of the
-image in the xsize and ysize options:
+image in the C<xsize> and C<ysize> options:
$img->read(file=>'foo.raw', xsize=>100, ysize=>100)
or die "Cannot read raw image\n";
If your input file has more channels than you want, or (as is common),
-junk in the fourth channel, you can use the datachannels and
-storechannels options to control the number of channels in your input
+junk in the fourth channel, you can use the C<datachannels> and
+C<storechannels> options to control the number of channels in your input
file and the resulting channels in your image. For example, if your
input image uses 32-bits per pixel with red, green, blue and junk
values for each pixel you could do:
0 - samples are pixel by pixel, so all samples for the first pixel,
then all samples for the second pixel and so on. eg. for a four pixel
-scanline the channels would be laid out as:
+scan line the channels would be laid out as:
012012012012
=item *
-1 - samples are line by line, so channel 0 for the entire scanline is
-followed by channel 1 for the entire scanline and so on. eg. for a
-four pixel scanline the channels would be laid out as:
+1 - samples are line by line, so channel 0 for the entire scan line is
+followed by channel 1 for the entire scan line and so on. eg. for a
+four pixel scan line the channels would be laid out as:
000011112222
=head2 PNG
-There are no PNG specific tags.
+=head3 PNG Image modes
+
+PNG files can be read and written in the following modes:
+
+=over
+
+=item *
+
+bi-level - written as a 1-bit per sample gray scale image
+
+=item *
+
+paletted - Imager gray scale paletted images are written as RGB
+paletted images. PNG palettes can include alpha values for each entry
+and this is honored as an Imager four channel paletted image.
+
+=item *
+
+8 and 16-bit per sample gray scale, optionally with an alpha channel.
+
+=item *
+
+8 and 16-bit per sample RGB, optionally with an alpha channel.
+
+=back
+
+Unlike GIF, there is no automatic conversion to a paletted image,
+since PNG supports direct color.
+
+=head3 PNG Text tags
+
+Text tags are retrieved from and written to PNG C<tEXT> or C<zTXT>
+chunks. The following standard tags from the PNG specification are
+directly supported:
+
+=over
+
+=item *
+
+C<i_comment>X<tags,i_comment> - keyword of "Comment".
+
+=item *
+
+C<png_author>X<tags,PNG,png_author> - keyword "Author".
+
+=item *
+
+C<png_copyright>X<tags,PNG,png_copyright> - keyword "Copyright".
+
+=item *
+
+C<png_creation_time>X<tags,PNG,png_creation_time> - keyword "Creation Time".
+
+=item *
+
+C<png_description>X<tags,PNG,png_description> - keyword "Description".
+
+=item *
+
+C<png_disclaimer>X<tags,PNG,png_disclaimer> - keyword "Disclaimer".
+
+=item *
+
+C<png_software>X<tags,PNG,png_software> - keyword "Software".
+
+=item *
+
+C<png_title>X<tags,PNG,png_title> - keyword "Title".
+
+=item *
+
+C<png_warning>X<tags,PNG,png_warning> - keyword "Warning".
+
+=back
+
+Each of these tags has a corresponding C< I<base-tag-name>_compressed
+>> tag, eg. C<png_comment_compressed>. When reading, if the PNG chunk
+is compressed this tag will be set to 1, but is otherwise unset. When
+writing, Imager will honor the compression tag if set and non-zero,
+otherwise the chunk text will be compressed if the value is longer
+than 1000 characters, as recommended by the C<libpng> documentation.
+
+PNG C<tEXT> or C<zTXT> chunks outside of those above are read into or
+written from Imager tags named like:
+
+=over
+
+=item *
+
+C<< png_textI<N>_key >> - the key for the text chunk. This can be 1
+to 79 characters, may not contain any leading, trailing or consecutive
+spaces, and may contain only Latin-1 characters from 32-126, 161-255.
+
+=item *
+
+C<< png_textI<N>_text >> - the text for the text chunk. This may not
+contain any C<NUL> characters.
+
+=item *
+
+C<< png_textI<N>_compressed >> - whether or not the text chunk is
+compressed. This behaves similarly to the C<<
+I<base-tag-name>_compressed >> tags described above.
+
+=back
+
+Where I<N> starts from 0. When writing both the C<..._key> and
+C<..._text> tags must be present or the write will fail. If the key
+or text do not satisfy the requirements above the write will fail.
+
+=head3 Other PNG metadata tags
+
+=over
+
+=item *
+
+X<tags, png_interlace>C<png_interlace>, C<png_interlace_name> - only
+set when reading, C<png_interlace> is set to the type of interlacing
+used by the file, 0 for one, 1 for Adam7. C<png_interlace_name> is
+set to a keyword describing the interlacing, either C<none> or
+C<adam7>.
+
+=item *
+
+X<tags, png_srgb_intent>C<png_srgb_intent> - the sRGB rendering intent
+for the image. an integer from 0 to 3, per the PNG specification. If
+this chunk is found in the PNG file the C<gAMA> and C<cHRM> are
+ignored and the C<png_gamme> and C<png_chroma_...> tags are not set.
+Similarly when writing if C<png_srgb_intent> is set the C<gAMA> and
+C<cHRM> chunks are not written.
+
+=item *
+
+C<tags, png_gamma>C<png_gamma> - the gamma of the image. This value is
+not currently used by Imager when processing the image, but this may
+change in the future.
+
+=item *
+
+X<tags, png_chroma_...>C<png_chroma_white_x>, C<png_chroma_white_y>,
+C<png_chroma_red_x>, C<png_chroma_red_y>, C<png_chroma_green_x>,
+C<png_chroma_green_y>, C<png_chroma_blue_x>, C<png_chroma_blue_y> -
+the primary chromaticities of the image, defining the color model.
+This is currently not used by Imager when processing the image, but
+this may change in the future.
+
+=item *
+
+C<i_xres>, C<i_yres>, C<i_aspect_only> - processed per
+I<Imager::ImageTypes/CommonTags>.
+
+=item *
+
+X<tags, png_bits>C<png_bits> - the number of bits per sample in the
+representation. Ignored when writing.
+
+=item *
+
+X<tags, png_time>X<png_time> - the creation time of the file formatted
+as C<< I<year>-I<month>-I<day>TI<hour>:I<minute>:I<second> >>. This
+is stored as time data structure in the file, not a string. If you
+set C<png_time> and it cannot be parsed as above, writing the PNG file
+will fail.
+
+=item *
+
+C<i_background> - set from the C<sBKG> when reading an image file.
+
+=back
=head2 ICO (Microsoft Windows Icon) and CUR (Microsoft Windows Cursor)
Icon and Cursor files are very similar, the only differences being a
-number in the header and the storage of the cursor hotspot. I've
+number in the header and the storage of the cursor hot spot. I've
treated them separately so that you're not messing with tags to
distinguish between them.
=item *
-following lines which contain 0 and 1 placeholders for each scanline
+following lines which contain 0 and 1 placeholders for each scan line
of the image, starting from the top of the image.
=back
$im->settag(name => 'cur_hotspoty', value => 16);
$im->write(file => 'box.cur');
+=for stopwords BW
+
=head2 SGI (RGB, BW)
SGI images, often called by the extensions, RGB or BW, can be stored
=item *
-i_comment - the IMAGENAME field from the image. Also written to the
-file when writing.
+i_comment - the C<IMAGENAME> field from the image. Also written to
+the file when writing.
=item *
-sgi_pixmin, sgi_pixmax - the PIXMIN and PIXMAX fields from the image.
-On reading image data is expanded from this range to the full range of
-samples in the image.
+sgi_pixmin, sgi_pixmax - the C<PIXMIN> and C<PIXMAX> fields from the
+image. On reading image data is expanded from this range to the full
+range of samples in the image.
=item *
=over
-=item register_reader
+=item register_reader()
Registers single or multiple image read functions.
},
);
-=item register_writer
+=item register_writer()
Registers single or multiple image write functions.
C<Imager::File::>I<your-format-name>C<Writer> and Imager will attempt
to autoload it.
+=head1 PRELOADING FILE MODULES
+
+=over
+
+=item preload()
+
+This preloads the file support modules included with or that have been
+included with Imager in the past. This is intended for use in forking
+servers such as mod_perl.
+
+If the module is not available no error occurs.
+
+Preserves $@.
+
+ use Imager;
+ Imager->preload;
+
+=back
+
=head1 EXAMPLES
=head2 Producing an image from a CGI script
Once you have an image the basic mechanism is:
+=for stopwords STDOUT
+
=over
=item 1.
If your images are RGB images the default quantization mechanism will
produce a very good result, but can take a long time to execute. You
-could either use the standard webmap:
+could either use the standard web color map:
Imager->write_multi({ file=>$filename,
type=>'gif',
make_colors=>'mediancut' },
@imgs);
-By default all of the images will use the same global colormap, which
+By default all of the images will use the same global color map, which
will produce a smaller image. If your images have significant color
differences, you may want to generate a new palette for each image:
=head1 BUGS
-When saving Gif images the program does NOT try to shave of extra
+When saving GIF images the program does NOT try to shave off extra
colors if it is possible. If you specify 128 colors and there are
-only 2 colors used - it will have a 128 colortable anyway.
+only 2 colors used - it will have a 128 color table anyway.
=head1 SEE ALSO
projects / imager.git / blobdiff