How to convert JPEG to binary using Java & save into database

[himaloy]

Hi,

i need to know how can i convert a JPEG grey scale image into binary
file using Java and save that file into a database for example MySql...

is it hard to do?

Thnks..

 

[Baby Lion]

write it to an array of byte
then save it to blob of DB
you can search blob in jdk api document
himaloy 写é“：

 

[Manish Pandit]

Hi,

I would recommend storing the files on the file system, and store the
pointers to the files in the database instead of a blob (unless you're
storing thumbnails or files relatively small in size). You can store
something like server/folder/filename in mySQL for every file, which
should give your app enough info to pull the file when need be.

-cheers,
Manish

 

[Simon Brooke]

I would recommend storing the files on the file system, and store the
pointers to the files in the database instead of a blob (unless you're
storing thumbnails or files relatively small in size). You can store
something like server/folder/filename in mySQL for every file, which
should give your app enough info to pull the file when need be.

H'mmmm... this is what I currently do. It's simple and 90% of the time it
works. But if the file in the file system gets moved or deleted, it
breaks. Actually shoving the data into the database has the advantage that
the database looks after referential integrity (i.e., in this case, the
image doesn't get deleted unless the record gets dropped).

 

[Manish Pandit]

But if the file in the file system gets moved or deleted, it
breaks. Actually shoving the data into the database has the advantage that
the database looks after referential integrity (i.e., in this case, the
image doesn't get deleted unless the record gets dropped).

In that case the file system should be controlled - and people/process
should be well aware of the consequences of moving the files around. If
you do want to take the blob route, do ensure to load test the system,
as I am quite sure blob selects will slow down your system
considerably, based on the image size, access frequency and access
mechanism (filtered vs. lookup..).

-cheers,
Manish

 

[steve]

write it to an array of byte
then save it to blob of DB
you can search blob in jdk api document
himaloy 写é“：

lame idea number 1.

 

[steve]

Hi,

I would recommend storing the files on the file system, and store the
pointers to the files in the database instead of a blob (unless you're
storing thumbnails or files relatively small in size). You can store
something like server/folder/filename in mySQL for every file, which
should give your app enough info to pull the file when need be.

-cheers,
Manish

lame idea number 2

 

[steve]

H'mmmm... this is what I currently do. It's simple and 90% of the time it
works. But if the file in the file system gets moved or deleted, it
breaks. Actually shoving the data into the database has the advantage that
the database looks after referential integrity (i.e., in this case, the
image doesn't get deleted unless the record gets dropped).

finally some sense.

 

[steve]

Hi,

i need to know how can i convert a JPEG grey scale image into binary
file using Java and save that file into a database for example MySql...

is it hard to do?

Thnks..

just convert to a grey scale, then stream it out to a blob.

if possible leave it in colour, unless you are absolutely sure you will never
need the original image again.

You can always pre-process between the database & the user.

What I actually do is store the images & a thumb nail, in the record.
(pre-process a thumb nail , make it perhaps no more than 5-10% of the
original image)
then for the user pull the thumbnails over to the user & if the user selects
the picture THEN bring over the full image.

Steve

 

[Matt Humphrey]

just convert to a grey scale, then stream it out to a blob.

The OP appears to already have a gray scale image and wants to know how save
it to a database.

Your prior message called writing the image to a blob a lame idea without
explaining, which does not help the OP or any other readers also looking for
information. I'd like to hear why you think streaming is now so much better
than writing the byte array directly.

Matt Humphrey (e-mail address removed) http://www.iviz.com/

 

[Matt Humphrey]

In that case the file system should be controlled - and people/process
should be well aware of the consequences of moving the files around. If
you do want to take the blob route, do ensure to load test the system,
as I am quite sure blob selects will slow down your system
considerably, based on the image size, access frequency and access
mechanism (filtered vs. lookup..).

I've used the file system approach before and it's nice for getting
something together quickly, but I've run into big trouble when the number of
files is more than small. At about 50,000 files in a single folder the OS
has a hard time finding things. I wouldn't recommend it for applications
that have to scale.

Matt Humphrey (e-mail address removed) http://www.iviz.com/

 

[Simon Brooke]

In that case the file system should be controlled - and people/process
should be well aware of the consequences of moving the files around. If
you do want to take the blob route, do ensure to load test the system,
as I am quite sure blob selects will slow down your system
considerably, based on the image size, access frequency and access
mechanism (filtered vs. lookup..).

Yup, but, case in point, I have an application that does this (images in
file system, reference in database) which has been in use on a fair number
of sites since 2000. When I distribute a new version, the easiest solution
to doing an update is to delete the application directory and drop the new
WAR file in place. However, this doesn't work because I store uploaded
images, etc, in a subdirectory of the upload directory. This may not be
the best thing to do, but it mostly works and I haven't fixed it.

So to update one either needs to copy all the upload subdirectories out of
the application, then stop and drop the application and install the new
WAR, wait for it to unpack, and copy the contents of the upload
directories back (which can be done with Tomcat with no server restart),
or else unpack the new WAR into the old application directory overwriting
its contents, which (a) doesn't work if you are replacing jar files in the
WEB-INF/lib with new ones with different names (which I usually am), and
(b) definitely does require a server restart.

Every time I produce a new release we have this issue come up; if I did
keep the actual image data (and XSL, and other uploaded content) in the
database it wouldn't happen, and sooner or later I'm going to get round to
making that change. I appreciate there may be performance issues, which I
shall probably get around by caching.

 

[himaloy]

thanks everyone for your reply.