Export OLE embedded images to file

[Geert Janssens]

Hi,

I have an access 2000 database containing images embedded in an OLE field.
Since the database is growing, I would like to get the images out, and
store them in files instead.

I found a database called ExportOLEtoJpegVer15 on Stephen Lebans' website,
which effectively can export the pictures.

However, the exported result is not so great: the exported images are tiny,
and rough, while the originals are good resolution and clear.

Here's a link to an example export file, and the original:
Original:
http://users.telenet.be/a206457/AH-0011Borg.tif
Exported version:
http://users.telenet.be/a206457/AH-0011B.JPG

The original was retrieved from the database as follows:
- Open a form displaying the image
- Select the image control (single click!, otherwise the image editor opens)
- Copy to clipboard
- Paste in the windows explorer. This creates a scrap book file
- Open the scrapbook file (opens with Imaging in W2K)
- Save a copy (as tif, which is the original format).

I could do this for a few pictures, but the databases contains a few
thousands...

Is there a way I could programmatically extract the images, and keep size
and quality ? Either by changing Stephen's nice database, or by reproducing
my steps programmatically ?

Thank you

Geert Janssens

 

[Stephen Lebans]

My MDB should yield the exact same results as your manual process as I
simply automate the Clipboard process you describe.
Can you sen me an MDB with a couple of the Images in question?

What application, OLE server, was used to insert the Images?
--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.

 

[Geert Janssens]

My MDB should yield the exact same results as your manual process as I
simply automate the Clipboard process you describe.
Can you sen me an MDB with a couple of the Images in question?

I have put a stripped down version with 49 image online:
http://users.telenet.be/a206457/TestImageDB.mdb (+/-9mb)

The db has only one table, with a key, name and image field.

What application, OLE server, was used to insert the Images?

Most of them were inserted directly with Kodak Image Scan Control (which I
presume uses twain to connect to the scanner's manipulation tool).

The code I wrote for this is quite short:

Private Sub BStartScan_Click()
On Error GoTo Err_StartScan_Click

Me.BImgScan.Image = Application.GetOption("Default Database Directory") & "\ItemSchets.tif"

Me.BImgScan.StartScan

Me.FSchets.Class = "Photoshop.Image.5"
Me.FSchets.OLETypeAllowed = acOLEEmbedded
Me.FSchets.SourceDoc = Me.BImgScan.Image
Me.FSchets.Action = acOLECreateEmbed

Exit_StartScan_Click:
Exit Sub

Err_StartScan_Click:
MsgBox Err.Description
Resume Exit_StartScan_Click

End Sub

Thanks,

Geert Janssens

 

[Stephen Lebans]

I'm unable to connect to the URL as posted. Can you check the spelling.
The primary URL is fine:
http://users.telenet.be/a206457/
--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.

 

[Geert Janssens]

Sorry,

I mixed up the name.

It should be:
http://users.telenet.be/a206457/ImageTestDB.mdb

Geert

 

[Geert Janssens]

Stephen,

Any luck with my image database yet ?

Thank you,
Geert

 

[Stephen Lebans]

I spent a couple of hours over the weekend on the issue. The problem seems
to be the application used as the OLE server, which in your case is the
Microsoft Imaging Document app.

The size of the Image displayed in the bound OLE frame control on the Access
form is not the same size when you manually cut and paste the Image into
another app. Also the color rendition is not accurate. Other MS Office
applications do not have any trouble with the pasted Image but non Microsoft
apps suffer the same problem that my Access solution does.

I need to spend several hours debugging this issue. The issue is complicated
by the fact that both my solution and MS Office store a Metafile on the
Clipboard. I think the issue is that I use the newer Enhanced Metafile while
MS Office continues to use the older Metafile format. It makes it difficult
to debug as you have to look at each Metafile record individually.

Honestly, I probably will not get a chance to spend several continuous hours
on this until later in the week. Email me directly if you have not heard
back from me by Saturday.
My Email is:
(e-mail address removed)
--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.

 

[Stephen Lebans]

I just heard from the developer today! He should be starting the mods
required by the end of this week. Great news!

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.

 

[Geert Janssens]

I just heard from the developer today! He should be starting the mods
required by the end of this week. Great news!

That's good news indeed!
Thanks,

Geert

 

[Stephen Lebans]

Sorry Geert, I mistakenly posted to this thread. That message relates to
another issue I am working on which uses a third party DLL to allow Access
users to convert Reports to PDF's without having to use a Printer Driver.
The only developer fixing your issue is me!<grin>

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.

 

[Geert Janssens]

Sorry Geert, I mistakenly posted to this thread. That message relates to
another issue I am working on which uses a third party DLL to allow Access
users to convert Reports to PDF's without having to use a Printer Driver.
The only developer fixing your issue is me!<grin>

Hmm,

I already found your reply was a bit out of context, but it sounded like
good news anyway...

I'm still glad you are willing to look into the issue later on. I'll wait
for some other good news from you.

Geert

 

[Stephen Lebans]

Geert I have spent another hour on this issue tonight and still have not
found a solution. I will have one last and prolongued look at it this
weekend.

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.

 

[Stephen Lebans]

Geert the issue seems to be directly related to the use of the Microsoft
Imaging Document app application as the OLE server. I am sorry but I don't
see a solution to your issue.


--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.

 

[Geert Janssens]

Geert the issue seems to be directly related to the use of the Microsoft
Imaging Document app application as the OLE server. I am sorry but I don't
see a solution to your issue.

Stephen, thank you for spending all this time.

I'm sorry to hear the bad news. Isn't there a way to tell Access to use
another OLE server, or is that too simplistic ?

If not, I'll have to look for other options.

For one, I would like to change the OLE server to use for future images
into the database, such that the problem doesn't get larger than it
already is. What OLE server would you suggest I use, and how do I go about
this ?

Secondly:
(quoted from an earlier mail):
The size of the Image displayed in the bound OLE frame control on the Access
form is not the same size when you manually cut and paste the Image into
another app. Also the color rendition is not accurate. Other MS Office
applications do not have any trouble with the pasted Image but non Microsoft
apps suffer the same problem that my Access solution does.

You mention that the size differs in the bound OLE frame and when cut and
pasted.
It is so that each image as it arrives in my database looks rough.
In order to fix this, I double click it, which gives me access to the
Microsoft Imaging's menus, where I select the image to be best fit. This
scales the image such that it fits within the OLE control in Ms Access.
Leaving the OLE field then displays a better image. The images are always
printed at this size also, and so this works ok in access. Would it be
better for the export if this manual scaling didn't happen, you think ?
Could this be the cause of the trouble we have here ?

All hints, suggestions, or even wild ideas are welcome here.



Geert