This article summarizes Murphy's experiments comparing the performance of eight different state-of-the-art classiciation methods.

Forget about the paper's title and abstract; it makes several novel and insightful claims with regard to 3D Haralick Textures.

A summary of the review paper Bob Muprhy co-authored "Automated interpretation of subcellular patterns from immunofluorescence microscopy"

This is a summary of the analysis the Murphy group did using the HeLa cell experiment over the last few years.

This is a summary of Bob Murpy's "vision" for the BioImage project. That project is an NSF funded collaboration between UCSB ($6.9M) and CMU ($2.5M). It doesn't appear implemented past the prototype stage; there is certainly nothing available for download. Website: http://www.bioimage.ucsb.edu/ .

This is an introduction to the biology and informatics techniques used in Location Proteomics.

We devise two common categories of events:

• Events that serve as a notification of state change.
• Events that represent invocation requests and completion of asynchronous operations.

In the first category fall those events that an agent posts on the event bus to notify other agents of a change in its internal state. Events in the second category are meant to support asynchronous communication between agents and the rendering engine. The AgentEvent class, which represents the generic event type, is sub-classed in order to create a hierarchy that represents the above categories. Thus, on one hand we have an abstract StateChangeEvent class from which agents derive concrete classes to represent state change notifications. On the other hand, the RequestEvent and ResponseEvent abstract classes are sub-classed by the container in order to define, respectively, how to request the asynchronous execution of a rendering operation and how to represent its completion. We use the Asynchronous Completion Token pattern [POSA2] to dispatch processing actions in response to the completion of asynchronous operations.

Interactions among agents are event-driven. Agents communicate by using a shared event bus provided by the container. The event bus is an event propagation mechanism loosely based on the Publisher-Subscriber [POSA1] pattern and can be regarded as a time-ordered event queue — if event A is posted on the bus before event B, then event A is also delivered before event B. Events are fired by creating an instance of a subclass of AgentEvent and by posting it on the event bus. Agents interested in receiving notification of AgentEvent occurrences implement the AgentEventListener interface and register with the event bus. This interface has a callback method, eventFired, that the event bus invokes in order to dispatch an event. A listener typically registers interest only for some given events — by specifying a list of AgentEvent subclasses when registering with the event bus. The event bus will then take care of event de-multiplexing — an event is eventually dispatched to a listener only if the listener registered for that kind of event.

The container provides a flexible and extensible configuration mechanism. Each agent has its own configuration file which is parsed at start-up by the container. The configuration entries in this file are turned into objects and collected into a map-like object, which is then passed to the agent. This map object also contains pointers to the container’s services. Thus, we can think of this object as a Registry [Fow03]. There is one Registry for each agent, so configuration entries are private to each agent — container’s services are shared among all agents though. The container also has its own configuration file and Registry.

The container maintains a set of predefined bindings that are used to convert a configuration entry into an object — such as a String, Integer, IconFactory, Font, etc. However, agents can specify custom handlers for converting a configuration entry into an object.

This document describes the macro-design of the system, supplies a rationale for that design and link those requirements that deeply affect the architecture (often non-functional requirements, such as performance and extensibility) to the design. The system is analyzed from different perspectives (views), each of which is an abstraction of the system that focuses on a given aspect and suppresses all other details irrelevant to that context.

We provide a:

• Logical view: Overall conceptual design solution that addresses the functional requirements.
• Process view: How the abstractions depicted by the conceptual solution are allocated to processes and threads, logical distribution of processes and their communication and synchronization.
• Implementation view: Organization of the components and files that are used to assemble and release the physical system. The conceptual elements in the logical and process views are connected with their physical realization.
• Deployment view: Hardware topology on which the system executes. This view maps the various elements identified in the logical, process, and implementation views onto the processing nodes. The installation of the parts that make up the system is described here.