|-height||The size of the image. These might be create-only with new() taking a size which is then fixed. If the image can be resized then set() of -width and/or -height does a resize.|
|-file (string)||Set by new() reading a file, or load() or save() if passed a filename, or just by set() ready for a future load() or save().|
|-file_format (string)||The name of the file format loaded or to save as. This is generally an abbreviation like XPM, set by load() or set() and then used by save().|
|-hotx (integers, or maybe -1 or maybe undef)|
|-hoty||The coordinates of the hotspot position. Images which can be a mouse cursor or similar have a position within the image which is the active pixel for clicking etc. For example XPM and CUR (cursor form of ICO) formats have hotspot positions.|
|-zlib_compression (integer -1 to 9, or undef)||
The compression level for images which use Zlib, such as PNG. 0 is no
compression, 9 is maximum compression. -1 is the Zlib compiled-in default
(usually 6). undef means no setting to use an image library default if
it has one, or the Zlib default.
For reference, PNG format doesnt record the compression level used in the file, so for it -zlib_compression can be set() to control a save(), but generally wont read back from a load().
|-quality_percent (integer 0 to 100, or undef)||The quality level for saving lossy image formats such as JPEG. 0 is the worst quality, 100 is the best. Lower quality should mean a smaller file, but fuzzier. undef means no setting which gives some image library default.|
Sloping lines are drawn by a basic Bressenham line drawing algorithm with integer-only calculations. It ends up drawing the same set of pixels no matter which way around the two endpoints are passed.
Would there be merit in rounding odd numbers of pixels according to which way around line ends are given? Eg. a line 0,0 to 4,1 might do 2 pixels on y=0 and 3 on y=1, but 4,1 to 0,0 the other way around. Or better to have consistency either way around? For reference, in the X11 drawing model the order of the ends doesnt matter for wide lines, but for implementation-dependent thin lines its only encouraged, not required.
Ellipses are drawn with the midpoint ellipse algorithm. This algorithm chooses between points x,y or x,y-1 according to whether the position x,y-0.5 is inside or outside the ellipse (and similarly x+0.5,y on the vertical parts).
The current ellipse code ends up with 0.5s in the values, which means floating point, but is still exact since binary fractions like 0.5 are exactly representable. Some rearrangement and factors of 2 could make it all-integer. The discriminator in the calculation may exceed 53-bits of float mantissa at around 160,000 pixels wide or high. That might affect the accuracy of the pixels chosen, but should be no worse than that.
The current code draws a diamond with the Bressenham line algorithm along each side. Just one line is calculated and is then replicated to the four sides, which ensures the result is symmetric. Rounding in the line (when width not a multiple or height, or vice versa) is biased towards making the pointier vertices narrower. That tends to look better, especially when the diamond is small.
The subclasses like GD or PNGwriter which are front-ends to other drawing libraries dont necessarily use these base algorithms, but can be expected to something sensible within the given line endpoints or ellipse bounding box. (Among the image libraries its surprising how variable the quality of the ellipse drawing is.)
Image::Xpm, Image::Xbm, Image::Pbm, Image::Base::GD, Image::Base::Imager, Image::Base::Imlib2, Image::Base::Magick, Image::Base::PNGwriter, Image::Base::SVG, Image::Base::SVGout, Image::Base::Text, Image::Base::Multiplex
Mark Summerfield. I can be contacted as <email@example.com> - please include the word imagebase in the subject line.
Copyright (c) Mark Summerfield 2000. All Rights Reserved.
Copyright (c) Kevin Ryde 2010, 2011, 2012.
This module may be used/distributed/modified under the LGPL.
|perl v5.20.3||IMAGE::BASE (3)||2012-08-01|