Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!rutgers!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!apple!sun-barr!newstop!texsun!smunews!ti-csl!choctaw!peterson From: peterson@choctaw.csc.ti.com (Bob Peterson) Newsgroups: comp.databases Subject: Re: More on image databases Message-ID: <109445@ti-csl.csc.ti.com> Date: 6 Feb 90 23:32:05 GMT References: <15498@orstcs.CS.ORST.EDU> Sender: news@ti-csl.csc.ti.com Organization: TI Computer Science Center, Dallas Lines: 91 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