Albeit a bit long-winded. Or in the words of Sir Thomas Moore, in peril of
his life while being prosecuted ostensibly for treason, though in reality,
for opposing the King of England's divorce, attempting to evade the
questions put to him: "I trust I make myself obscure?"

At 05:01 PM 2/25/98 -0500, John Watson wrote:
>    Now, that is an *awesome* answer!
>
>-----Original Message-----
>From: Byron Canfield <barn(at)byronc.com>
>To: boyermr(at)jmu.edu <boyermr(at)jmu.edu>; Susan Pinochet <pinochet(at)polaris.net>
>Cc: hwg-graphics(at)hwg.org <hwg-graphics(at)hwg.org>
>Date: Wednesday, February 25, 1998 3:42 PM
>Subject: Re: Scanning to Vector vs. Bitmap
>
>
>|Mike,
>|
>|Yes, that is correct. Scanners, in the conventional sense (there are
>|exceptions), examine defined units of the surface area of an object
>|(defined by the settings in the scanning software), and interpret the color
>|values (RGB or CMYK) of that specific unit, thereby converting it to a
>|pixel of same color value.
>|
>|The exceptions mentioned above are scanners that now available for 3D
>|scanning that actually examine contours of objects and generate vector
>|information, but no color information is included, so they are not
>|appropriate for designing basic web images.
>|
>|There is software available, quite a bit, actually, for examining a scanned
>|image's pixels and determining the necessary vector information to best
>|create and representation of that image in vector form. They have their
>|strengths and weaknesses, but, in many cases, it's a good starting point.
>|Adobe's product, if I'm not mistaken, is Streamline; CorelDRAW includes
>|CorelTrace (or CorelOCR-TRACE); and their are others.
>|
>|Alternately, you can import the bitmap image into a vector program, placing
>|it on a layer which you then lock, so you don't accidentally move the
>|bitmap after much meticulous tracing. Then manually trace the outlines of
>|the objects you want to be part of your vector image. This has the
>|advantage of creating, potentially, much simpler objects, mathematically,
>|with the fewest control points. You can also, by performing the trace
>|function manually, make visual judgements that are far beyond the
>|capability of any software.
>|
>|And to Susan,
>|
>|If your image is just black and white, or if you think you can manually
>|trace the image if rendered in black and white, ask your copy shop to scan
>|the image as a grayscale TIF at 300 d.p.i. Ask them to examine the size of
>|the file, when saved with LZW compression, and if, at that point, it will
>|not fit on a diskette, have them resample (reduce the pixel dimensions,
>|either by specifying new pixel dimensions or a new d.p.i. value with "real"
>|dimensions--inches, cm, etc.) it down to a size that will fit on a
>|diskette. Be sure to have them check the COMPRESSED file size, so that they
>|don't resample it down farther than necessary.
>|
>|
>|Are you ready? Here we go...
>|
>|For example, an 8" x 12" image that is scanned at 600 d.p.i. measures 4800
>|pixels (8" * 600 d.p.i.) by 7200 pixels (12" * 600 d.p.i.), for a total of
>|34,560,000 pixels.
>|
>|[ p = (h * v) * (r^2) ]       <==that last bit is r "squared"
>|
>|where "p" is the number of pixels in the image
>|"h" is the horizontal measure in inches
>|"v" is the vertical dimension in inches
>|and "r" is the d.p.i. of the image
>|

>|Surface area is: 8" * 12", or 96 square inches
>|Surface area times (d.p.i. squared) equals the number of pixels: 96 square
>|inches * 360,000 = 34,560,000 pixels
>|
>|Without compression, a grayscale TIF file will occupy a number of bytes
>|just slightly more than the number of pixels in the image (on a PC,
>|somewhere around 400 bytes more; Macs typically store some resource
>|information that adds a little more). This is the "overhead" for the file.
>|The size, for this 34,560,000-pixel image, is 34,560,338 bytes (about 33
>|megabytes).
>|
>|When saved WITH compression, the results will vary widely, depending on the
>|content of the image. If the compressed form of this 34,560,000-pixel file
>|is  11,492,452 bytes in size, the compression scheme is able to squeeze the
>|information down, on average, to better about 3 pixels per byte
>|(approximately 3 to 1 ratio). When your image is resampled down in size,
>|you can expect a similar compression ratio to that of the original, so it
>|is possible to figure out how much of a reduction is necessary to get the
>|file down to a size that will fit on a diskette.
>|
>|If anything, you want to err on the side of decreased ratio--assume that
>|the compression ratio will not be quite as good, in otherwords, start
>|working with a desired compressed file size slightly smaller than what will
>|fit on the diskette.
>|
>|
>|With a compression ratio of approximately 3 pixels per byte, assuming you
>|need a 1,048,576-byte file (1 megabyte -- in order to fit in on a diskette;
>|this will allow a little unused space on the diskette, just in case the
>|compression ration isn't quite as good as expected), you need to bring the
>|non-compressed file size down to about 3,145,728 bytes (3 megabytes -- or,
>|approximately that number of pixels minus whatever "overhead"; in this
>|case, I'll lop off 338 bytes for overhead for a pixel count of 3,145,390).
>|
>|So let's work the equation (a long time back), to solve for "r" (d.p.i.). I
>|don't know the appropriate text character to denote "square root," so I'll
>|just use the words:
>|
>|original equation: [ p = (h * v) * (r^2) ]
>|
>|Now solving for "r":  r = square root of (p / (h * v))
>|
>|In other words, the desired pixel count, 3,145,390, divided by the surface
>|area in inches (96 square inches, as determined before):
>|
>|3,145,390 p / 96 si =  32764.47916667 pixels per square inch
>|
>|(not a useful number, we'll round down to 32764)
>|
>|square root of 32765 ppsi is   181.0082871031 d.p.i.
>|
>|(again, not a useful number, so round down to 180. This is the d.p.i. value
>|you would use to resample the file down to fit in on a diskette, for all
>|the above parameters.
>|
>|For this example file, the result of these calculations and using 180 as
>|the resampling value, is an image that is 1440 pixels by 2160 pixels, with
>|a total pixel count of 3,110,400 pixels. This particular file compresses
>|down (based on content) to 1,673,048 bytes--not enough to fit on a
>diskette.
>|
>|But by examining the ratio of compression at this size, we can better
>|approximate the size necessary for the uncompressed version. The ratio of

>|this last version is approximately 1.86 to 1. Let's hedge the bet, and
>|reduce that ratio even further to  1.5 to 1 (you'll still end up with a
>|file that has plenty of resolution).
>|
>|So if you need a file that is no more than 1,048,576 bytes (1 megabyte),
>|multiply by the 1.5, i.e.:
>|
>|1,048,576 * 1.5 = 1,572,864 bytes, uncompressed (pretty close to half the
>|present file size). So we work the equation again, using the new numbers:
>|
>|Desired pixels is file size 1,572,864 - overhead of 338 bytes
>|
>|Now solving for "r":  r = square root of (p / (h * v))
>|
>|1,572,526 p / 96 square inches = 16,380.479 pixels per square inch
>|
>|square root of 16,380 ppsi = 127.9843740462 d.p.i., which we'll round down
>|to 125 d.p.i.
>|
>|Resampling the image (either new one or original) to 125 d.p.i. yields a
>|file with dimensions of 1000 pixels by 1500 pixels, with a total pixel
>|count of 1,500,000, well within the maximum.
>|
>|This file then compresses down, using the LZW compression, to a yield a
>|file size of 927,364 bytes.
>|
>|At 11:05 AM 2/25/98 -0500, Boyer, Michael R wrote:
>|>I'm still not quite sure of your questions... I don't use
>|>Claris Works too much, and the TIFF format even less, but
>|>as to your question about a scanner: If you're going to be
>|>working in the web-design field, getting a scanner is
>|almost a must. Then again, if you're just doing this as a
>|>hobby, the copy center may be fine.... As it is, I believe
>|>that scanners don't create vector graphics. I think they
>|>only create Raster format graphics. Anyone else know this
>|>for sure?
>|>
>|>Mike
>|>On Wed, 25 Feb 1998 09:57:27 -0500 Susan Pinochet
>|>> What should I ask for? If "copy shop" is the problem, what do I need to
>|>> look for to find someone who can do this? Am I going to have to buy a
>|>> scanner?
>|>>
>|>> -- Susan Pinochet <pinochet(at)polaris.net>
>|>>      home < ... coming soon ... >
>|>>    church <http://www.geocities.com/WestHollywood/5876/>
>|>>     pride <http://www.geocities.com/WestHollywood/9209/>
>|>>
>|>>
>|>
>|>--
>|>Boyer, Michael R
>|>boyermr(at)jmu.edu
>|>"One Ring to Rule them all,
>|> One Ring to Find them.
>|> One Ring to bring them all,
>|> and in the Darkness bind them..."
>|>--JRR Tolkien
>|>
>|Barn
>|(Byron Canfield)
>|http://www.byronc.com
>|================================
>|    "Inside every large problem
>|     there is a small problem struggling to get out."
>|          --Hoare's Law of Problem Solving
>|
> 
Barn
(Byron Canfield)
http://www.byronc.com
================================
    "Inside every large problem
     there is a small problem struggling to get out."
          --Hoare's Law of Problem Solving

HWG: hwg-graphics mailing list archives, maintained by Webmasters @ IWA