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

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