[comp.databases] database containing gray-scale graphic images

ccy@po.CWRU.Edu (Cheung C. Yue) (12/20/90)

I wonder if anyone knows of database programs which will handle
both text and graphics.  I have seen ads in PC Magazine on such
programs (e.g. used for storing personnel data), but would like
to know of people's first-hand experience with such programs. 
We have both Mac's and IBM's at our site, so information on programs 
for either of those platforms will be appreciated.
-- 
C. Cho Yue                                  ccy%po.cwru.edu@cunyvm.bitnet
Dept of Medicine                            ccy@po.cwru.edu
CWRU at MetroHealth Medical Center
3395 Scranton Rd., Cleveland, OH 44109

kenn@intrbas.uucp (Kenneth G. Goutal) (12/20/90)

InterBase is a relational dbms that runs on SCO Unix and SCO Xenix
and can handle graphics perfectly well, in fields of a type called a 'blob'.
From a programming standpoint, a blob looks a lot like a Unix file --
an unstructured stream of an arbitrary number of raw bytes.
Once a record has been selected, the field can be read with getb()
calls much as one might read a Unix file with getc() calls.
One can also read large chunks of a blob called 'segments',
just for efficiency's sake.  Finally, there is a function called 
blob_dump() that dumps the field into a real Unix file,
for those cases where that turns out to be useful.
A parallel set of functions are available for writing the field
when storing a new record into the relation or modifying an existing one.

We also have a notion called 'blob filters', which are functions you
can define and make part of the access method code and are invoked
whenever it's appropriate to convert from one kind of a blob to another,
e.g. in this case perhaps converting some internal representation of
gray scale to different formats for different kinds of display hardware
and/or software.

Sorry, no Mac implementation at this time.

-- Kenn Goutal
   Technical Support

Interbase Software Corporation
209 Burlington Road
Bedford  MA  01730
617.275.3222
...!linus!intrbas!kenn
...!uunet!intrbas!kenn

jamesr@cortex.med.jhu.edu (Jim Rosenberg) (12/20/90)

In article <117@intrbas.UUCP>, kenn@intrbas.uucp (Kenneth G. Goutal) writes:
> InterBase is a relational dbms that runs on SCO Unix and SCO Xenix
> and can handle graphics perfectly well, in fields of a type called a 'blob'.

Will Interbase run on a DEC workstation network (3100's running off of
a 5400 server) running Ultrix ?  Are there other RDBMS's that handle
gray-scale images that will run on such a network ?  How well do
Interbase and any other RDBMS's with "blobs" handle multi-vendor networks,
and networks that combine PC's and Unix workstations ?

> Once a record has been selected, the field can be read with getb()
> can also read large chunks of a blob called 'segments'... for efficiency
> blob_dump()... dumps the field into a real Unix file,
> A parallel set of functions are available for writing the field

How is the speed on retrieving and storing images in these RDBMS's ?  
Are there ANY limits on the size of the "blob."  Is there a clear 
relationship between performance and the size of the blob (aside from 
system throughput constraints) ?  Does the inclusion of "blobs" affect 
the performance of the RDBMS in handling queries / updates of "traditional"
domains such as "name" or "age" ?  Can calls for "blobs" be embedded in "C"
programs ? How do these RDBMS's compare with "non-blob" RDBMS's in general 
(query languages, 4GL's, form makers and report writers) ?

We are a medical imaging research lab with approx. 2500 image series on 
approx. 1000 subjects.  An "image series" consist of between 10 and 60
individual images, all in a file between 3Mb and 10Mb.  I am currrently 
designing a RDB for all the information we have on these subjects 
(test scores, demographics, etc.).  I am interested in the possibility 
of using a RDBMS to manage access to the medical images as well; this 
would require embedding queries for the images into "C" and "X Windows" 
programs we use for analysis.  Speed of access is the critical factor in
determining the feasibility of using an RDBMS:  our users need those images
in (very few) seconds.

> We also have a notion called 'blob filters'... functions you... define...
> whenever it's appropriate to convert from one kind of a blob to another...
> perhaps converting some internal representation of gray scale to
> different formats for different... hardware and/or software.

This sounds great !  Is there this sort of support in other "blob handling"
RDBMS's ?

Thanks in advance for all the information.  Response to this news group
or by email (jamesr@cortex.med.jhu.edu) is fine.  If there is a lot of 
interest and I recieve a number of email responses, I will summarize to
the net.

James Rosenberg (jamesr@cortex.med.jhu.edu)
Systems Manager
Div. Psych. Neuro-Imaging
Johns Hopkins Medical Institutes

dberg@informix.com (David I. Berg) (12/21/90)

In article <1990Dec19.181537.10103@usenet.ins.cwru.edu> ccy@po.CWRU.Edu (Cheung C. Yue) writes:
>
>I wonder if anyone knows of database programs which will handle
>both text and graphics.
>We have both Mac's and IBM's at our site, so information on programs 
>for either of those platforms will be appreciated.

Informix databases can store graphic images in the form of Binary Large
OBjectS (BLOBS). To the database user, they appear as columns in
a table. They are actually stored in "blobspaces" on disk. The blob-
spaces are managed by the DB engine. They can be retreived to a file
and processed by any software designed to do so, such as our graphics
software product Wingz. Wingz runs on the Mac, under Windows, Open
View, and soon OSF/MOTIF. Using our client/server architecture
product Datalink, Wingz can interact with any Informix datbase on any
platform via TCP/IP. 
  ___                   ___
  /  ) __      . __/    /_ ) _       __  Informix Software, Inc.
_/__/ (_(_ (/ / (_(_  _/__> (-' -/~ (_/  5299 DTC Boulevard, Suite 740
dberg@cougar.informix.com           _/   Englewood, CO 80111     (303) 850-0210

kenn@intrbas.uucp (Kenneth G. Goutal) (12/22/90)

In article <1094@cortex.med.jhu.edu> (Jim Rosenberg) writes:

>Will Interbase run on a DEC workstation network (3100's running off of
>a 5400 server) running Ultrix ?  

I will have to check to make sure about the 5400,
but I know we have it running on 3100's here.
And yes, they all talk to each other.
An application on node A can bring up a db on node B and another on node C
and perform inquiries involving the two of them and display the results
on node A.

>How is the speed on retrieving and storing images in these RDBMS's ?  

That, unfortunately, is rather hard to say a priori.
Performance always depends on so many factors that we can measure them
all in a 'laboratory environment' and make sensible predictions.
Your best bet is to do some benchmarks in your own environment.

>Are there ANY limits on the size of the "blob."  

The limit in Interbase is the size of a longword.
We may actually use only 31 bits, but you get the idea.

>Is there a clear 
>relationship between performance and the size of the blob (aside from 
>system throughput constraints) ?  

I'll have to pass on this one for now.

>Does the inclusion of "blobs" affect 
>the performance of the RDBMS in handling queries / updates of "traditional"
>domains such as "name" or "age" ?  

Depends.  If I retrieve only the traditional fields from records containing
blobs, then only those fields are passed across the network.
If the retrieval is not constrained by doing a string search on the
contents of the blob (unlikely in your case), then there it is probable
that the access method won't have to drag the blobs in off disk at all;
the blob fields are still not sent to the user's program unless asked for.
Naturally, if you *do* ask for the blob fields as well as the traditional
fields, there is just that much more data to be passed back and forth.

>Can calls for "blobs" be embedded in "C" programs ? 

Certainly!

How do these RDBMS's compare with "non-blob" RDBMS's in general 
>(query languages, 4GL's, form makers and report writers) ?

Interbase supports both SQL and our proprietary query language GDML.
Our blob support in SQL is done in such a way as not to require extensions
to the SQL syntax.  We have an interactive query interface called QLI;
blobs are handled in QLI essentially to the extent that there is a blob
filter that can convert the blob to ASCII for printing.  QLI has a
report writer built into it.  Interbase includes a forms package called
PYXIS that can be used both from QLI and from applications coded in your
favourite 3GL.  Forms support blobs to the extent that they are text;
I'd have to check to see if blob filters are automatically invoked.

>We are a medical imaging research lab with approx. 2500 image series on 
>approx. 1000 subjects.  An "image series" consist of between 10 and 60
>individual images, all in a file between 3Mb and 10Mb.  

I.e. your images currently occupy a total of 
something like 7500Mb to 25000Mb ?

>would require embedding queries for the images into "C" and "X Windows" 

We have customers who have developed applications that use DECwindows,
writing in C.

>Speed of access is the critical factor in
>determining the feasibility of using an RDBMS:  our users need those images
>in (very few) seconds.

Again, I would strongly recommend working out some sort of benchmark
that will give you an accurate representation of expected performance
based on a model of your application.

-- Kenn Goutal
   Technical Support

Interbase Software Corporation
209 Burlington Road			...!linus!intrbas!kenn
Bedford  MA  01730			...!uunet!intrbas!kenn
617.275.3222