Jon
First, changing the size of an image with the image tag only changes
what is displayed, not what is accessed by the web server, served,
downloaded and cached by the browser.
There is at least one server-side program that can do quite a bit to
dynamically change an image at the server:
real resizing, cropping, overwriting with text (maybe in the client's
language)
Have a look at;
http://www.wizards.dupont.com/cristy/ImageMagick.html
and a rudimentary interactive interface at:
http://www.imagemagick.org/MagickStudio/scripts/MagickStudio.cgi/
Now, say that you have a database of very high-resolution images that
you sell (the user can download). The high resolution is necessary
for off-line rendering/printing, say, millions of colors at
1000x1000 pixels or greater..
A user wants to preview an image at one or more sizes at 72x72 or 300x300 (for
sample printing).
You could download the large file and display at 72x72... a real waste of
bandwidth.
The user would have to buy the image, sight & quality, unseen, because
once it's downloaded...
You could maintain several size/resolution files to try and anticipate what
the user will want... but that is a waste of file/directory slots, probably
wouldn't give the user what he wants, and is ugly to program/keep track of
Or, you could let the user any select the size/resolution/cropping, etc. that
he wants. then server-side transform the image and download.
The user could experiment at several lower resolutions before starting
a large download that wouldn't give him what he wants
Kodak offers some of these capabilities with its picture disk offering.
A file system is not very good at this task:
A limited number of directory entry, then you the programmer must decide to
spill to another directory, create it, etc...
no protection from deleting or changing the image while enforcing that the
corresponding database reference to the file is synchronized
Inability to treat the "database" as an entity, say for backup
more overhead (time and storage) to manipulate individual images
You, the developer, must write garbage-collection programs to resolve
orphans and other inconsistencies between what is in the database and
what's in the file system
You don't get all the good things a database offers.
Your point that
"this database already exists...I call it a file system"
could apply equally to any free-form content such as the "article"
content used to serve dynamic pages.
I don't want to start a flame, but, you could do without a database
altogether and just use the file system.
I have written shopping carts, etc using flat-file text files to
simulate a database (separate tables, indexes, relationships). It's
messy, but it works.
My point was this. I am looking for a better way to manage a large
number of binary files:
a file system alone is not very good
a db front-end to a file system is better.
A db-only solution would be better yet, if it is practical...
... someday, it will be! We have to start somewhere!
There probably is enough justification to develop a "special purpose"
database server to begin to address applications such as:
medical images such as x-rays or MRI-scans
legal records
voice mail
entertainment such as audio/video
business - architect plans/drawings real estate walk-thrus
law enforcement - voice/finger prints
Dick
At 8:37 PM -0400 9/15/00, Jon Hall wrote:
>Err this database already exists...I call it a file system. What would you
>dynamically change in an image? Changing the size of an image is already
>possible via the <img> tag. Changing resolution on the fly would require
>processing power that is way beyond capabilities today, not to mention the
>browsers dont support over 72x72...
>
>jon
>----- Original Message -----
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
