Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!pasteur!postgres.Berkeley.EDU!aoki
From: aoki@postgres.Berkeley.EDU (Paul M. Aoki)
Newsgroups: comp.graphics
Subject: What does/should a image DBMS look like?
Message-ID: <14791@pasteur.Berkeley.EDU>
Date: 20 Jun 89 04:51:38 GMT
Sender: news@pasteur.Berkeley.EDU
Reply-To: aoki@postgres.Berkeley.EDU (Paul M. Aoki)
Distribution: na
Organization: Postgres Research Group, UC Berkeley
Lines: 67

Image processing folks and SciViGuys:

As someone with a database background but no experience with what 
Real Image Processing people do, I'd like to hear what kind of 
services and interfaces you folks would like from your data managers.

Let's say you could store your binary data in a "real" DBMS --
one that provided transactions, multiuser access, a query language,
a programming language interface, etc., like the commercial relational 
systems do, as well as (say) version control, user-defined functions 
and access methods, and so on.  This would allow queries like, oh,

define 8BIT (name = text, attrs = text[], history = text, image = bytea)

append 8BIT (name = 24BIT.name,
	     attrs = 24BIT.attrs, 
	     history = 24BIT.history << "requantized to 8bit at" << timenow(),
	     image = requantize(24, 8, 24BIT.image))
	where 24BIT.name = "Lenna" or 24BIT.name = "Mandrill"

That is, requantize the two images and place the result in a new 
relation, adding a note to the 8bit image's history that it came 
from a 24bit image.

*** Is this really a desirable thing?  How does this compare to what 
you are using now?

Now, the data you've got is presumably big (meaning "per image" as well 
as "in aggregate").  How would you like to be able to access the data?

Assume the usual (?) sort of I/O-server/Cray/Hyperchannel setup
is possible but not required.

*** Would you want to see:
	DBMS server on frontend, client on supercomputer?
	DBMS and client on supercomputer?
	something else?

Let's say someone was willing to hack the DBMS to present a reasonable 
programming interface to the record data -- whatever you want.

*** Would you want to see:
	DBMS server communicating through (embedded) query language 
		with the application, with the application explicitly 
		negotiating for chunks of data (bytes, pages, ..)
	DBMS server communicating through IPC with the application,
		with the application explicitly negotiating for chunks 
		of data (bytes, pages, ..)
	performing computation in the DBMS server process using 
		user-defined functions (as in the example), with the 
		function controlling I/O in a loose way by a mechanism 
		like (say) the C standard I/O library
	something else?

*** What else would you like to see?

If some of this doesn't make sense to you or doesn't fit your 
world-picture, send me mail and I'll try to clear things up.
As I said, I'm really just trying to get a grip on what kind
of interfaces "big-data" people want to their data managers,
how they would like to set up their systems, etc.  If you have
the gumption to write a huge followup describing what you use
now and what you'd like to see, I'm sure there are others who
would be interested in reading it.

--
Paul M. Aoki		aoki@postgres.Berkeley.EDU		...!ucbvax!aoki