curt3028@oce.orst.edu (Curt Vandetta) (02/06/90)
Hello Folks, I've been reading the discussion here about an image database and I'm quite interested in this myself. I'm working for a professor who is doing satellite image processing, and I've put together a database to keep track of his images. I've found that the relational model works very well for keep track of the properties of each image, like which satellite the image was taken from, where the raw data is, which algorithms were used to process the image, etc. But I have not been able to put the images themselves into the database, only the path to the image (this is all being done on a UNIX system so the path is like /img1/1982/...). The problem is that I have a byte stream that is 262.144K (the images are 512 x 512 x 8bits, some day to be 24bits deep) which is much to big for a single column, and a head ache to try to maintain multiple columns (like 512 columns one for each raster line). The idea of compressing the image before I store it brings me to the problem of variable length columns (not every image will compress to the same size) and my still be to large for one column. Plus, I lose the ability (or at least possibility) of doing queries on the image itself. (See below for a further explanation) I'm more than convinced that I will need to migrate to an object oriented model to keep the images in the database themselves, and I'm in the process of coming to speed on the object oriented approach. So please for give me if this next question is obvious, but what I hope to do (someday), is have the database setup in such a way that the end-user can do querys on say, pixel values inside of an image. Before you say "Why would you want to do that!?", let me explain. Each of the images are of piece of the coastline (refered to as tiles) from Washington to California, that's on the Pacific Ocean for those who aren't good at geography :-) and each image measures ocean surface temperature. So what I have are tiles (512 x 512 and 8 bits deep) representing the temperature of the ocean. Now what some Oceanographer is going to want to do with this database is make a query like "Give me all of the tiles e (where e is say the tile that has the San Francisco Bay in it) where the average temperature for the bay is above 55 degrees" Don't let the "average part" confuse the issue here, that was just an example, the query could be on say pixel 10245, so it would "every tile with pixel 10245 greater than 134 (a byte value that represents 55 degrees)". Now before I spend years on the object oriented model, is this kind of thing even possible under the object oriented or even relation model? The type of query requires that each byte value (or pixel value for the graphics people) be maintain and searchable by the database. And all of this doesn't even bring be to issue of viewing each image, but that's a topic for another news group :-) Anyway, what I was hoping to get from this posting was the names of some people who are doing similar work, it would sure be nice to hear how others have approached this problem (or would approach, I certainly don't want to keep others from responding!) Thanks for hearing me out, Curt curt@oce.orst.edu
mao@eden (Mike Olson) (02/06/90)
In article <15498@orstcs.CS.ORST.EDU>, Curt Vandetta (curt3028@oce.orst.edu) writes: > I've been reading the discussion here about an image database > and I'm quite interested in this myself. ... > I'm more than convinced that I will need to migrate to an object > oriented model to keep the images in the database themselves, and > I'm in the process of coming to speed on the object oriented approach. > So please for give me if this next question is obvious, but what I > hope to do (someday), is have the database setup in such a way that > the end-user can do querys on say, pixel values inside of an image. > ... > Now before I spend years on the object oriented model, is this > kind of thing even possible under the object oriented or even > relation model? this is a pretty interesting application; i can't point you at a system that'll do what you want today, but i have some observations. there's no a priori reason that you *can't* do this on a relational system. what you need is abstract data types (ADTs). you write code that "imports" and "exports" the data for the relational system, and you write code that does the sort of searches you need. then you register these functions with the database. it calls your funcs to read and write the data; when you run a query on the data, it calls your functions. there are details i'm glossing over, but this is the basic idea. you can argue that this is an object-oriented approach, if you like, but relational system vendors are moving toward this sort of functionality. the real problem you have is that the values you want to store are enormous. given that a single value for you is 512x512x8 bits, you need to store 262,144 bytes in a single logical write. that means that you need enormous tuples. i suspect that vendors of dedicated oodb systems, as well as relational vendors, will have a problem with this. i'd be interested in hearing what sort of solutions you come up with. mike olson postgres research group uc berkeley mao@postgres.berkeley.edu
jkrueger@dgis.dtic.dla.mil (Jon) (02/07/90)
curt3028@oce.orst.edu (Curt Vandetta) writes: > I'm more than convinced that I will need to migrate to an object > oriented model to keep the images in the database themselves Be less than convinced. You need user-defined data types as first class objects. You don't need inheritance, message passing, cheap instantiation of new objects. > hope to do (someday), is have the database setup in such a way that > the end-user can do querys on say, pixel values inside of an image. > query like "Give me all of the tiles e (where e is say the tile that > has the San Francisco Bay in it) where the average temperature for the > bay is above 55 degrees" select i.name, i.date, i.technican from image i where avg_temperature(i.tile) > fahr_to_kelvin(55) Now the bad news: no existing commercial RDBMS can do this. Some are close, but I won't give plugs: ask your local sales critter. If he says no, kill him. This will encourage right thinking in vendors :-) Also note that first class support includes access methods appropriate to the data type, in this case 2d, else all such queries will be exhaustive table scans and response time will increase linearly with table size. > this was just an example, the query could be on say > pixel 10245, so it would "every tile with pixel 10245 greater than > 134 (a byte value that represents 55 degrees)". Same bad news, but same good news: nothing in the relational model stops you from: select i.name, i.date, i.technican from image i where pixel(i.tile, 10245) > 134 But wouldn't you rather: select i.name, i.date, i.technican from image i where avg_temperature(coastline(i.tile)) > avg_temperature(standard) ??? -- Jon -- Jonathan Krueger jkrueger@dtic.dla.mil uunet!dgis!jkrueger The Philip Morris Companies, Inc: without question the strongest and best argument for an anti-flag-waving amendment.
peterson@choctaw.csc.ti.com (Bob Peterson) (02/07/90)
In article <15498@orstcs.CS.ORST.EDU> curt3028@oce.orst.edu (Curt Vandetta) writes: > > Hello Folks, > > I've been reading the discussion here about an image database > and I'm quite interested in this myself. > ... > But I have not been able to put the images > themselves into the database, only the path to the image (this is all > being done on a UNIX system so the path is like /img1/1982/...). > The problem is that I have a byte stream that is 262.144K (the images > are 512 x 512 x 8bits, some day to be 24bits deep) which is much to > big for a single column, and a head ache to try to maintain multiple > columns (like 512 columns one for each raster line). I'm a member of the Zeitgeist OODB effort at Texas Instruments. A couple of years ago we used our system to do something very similar, i.e., store images and retrieve them for display. In our case the application didn't require querying directly on the images. What we were doing was displaying pictures of a store and allowing the user to navigate and focus by touching sensitive areas of the image, e.g., the aisle to the right, or the item on the shelf below and to the left. We've also stored integrated circuit design objects, some of which are graphs that, when stored, are as large as 4.5 megabytes each! I would claim that the size of your images should not a problem for an OODB, even if your images do go to 512x512 by 24 bits deep. That is, an OODB should be able to take your object instance, which will probably be an image and the accompanying attributes, and store it as a single entry in the OODB. I believe commercially available relational databases can store byte streams ranging from 256 bytes to 2 gigabytes, depending on the vendor. You'll have to ask individual vendors about their limits, i.e., Oracle, Informix, Sybase, Ingres, et al. > > ... > > I'm more than convinced that I will need to migrate to an object > oriented model to keep the images in the database themselves, and > I'm in the process of coming to speed on the object oriented approach. Good idea! You'll want to look at recent OOPSLA and SIGMOD proceedings, and, if you can find it, the Springer-Verlag book containing the papers from the Second International Workshop on Object-Oriented Databases. The actual reference is K. R. Dittrich, ed., _Advances in Object-Oriented Database Systems_. Heidelberg, West Germany: Springer-Verlag, 1988. > So please for give me if this next question is obvious, but what I > hope to do (someday), is have the database setup in such a way that > the end-user can do querys on say, pixel values inside of an image. > ... > Now what some > Oceanographer is going to want to do with this database is make a > query like "Give me all of the tiles e (where e is say the tile that > has the San Francisco Bay in it) where the average temperature for the > bay is above 55 degrees" Sounds like a very reasonable query. An OODB should be able to handle such queries in one way or another. You'll need to explore the detailed abilities of several OODBs to get an idea of what each offers in the way of queries. > Now before I spend years on the object oriented model, is this > kind of thing even possible under the object oriented or even > relation model? The type of query requires that each byte value > (or pixel value for the graphics people) be maintain and searchable > by the database. Yes, such queries are possible. In most systems you'll have to write the code that computes the temperature (or whatever), but once you do the database should be able to give you back the tiles that match your criteria. You are, however, on the leading (bleeding) edge of what can be done, so don't be surprised at confusion and contradiction when you ask what is and is not possible. And also expect to hear a lot of "Real soon now," and "We're a research group, and we have what you want but we can't give out the code." > ... > Curt > curt@oce.orst.edu Bob Bob Peterson Compuserve: 70235,326 Expressway Site, Texas Instruments Internet: peterson@csc.ti.com North Building, P.O. Box 655474, MS238 Landline: (214) 995-6080 2nd Floor, Dallas, Texas, USA 75265 CSC Aisle C3
sakkinen@tukki.jyu.fi (Markku Sakkinen) (02/07/90)
In article <15498@orstcs.CS.ORST.EDU> curt3028@oce.orst.edu (Curt Vandetta) writes: > [..] I'm working for a > professor who is doing satellite image processing, and I've > put together a database to keep track of his images. I've found > that the relational model works very well for keep track of > the properties of each image, [...] > ... > The problem is that I have a byte stream that is 262.144K (the images > are 512 x 512 x 8bits, some day to be 24bits deep) which is much to > big for a single column, and a head ache to try to maintain multiple > columns (like 512 columns one for each raster line). > > The idea of compressing the image before I store it brings me to the > problem of variable length columns [...] > ... > query like "Give me all of the tiles e (where e is say the tile that > has the San Francisco Bay in it) where the average temperature for the > bay is above 55 degrees" Don't let the "average part" confuse the > issue here, that was just an example, the query could be on say > pixel 10245, so it would "every tile with pixel 10245 greater than > 134 (a byte value that represents 55 degrees)". > ... Here comes a surprising comment from someone who firmly believes OO databases to be the way of the (not too distant) future -- The purposes mentioned do _not_ seem to necessarily require an OO approach. There is no great need for data abstraction and encapsulation, which are among the prime concerns of object orientation. Rather, the "everything is equally visible" principle of the relational model would seem to apply quite well - some reservations must perhaps be made if data compression is considered. In consequence, some of the extensions of the relational model might be pretty suitable for your kind of problem, because they can handle arrays. One school is called NF^2 (for non-first normal school): for instance the work at the IBM Heidelberg Scientific Center in Germany (AIM = Advanced Information Management). Then there is Postgres from Berkeley, which I believe was recently announced to be available over the net (anonymous FTP?). > And all of this doesn't even bring be to issue of viewing each image, > but that's a topic for another news group :-) > ... That could be more natural in an OO system, but not impossible to add to an extensible system like Postgres either. Markku Sakkinen Department of Computer Science University of Jyvaskyla (a's with umlauts) Seminaarinkatu 15 SF-40100 Jyvaskyla (umlauts again) Finland SAKKINEN@FINJYU.bitnet (alternative net address)