Bisque: Bio-Image Semantic Query User Environment Workshop on Imaging for High Throughput Phenotyping October 1, 2009 Mikhail Kovtun Benfey Lab, Duke University Bisque. October 1, 2009 – p. 1/22
Who is Bisque Work on Bisque begun in 2004 at University of California, Santa Barbara. Bisque is under active development now. Project heads: B. S. Manjunath, professor, Electrical and Computer Engineering Department, director of Center for Bio-Image Informatics A. K. Singh, Professor, Department of Computer Science Core developers: Kristian Kvilekval, researcher, Center for Bio-Image Informatics Dmitry Fedorov, researcher, Center for Bio-Image Informatics Full list of Bisque developers at: http://biodev.ece.ucsb.edu/projects/bisquik/wiki/DeveloperContributers Bisque. October 1, 2009 – p. 2/22
What is “image database”? Server Image store Metadata store Client Various applications that allow biologists to store / search / retrieve / analyze / ... images in the database These applications can be either: “Primary” — created by developers of this image database “Secondary” — created by third-party developers Protocol — how client speaks to server Bisque. October 1, 2009 – p. 3/22
Bisque clients: Web browser Upload image Bisque. October 1, 2009 – p. 4/22
Bisque clients: Web browser View images Annotate images Bisque. October 1, 2009 – p. 5/22
Bisque clients: Web browser Add graphical annotation: Bisque. October 1, 2009 – p. 6/22
Bisque clients: Web browser Search and browse images Bisque. October 1, 2009 – p. 7/22
Bisque clients: Web browser Collect data from multiple image sources Bisque. October 1, 2009 – p. 8/22
Bisque clients: Web browser Perform image analysis Bisque. October 1, 2009 – p. 9/22
Bisque clients: Standalone applications Digital notebook: batch upload and annotations Bisque. October 1, 2009 – p. 10/22
Bisque clients: Standalone applications Digital notebook: graphical annotations Bisque. October 1, 2009 – p. 11/22
Bisque clients: Standalone applications Powerful 2D and 3D viewers Bisque. October 1, 2009 – p. 12/22
Bisque analysis modules Analysis modules, from the point of view of Bisque core, are HTTP servers. Bisque client asks Bisque server to execute an analysis module and supplies required parameters (via HTTP request). Bisque server sends HTTP request to analysis module. Analysis module sends HTTP requests to Bisque server to get images for analysis. Analysis module performs analysis. Analysis module sends HTTP requests to Bisque server to store results of analysis (new metadata, images, other files...). Client can access results of analysis as regular Bisque data. Analysis modules can be integrated into Bisque server, which reduces data transfer overhead. There are libraries for various programming languages that implement communication with Bisque server. Bisque. October 1, 2009 – p. 13/22
Bisque analysis modules (cont.) Important: Analysis modules can retrieve any relevant data from Bisque server—even metadata that are not “known” to Bisque server. Results stored by an analysis module can be anything—even new relations between images and metadata (for example: similarity links between analyzed images). Analysis modules can take graphical annotations as input and can generate results in form of graphical annotations. Bisque. October 1, 2009 – p. 14/22
Bisque server: image store “Image store” is actually “binary data store” – any file can be stored here. But for image files it provides additional functionality: Conversions to other image formats (ome-tiff, gif, png, etc.) Extraction of planes Generating animations Performing geometric transformations Other parts of Bisque and Bisque applications communicate to image store using HTTP protocol. Bisque. October 1, 2009 – p. 15/22
Bisque server: metadata store Bisque uses very simple—but powerful—metadata structure. Metadata store can be thought of as a uniform set of tuples. The most important fields in these tuples are type , name , and value . Tuples are linked by child-to-parent relation. In addition: every tuple is a Bisque object , and every Bisque object has URI. This is sufficient to model arbitrary relational database. Some types of tuples are “known” to Bisque core, and it uses this knowledge to perform its tasks. Example: user/groups data. Other types are just stored—it is up to application to interpret them properly. Example: graphical annotation. Bisque. October 1, 2009 – p. 16/22
Bisque server: metadata store (cont.) Internally, Bisque metadata are stored in SQL database. Bisque was tested to work with: SQLite MySQL PostgreSQL Bisque server heavily optimize database queries—there is no noticeable degradation in performance (which one might expect as consequence of “interpretation”). Bisque. October 1, 2009 – p. 17/22
Bisque client-server protocol All Bisque components communicate one to other using HTTP protocol with metadata encoded as XML content. This is a HUGE advantage of Bisque: Protocol can be easily documented. Developers of third-party applications can learn how to communicate to Bisque quickly. Keeping compatibility between protocol versions is drastically simplified. It is possible to write wrappers for other image databases so that images and metadata can be used from Bisque (currently, a wrapper for OME database is implemented; wrapper for OMERO database is under development). Bisque. October 1, 2009 – p. 18/22
Image-centric vs. Experiment-centric vs. ...-centric User Interface A significant part of user’s interaction with an image database follows the pattern: Search (filter) data Browse though the data obtained on the previous step This is where “...-centricity” appears: What are items which one has to browse through? In this sense, all existing image databases are “image-centric.” However, for a specific type of experiment other ways of browsing information might be much more natural. Rootarray experiments give an example of such need. Bisque. October 1, 2009 – p. 19/22
Image-centric vs. Experiment-centric vs. ...-centric User Interface (cont.) A single rootarray experiment results in hundreds or even thousands of images (64 roots imaged in different resolutions in multiple rounds...) There are a lot of chunks of information that relate to the experiment as a whole (and thus must be associated with each image): Genotypes seeded Environmental conditions Treatment(s) applied Etc. There a lot of links between images and other experiment-related data which should be easy to follow. Etc. Bisque. October 1, 2009 – p. 20/22
Image-centric vs. Experiment-centric vs. ...-centric User Interface (cont.) The need of other than “image-centric” view on image database is now understood by community, and notions like “dataset,” “experiment”, etc. are under development in Bisque. But... Development resources are limited, and developer will start with feature that his closest neighborhood is requesting. There is no guarantee that this is what you need. Bisque is the only system I am aware of that makes it feasible for you to develop a feature that you need. Bisque. October 1, 2009 – p. 21/22
Other Bisque advanced features Version control Bisque employs “write once—read many” paradigm. Each data item has timestamp. Updating data item means creating a new data item with newer timestamp. This is a cornerstone of versioning, and it provides referential integrity. Transaction control For every data object its sources (both data objects and modules used to create this data object) are recorded. This allows system to re-evaluate result objects whenever original data objects or modules were changed. Inherent scalability Bisque. October 1, 2009 – p. 22/22
Recommend
More recommend
