Re: About AutoCAD, BMPs and TIFFs (WAS: Bitmap to .wmf conversio n )

[George Mena <George -dot- Mena -at- ESSTECH -dot- COM>]

Eric,

Re opening the scanned image in AutoCAD Release 14, I'm saying this:

1) The bitmap image data that comes up in the new drawing is editable in
AutoCAD Release 14 as vector objects.  This image data can be saved in
the *.dwg format and edited in AutoCAD Release 14.

2) If you scan an image containing the circle overlapping the square,
which also overlaps a triangle, all three objects will be editable in
AutoCAD Release 14.

3) As far as exporting a file with editable, vector-based shapes goes,
*.dxf is probably your best bet out of AutoCAD Release 14.  You'd have
to edit the *.dxf in either Release 14 again or in AutoCAD LT 97.  To
edit in Adobe Illustrator, you'd want to convert the *.dxf to the native
*.ai format for Illustrator.  You could probably do this using either
HiJaak or Graphics File Converter Gold for Windows.  GFC 1.0 and 3.0
supports 65 file formats total; not sure about HiJaak.   CorelDraw's
*.cdr format isn't supported in Graphics File Converter 1.0.

(Note:  I should add this is version 1.0 of the program; the folks at
IMSI Software in San Rafael, CA, who make this program, have a strange
way of developing their programs.  They went from version 1.0 directly
to version 3.0 without stopping at version 2.0 on this particular
program; something I learned when I visited their web site to do some
troubleshooting! As a result, your system should have BOTH versions 1
AND 3 in order to be effective. Makes me glad I hung onto version 1.0!

(Additionally, one of the companies currently goading the Justice
Department to take Autodesk into court is also IMSI Software, along with
some 20 other graphics software companies, on core monopoly charges a la
Microsoft.  The issue:  graphics file conversion: Autodesk doesn't want
to disclose its secrets.  The competition is screaming foul, and for
good reason:  Autodesk is less than honest in its dealings, even though
it does have an excellent software police force.  CEO Carol Bartz is
totally committed to maintaining the monopolistic stranglehold on the
graphics software business just as much as Bill Gates is committed to
keeping Planet Earth addicted to Windows.).

Re the "effective and good conversion:"

AutoCAD Release 14 does in fact give you the effective and good
conversion.  The best way you can see this for yourself is to test drive
AutoCAD Release 14 for yourself.  When I first saw this demonstrated for
me, it was by one of my mechanical engineers at my last permanent job.
After I saw what he did, I wanted to try it out myself.  I scanned one
of our electrical schematics into my system, saved the file to diskette
as a TIFF file and used AutoCAD Release 14 to edit the drawing and save
it in AutoCAD's *.dwg format.  This was back in the summer of 1996.  And
yes, I was able to go to grips on each object.

Re the tools (and forgetting the glassware for the moment):

AutoCAD Release 14 costs $3500.  Now you know why it costs that much:
it does that much.  Ask a mechanical designer who uses AutoCAD Release
14 daily.  Leave AutoCAD LT 97 (at $425, a real bargain) for more basic
sketches and editing dxf-based versions of OrCAD schematic files. :D

Will you suffer data loss?  On basic line art, not usually, basing that
on my firsthand experience.  On scanned-in full-color art of Ren and
Stimpy, I couldn't say.  Didn't scan in Ren and Stimpy, nor did we
import the Ren & Stimpy *.bmp from the Windows *.bmp gallery.  My guess
is that you'd have color data loss, but not necessarily basic line drop.
Ren and Stimpy would probably still have both their arms, feet, legs,
eyes and nose.  I'd guess that any color data loss could easily be
restored with AutoCAD's hatching and shading capabilities.

For more information, go test drive AutoCAD Release 14 or whatever the
current version is.

George

> -----Original Message-----
> From: Eric J. Ray [SMTP:ejray -at- RAYCOMM -dot- COM]
> Sent: Wednesday, September 09, 1998 1:57 PM
> To:   TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
> Subject:      Re: About AutoCAD,             BMPs and TIFFs (WAS:
> Bitmap to .wmf conversion )
>
> 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
>

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=