TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Re: About AutoCAD, BMPs and TIFFs (WAS: Bitmap to .wmf conversion )
Subject:Re: About AutoCAD, BMPs and TIFFs (WAS: Bitmap to .wmf conversion ) From:"Eric J. Ray" <ejray -at- RAYCOMM -dot- COM> Date:Wed, 9 Sep 1998 14:57:26 -0600
George,
Are you really saying that if you open a scanned image
of a circle partially overlapping a triangle which partially
overlaps a square, AutoCad can export a file with
three individually editable, vector-based shapes
(a full circle, full triangle, and full square)? I'd like
to see that in action.
(If that's not what you're saying, I've completely missed
your point, because I see no difference between AutoCad's
save-as-vector and any other program's save-as-vector
options.)
>What the folks at Autodesk did was develop a translation algorithm that
>makes bitmap-to-vector conversion possible.
Bitmap to vector conversion isn't new. Effective and good conversion
would be news.
>image data is binary in nature. Creating a translation algorithm that
>can turn imported bitmaps into vectors had to be possible. It had to be
>possible because export filters already use algorithms to export bitmap
>versions of vector drawings.
Well, that's like saying that creating a tool that can reconstruct
a whole object from a broken one must be possible because
tools already exist that can break objects. (We have some
glassware that could benefit from that one.)
Seriously, the problem that you get into
with conversions from vector graphics is the data loss.
Actually converting from bitmap to vector isn't significant--
recovering the objects from the vector graphic is the problem
and the attraction of conversions.
>The patterns and colors mentioned in the post are based on the raw
>binary data required to generate the image in the first place. Without
>the raw binary data being used by a processor via the machine language
>routines, a video card doesn't know how to draw the image to the
>monitor. Without knowing how to draw the image on the monitor screen,
>the data is never transferred over the address/data lines between the
>CPU and the video chip. And data I/O transfer is something that MUST
>happen, regardless of whether you're writing a chapter or working up a
>block diagram in the graphics editor du jour. :D
>
>Hope this helps. :D
Not much, actually. If you look at a bitmap image (displayed on
a screen, if you will), you see merely colors at specific addresses.
Blue dot, red dot, yellow dot. That's what you see and what is
drawn. That the actual image is a blue line with a shorter
red line and an even shorter yellow line superimposed isn't information
that makes it to the "raw binary data", let alone the monitor.
That's the information contained in an original vector drawing,
which is the same information lost in conversion to bitmap format
(through scanning or save-as), and the main issue with conversions.
Eric
*********************************************************
* Eric J. Ray, ejray -at- raycomm -dot- com, http://www.raycomm.com/
* TECHWR-L Listowner, co-author _Mastering HTML 4.0_
* _HTML 4 for Dummies Quick Reference_, and others.
* Looking for new consulting projects--please query if interested.