You really should learn how to search via GoogleGroups as it is an
invaluable tool for solving computer/software related issue.. Your issue
pops up in the NG's at least once a day for the past several years.
From: Stephen Lebans - view profile
Date: Wed, Feb 15 2006 1:16 am
Email: "Stephen Lebans"
<
[email protected]>
Groups: comp.databases.ms-access
Not yet ratedRating:
show options
Reply | Reply to Author | Forward | Print | Individual Message | Show
original | Report Abuse | Find messages by this author
Why did I bother to write such a detailed response? I'm building a graphic
FAQ as I'm getting tired of answering this same question over and over and
over...<grin>
You must have an application on your computer that can function as OLE
Server for the particular Images types you are embedding in the table. When
a Package object is created, the application that is currently registered to
handle this file extension(jpg, gif whatever) cannot function as an OLE
Server for this image type. Instead, the entire file, plus a small Access
and OLE Header is prepended to a copy of the actual file. When you Activate
this object, by double clicking on it, Access basically performs an
Application.FollowHyperLink call. This launches whatever application is
registered for this file extension and passes it the unwrapped copy of the
original embedded file. I have simplified the process a bit but it is an
accurate statement of what is happening behind the scenes.
So you need to find an application on your computer that can function as an
OLE Server for the desired Image types and is currently registered on your
system to display these specific image types. Viable OLE Server apps include
MS Paint(Bmp, Gif), MS Photo Editor(everything except Tif), Paint Shop
Pro(everything), PhotoShop(everything I think) and so on and so on. A simple
method to associate a specific application with a specific Image type is to:
1) Open a folder containing the Images you want to insert.
2) Right click on a file while holding down the SHift key.
3) From the popup menu select "Open With".
4) Scroll down the Open With Dialog window until you find MS Photo
Editor and select it.
5) Check the Always use this program to open this file type CheckBox
control.
6) Click OK.
Repeat the steps once for each different type of Image file you want to
embedd in your table.
*********************************************
What are the specific Image types you want to embed? What Paint or Drawing
applications do you have available on your system?
To achieve the smallest record sizes, and allow for distribution to other
computers, I would recommend converting every image to BMP and ensure MS
Paint owns the registration for BMP files before they are inserted. Why do I
suggest converting to BMP format? Glad you asked.<grin>
The actual format of the Image data the application inserts into the OLE is
completely and utterly up to the OLE Server app. No other application,
including Access, will process this data. You would think a smart OLE Server
would simply insert say, the original compressed JPEG as is, in order to
save space. After all, the JPG is compressed on disk, why not store it that
way? Well, in all of the time I have spent working with embedded objects, I
have NEVER come across an instance when the application has done anything
but store a fully uncompressed Bitmap in the OLE field. The majority of apps
store the uncompressed Bitmap data as RGB triplets. Not quite a packed DIB
but close.
The OLE bloating issue is further exacerbated by the OLE specification that
a Presentation stream must be included as part of the OLE object. This
Presentation structured storage Stream is comprised of a full size
uncompressed Bitmap of the original file. It is generally wrapped up within
a CF_METAFILEPICT structure. This Presentation Bitmap is required so that
Access can display the image when:
1) The OLE object has not been activated yet so the OLE Server is not active
in Memory and does not have to render the Image
2) The original application that functioned as the OLE Server is not
available on the current system
Let's look at a specific example. In this case we will use a 24bit 800 * 400
Jpeg Image that compresses to 50KB.
Uncompressed Bitmap(RGB triplets, 3 bytes per pixel - 24 Bits)
800 * 3 bytes per pixel = 2400 bytes per row
2400 bytes x 400 rows = 960,000 bytes = 960K
So a single instance of the uncompressed Image = 960KB
The Presentation Bitmap = another 960KB
-----------------------------------------------------------
So now we have a grand total of 1,920,000KB of Image data that is inserted
into the OLE object field for an original 50KB Jpeg file. There is
additional overhead as well for the other OLE structured storage streams
that comprise the embedded OLE object, plus the private Access header and
the Access OLE header data. But this other data amounts to only a few KB or
less in total.
The absolute worse case can result in another complete uncompressed Bitmap
being stored as well. As the older METAFILEPICT structure is used, some
modern applications prefer initially to work with the newer Enhanced
Metafile(EMF) format and then convert this to a METAFILEPICT. Unfortunately,
there is a bug/feature whereby the GDI API that performs this conversion
process actually embedds a full copy of the original EMF as a Metafile
Comment record within the ouput METAFILEPICT. Why did I bother to mention
this if I'm not sure? I'm sure that I have seen this on at least one
occasion but have been unable to find the original OLE object field data in
question.
Now there are some ways around the OLE bloat issue. The best you can do is
ensure only a single instance of the uncompressed Bitmap is stored.
If you use MS Paint to embed a BMP image, only a single copy of the
uncompressed Image is stored. You still have full Activate/Double Click
functionality so the user can edit the Image in place with MS Paint.
If you only need to display the Image but not allow the user to
Activate/Double Click to edit then you can embed the Image as one of the
STATIC object types. Again, only a single copy of the uncompressed BMP is
stored. You don't much control over this process though as it is up the
application inserted the image.
I always meant to write a simply OLE Server(really an OLE Handler) that
would store the compressed Image and create a low resolution, 8 bit color
Bitmap for the Presentation stream. I have given up on these plans as
Microsoft has announced that the OLE technology is now baked and basically
put into maintentance mode( I read this in the VISTA section on MSDN I
believe). The new version of Access will finally be able to store compressed
Images directly with no bloating.
To that end I have created an OLE Object extraction tool. The next addition
to this project will allow for the extraction of the embedded images and the
automatic conversion and reinsertion of the image into the new Access 12
field type that will house the compressed Image data.
http://www.lebans.com/oletodisk.htm
NEW - Feb 06/2006 ExtractInventoryOLE.zip A2K or higher ONLY! This
version saves the entire contents of a table containing OLE Objects to disk.
Does NOT require the original application that served as the OLE server to
insert the object. Supports all MS Office documents, PDF, All images
inserted by MS Photo Editor, MS Paint, and Paint Shop Pro. Also supports
extraction of PACKAGE class including original Filename. Contains function
to produce a full Inventory of the OLE field including LINKED path and
Filenames. Uses Structured Storage API's to read the actual contents of the
field. Version BETA 1.56
--
HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
