Image Question

* "Stan Sainte-Rose" <st**@cyber972.com> scripsit:

What is the better way to save image into a database ?
Just save the path into a field or save the image itself ?
I have 20 000 images (~ 10/12 Ko per image ) to save.

I would store them in the database.

;-)

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

Nov 20 '05 #3

Hi Stan,

I can't see any particular advantage to storing the images in the database
can you? I can think of a number of key reasons not to.

Tom

"Stan Sainte-Rose" <st**@cyber972.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

Hi,
What is the better way to save image into a database ?
Just save the path into a field or save the image itself ?
I have 20 000 images (~ 10/12 Ko per image ) to save.

Stan

Nov 20 '05 #4

Terry Williams

It guess, it would depend on the type of application.

For a web application, I think it would be best to store a image path to
a database, but actually store the image in a directory, and not bloat
your database.

For a desktop c/s application, I think it would best to store the image
in a database, then having to access a shared resource to access the
image.

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

Nov 20 '05 #5

Stan,

IMHO, here's some of the pros and cons of storing the image data in the
database as opposed to just a link the file:

Pro's
--------
1) Synchronization is easier if you store the data in the database because:
a) If you delete the image record, you don't have to worry about deleting
the file
b) If the file is moved, links in the database may be broken as a result
c) If you move the database (e.g. because you're changing the server), you
don't have to worry about moving the files too and maintaining all the links

2) You don't have to worry about duplicate file names for the image files

3) If your database is located on a network server, but the images are
scattered on client machines then maintaining links will be a nightmare.
Having the images as part of the database would be an advantage.

Con's
-------
If you corrupt your database, all images are lost, not just one or two (but
if you don't keep backups then well...)

If you use a database that stores the database as one file (e.g. Access),
then this one file may become pretty big, so copying it and backing it up
will be a bit more hassle because you may have to split it.
I would tend to go for storing the data in the database, not only because of
the benefits above, but because its easier to program as you don't have to
worry about all the file IO and directory permissions etc.

Hope this helps,

Trev.

"Stan Sainte-Rose" <st**@cyber972.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

Hi,
What is the better way to save image into a database ?
Just save the path into a field or save the image itself ?
I have 20 000 images (~ 10/12 Ko per image ) to save.

Stan

Nov 20 '05 #6

Trev,

I'm happy to see that someone posted a thought process rather than just an
"opinion" but consider that we don't know anything about the images like how
often they may change, what they are used for, etc. To conclude something
with as little information as has been posted isn't typically a good idea...

Synchronization for instance... if you delete the record you have
effectively erased the image. Are we certain destroying the image is the
goal? Where is the original, if we're lucky in yet another folder on the
hard drive, if we're unlucky it's gone.

If images are duplicated (the "no image available" image for instance) then
you have stored (possibly) hundreds of copies of that image. Will the
system eventually have to support multiple formats? Do you want to store
..jpeg, .gif and .png in three separate columns?

Would you suggest the same thing if the guy was storing 20,000 video files?
What size of file would stop at and what if there was a combination of
20,000 images and 10,000 very large video files?

And as for "you don't have to worry about the file i/o" again we don't
really know if that is the entire purpose of the database of images right?
How do they get uploaded and are they available for download?

Tom
"Trev Hunter" <hu*********@hotmail.com> wrote...

Stan,

IMHO, here's some of the pros and cons of storing the image data in the
database as opposed to just a link the file:

Pro's
--------
1) Synchronization is easier if you store the data in the database because: a) If you delete the image record, you don't have to worry about deleting
the file
b) If the file is moved, links in the database may be broken as a result
c) If you move the database (e.g. because you're changing the server), you
don't have to worry about moving the files too and maintaining all the links
2) You don't have to worry about duplicate file names for the image files

3) If your database is located on a network server, but the images are
scattered on client machines then maintaining links will be a nightmare.
Having the images as part of the database would be an advantage.

Con's
-------
If you corrupt your database, all images are lost, not just one or two (but if you don't keep backups then well...)

If you use a database that stores the database as one file (e.g. Access),
then this one file may become pretty big, so copying it and backing it up
will be a bit more hassle because you may have to split it.
I would tend to go for storing the data in the database, not only because of the benefits above, but because its easier to program as you don't have to
worry about all the file IO and directory permissions etc.

Hope this helps,

Trev.

"Stan Sainte-Rose" <st**@cyber972.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
Hi,
What is the better way to save image into a database ?
Just save the path into a field or save the image itself ?
I have 20 000 images (~ 10/12 Ko per image ) to save.

Stan

Nov 20 '05 #7

* "Tom Leylan" <ge*@iamtiredofspam.com> scripsit:

I can't see any particular advantage to storing the images in the database
can you? I can think of a number of key reasons not to.

Easier deployment may be a reason for storing everything in the
database. No "dangling" filenames/paths may be another reason.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

Nov 20 '05 #8

> I'm happy to see that someone posted a

thought process rather than just an
"opinion"
Cheers, but some of the first words in my post were "IMHO" ;)

but consider that we don't know
anything about the images like how
often they may change, what they
are used for, etc. To conclude something
with as little information as has
been posted isn't typically a good idea...

I admit, I was wrong to make so many assumptions about what the final
product will be doing and how it will do it. I based my assumptions on an
app that I recently wrote that stores documents of all types in a central
database. I was wrong to assume that the OP's application was similar
without more information. I did happen to notice your first post made the
opposite assumption that there isn't any advantage to storing the images in
the database though...
If ya have the time, let me explain my design (and hence my recommendations
based on these assumptions):

1) The Application will be used to store documents in a central location
(this can apply to a web server, email application, windows application
etc). This will involve users selecting a document from their local machine
and "uploading" it to the server.

2) When the user wants to view the file, they query the server. At this
point, if there is no record in the database, the user can't get the file,
so effectively there is no file anymore (even if there is a orphan file
somewhere on the server that had its record deleted).

3) If a user deletes a file from the server, it is deleted from the server,
not the location that they originally uploaded it from.
To respond to your comments:
Synchronization for instance...
if you delete the record you have
effectively erased the image. Are we
certain destroying the image is the goal?
See point (3) and again, sorry for the assumption.
If images are duplicated (the
"no image available" image for
instance) then you have stored
(possibly) hundreds of copies of that image.
I would expect a bit of common sense on the part of the database schema and
application design to handle these situations. To handle no image available,
store Null and have a default image elsewhere. To handle multiple copies of
the same image, implement the schema with a join table and implement the UI
so that the user gets prompted if a similar image exists (based on other
data about the image).
Do you want to store
.jpeg, .gif and .png in
three separate columns?
Again, a little bit of design intelligence would do here.

Would you suggest the same thing if the
guy was storing 20,000 video files?
Probably not. They *did* state their requirements on this point in the
original post though. The reason why I wouldn't recommend it is because of
one of the con's mentioned in my first post (the part about maintaining a
large single file for backups etc.) would far outweigh the benefits of
storing in the database.
again we don't really know if that is
the entire purpose of the database of
images right? How do they get uploaded
and are they available for download?
Again, my bad for making the assumptions.

To conclude something
with as little information as
has been posted isn't typically a good idea...
Point taken and I'll be more careful in the future. I hope you can do the
same before posting responses like your original one:
I can't see any particular
advantage to storing the
images in the database
can you? I can think of
a number of key reasons not to.

Thanks for the discussion. Hopefully I'll learn not to make assumptions like
this in the future.

Trev.

"Tom Leylan" <ge*@iamtiredofspam.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl... Trev,

I'm happy to see that someone posted a thought process rather than just an
"opinion" but consider that we don't know anything about the images like how often they may change, what they are used for, etc. To conclude something
with as little information as has been posted isn't typically a good idea...
Synchronization for instance... if you delete the record you have
effectively erased the image. Are we certain destroying the image is the
goal? Where is the original, if we're lucky in yet another folder on the
hard drive, if we're unlucky it's gone.

If images are duplicated (the "no image available" image for instance) then you have stored (possibly) hundreds of copies of that image. Will the
system eventually have to support multiple formats? Do you want to store
.jpeg, .gif and .png in three separate columns?

Would you suggest the same thing if the guy was storing 20,000 video files? What size of file would stop at and what if there was a combination of
20,000 images and 10,000 very large video files?

And as for "you don't have to worry about the file i/o" again we don't
really know if that is the entire purpose of the database of images right?
How do they get uploaded and are they available for download?

Tom

Nov 20 '05 #9

It might but that would depend upon "deployment" and it wasn't mentioned.
Nor was the database.

If a solution is faster, easier and more reliable it seems like a good
reason to use it but I'm not certain we know that putting 10,000 images in a
database is any of those things.
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:uH**************@TK2MSFTNGP10.phx.gbl...

* "Tom Leylan" <ge*@iamtiredofspam.com> scripsit:
I can't see any particular advantage to storing the images in the database can you? I can think of a number of key reasons not to.

Easier deployment may be a reason for storing everything in the
database. No "dangling" filenames/paths may be another reason.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

Nov 20 '05 #10

"Trev Hunter" <hu*********@hotmail.com> wrote...

Cheers, but some of the first words in my post were "IMHO" ;)
Clearly most replies are opinions but it is nice when people post the
rational behind. Situations are different and therefore perhaps the
conclusion.
I admit, I was wrong to make so many assumptions about what the final
product will be doing and how it will do it. I based my assumptions on an
app that I recently wrote that stores documents of all types in a central
database. I was wrong to assume that the OP's application was similar
without more information. I did happen to notice your first post made the
opposite assumption that there isn't any advantage to storing the images in the database though...
It is great that you have experience with it. I was going to suggest to the
OP that he seek out people doing this type of thing (whatever it is he is
doing) so that he didn't just get responses based upon people taking 15
seconds out to reply. I'll admit that believe he will be at least "as well
off" by keeping the images outside but I intended to ask him what he thought
the advantages might be for storing them in the database. I can't think of
many... that doesn't mean that we can't post "it will be easier" but is that
in fact a "fact"?

Perhaps... how does he get 10,000 images into the database attached to the
proper records?
1) The Application will be used to store documents in a central location
(this can apply to a web server, email application, windows application
etc). This will involve users selecting a document from their local machine and "uploading" it to the server.
I would have guessed from the short description that users wouldn't directly
upload files. So that's interesting.
2) When the user wants to view the file, they query the server. At this
point, if there is no record in the database, the user can't get the file,
so effectively there is no file anymore (even if there is a orphan file
somewhere on the server that had its record deleted).
I don't think I get this. But anyway, I would guess that a user could
select only from records in the database. If it isn't in the database then
it doesn't qualify for downloading and/or viewing. It doesn't matter if the
an image is sitting in folder... I have images sitting in folders on my
webserver, you can't get them :-)
3) If a user deletes a file from the server, it is deleted from the server, not the location that they originally uploaded it from.
Seems reasonable to me.
To respond to your comments:
Synchronization for instance...
if you delete the record you have
effectively erased the image. Are we
certain destroying the image is the goal?
See point (3) and again, sorry for the assumption.

We don't know that user routinely (if ever) keeps the images. Once
submitted they are "safely stored in the image archive" so what's the point?
Are the users working inhouse or subscribers to some service? I don't know
who owns the images.

If images are duplicated (the
"no image available" image for
instance) then you have stored
(possibly) hundreds of copies of that image.

I would expect a bit of common sense on the part of the database schema

and application design to handle these situations. To handle no image available, store Null and have a default image elsewhere. To handle multiple copies of the same image, implement the schema with a join table and implement the UI so that the user gets prompted if a similar image exists (based on other
data about the image).
Seems reasonable.

Do you want to store
.jpeg, .gif and .png in
three separate columns?

Again, a little bit of design intelligence would do here.

Perhaps but maybe I didn't explain it correctly. I can choose (from a
number of websites) to view movie trailers in one of three distinct formats
and often in low or high bandwidth versions. This means they have 6
different copies of the same film stored. If it is an image database such
that people can purchase and download the images it isn't hard to imagine
that a thumbnail would be required. Probably a larger image and possibly
another hi-definition version.

see: http://pro.corbis.com/

for information on image storage see:
http://sunsite.berkeley.edu/Imaging/Databases/

Would you suggest the same thing if the
guy was storing 20,000 video files?

Probably not. They *did* state their requirements on this point in the
original post though. The reason why I wouldn't recommend it is because of
one of the con's mentioned in my first post (the part about maintaining a
large single file for backups etc.) would far outweigh the benefits of
storing in the database.

I agree. That's why I'm doubtful that storing the 10K images directly in
the database is a good idea. To be sure, it might be a great idea I just
(so far) don't think so.

To conclude something
with as little information as
has been posted isn't typically a good idea...

Point taken and I'll be more careful in the future. I hope you can do the
same before posting responses like your original one:

Sorry, I thought yours was the thoughtful response. Again I probably didn't
make myself clear on that. You gave "reasons" and so many times people just
post "opinions" never offering a basis for why they think what they think.

Which computer is best? <Blah Corp.> Oh that's great... why?

I can't see any particular
advantage to storing the
images in the database
can you? I can think of
a number of key reasons not to.

I see now... it was intended to be an invitation for discussion. Rather
than post "I think this... or that" I thought I might find out what the guy
with problem had thought about so far. He could be doing this for a large
corporation with a dedicated server and SQL Server or he could be putting
something together for the "dungeons and dragons" role-playing game he hosts
on a free internet site. I have no idea the kind of money or equipment (or
expertise) he has at his disposal.
Thanks for the discussion. Hopefully I'll learn not to make assumptions like this in the future.

It isn't you Trev... it is the way people post stuff in general. That's one
of the reasons "which computer language is best" type questions generate so
much heat and so little light. Few people ask "what do you want to do with
it" before mentioning the language they know.

Take care,
Tom

Nov 20 '05 #11

Cor

Hi Herfried,

You know I am busy with this.

The trouble I have now.
I cannot convert all formats to and from the database.
I have the idea that I loose information converting it from and to

Can you help me to overcome this or tell me what is wrong or right of above?

Cor

Nov 20 '05 #12

Cor

Hi Stan,

I am busy with this so I cannot give you a complete answer.

I think it is very fine to use for thumbnails.
(Very fast processable)

For real images I am in doubt.

(If you want to know why see for that my question to Herfried)

Cor

Nov 20 '05 #13

Stan Sainte-Rose

Wowww
I never thought my post will get this mass of replies...
I thank you for your opinions.. :)

Stan

Nov 20 '05 #14

Cor,

I've recently implemented a solution to store all types of files in a
database (I've used Access, but the same principals should work for other
databases too). Let me know if I can be of assistance.

Trev.
"Cor" <no*@non.com> wrote in message
news:OO**************@TK2MSFTNGP09.phx.gbl...

Hi Herfried,

You know I am busy with this.

The trouble I have now.
I cannot convert all formats to and from the database.
I have the idea that I loose information converting it from and to

Can you help me to overcome this or tell me what is wrong or right of above?
Cor

Nov 20 '05 #15

> Clearly most replies are opinions but it

is nice when people post the
rational behind.
Agreed. It's always nice to get a bit of an explanation for solutions to
problems.
but I intended to ask him what he thought
the advantages might be for storing them in the database
Again, my bad for not asking the them to be a little more specific about the
requirements before posting my reply.
I can't think of many...
What advantages or disadvantages there may be depend on the requirements,
something that wasn't explained to either of us. I might have been wrong to
give pros and cons without the requirements (or providing my own explanation
for the pros and cons), but "I can't think of many..." is bordering on one
of those 15 second answers you mentioned (see why at *** below)
how does he get 10,000 images into the database attached to the
proper records?
The same way he gets 10,000 records in the database to point to the correct
files (although a bit slower because of the data transfer).
I would have guessed from the short
description that users wouldn't directly
upload files. So that's interesting.
I don't know your experience with applications that do this, but I guess I
was swayed because I recently implemented a solution to upload files to a
central location and chose to go the database route.

I don't think I get this. But anyway, I
would guess that a user could
select only from records in the database.
Yes. The solution I implemented stored the documents on a server. To view a
list of the available documents, the user queries the database (not the file
system) for descriptions of the files. If there isn't any record for the
document, there is no way to get the document (unless you stored outside the
db and could get to the file going "behind the scenes" of my server
application).

I guess the two different types of applications that could be implemented
are as follows (regardless of where the files are stored):

1) Where the database complements the files - i.e. The user has a set of
files and then an auxiliary database designed to provide descriptions of the
files.

2) Where the database controls the files - i.e. The user has a set of files,
but wants to *copy* them to a central location. The database stores
descriptions of the files and provides the only index to the location of the
copied files.
If it isn't in the database then
it doesn't qualify for downloading
and/or viewing. It doesn't matter if the
an image is sitting in folder... I have
images sitting in folders on my
webserver, you can't get them :-)
This depends on the pattern implemented (1 or 2). If pattern (1) is
implemented, then there is no point storing the files in the database and
copying them needlessly. If pattern (2) is implemented, then there are both
advantages and disadvantages to storing within the database. Depending on
the requirements, the disadvantages may outweigh the advantages, or vise
versa. In any case, pattern (2) requires that the files be copied - if they
are stored in the database or on the server's file system doesn't matter to
the user - as far as they are concerned, they copied the file and the only
way to get to it is by querying the database.

Pattern (2) also requires that the database and files be kept in sync all
the time. If you're worried about deleting an image, but loosing the actual
image data, then you shouldn't delete the row from the database - simply
mark a "Deleted" field as true or something.

That's why I'm doubtful that storing
the 10K images directly in
the database is a good idea.
To be sure, it might be a great idea I just
(so far) don't think so.
It depends on the requirements and how you weigh up the pros and cons based
on those requirements.
I see now... it was intended to be an
invitation for discussion. Rather
than post "I think this... or that"
I thought I might find out what the guy
with problem had thought about so far.
*** I see that now, but your post could easily have been taken for one of
those 15 second answers (as I took it by mistake). Maybe a direct question
would have been better...
It isn't you Trev... it is the way people post
stuff in general.
It was partly me... I posted a response based on wide ranging assumptions.
That's another type of posting I'd like to see an end to.

That's one of the reasons
"which computer language is best" type
questions generate so
much heat and so little light.
lol. I never heard anybody put it better. We've all seen too many of those
posts lately (and I've always tried to narrow my answer down to "base your
choice on your requirements").
Thanks again for the discussion.
Take care,

Trev.
"Tom Leylan" <ge*@iamtiredofspam.com> wrote in message
news:eG**************@TK2MSFTNGP11.phx.gbl... "Trev Hunter" <hu*********@hotmail.com> wrote...
Cheers, but some of the first words in my post were "IMHO" ;)
Clearly most replies are opinions but it is nice when people post the
rational behind. Situations are different and therefore perhaps the
conclusion.
I admit, I was wrong to make so many assumptions about what the final
product will be doing and how it will do it. I based my assumptions on an
app that I recently wrote that stores documents of all types in a central database. I was wrong to assume that the OP's application was similar
without more information. I did happen to notice your first post made the opposite assumption that there isn't any advantage to storing the images

in
the database though...

It is great that you have experience with it. I was going to suggest to

the OP that he seek out people doing this type of thing (whatever it is he is
doing) so that he didn't just get responses based upon people taking 15
seconds out to reply. I'll admit that believe he will be at least "as well off" by keeping the images outside but I intended to ask him what he thought the advantages might be for storing them in the database. I can't think of many... that doesn't mean that we can't post "it will be easier" but is that in fact a "fact"?

Perhaps... how does he get 10,000 images into the database attached to the
proper records?
1) The Application will be used to store documents in a central location
(this can apply to a web server, email application, windows application
etc). This will involve users selecting a document from their local machine
and "uploading" it to the server.

I would have guessed from the short description that users wouldn't

directly upload files. So that's interesting.
2) When the user wants to view the file, they query the server. At this
point, if there is no record in the database, the user can't get the file, so effectively there is no file anymore (even if there is a orphan file
somewhere on the server that had its record deleted).
I don't think I get this. But anyway, I would guess that a user could
select only from records in the database. If it isn't in the database

then it doesn't qualify for downloading and/or viewing. It doesn't matter if the an image is sitting in folder... I have images sitting in folders on my
webserver, you can't get them :-)
3) If a user deletes a file from the server, it is deleted from the server,
not the location that they originally uploaded it from.

Seems reasonable to me.
To respond to your comments:
Synchronization for instance...
if you delete the record you have
effectively erased the image. Are we
certain destroying the image is the goal?

See point (3) and again, sorry for the assumption.

We don't know that user routinely (if ever) keeps the images. Once
submitted they are "safely stored in the image archive" so what's the

point? Are the users working inhouse or subscribers to some service? I don't know who owns the images.
If images are duplicated (the
"no image available" image for
instance) then you have stored
(possibly) hundreds of copies of that image.
I would expect a bit of common sense on the part of the database schema

and
application design to handle these situations. To handle no image

available,
store Null and have a default image elsewhere. To handle multiple copies

of
the same image, implement the schema with a join table and implement the

UI
so that the user gets prompted if a similar image exists (based on other
data about the image).

Seems reasonable.
Do you want to store
.jpeg, .gif and .png in
three separate columns?

Again, a little bit of design intelligence would do here.

Perhaps but maybe I didn't explain it correctly. I can choose (from a
number of websites) to view movie trailers in one of three distinct

formats and often in low or high bandwidth versions. This means they have 6
different copies of the same film stored. If it is an image database such
that people can purchase and download the images it isn't hard to imagine
that a thumbnail would be required. Probably a larger image and possibly
another hi-definition version.

see: http://pro.corbis.com/

for information on image storage see:
http://sunsite.berkeley.edu/Imaging/Databases/
Would you suggest the same thing if the
guy was storing 20,000 video files?
Probably not. They *did* state their requirements on this point in the
original post though. The reason why I wouldn't recommend it is because of
one of the con's mentioned in my first post (the part about maintaining a large single file for backups etc.) would far outweigh the benefits of
storing in the database.

I agree. That's why I'm doubtful that storing the 10K images directly in
the database is a good idea. To be sure, it might be a great idea I just
(so far) don't think so.
To conclude something
with as little information as
has been posted isn't typically a good idea...

Point taken and I'll be more careful in the future. I hope you can do the
same before posting responses like your original one:

Sorry, I thought yours was the thoughtful response. Again I probably

didn't make myself clear on that. You gave "reasons" and so many times people just post "opinions" never offering a basis for why they think what they think.

Which computer is best? <Blah Corp.> Oh that's great... why?
I can't see any particular
advantage to storing the
images in the database
can you? I can think of
a number of key reasons not to.

I see now... it was intended to be an invitation for discussion. Rather
than post "I think this... or that" I thought I might find out what the

guy with problem had thought about so far. He could be doing this for a large
corporation with a dedicated server and SQL Server or he could be putting
something together for the "dungeons and dragons" role-playing game he hosts on a free internet site. I have no idea the kind of money or equipment (or expertise) he has at his disposal.
Thanks for the discussion. Hopefully I'll learn not to make assumptions like
this in the future.

It isn't you Trev... it is the way people post stuff in general. That's

one of the reasons "which computer language is best" type questions generate so much heat and so little light. Few people ask "what do you want to do with it" before mentioning the language they know.

Take care,
Tom

Nov 20 '05 #16

Cor

Hi Trev,

I would have been so lucky if Herfried would give an answer on this. :-))

But I am lucky with your answer anyway you understand, but why I did wanted
Herfried to answer was because of another reason. (He gives mostly greath
answers, but when it is about databases I told him he can better skip that a
while untill he real knows it).

My problem is, that I very good know how to get a Jpeg it a database, but I
want to cut those images also in a format that is more properiate for my
needs.

And I also heard Herfried saying that when you translate a gif to a bytearea
that you then lose half of your pixel information. (I believe that about
media Herfried knows it very well) And there is not alone Jpeg and Gif, so I
am in doubt if I gonna do that, so I stopped it a short while untill I see
some better documentation.

(On MSDN it is only in C# as far as I could see and very slight (encoding is
the keyword)).

I know very good how to put and get blobs in a database (Access, SQL
whatever) by the way.

It is the "correct" conversion from real quality images to Bitmaps and back
that botters me.

But a lot of thanks for your offer again, I remember it me when I start
again.

(I started with some greath help from Fergus, he gave me the start and then
I developped from that much further (not the database part, that I did know
already)).

Cor

Nov 20 '05 #17

No problem Cor. I thought it may have been a problem with the BLOBS. I
haven't got much experience with image conversion, so can't be of any use to
you. I would point you in the direction of
microsoft.public.dotnet.framework.drawing though...

Best of luck,

Trev.
"Cor" <no*@non.com> wrote in message
news:Oy**************@tk2msftngp13.phx.gbl...

Hi Trev,

I would have been so lucky if Herfried would give an answer on this. :-))

But I am lucky with your answer anyway you understand, but why I did wanted Herfried to answer was because of another reason. (He gives mostly greath
answers, but when it is about databases I told him he can better skip that a while untill he real knows it).

My problem is, that I very good know how to get a Jpeg it a database, but I want to cut those images also in a format that is more properiate for my
needs.

And I also heard Herfried saying that when you translate a gif to a bytearea that you then lose half of your pixel information. (I believe that about
media Herfried knows it very well) And there is not alone Jpeg and Gif, so I am in doubt if I gonna do that, so I stopped it a short while untill I see
some better documentation.

(On MSDN it is only in C# as far as I could see and very slight (encoding is the keyword)).

I know very good how to put and get blobs in a database (Access, SQL
whatever) by the way.

It is the "correct" conversion from real quality images to Bitmaps and back that botters me.

But a lot of thanks for your offer again, I remember it me when I start
again.

(I started with some greath help from Fergus, he gave me the start and then I developped from that much further (not the database part, that I did know already)).

Cor

Nov 20 '05 #18

* "Tom Leylan" <ge*@iamtiredofspam.com> scripsit:

It might but that would depend upon "deployment" and it wasn't mentioned.
Nor was the database.

If a solution is faster, easier and more reliable it seems like a good
reason to use it but I'm not certain we know that putting 10,000 images in a
database is any of those things.

It depends on the circumstances.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

Nov 20 '05 #19

* "Cor" <no*@non.com> scripsit:

You know I am busy with this.

The trouble I have now.
I cannot convert all formats to and from the database.
I have the idea that I loose information converting it from and to

Can you help me to overcome this or tell me what is wrong or right of above?

Mhm... Why not store the files as BLOBs?

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

Nov 20 '05 #20

Cor

Herfried,

The trouble I have now.
I cannot convert all formats to and from the database.
I have the idea that I loose information converting it from and to

Can you help me to overcome this or tell me what is wrong or right of
above?
Mhm... Why not store the files as BLOBs?

1. The question was, do you have the routine to convert all image formats to
blobs,
2. Do you kow if you loose image information from converting to and from
blobs.

Cor

Nov 20 '05 #21

* "Cor" <no*@non.com> scripsit:

1. The question was, do you have the routine to convert all image formats to
blobs,
Yes. Simply store the whole file.
2. Do you kow if you loose image information from converting to and from
blobs.

You won't loose information when storing the whole image file.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

Nov 20 '05 #22

Cor

Hi Herfried,

Not that it is really important but now you make me curious.
(I told you that I did know very few about imaging, it is something more but
not what I wanted it to be)

I have a gif file

I load that as an image
I stream that to a bytearea (Here I can not loose data I think)
I save that as a blob (that is the part where I am sure to loose no data)
I read that as a blob (no problem as far as I can see it are bytes)
I stream that to an image (I think that here is also no problem)
I save that as a png

And then there is no data lost?

Same question with the difference the last sentence because the previous
sounds to me impossible.

I save that as a gif

Is in the last situation is every bit from the created gif file the same as
the original?

Cor

Nov 20 '05 #23

* "Cor" <no*@non.com> scripsit:

Not that it is really important but now you make me curious.
(I told you that I did know very few about imaging, it is something more but
not what I wanted it to be)

I have a gif file

I load that as an image
I stream that to a bytearea (Here I can not loose data I think)
I save that as a blob (that is the part where I am sure to loose no data)
I read that as a blob (no problem as far as I can see it are bytes)
I stream that to an image (I think that here is also no problem)
I save that as a png
Why do you want to save it as a PNG?
And then there is no data lost?

Same question with the difference the last sentence because the previous
sounds to me impossible.

I save that as a gif
Why? Just save the byte array to a GIF file.
Is in the last situation is every bit from the created gif file the same as
the original?

Yes.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

Nov 20 '05 #24

Cor

Hi Herfried,

Thanks,

Do you have for me managed code sample for this?

Why? Just save the byte array to a GIF file.

Because I never saw that posibility, so maybe I do something to much.

Cor

Nov 20 '05 #25

Cor:

If saving binary data in a blob could result in lost or modified data it
would be virtually useless. I can't imagine a "database" that decided on
your behalf what was and was not "information."

Tom

"Cor" <no*@non.com> wrote in message
news:em*************@TK2MSFTNGP10.phx.gbl...

Herfried,
The trouble I have now.
I cannot convert all formats to and from the database.
I have the idea that I loose information converting it from and to

Can you help me to overcome this or tell me what is wrong or right of
above?

Mhm... Why not store the files as BLOBs?

1. The question was, do you have the routine to convert all image formats

to blobs,
2. Do you kow if you loose image information from converting to and from
blobs.

Cor

Nov 20 '05 #26

* "Cor" <no*@non.com> scripsit:

Do you have for me managed code sample for this?

That's a question for the ASP.NET group. Currently, I don't have a
sample.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

Nov 20 '05 #27

Cor

Hi Herfried,

That's a question for the ASP.NET group. Currently, I don't have a
sample.

Reading a gif file in a byte area?

You asked me why I did not do that, and than I said I did not know how to do
that with managed code.

And no

:-)

So serious, was it late yesterday Herfried?

Cor

Nov 20 '05 #28

Cor

Hi Tom,

If saving binary data in a blob could result in lost or modified data it
would be virtually useless. I can't imagine a "database" that decided on
your behalf what was and was not "information."

No for showing a picture on a form or a thumbnail it can be very effective.
I did not check it, however my idea was that an 32Mb Tiff picture would not
fit easy as a field in a database.

But if you have expieriences with putting that kind of pictures in a
database I would glad hear about those expiriences.

Cor

Nov 20 '05 #29

Cor,

I did mention that I didn't know too much about Image conversion, but here
are a few conditions under which you may loose data:

1) Changing from a "lossless" format to a "lossy" format (e.g. Gif to Jpeg -
Gif stores an exact replication of the image data, but JPEG compression
results in smaller sizes because it discards data that it thinks isn't
important)

2) Changing the color depth of the image (e.g. 24 bit PNG to 8 bit gif - Gif
only stores 256 colors, PNG can store 8 bit or 24 bit (or higher) images.

3) Changing between formats where the destination format doesn't support
transparent colors.

4) Changing between a vector format to a bitmap format (e.g. wmf to gif)

5) Changing the resolution of the image.

6) Changing from a specialized format that stores data other than image data
(e.g. photographers name) or a format that can hold multiple images (e.g.
Icon) to another format that doesn't support these features.
These should be the only types of conditions that you could "loose" data.
You shouldn't be loosing any by storing it in a BLOB (assuming there's no
bugs in your database code ;)

From what I understand from your conversion, changing from GIF to PNG
shouldn't cause you to loose any data (although the PNG compression could
result in fewer bytes in some cases)

A better group for this might be microsoft.public.dotnet.framework.drawing
or a more generic image convcersion group as you problem seems to be with
changing image formats, not the storing of data in BLOBS or other files.
Hope this helps,

Trev.

"Cor" <no*@non.com> wrote in message
news:O1**************@TK2MSFTNGP09.phx.gbl...

Hi Herfried,

Not that it is really important but now you make me curious.
(I told you that I did know very few about imaging, it is something more but not what I wanted it to be)

I have a gif file

I load that as an image
I stream that to a bytearea (Here I can not loose data I think)
I save that as a blob (that is the part where I am sure to loose no data)
I read that as a blob (no problem as far as I can see it are bytes)
I stream that to an image (I think that here is also no problem)
I save that as a png

And then there is no data lost?

Same question with the difference the last sentence because the previous
sounds to me impossible.

I save that as a gif

Is in the last situation is every bit from the created gif file the same as the original?

Cor

Nov 20 '05 #30

* "Cor" <no*@non.com> scripsit:

That's a question for the ASP.NET group. Currently, I don't have a
sample.

Reading a gif file in a byte area?

You asked me why I did not do that, and than I said I did not know how to do
that with managed code.

Sorry, misread your post. Have a look at the 'MemoryStream' class.
You can create a memory stream from a byte array and then use
'Image.FromImage' to construct an image from the data. Alternatively,
you can use the 'BinaryWriter' to write the byte array to disk.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

Nov 20 '05 #31

Cor,

"Lossy compression" that you voluntarily choose to use is one thing...
having the database decide that it will "lose data" by dropping some bytes
from a binary stream is quite another. A blob "must" return whatever you
store in it unchanged. Keep in mind it doesn't know why you are storing the
data, it doesn't know it is an image destined for a web page.

One of the problems you encounter when very large binary fields are stored
is a maintenance issue. Not a big deal if you mostly add images but (as far
as I know) if you update and delete images a lot the database becomes filled
with old versions of the data which have to be purged periodically.

Tom

"Cor" <no*@non.com> wrote in message
news:Op**************@TK2MSFTNGP09.phx.gbl...

Hi Tom,
If saving binary data in a blob could result in lost or modified data it
would be virtually useless. I can't imagine a "database" that decided on your behalf what was and was not "information."
No for showing a picture on a form or a thumbnail it can be very

effective. I did not check it, however my idea was that an 32Mb Tiff picture would not fit easy as a field in a database.

But if you have expieriences with putting that kind of pictures in a
database I would glad hear about those expiriences.

Cor

Nov 20 '05 #32

Cor

Hi Herfried,

Sorry, misread your post. Have a look at the 'MemoryStream' class.
You can create a memory stream from a byte array and then use
'Image.FromImage' to construct an image from the data. Alternatively,
you can use the 'BinaryWriter' to write the byte array to disk.
Here a link with some answers that are given in this newsgroup on that.

http://groups.google.com/groups?hl=e...languages.vb.*

But you told me to do it this way and that I did find very intrestingWhy? Just save the byte array to a GIF file.

I could not make the URL shorter.

:-))))))))

Cor

Nov 20 '05 #33

* "Cor" <no*@non.com> scripsit:

Sorry, misread your post. Have a look at the 'MemoryStream' class.
You can create a memory stream from a byte array and then use
'Image.FromImage' to construct an image from the data. Alternatively,
you can use the 'BinaryWriter' to write the byte array to disk.

Here a link with some answers that are given in this newsgroup on that.

I know you already know the answer to your question!

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

Nov 20 '05 #34

Cor

Hi Trev,

The meaning of this thread is not the information, but the way we give
answers in this newsgroup.

But thanks for the information, because it added something again to mine and
I it makes things I was not sure of more sure because you read the same.
(It interest me, so it is not spoiled information)

And when I next time have a question like this, I take your advice and go
directly to Bob Powell in the drawing group.

And read my last answer to Herfried. Than all comes more clear.

:-)

Cor

I did mention that I didn't know too much about Image conversion, but here
are a few conditions under which you may loose data:

1) Changing from a "lossless" format to a "lossy" format (e.g. Gif to Jpeg - Gif stores an exact replication of the image data, but JPEG compression
results in smaller sizes because it discards data that it thinks isn't
important)

2) Changing the color depth of the image (e.g. 24 bit PNG to 8 bit gif - Gif only stores 256 colors, PNG can store 8 bit or 24 bit (or higher) images.

3) Changing between formats where the destination format doesn't support
transparent colors.

4) Changing between a vector format to a bitmap format (e.g. wmf to gif)

5) Changing the resolution of the image.

6) Changing from a specialized format that stores data other than image data (e.g. photographers name) or a format that can hold multiple images (e.g.
Icon) to another format that doesn't support these features.

These should be the only types of conditions that you could "loose" data.
You shouldn't be loosing any by storing it in a BLOB (assuming there's no
bugs in your database code ;)

From what I understand from your conversion, changing from GIF to PNG
shouldn't cause you to loose any data (although the PNG compression could
result in fewer bytes in some cases)

A better group for this might be microsoft.public.dotnet.framework.drawing
or a more generic image convcersion group as you problem seems to be with
changing image formats, not the storing of data in BLOBS or other files.

Hope this helps,

Trev.

Nov 20 '05 #35