question regarding image processing

**Michael Fesser** · Jun 2 '08, 10:37 AM

Re: question regarding image processing

..oO(DP)

>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&c=News Maker&k=2&a mp;d=1EF4EE1EFB 3A2CD3E55FD7668 143826B10621193 DB58D674"
>id="ctl12_ctlC omp_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.

Simple copy & paste won't work, since the link contains character
references (&), which are required for HTML. Try this one to get the
image:

http://cache2.asset-cache.net/xc/200186170-001.jpg?v=1&c=NewsMaker&k=2&d=1EF4EE1EFB3A2CD3E55FD7668143826B10621193DB58D674

>Any one knows what technique is this?

Just because you see a .jpg in the URL doesn't necessarily mean it is an
image. It can be anything else, in this case it could be a script that
returns an image based on the passed parameters.

Remember: a URL is just a string, nothing more. Things like "directory"
or "file extension" don't have a real meaning there. It's completely up
to server to decide what to do with something like ".jpg" at the end.

Micha

**Captain Paralytic** · Jun 2 '08, 10:37 AM

Re: question regarding image processing

On 20 May, 23:47, DP <ldpha...@gmail .comwrote:

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

I'm not sure what you're after doing here. Hiding the path to an image
is not the same thing as hiding an image. If you hide an image, no one
can see it. If you allow someone to see it (on their browser), they
already have the image on their machine, in which case there is no
point in hiding the "path". I sometimes store images in a database
table, so there is no "path" as such.

If you want people to be able to see your images on their browser but
not to be able to keep a copy of them, forget it. There was a long
discussion about this recently. The bottom line is that the only thing
you can do to stop folks having a useful copy on their machine is to
put a watermark on the pictures.

DP · Jun 2 '08, 10:37 AM

Re: question regarding image processing

Thanks Michael & Captain. I know that Apache httpd.conf can be set to
execute any extension (I just know the fact). I just don't know that
they use what technique to return the image. I have a few assumptions,
but don't know which one is best:

1. the '.jpg' is an executable script, and it reads the image data
from original image file in file system, adds watermark, and outputs.
Or it can read data from watermarked image (watermarked image is
created from upload time). Then what happens if I need to display 50
images in one page? the script only processes one by one.

2. Images (and maybe watermarked images & thumbnails) are stored in
database. The script just returns data. I don't like this approach
because if I have hundreds of thousands of images, database is
probably not a good choice (from some discussions about storing images
in db vs. file system)

NC · Jun 2 '08, 10:37 AM

Re: question regarding image processing

On May 20, 4:47 pm, DP <ldpha...@gmail .comwrote:

>
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&c=NewsM aker&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?

Who knows... Maybe the parameters are just for logging and have no
use in
the actual application. Maybe the server is configure to rewrite
URLs...

I just copy the link, and paste into a new window, I won't see the image.
>
Any one knows what technique is this?

There is no technique. Try replacing "&" with "&":

http://cache2.asset-cache.net/xc/200186170-001.jpg?v=1&c=NewsMaker&k=2&d=1EF4EE1EFB3A2CD3E55FD7668143826B10621193DB58D674

The file is perfectly visible...

Cheers,
NC

**Michael Fesser** · Jun 2 '08, 10:37 AM

Re: question regarding image processing

..oO(DP)

>Thanks Michael & Captain. I know that Apache httpd.conf can be set to
>execute any extension (I just know the fact). I just don't know that
>they use what technique to return the image. I have a few assumptions,
>but don't know which one is best:
>
>1. the '.jpg' is an executable script, and it reads the image data
>from original image file in file system, adds watermark, and outputs.
>Or it can read data from watermarked image (watermarked image is
>created from upload time). Then what happens if I need to display 50
>images in one page? the script only processes one by one.

Each image request is independent from each other and will start another
instance of the script on the server. In theory 50 requests would invoke
the same script 50 times, but in practice this won't happen because of
some default limits each web server has. Usually at most 2 or 4 requests
from the same client to the same host are answered in parallel, all
others are delayed. The same happens with static files as well.

>2. Images (and maybe watermarked images & thumbnails) are stored in
>database. The script just returns data. I don't like this approach
>because if I have hundreds of thousands of images, database is
>probably not a good choice (from some discussions about storing images
>in db vs. file system)

The real issue will be the same as with #1: You have to call a script
for each image. That's the main impact to the overall site performance.
Whether the images are stored on disk or in a DB is more a question of
personal preference, although DB storage may slow things down even more
in such a case (50 script calls, 50 DB connections, 50 data transfers
from the DB to the script).

Micha

**=?ISO-8859-1?Q?=22=C1lvaro_G=2E_Vicario=22?=** · Jun 2 '08, 10:37 AM

Re: question regarding image processing

DP escribió:

1. the '.jpg' is an executable script

Actually, you have no way to find out where the URL points to. With
modules like Apache's mod_rewrite you can make
http://example.com/foo/bar.jpg?a=1&b=1 point to
http://example.com/scripts/do-fancy-stuff.php?x=2 and it'll be
completely invisible to site visitors.

Then what happens if I need to display 50 images in one page? the script only processes one by one.

That's true even with regular JPEG files: one file, one picture. God
bless caching, queueing and multitasking ;-)

2. Images (and maybe watermarked images & thumbnails) are stored in
database. The script just returns data. I don't like this approach
because if I have hundreds of thousands of images, database is
probably not a good choice (from some discussions about storing images
in db vs. file system)

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.

--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://bits.demogracia.com
-- Mi web de humor al baño María: http://www.demogracia.com
--

**Jerry Stuckle** · Jun 2 '08, 10:37 AM

Re: question regarding image processing

Michael Fesser wrote:

.oO(DP)
>

>Thanks Michael & Captain. I know that Apache httpd.conf can be set to
>execute any extension (I just know the fact). I just don't know that
>they use what technique to return the image. I have a few assumptions,
>but don't know which one is best:
>>
>1. the '.jpg' is an executable script, and it reads the image data
>>from original image file in file system, adds watermark, and outputs.
>Or it can read data from watermarked image (watermarked image is
>created from upload time). Then what happens if I need to display 50
>images in one page? the script only processes one by one.

>
Each image request is independent from each other and will start another
instance of the script on the server. In theory 50 requests would invoke
the same script 50 times, but in practice this won't happen because of
some default limits each web server has. Usually at most 2 or 4 requests
from the same client to the same host are answered in parallel, all
others are delayed. The same happens with static files as well.
>

>2. Images (and maybe watermarked images & thumbnails) are stored in
>database. The script just returns data. I don't like this approach
>because if I have hundreds of thousands of images, database is
>probably not a good choice (from some discussions about storing images
>in db vs. file system)

>
The real issue will be the same as with #1: You have to call a script
for each image. That's the main impact to the overall site performance.
Whether the images are stored on disk or in a DB is more a question of
personal preference, although DB storage may slow things down even more
in such a case (50 script calls, 50 DB connections, 50 data transfers
from the DB to the script).
>
Micha

If you have a large number of images, a database is often faster than
the file system. Databases can easily handle 100K images; file systems
not so much.

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

**Jerry Stuckle** · Jun 2 '08, 10:37 AM

Re: question regarding image processing

Álvaro G. Vicario wrote:

DP escribió:

>1. the '.jpg' is an executable script

>
Actually, you have no way to find out where the URL points to. With
modules like Apache's mod_rewrite you can make
http://example.com/foo/bar.jpg?a=1&b=1 point to
http://example.com/scripts/do-fancy-stuff.php?x=2 and it'll be
completely invisible to site visitors.
>
>

>Then what happens if I need to display 50 images in one page? the
>script only processes one by one.

>
That's true even with regular JPEG files: one file, one picture. God
bless caching, queueing and multitasking ;-)
>
>

>2. Images (and maybe watermarked images & thumbnails) are stored in
>database. The script just returns data. I don't like this approach
>because if I have hundreds of thousands of images, database is
>probably not a good choice (from some discussions about storing images
>in db vs. file system)

>
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.

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

**=?ISO-8859-1?Q?=22=C1lvaro_G=2E_Vicario=22?=** · Jun 2 '08, 10:37 AM

Re: question regarding image processing

Jerry Stuckle escribió:

If you have a large number of images, a database is often faster than
the file system. Databases can easily handle 100K images; file systems
not so much.

If you mean "in the same directory", you're absolutely right.

--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://bits.demogracia.com
-- Mi web de humor al baño María: http://www.demogracia.com
--

**Peter H. Coffin** · Jun 2 '08, 10:37 AM

Re: question regarding image processing

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... (:

--
72. If all the heroes are standing together around a strange device and begin
to taunt me, I will pull out a conventional weapon instead of using my
unstoppable superweapon on them.
--Peter Anspach's list of things to do as an Evil Overlord

**Jerry Stuckle** · Jun 2 '08, 10:37 AM

Re: question regarding image processing

Álvaro G. Vicario wrote:

Jerry Stuckle escribió:

>If you have a large number of images, a database is often faster than
>the file system. Databases can easily handle 100K images; file
>systems not so much.

>
If you mean "in the same directory", you're absolutely right.
>
>

But putting them in different directories means having to plan for those
directories in your code - adding more programming overhead (and places
to go wrong). Additionally, if you don't "guess" right the first time,
you then need to go back and redo that code to get additional
directories. Or you have lots of directories with just 1 or 2 files in
each one.

I've been storing binary data in SQL databases since the mid 80's, when
we stored documents on a DB2 mainframe. It works great.

Other advantages - backups are easier - just backup the database. And
if you use a database/engine with referential integrity, you don't have
to worry about images being deleted from the file system and still being
pointed to in the database.

Additionally, you can have things like the image size stored in the
database with the image, so you don't have to go looking for it later.
You can even have a caption for it. And it's all one retrieval - not a
retrieval plus a file system call.

Databases are made for handling data. It doesn't matter if that data is
text or binary; it does both quite well.

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

**Jerry Stuckle** · Jun 2 '08, 10:37 AM

Re: question regarding image processing

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.

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

**The Natural Philosopher** · Jun 2 '08, 10:37 AM

Re: question regarding image processing

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.
>

A database *is* files, Jerry.

**Rik Wasmus** · Jun 2 '08, 10:37 AM

Re: question regarding image processing

On Sat, 24 May 2008 10:34:10 +0200, The Natural Philosopher <a@b.cwrote:

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.
>>

A database *is* files, Jerry.

.... but backing up the files of a database instead of using proper
mechanisms is asking for corruption. It's not the physical presence on a
hard drive that's the problem, it's having to apply 2 different processes.
As a bonus, keeping a database in sync in another location is far easier
(with more mature tools) then syncing files. (Allthough I could not
imagine life without rsync)
--
Rik Wasmus
....spamrun finished

question regarding image processing

question regarding image processing

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment