aoki@postgres.Berkeley.EDU (Paul M. Aoki) (06/20/89)
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
ingoldsb@ctycal.COM (Terry Ingoldsby) (06/22/89)
In article <14791@pasteur.Berkeley.EDU>, aoki@postgres.Berkeley.EDU (Paul M. Aoki) writes: > 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 .... > *** Would you want to see: > DBMS server on frontend, client on supercomputer? > DBMS and client on supercomputer? > something else? ..... > *** 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? > I'm sure that each application area will have some conflicting needs. Hopefully if we all tell you what we need, you can figure out the commonality across applications. I work with Geographic Information Systems (GIS). My particular GIS involves municipal mapping, so we have streets, parcels (lots of land), fire hydrants, bus stops, and so on. We also know (or find out) things like average age of population in an area. To effectively manipulate our data we need to be able to make queries like: - Show me all the areas where the average age is < 35 that are over 5 km from a swimming pool. - List all parcels of land that are served by bus route 44. You get the idea. If you can satisfy these queries AND get the graphics or text on the screen quickly then the world will beat a path to your door. As for the hardware environment, more and more the GIS world is moving towards workstations networked to central file servers and plot servers. Also bear in mind that many people will be accessing the database concurrently. Easy, eh!? -- Terry Ingoldsby ctycal!ingoldsb@calgary.UUCP Land Information Systems or The City of Calgary ...{alberta,ubc-cs,utai}!calgary!ctycal!ingoldsb