question regarding image processing

[DP]

Hi,

I'm not sure if this is the right group to ask. I am developing a
small image library and I don't know how to hide the actual path to
the image. So I go to the stock photo library websites to see how they
hide their images. This is what I see from gettyimages.com

<img src="http://cache2.asset-cache.net/xc/200186170-001.jpg?
v=1&amp;c=NewsM aker&amp;k=2&am p;d=1EF4EE1EFB3 A2CD3E55FD76681 43826B10621193D B58D674"
id="ctl12_ctlCo mp_imgThumb" class="thumbHei ght">

Can someone please explain why there are parameters after the ".jpg",
which is not an executable file? I've got the link by right-click and
view image properties. However, if I just copy the link, and paste
into a new window, I won't see the image.

Any one knows what technique is this?

Thank you.
DP.

[Peter H. Coffin]

On Fri, 23 May 2008 12:10:15 -0400, Jerry Stuckle wrote:

Peter H. Coffin wrote:

>On Fri, 23 May 2008 07:40:37 -0400, Jerry Stuckle wrote:

>>Álvaro G. Vicario wrote:
Some guys adore storing binary data in databases but of course that's a
good old discussion. I particularly find no benefits in it (you can't do
searches like "WHERE category_id=20 AND picture PORTRAITS A 'black
cat'") and it add an annoying overhead in all related tasks.
The ability to search is not the only reason to store things in
databases. And if you have hundreds of thousands of images, a database
can be more efficient.

It's a little rough on the incremental backups, though... (:

Only the first time. But it makes backups easier - you don't have to
back up files and database. Just the database.

Which DBMS do incremental backups well? I'm mostly familiar with MySQL
and DB2 and both of those are pretty much "shut things down, back up the
whole thing" every single time, while using filesystem storage for
100000 images would mean backing up 99940 only once, then the handful of
new or changed ones every increment. And it takes quite a different
amount of time on my ancient tape drives to back up 10GB instead of
2-3MB.

--
Better to teach a man to fish than to give him a fish. And if he can't
be bothered to learn to fish and starves to death, that's a good enough
outcome for me.
-- Steve VanDevender

[Jerry Stuckle]

Peter H. Coffin wrote:

On Fri, 23 May 2008 12:10:15 -0400, Jerry Stuckle wrote:

>Peter H. Coffin wrote:

>>On Fri, 23 May 2008 07:40:37 -0400, Jerry Stuckle wrote:
Álvaro G. Vicario wrote:
Some guys adore storing binary data in databases but of course that's a
good old discussion. I particularly find no benefits in it (you can't do
searches like "WHERE category_id=20 AND picture PORTRAITS A 'black
cat'") and it add an annoying overhead in all related tasks.
>
>
The ability to search is not the only reason to store things in
databases. And if you have hundreds of thousands of images, a database
can be more efficient.
It's a little rough on the incremental backups, though... (:

Only the first time. But it makes backups easier - you don't have to
back up files and database. Just the database.

Which DBMS do incremental backups well? I'm mostly familiar with MySQL
and DB2 and both of those are pretty much "shut things down, back up the
whole thing" every single time, while using filesystem storage for
100000 images would mean backing up 99940 only once, then the handful of
new or changed ones every increment. And it takes quite a different
amount of time on my ancient tape drives to back up 10GB instead of
2-3MB.

DB2 actually will do incremental backups based on the binary logs.
MySQL doesn't do that yet - but you can emulate it with a slave.

You probably could do an incremental backup with MySQL based on the
binary logs, but I don't know how hard it would be.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===