Live Picture Foundation library: provides features that are not specific to FITS or FlashPix. Examples are memory management, file i/o, generic pixel buffers, and mathematical operations.
Imaging modules: These have no knowledge of FITS, but require some features from the Foundation classes.
FITS rendering and File handling modules
FITS editing modules
· Rule: Only a module which rests directly upon another module may access it. (See black arrows.)
· A generic messaging mechanism acts as a bridge between the Application Model and the User Interface. (See red arrow).
Obelix Client will manipulate FlashPix files at two distinct levels:
· Directly — for image browsing needs — via the FlashPix SDK
· Indirectly, through the FITS RIP.
This is the high level API of choice for direct manipulation of FlashPix files. Obelix will use this API for all non-FITS related operations (such as viewing thumbnails of files, etc.). As a general principle, always use the highest level API which performs the desired task.
The FITS RIP can use any image which follows the RIImage protocol. FlashPix and IVUE are two examples of formats that follow this protocol.
This is the implementation of the RIImage protocol which is specific to FlashPix.
These APIs will be developed as part of the Obelix project. These features generally exist in some form within the Live Picture 2.6 , and must be extracted from the application and made available in library form.
These modules exist today. Those interfaces necessary to develop Obelix type applications will be documented as part of the Obelix project.
FITS, by definition, consumes images. FITS understands images as objects which follow the RIImage protocol, for which LPI has a FlashPix implementation.
Both FITS and RIImage rely on low level services provided by the Foundation Library.
 This messaging mechanism is provided to solve a specific problem. Pragmatic considerations such as performance and native platform “look and feel” cause us to choose a platform-specific UI framework. Given this necessity, we attempt as a consequence to enlarge the application model (or AM, which is portable), at the expense of the UI (which is tied to the platform). Without this messaging mechanism, something is still missing: If the AM makes no calls to the UI whatsoever, it forces the AM to be divided into many tiny functions, which must still be glued together by non-portable UI components. The generic message approach allows higher level code, including “interactive glue” to be defined in the AM itself. The AM, by broadcasting messages about its actions to unknown “listeners” (in this case, the UI), allows the UI to synchronize with and respond to application model events. In this way, the AM can grow to include very high level functions including a degree of interaction with no investment in the specification, protocol, or implementation of the UI.