Images are stored in RAW format, not in JPEG

[Yair Sageev]

Greetings,

I am storing JPEG images in my database. The problem is that the JPEG
compression is seemingly not preserved when the images are stored, because
the size of the database balloons in size to several hundred megabytes. Is
there any way to get access to store images in original format? These are
about 600k sized JPEGs.

Thanks

 

[Roger Carlson]

The usual solution is to NOT store the picture in a field. This can quickly
bloat your database. The best solution is to store the picture on the hard
drive and simply store the path and file name to the file in the database.
Then you can programmatically load the picture into a form (or report) into
an unbound Image Control.

On my website (see sig below) is a small sample database called
"Picture.mdb" which illustrates how this is done.

 

[Armen Stein]

Greetings,

I am storing JPEG images in my database. The problem is that the JPEG
compression is seemingly not preserved when the images are stored, because
the size of the database balloons in size to several hundred megabytes. Is
there any way to get access to store images in original format? These are
about 600k sized JPEGs.

Thanks

Hi Yair,

Storing images inside a database will cause database bloating issues, as
you are seeing.

Instead, store the windows path to each image in the record. If you
don't want to store the entire path, just store the image name and
concatenate it onto the folder path from a configuration table.

If you want to display the images in your application, you can set the
image control to display the image from an external path.

Hope this helps,

 

[Tony Toews]

I am storing JPEG images in my database. The problem is that the JPEG
compression is seemingly not preserved when the images are stored, because
the size of the database balloons in size to several hundred megabytes. Is
there any way to get access to store images in original format? These are
about 600k sized JPEGs.

Actually what really happens is Access stores a .bmp version of the
..jpg file and other stuff.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[Exponent]

Yes, you can store the raw binary data directly in the field and avoid the overhead and loss of compression
and possibly metadata (eg EXIF).

One way to do this is with VBA - use GetChunk & AppendChunk to store and extract the images. To display
them it is necessary to extract the image to a temporary file, then use an Image control as for an 'external
file' approach. Larry Linson's sample contains an illustration of this approach - see the links page on
our site in the sig below.

Another approach is to use a 3rd party control designed for this purpose. We provide one such control,
DBPix, which can bind directly to a binary/BLOB field (eg OLE Object) and provides most or all of the functionality
required without needing any code. Additional features include asynchronous decoding, EXIF viewing, zoom,
pan and alignment control, resampling/thumbnailing, rotation (including lossless jpeg rotation) and more.
As well as overcoming the bloat problem and providing additional capabilities, several possible problems
with OLE Embedding/OLE Servers or Graphics filters and the Access Image Control are avoided. For more
info see the url in the sig below.

 

[Yair Sageev]

Thanks.

But... why should this cause bloating issues? Why the heck doesn't it store
the image in jpeg format? I would prefer not to have external links because
the database might be moved from machine to machine. I don't understand why
10 600k JPEGS bloat the database to 150 megabytes. That makes no sense
whatsoever.

Having a bad hair day over here....

 

[Exponent]

It's not that Access can't store the image in jpeg format; it can. The cause of the overhead is the use
of OLE Embedding/Linking for storage. If the image is stored as raw-binary (BLOB) data there is little
or no overhead compared to the filesystem, and compression/quality and metadata are preserved.

My other reply contains references to pure-code and component-based implementations of raw-binary (BLOB)
image storage (Larry Linson's sample and our DBPix Image Control).

--
_______________________________________________________
http://www.ammara.com/
Image Handling Components, Samples, Solutions and Info
DBPix 2.0 - lossless jpeg rotation, EXIF, asynchronous

Thanks.

But... why should this cause bloating issues? Why the heck doesn't it store
the image in jpeg format? I would prefer not to have external links because
the database might be moved from machine to machine. I don't understand why
10 600k JPEGS bloat the database to 150 megabytes. That makes no sense
whatsoever.

Having a bad hair day over here....

 

[Dirk Goldgar]

Thanks.

But... why should this cause bloating issues? Why the heck doesn't
it store the image in jpeg format? I would prefer not to have
external links because the database might be moved from machine to
machine. I don't understand why 10 600k JPEGS bloat the database to
150 megabytes. That makes no sense whatsoever.

I can only guess as to why Access doesn't store the image in its
original format; or rather, as I understand it, it stores the image in
its original format *and also* in a device-independent bitmap format.
My guess is that it does that so that it can count on always being able
to display the image no matter what graphics filters/viewers a user may
have on his PC. However, it is a royal pain.

Although moving the image files along with the database doesn't seem
like such a chore to me, if you want to avoid that and store the images
inside the database as JPEGs only (no bitmaps), you can use the
technique demonstrated by Larry Linson here:

http://accdevel.tripod.com/imaging.htm

You would be interested in his third technique, storing the image as
BLOB. Stephen Lebans may also have demonstrated such a technique on his
web site,

www.lebans.com

 

[John Nurick]

I can only guess as to why Access doesn't store the image in its
original format; or rather, as I understand it, it stores the image in
its original format *and also* in a device-independent bitmap format.
My guess is that it does that so that it can count on always being able
to display the image no matter what graphics filters/viewers a user may
have on his PC. However, it is a royal pain.

AIUI that's why it does it - in the same way that Word (say) stores
images of embedded Excel worksheets as well as the actual worksheet
data, so the document can still be read and printed even if Excel is no
available.

 

[Yair Sageev]

Thanks alot for the help guys -- I'll check out the BLOB solution.

 

[Tony Toews]

I can only guess as to why Access doesn't store the image in its
original format; or rather, as I understand it, it stores the image in
its original format *and also* in a device-independent bitmap format.
My guess is that it does that so that it can count on always being able
to display the image no matter what graphics filters/viewers a user may
have on his PC. However, it is a royal pain.

Ah, that would be a good reason. I always figured it was because
decoding jpg files is CPU intensive and kinda slow on 386s. Whereas
bmp files are very fast displaying.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm