CA2203898A1 - System for communication of image information between multiple-protocol imaging devices - Google Patents

Abstract

A medical imaging system for communicating image information between a plurality of different input imaging devices having different input protocols and a plurality of different output imaging devices having different output protocols takes advantage of a reusable software architecture having a plurality of functionally independent components. The individual components can be configured in a communication pipeline to communicate image information between an input imaging device and an output imaging device according to desired protocols. Each component can be interchanged with a differently configured component to facilitate communication of image information according to a different protocol, thereby reconfiguring the pipeline to achieve significant flexibility. Moreover, the software architecture is scalable to produce a plurality of communication pipelines, each of which can be configured according to desired protocols. Thus, the system of the present invention can support a different protocol by either swapping components to reconfigure a single communication pipeline, or by simply selecting an alternative among a plurality of differently configured communication pipelines in the scalable architecture. Because each of the components is isolated and functionally independent, if redesign of a component is necessary, several programmers can be allocated to the effort with little added overhead, saving time and expense. The modularity of the architecture also enables necessary modifications or corrections to be made to a single component with little impact to the overall system.

Description

SYSTEM FOR COMMUNICATION OF IMAGE INFORMATION
BETWEEN MULTIPL~PROTOCOL IMAGING DEVICES
Field of the Invention The present invention relates to im~Ein~ systems, and, more particularly, to t~lS for commu ~ image "~.lllalion between an input imagin~ device and an output im~in~ device in an jmaEjn~ system.
0 Discussion of Related Art An imagin system typically in~1udes an input im~in,~ device that generates image i,lrollllaliol~, and an output im~in~ device that forms a visible representation of an image based on the image il~lll.alion. In a medical imaEjn~ system, for eY~mrlç, the input im~gjng device may include a ~ nostic device, such as a 15 magnetic ~son~nce (MR), computed tomography (CT), conventional radiography (X-ray), or ultrasound device. Alternatively, the input im~inE~ device may include a user interface device, such as a keypad, mouse, or trackball, also capable of g~al;ng met~ic~l image ,nrullllalion. The output im~ing device in a medical im~in~ system typically incl~ldçs a continuous tone digital laser imager. The laser 20 imager exposes an im~E~in~ media in response to the image il~l nlation to form the visible representation.
The image h~llnd~ion generated by the input im~ging device include~ image data conl~ i"~ digital image values representali~/e ofthe image, and im~ging requests specifying operations to be performed by the laser imager. Each of the 2s digital image values CGII ~,sponds to one of a plurality of pixels in the original image, and represenls an optical density associated with the le~le.iLi~e pixel. In response to an im~ging request, the laser imager converts the digital image values to generate laser drive values used to modulate the intensity of a scanning laser. The laser drive values are calculated to produce exposure levels, on the im~ging media, necessary 30 to reproduce the optical densities associated with the pixels in the original image when the media is developed, either by wet chemical processing or dry thermal processing The laser imager may perform a number of additional operations in response to the im~ng requests generated by the input im~ging For example, the laser imager may manipulate the image data, prior to generating the laser drive values, to produce a variety of di~rerenl format and/or appe~ce characteristics.The image il~."lalion processed by the laser imager has a format det~l,fil~ed by an input protocol ~so~ cd with the particular input ima~in~ device.
s Medical ;~ s~ ~ellls preferably are capable of h~nrlling image il~l,l,alion generated accGI d;llg to a variety of diverse input pi ~.locols. An input protocol can be characte i2ed as inclu-ling an input driver protocol, which detellliines requi~.l,.,nls for comml~n;c~tion with a particular input im~in~ device, and an input interpreter protocol, which determines the format for int~l~rè~ g image lo ii~,ll.alion ~ener~led by the input ima~in~ device. The number of di~tle.ll input protocols results, to some degree, from the various types of input im~ging devices ple~enlly in use, e.g., MR, CT, X-ray, ultrasound, each of which may gel). .ale image inro---,alion according to a di~relèlll protocol. The primary source of Ji~ele.,l input protocols is, however, the existence of a number of modalities, i.e., input im~gin~ devices made by dirrerenl m~nl~f~cturers and having unique, m~nllf~ctllrer-specific input protocols. For example, m~m1f~cturers such as SiçnnPnc, Toshiba, GE, and Picker pr~ ~e~,lly make CT-type input im~ging devicesthat provide similar functionality, but which generate image il~o-l"alion accorJil~g to diLrerel,l modality-specific input protocols.
In addition to the ability to handle multiple input protocols, medical im~ing systems preferably are capable of h~ntllin~ communication of image i.~....ation to output im~7ng devices according to multiple output protocols. Like an input protocol, an output protocol can be characterized as inrlllrling an output driver protocol, which determines requi- e me"Ls for communication with a particular 25 output im~ging device, and an output interpreter protocol, which determines the format for tr~n~l~ting image information into a form understood by the output im~ging device. Different output protocols primarily result from the availability of laser im~ging output devices having di~erenl sets of functional capabilities. The di~elent sets of functional capabilities present var,ving complexity that can lead to 30 di~lêlll output protocols. For example, Minnesota Mining & ~nllf~cturing Company ("3M"), of St. Paul, Minnesota, p~ ese~lly offers laser imagers having W O 96/16373 PCTnUS95113436 Ji~;re.lt sets of fi~ ;on~l cspsbilities ~fe"ed to as the "831," "952," and "SuperSet" sets, each of which is ~ccoci~ted with a set-specific output protocol.
FYicting me~ic~l imaging systems piesenlly ~-c~mmod~te multiple input and output protocols on an ad-hoc basis by the design of a hai.l-.~e and/or son~are 5 interface speçificslly co~ ed for a panicular input protocol and a particular output protocol. The use of a custom-made interface is c ,~ .nely inflexible. Ifco~ nirnl;on with a di~ t input im~jng device is later required, the entire interface must be redçcigned to handle the relationship between the new input protocol and the old output protocol. A change in the output im~ i~ device o similarly requires redesign of the interface to handle the relationship bclwe~n the new output protocol and the old input protocol. Unfonunately, redesign of the interface is a cun,l)e,~o,.le task that often requires a cignific.~nt in~e~l...en~ in halJ~a,e and/or software d~ ,lopr"el-l time. Even seçmingly minor modifications in functionality of an input or output im~jng device can produce ~,ume.ous, costly design ch~es that propagate throughout the interface.
Nevertheless, there are increasing dem~nds for more flexible medical imaging systems capable of providing communication between a variety of input and output imsgin~ devices having multiple protocols. It is desirable that such medical im~ging systems not only provide flexibility with respect to current protocols, but also be capable of adaptation to handle future protocols in a cost-effective manner. Existing medic~l im~ging systems generally fail to meet the above dem~nds.

Summary of the Invention In view of the limitations of eYi~tine medical im~ging systems, the present invention is directed to a mediç~l jm~gin~ system for communicating image h~",lalion between a plurality of di~l e,ll input im~ging devices having di~el elll input protocols and a plurality of di~l e,ll output im~ing devices having di~l enl output protocols.
The system of the present invention takes advantage of a reusable so~ware a~ ileclllre having a plurality of functionally independent components. The individual cG..Ipon~ .I s can be con~igured in a communication p;peli,le to comm~ icate image il~,.,lalion bel-~cen an input imseing device and an output imqg~ device according to desired protoco!c Each co...ponf .l can be interchanged with a di~erenlly confi~red cG",pone,lt to f~ t-ste co....~ ~ication of image il~""alion according to a di~Lre.,l protocol, thereby reconfi~l~ing the pipeline to achieve ci&nific?~t fl~Yibility. As a further advantage, the comm.~lication pipeline can be dynsmicslly configured to incollJolalf con,pon~.,ls applop.iale for the current en~ilonl~
Moreover, the s~ e arc~-itect ~re is scalable to produce a plurality of o comm~n:~stion pipelhles, each of which can be confi~red according to desiredprotocols. Thus, the system of the present invention can support a di~trenl protocol by either s~apping co",ponenls to recon~igure a single communication p;pelil~e, or by simply selecting an alternative among a plurality of di~re"lly confi~red communic?tion p;pÇlinec in the scalable architecture.
Further, because each of the colllponc-lls is isolated and functionally indep~nd~nt if redesign of a component is necess~ y, several programmers can be allocated to the effort with little added overhead, saving time and expense. Themodularity ofthe arr~itect-~re also enables necess~y modifications or corrections to be made to a single co".ponenl with little impact to the overall system.
Additional features and advantages of the present invention will be set forth in part in the description that follows, and in part will be apparenl from the description, or may be learned by practice of the present invention. The advantages of the present invention will be realized and ~tt~ined by means particularly pointed out in the written desc,iption and claims hereof, as well as in the appended drawings.

Brief Description of the Drawings The acco",pa"ying drawings are included to provide a further underst~n-ling of the present invention and are incG,I,ol~led in and constitute a part of this speçifiç~tion. The drawings illustrate exemplary embodiments of the present invention and togeth~r with the desc,i~,lion serve to explain the p~ ciples ofthe inventlon.
Fig. 1 is a filnction~l block diagram of a meAic~l im~ng system for co.. ~-~-. r~l;on of irnage h~ro~"alion b~ ell mlllt:, !e protocol imaging devices, in 5 accordance with the present invention;
Fig. 2 is a diagram ofthe l~ ;on~ ) b~ l~.~n a plurality of diverse protocols and a set of base-class protocolC~ in accordance with the present invention; and Fig. 3 is a filnction~l block diagl~" of a client-server ~ ior.~h;p applicable 10 to the metli~l ima~in system shown in Fig. 1, in acco-dance with the present invention.

Detailed Desc,iplion ofthe Pl~relled Embo~;...c..~s Fig. 1 is a filnGtion~l block diagram of a mediç~l im~gjn~ system 10 for 5 comm~niG~tion of image inru""alion between multiple-protocol imaging devices, in accordance with the present invention. The medic~l im~ging system 10 inrl~ldçs aplurality of input im~jn~ devices 12, one or more input interface components 14,one or more output interface co"-ponenls 16, and one or more output im~ging devices 18. Each ofthe input interface co",i)onenls 14 incl~des an input driver 20 co",ponenl 20 and an input inte-~-eler coml)one,ll 22. Each ofthe output interface co...i)onenls 16 incl~ldes an output interpreter co,..l)onent 24 and an output driver component 26. An interface executive co"~pone,ll 28 defines one or more (1 to N)comm~miC~tion pipel;l-es 30. Each comm--n;cation pipeline 30 communicatively binds one ofthe input im~ine devices 12, one ofthe input driver components 20, 2s one of the input interpreter co.n~lo-lents Z2, one of the output inte"~. elelcomponents 24, one of the output driver components 26, and output im~gin~ device18 in a bi-directional maMer. The output im~ging device 18 may communicate with any of pipelines 30 on a shared basis. Alternatively, a plurality of outputim~ing devices 18 could be provided, each being communicatively interconnected 30 with a particular pipeline 30.

The input interface co",?one.lls 14, output interface co",ponenls 16, and interface e~e~ e co",pon~"l 28 are implem~nted as a sonwal. system that interfaces with input imagj~ devices 12 and output ima~ng device 18. The sofl~..ue system may be imple~ nled as part of an output ;...aei~g device 18, such 5 as a continuoluc tone digital laser imager, or as part of a disc,~te device controlling commlln:-stion of image i~ ,alion between input ima~nE devices 12 and output imag ~ device 18. The image "~,lllalion gen~aled by input imq~in device 12 incl~des both requests for ;...ae,ng operations, and image data co.~lA;-.;l~g digital image values r~pl e3elllali.~e of an image to be hqntlled by output ima~yng device 18.
0 For p.ll~,oses ofthis description, pipeline 30 will be described as hqnrlling communic~qtiorl of image h~rol ",alion in the form of imqging requests, with image i,~"llalion in the form of digital image values repl esenlali~e of the image being co.. ~ Gqted by a separate communication path. It is conceivable, however, that F;l.el; .c 30 could be confi~red to handle communication of image il~"nalion in 15 the form of both requests for im~ging operations and image data conl;.;..;~lg the digital image values.
Each of input interface co"~ponents 14 is configured to receive the image inforl.lalion, via one of input driver co""~onenls 20 from an input im~gin~ device 12 according to one of a plurality of di~l enl input interface protocols. Each input 20 interface protocol is specifis~lly associated with one of input im~ging devices 12 and reflects the modality-specific requiremc.,ls for communication with the particular input imaging device. Each of the input interface components 14 also is configured to generate first im~ging requests according to one of the input interface protocols, via one of input intt;",rt;~er components 22, based on the content of the 25 received image h~ll"alion. The first im~gin~ requests represenl instructions generated by input im~gjng device 12, as tr~nQ'~ted by input interpreter component 22 for commllnic~tion to output interface component 16.
Each of output interface co"~ponents 16 is configured to generate second ima~jng requests according to one of a plurality of di~, enl output protocols, via 30 one of output interpreter components 24, based on the content of the first im~ging request. The second im~ ing requests repl-esenl the content of the first im~ging requests, as tr~nehsted by output i..l~ er com?onenl 24 for comm~mication to output ;--.agine device 18. Each output interface protocol is speçific~lly associaled with the type of output ima~in device 18 and, like the input interface protocol,reflects the requ;.~n,ents for comml~n e~tiQn with the particular output im~n~
s device. In a~dition~ each ofthe output interface cGr,.ponenls 16 is configured to cG.. vnicate the second imsging requests to output imaging device 18, via output driver colllponcnl 26, ~co d~g to one ofthe output interface protocols.
The sub-co-..pol-çn1~ of input interface components 14 and output interface co".ponenls 16, i.e., input driver col"ponent 20, input i"le.~"~ler COIllpOl-el-~ 22, 0 output inle""eler cG"")onenl 24, and output driver CGIllponCnt 26, are described togeth~ herein in recognition that an input interface co",pone"l, as well as an output interface co"")onenl, could be implemented as a single, integral softwaremodllle. It is pre~".d, however, that an input interface co"~pone~l 14 be realized by a discrete input driver co""~)onenl 20 and a discrete input inle,l"~tel component 5 22 and, similarly, that an output interface co,,,ponc;,,l 16 be realized by a discrete output interpreter co"")oncnl 24 and a discrete output drive co,."~)on. .,l 26. A
discrete imple...e~ ;on ofthe sub-componc.,ls divides the functionality of each interface co""~onenl 14, 16 into smaller p~ç~ os for better modularity. As an example, with added modularity, çl-~nges in hardware interface specifications for an 20 input im~ng device 12 require only reconfiguration of input driver component 20 instead ofthe entire input interface co",pol-en~ 14.
Each of the input interface protocols inçl~des both an input driver protocol applicable to input driver components 20 and an input interpreter protocol applicable to input interpreter components 22. The approp, iale input driver 25 protocol is determined by the communication requirements of a particular input im~ing device 12, whereas the approp,iale input interpreter protocol is determined by the image i"ro""a~ion format of the particular input im~ing device.
The image il~""alion format refers to the types of im~ing requests generated according to the protocol of a particular input im~ging device 12. The input driver 30 protocol specifies the manner in which an input driver component 20 should carry out the 1, ~r,s~l of image i,~""ation from an input im~gin~ device 12. The input illt~l~,r~ter protocol s~ec;r.es the manner in which input i,lt~.~,leler cGIl~ponenl 22 should illt~ el the image il~ll,laLion to generate the first im~P~inp request~. The input driver and input interpreter protocols can vary ~igr ificqntly according to ~irr~.~nc~s in the type of input ;...aeing device 12, e.g., MR, CT, conv~nlional X-s ray, ulll. soulld, as well as the m~mlf~cturer ofthe input ;~.~a~i~g device, e.g.,S;~mçn~ Toshiba, GE, or Picker.
Each ofthe output interface protocols includes an output illtel~ ter protocol applicable to output inlel~,t~h. co",ponenls 24 and an output driver protocol applicable to output driver co---ponenls 26. The output driver protocol is 0 dete.",i"ed by the commlm;c~tion requilt",~,nls of output imqging device 18, whereas the applo~"ia~e output interpreter protocol is determined by the image illrullllalion format ofthe output im?gjn_ device. The output interpreter protocol spe~ifies the manner in which output interpreter cG""~one"l 24 should interpret first im~ing requests to generate second ;...~ging requests in a forrn understood by 5 output im~ing device 18. The input driver protocol specifies the manner in which an output driver cGn,?onenl 20 should carry out the 1, ani~rer of second im~ing requests to output ;.~.~gjl~g device 18. Like the input interface protocols, the output interface protocols are subject to variation. For example, both the output driver and output interpreter protocol can vary according to the type of functional 20 capabilities provided by output im~ging device 18, e.g., 831, 952, or Superset in the case of a laser imager m~nuf~ctllred by 3M.
Notwith~t~n~ing functions specific to a particular protocol, components 20, 22, 24, 26 of like type, e.g., all input driver components, are configured to p~several common tasks. For example, input driver components 20 share a set of 25 co~ ol- tasks necessh. y to communicate with a particular input im~ging device 12.
An input driver component 20 is configured to handle any hardware specifics suchas interrupts, buffers, and h~n-i~h~king necess~.y to transfer im~ging il~lll,aLion to and from a particular input im~ging device 12. The input driver component 20 is further configured to handle any other specific needs of input im~ging device 12, 30 such as p~c~eti7ing or initi~li7~tion. The input driver component 20 pe,ro""s all neceSs~y communication tasks, isolating the rem~in~er of pipeline 30 from any knowledge that co,.. -~- c*~;on is carried out via a serial interface, a parallel interface, a n~,lwol~ interface, or any other ...ccl-~n ~ In ~u~ y, the e~l.Ql-Q:bility of input driver co-mronent 20 is two-fold. First, input driver co.~ o~ 20 receives image i.~l".alion from input im~ng device 12 and 5 prepa,~s the image inrolllldlion for the next stage of pipel;ne 30, i.e., input ~-lt~ ler CGmpOIl~-~l 22. Second, input driver component 20 llani.."ils any l~,rol-~s en-elging from bi-direction~l pipeline 30 to input ;.n~&in,~ device 12, as will be further ~-yl~i~-ed below.
The input interpreter co~..por~ 22, the next co..,ponenl in pireline 30, also 0 shares a common set of tasks with other input interpreter cGlllponenls, without regard to a specific input interpreter protocol. Primarily, after obtai"i"g image i~,ll,alion from an input driver component 20, an input inttl~iele~ cG",ponenl 22 analyzes requests con~ -Pd in the image il~,lnalion and tr~n~tes them to ge~le~ale first ;..~ng requests co,,~s,uonding to operations provided by output 15 ima~ing device 18. The first im~ging requests include requests for a variety of cG~Illon im~ing services provided by output imaging device 18. In a typical me~ l im~jn~ system, such requests may include, for example, requests to initiate an image print job by output im~ing device 18, requests to abort a previously initi~ted image print job, requests to define or modify a format of an image to be 20 printed, requests to delete a set of image data rel)l ese.llalive of a previously acquired image, and requests to store image data in a particular image location.The manner in which input interpreter component 22 interprets the requests generated by input im~ ng device 12 may vary according to the specific input interpreter protocol. The input i~lel~leler component 22 understands the precise2~ format, instructions, and timing consl~i"l~ inherent in the image i,lro.",alion generated by a particular input im~ging device 12. Nevertheless, all input interpreter co",por,e.lls 22 still provide a common, basic function of generating first im~ ng requests. The input interpreter component 22 sends the first im~ging requests along pipeline 30. Once the first im~ging requests have been processed by 30 down~l,ea", components in bi-directional pipeline 30, and a response has beenreceived, input intt:""~tel component 20 forrns an appropl;ate re~,onse for input imaging device 12. The input i"~e",re~er component 22 sends the ,~ sponse along p;l.el -~e 30 to input; ~.aei.~g device 12, via input driver cG",ponen~ 20, which handles commlln:~~tion requue.l.e.lls I~PCÇSC~Y to l~nSnUl the ~..ponse to the input .
~ng devlce.
The output i,lte""~ler co",ponenl 24 is the third component in pil,elil-e 30.
The output h~.&eh~ device 18 may speak one of many di~ere~l protocols, such as 831, 952, or Superset in the case of a laser imager m~nl~frctllred by 3M.
An output inle.~"eler co,nponenl 24 is configured to receive, via pil~e~ e 30, first imaging requests generated by an input i"le",-~ ter co",ponen~ 22, and to interpret 0 the first im~ng requests to generate second im~ing reqU~ctc which co,~"" to the particular protocol required by output im~ging device 18. The second im~inE
requests CG" ~ spond to the first im~ging requests in subslance, but are configured arco,d;ng to the output protocol understood by output im~ing device 18.. Thus, the second imqgine requests serve as requests for the same im~ing services lS sl-e~ ed by first imagng reque~s The manner in which an output int~""~ter component 24 h~l~ .ylels the instructions may vary acco,ding to the specific output interpreter protocol dict~ted by output im~in~ device 18, but all output interpreter components 24 share a co"""on task of gene, ali"g second im~gjng requests in a protocol understood by the output im~ging device. The output interpreter co",poncnl 24 sends the second im~ging requests along pipeline 30. When output ima~ing device 18 processes the second im~ing requests and form~ tes a response received via pipeline 30, output interpreter co,n;)ol-e,-~ 24 removes any outputprotocol-specific i,~""alion and forms an approp, iale response for input interpreter cGIll?onenl 22.
2s The output driver component 26 is the fourth component in pipeline 30.
Like input driver components 20, all output driver components 26 perform a common set of communication tasks. Specifically an output driver co,l")onent 26 is configured to handle any hardware specifics such as interrupts, buffers, and h~nr~ch~ing necessa,y to l~srer im~gin~ information to and from a particular output im~in~ device 18. The output driver component 26 isolates the remainder of pipeline 30 from any knowledge that communication with output im~eing device WO 96/16373 PCT/US95tl3436 18 is carried out via a serial interface, a parallel interface, or a dual-port RAM, etc.
The output driver co .,pon~ ~l 26 l~ansmils second imabn~ requests generated by an output i~dw~ el cor~ ol~F nl 24 to output imagin~ device 18, .~ nlA:n; ~p any CQ~ 'rDtioll requucll~ ts. Further, output drivor cGI-~)on~,.ll 26 r~cei~s s rf,C~ es from output ima~ing device 18, and p-~par~s the res~onse for v ~ Cj~;on to output interpreter CGIllpOllenl 24 via bi-directional pipelinc 30.The interface executive compone..l 28, which defines the structure of p;pcl;nc 30, is the f~h co".ponenl ofthe software system. The interface executive con~l-one.~1 28 is configured to communicatively inte.conne~,l a number of o components 20, 22, 24, 26 having di~renl protocols on a selected basis to provide significant flexibility This flexibility provides a medical im~ing system 10 capable of achieving commun;cation between a variety of di~le"l input im~gin~ devices 12and one or more output im~in~ devices 18 having a variety of di~ere.,l functional cap 1 jlities Thus, interface executive cG"~ponent 28 treats each functionally s in~ep~nd~nt co--"~on~nl 20, 22, 24, 26 as a block with a clearly identified set of re~lon-il.ilities and a defined interface. The interface executive component 28 selects the approp- iate series of black boxes based on the envirolullenl~ and binds them together to forrn the co--~plele pipelinc 30 As a further advantage, interface executive component 28 preferably is configured to dynamically bind the components to form a communication pipeline 30 appropliale for the current im~ing environment Moreover, interface executive component is configured to produce a scalable software architecture having a plurality (1 - N) of comm~lnic~tion pi~,eli"es 30 configured accolding to dil~lenL protocols The scalable architectllre enables output im~gjng device 18 to communicate 2~ ~im -it~neously with several input im~ging devices 12 on a shared basis using the necessA~y protocols, as provided by each pipeline 30 Alternatively, a plurality of output im~n~ devices 18 can be provided, each being communicatively inte,~;onl-e~led with a particular pipeline 30 The interface executive component 28 scales the soll~al e architecture to match the requiremellls of the environmenls, creating as many pipelines 30 as there are input im~ing devices 12 requiring an interface with an output im~ing device 18. The interface executive con-l)oncl~l 28 selectively binds a series of co.nl.o 20, 22, 24, 26 having specific protocols necess ~ y to match a particular input imqgin~ device 12, a particular output imaging device 18, and the required ha~l~vd.e interfaces. The nature of co...l-o~ s 20, 22, 24, 26 enables them to be s selectively e~ ged in or out of a pipe~ e 30 in a modular fashion by interfaceexecutive cG...ponci-~ 28. Each ofthe CGIllpOn nlS 20, 22, 24, 26 is made .nl~.'la~,,e ~ble with another component of like type, but di~renl prolocol, by a series of son~a. e interfaces. Speçifi~lly, each co...pol.enl is configured according to a particular protocol, but includes a "base-class" software interface that ll~n~ es 10 the protocol into a base-class protocol generic to every component of like type.
The base-class interface is preferably built into each colllponenl such that anyCGn~pOne,nl 20, 22, 24, 26 in a pipeline 30 can be replaced without ane~iling the confif~.ration ofthe other co...pon.nl~ in the pipeline. Thus, individual cG...ponenls 20, 22, 24, 26 also can be reused, significantly reducine costs previously associated 15 with redesign efforts.
For ~ ~-..ple, if pipeline 30 were to be configured for comm~nication between a Siemens input im~ing device 12 and an output imagjng device 18 illlple-~P~I;..g 3M SuperSet functionality, all via serial data, interface executive component 28 would communicatively bind: (1) an input driver component 20 20 having an input driver protocol appropl iate for receiving im~ging information via a serial hardware interface associated with the Siemens input im~ging device, (2) an input inte.~.eler CO.I.~ onenl 22 having an input interpreter protocol app.op.iate for gene. alion of first im~gin~ requests based on the format of the image i..fo....a~ion received form the Siemens input im~ging device, (2) an output interpreter 25 component 24 having an output i..le.~.t;ler protocol applop.iale for gel.cl~lion of second im~ging requests understood by the 3M SuperSet output im~ ing device, and (4) an output driver co-..ponent 26 having an output driver protocol approp.iate for communication ofthe second im~gjng requests via a serial hardware interface ~.coci~ted with the 3M SuperSet output im~ging device. Alternatively, if 30 the pipeline 30 described above were to be modified for communication between a Toshiba input im~~jng device 12 and a 3M SuperSet output im~ging device 18, all via serial data, it would only be l~eCÇCSA~Y to PY~ nge the input driver col,lyon~
20 and input inle.~"eter cGIll~Joncnt 22 with colllpollenls confi~red accol li~ to input driver and input interpreter protocols, re;"~ecli~/ely, appro~)llate for the Toshiba mod~lity. The output interface col~pon~ 16, which ineludes a 3M
5 Superset-col.r~ ,d output u~ eter cGIllpon~l 24 and a 3M Superset serial-configl~red output driver cG~ )ollent 26, would already be col-figl~ cd accGIdillg to the leyuil~.lle-lls of output im~ing device 18, independently of input ima~n~
device 12, and Ihe.~role would be un~cted by the modification. Thus, interface e,~. Ii.~e colllponenl 28 would communicatively bind: (1) an input driver 0 colll~on&ll 20 having an input driver protocol appropliale for receiving jm~7n~
il~llllalion via a serial hardware interface ~c.coci~ted with the Toshiba input imaging device, (2) an input illte~preter con,ponenl 22 having an input inlel~leter protocol applo~,liale for genelalion of first ima~jn~ requests based on the format of the image il~.l,lalion received form the Toshiba input im~in~ device, (2) an 5 output intel~ ter conlponenl 24 having an output hlltl~reler protocol applopliale for gentl aliOIl of second i...~,;ne requests ulldel ~lood by the 3M SuperSet output im~jng device, and (4) an output driver coll,ponenl 26 having an output driver protocol app~o~,l iate for communication of the second imA~jng requests via a serial hardware interface associated with the 3M SuperSet output im~in~ device.
As another alternative, if the pipeline 30 described above were to be modified for communication between a Toshiba input im~in~ device 12 and a 3M
952 output imaein~ device 18, all via serial data, only modification of output interface con"~olle.,l 16 would be necç~cA.y. Specifically, interface executive con")onenl 28 would communicatively bind: (1) an input driver co,llponel,t 20 having an input driver protocol appl op, iale for receiving imA~in~ information via a serial hardware interface associated with the Toshiba input imA~in~ device, (2) an input illle~Jrèler component 22 having an input interpreter protocol approp,;ate for gene,ation of first im~in~ requests based on the format ofthe image information received form the Toshiba input imA~in~ device, (2) an output h~Lell~relel component 24 having an output interpreter protocol appl op, ;ate for gene, al;on of second im~in~ requests understood by the 3M 952 output imAgin~ device, and (4) an output driver component 26 having an output driver protocol appl op,iale for ication ofthe second im~ne requests via a serial hanlv~,~e interface a~cori~ted with the 3M 952 output ima~ng device. Thus, input interface COn~pOn~,.lt 14, inrl~lding a general serial-configured input driver CG..~rO~ 20 and 5 a Toshiba-configured input inl~ ,ieler co..,l-ol-~ .1 22, would be ullalr,~,led by the mo~ifi~q~tiQn Finally, if the pipeline 30 de~,,il.ed above were to be modified for c~ n~ cation b~ .cen a Toshiba input im ~ ng device 12 having a serial hardware interface and a 3M 952 output imqelng device 18, having a dual-port RAM
o interface, only modification of output interface component 16 would be necçcc~.y.
Speçifirqlly, interface executive co-"poncnl 28 would communicatively bind: (1) an input driver co,--ponc.~l 20 having an input driver protocol appl-up-iale for receiving imag1nS~ ..."alion via a serial hardware interface associated with the Toshiba input im ~ n~ device, (2) an input i--le-~ ter con",onc.~t 22 having an input 15 interpreter protocol apy~op~iate for generation of first im~n,~ requests based on the format ofthe image il~o~ lion received form the Toshiba input ima~ine device, (2) an output interpreter component 24 having an output interpreter protocol a~,l,rop.iate for gwle.~lion of second ;...~P.;I-e requests understood by the 3M 952 output imaeing device, and (4) an output driver component 26 having an output driver protocol applop.;ate for communication ofthe second im~ing requests via a dual-port RAM hardware interface associated with the 3M 952 output im~ng device. Thus, input interface component 14, in-~lu~ing a general serial-configured input driver component 20 and a Toshiba-configured input interpreter component 22, would be unaffected by the modification.
To f~rilit~te interçh~nge~hility, as described above, the software interfaces between components 20, 22, 24, 26 must be pre-defined to make each type of component generic. At the same time, however, an individual component 20, 22, 24, 26 must be configured to implement functions specific to a particular protocol.
In accordance with the present invention, the solution lies in object-oriented tec-hniq~les that are used to develop a generic base-class protocol for each type of component, e.g., input driver co.n~,onc.-l 20. The generic base-class protocol speeifies the functions provided by a co",l)one,ll and the procedures for llcce,~ g such fi~-c~;ons Each specific protocol co",ponenl "inherits" from the cGl,espollding base class protocol, and impl~rnpnts the interface to cfjnr(Jllll to the en~,,.ufi~ 1 The term "inhe~ilance" is used herein to refer to an object-oriented S pro~ e concepl by which abstract data types can be PYtPnded to allow for type/subtype rel~tionchirs Rather than reimpl~ ~~cn~ g shared characteristics, aclass can inherit Sf le~led data .ne...he~ ~ and n,~ her filnçtiollc of other classes.
Class il~h~,.ilance allows the "l~,lbel ~ of one class to be used as if they were ".fr ~be. ~ of a second class. No additionql pro~~ g is required to illlplenle the s~class, except for those operations that either extend or replace the l"embel ~
inherited from the other classes. As an object-oriented system develops, s~lbcl~ccec are constructed out of eYictin~ classes until the approp,iale fimctiQn~lity is developed. The construction of sub~l~c.ces results in the formation of a class hierarchy. The class l~er~, chy is rooted by a special class, l efelled to as the base class. The base class col-~ c a minim~l set of behavior common to all subclasses.
In accol dance with the present invention, each component 20, 22, 24, 26 is confi~red according to a specific protocol, but also serves as a sub-class of the base class protocol. Because each col"ponel~l 20, 22, 24, 26 inherits from the base-class protocol and implem~ntc a minim~l set of functions such that they meet base-class requil ~",e.,ls, it can be directly ;"lerchallged with any other component of like type that inherits from the same base-class protocol. The interchangeability resulting from the object-oriented techniques produces a "direct-connect" software arç~ itect lre in which each component can be effectively plugged into pipeline 30 without the need for additional interface development.
2s Fig. 2 is an example of an object-oriented protocol hierarchy that facilitates inte, ~ ge~bility of components 20, 22, 24, 26. The protocol hierarchy illustrates the imple...~ ;on of components 20, 22, 24, 26 for specific protocols that each "inherit" from a generic base-class protocol. For example, an input driver base protocol 32 may encompass a plurality of "inheriting" input driver protocols for30 di~lenl hardware interface requirements associated with an input im~ging device 12, such as a general serial input driver protocol 34, an SCSI input driver protocol W O96/16373 ~CTrus95tl3436 36, a Siemen~ serial input driver protocol 38, or a parallel input driver protocol 39.
A base-class input inl~. ~.r~ter protocol 40 may encG.,.pass a plurality of il~. il;ng input interpreter protocols for dirrcl e..l types of input ima~pn~ devices 12 orm9~lllf~cturers, such as a GE input interpreter protocol 42, a Toshiba input 5 inl~.~"eler protocol 44, a Si~m~nc input inle.~r~,ter protocol 46, or a Picker input inte.~ t~ protocol 48. As shown in Fig. 2, base-class input intcl~,.ete. protocol 40 may also r~col~ cs inheriting protocols for user interface devices such as a keypad protocol 50.
Similarly, a base-class output inlcl~,~ele[ protocol 52 may enco"lpass a o plurality of inhcliling output interpreter protocols for di~erenl types of output imagi~ devices 18, such as a 3M SuperSet output interpreter protocol 54, a 3M
831 output intc.yletel protocol 56, or a 3M 952 output interpreter protocol 58.
Finally, a base-dass output driver protocol 60 may encon~pass a plurality of inheriting output driver protocols for di~crenl hardware interface requirc...e.lls 15 associated with output imsf~ng device 18, such as a dual-port RAM output driver protocol 62, a serial output driver protocol 64, or a parallel output driver protocol 65. Each of the il~. iling protocols described above includes protocol-specific functions provided by a col..ponent 20, 22, 24, 26, but implements such functions via a generic interface that inherits from the co-lt;~.ponding base-class protocol 32, 40, 52, 60 For each base-class protocol 32, 40, 52, 60, described above, a variety of additional inheriting protocols can be implemented, according to the requil e.-.e.lls of the medical im~ging system environ...e..l As shown in Fig. 3, interface executive component 28 preferably defines pipeline 30 accolding to a client-server architect--re In Fig 3, an arrow pointing 25 from a component A to a component B indicates that component A is a client cG...pone.ll of server con-pol-enl B. The bi-directional arrows between input driver component 20 and input im~ging device 12 and between output driver component 26 and output imaging device 18 do not r e~rese..l a client-server relationship, but rather the hardware/so~ware interfaces of medical im~ging system 10. As indicated 30 by the arrows in Fig 3, interface executive component 28 preferably defines the client-server relationship such that input interpreter component 22 is a client con~l)or.e.~l of both input driver componenl 20 and output hlt~ ter cG.-.ponent 24, and output illt~ ctel co,npone.lt 24 is a client componen~ of output driver co...~on~lt 26. Consequently, input driver conlpollenl 20 and output inlt.lu~eler colll~ol~,.lt 24 are server co-,-pol~enls for input i,ltt,l,ieler co.nponent 22, and s output driver cc,.ll~,olle.,l 26 is a server conlporlcnl for output intc.~,leter co~ o~ l 24. The interface executive CO..~pO~ 28, itself, is a client cG.-.pone ~l of input driver CQI..l~Qn~ ~1 20, input illte.~,ietel cGIllponenl 22, output i.lte-l,.eler co~pon~ 1 24, and output driver ~!..pQnen1 26.
In the client-server rcl-l;o~lcl.;l) desclil.ed above, both input driver 0 co..l~)onenl 20 and output driver colllponenl 26 are purely server components for input interpreter co.lll)onc,.l 22 and output inte.~,relel component 24, ~specLi~ely.
The input driver cG.ly)onellt 20 and output driver corll~olle-,l 26 are les~ol1s;ble for low-level h&,d~d~e requile-llellts and are under control ofthe higher-level input inle.l,leter colllpoll~,.ll 22 and output interpreter colllponc,ll 24, rej~e.;li.~ely. The 5 input i--lt;-~,-eler co..lponen~ 22 is a client colllponc.ll of output il~ yfeler co.ll~,onelll 24, which provides a set of funclions by which the input intel~relel colll~,onc.ll controls output im~in~ device 18. The output interpreter component24 never initi~tes conl~ ~icalion with input inte.,u~etel component 22, but rather provides services at the request of the input inte",reler component. Finally, every 20 con")onenl 20, 22, 24, 26 is a server co-"ponc..l for interface executive component 28. Thus, interface executive cG."ponelll 28 !~ltimqtely controls the entire software system.
Communication between components 20, 22, 24, 26, 28 in the client-server relationship is carried out by the issuance of remote procedure calls (RPC's). A25 remote procedure call is a common communication mech~ni.em o~en used in complex distributed software systems. A client co...pol-el1t ~Yec~ltes a particular function by issuing a remote procedure call to a corresponding server component.The use of remote procedure calls hides the specific details and depçnd~n~ies, i.e., protocol-specific characteristics, of the individual components. The remote 30 procedure call handles all of the mec~nicmc necess~ry for inter-component cornm--nic~tion. As a result, the communication mech~ cmc remain generic, P~ the need for the design of protocol-specific meÇI~A~ .llC in each c~...ponenl Each c~l.l?onent 20, 22, 24, 26 is confi~red to provide services to a client co..lponenl, but is unaware of which or how many components are actually using it as a server component. The conlpolle..ls 20, 22, 24, 26 simply pc-ro..,l the 5 rcquests of client c~lnpon~-ls without e~,il,;lhlg protocol-specific depçndr-n~ iPs.
A remote procedure call is used to execute a function in the follo~ing manner. First, when a software process being pe~ r~ cd by a client co,l,?on~ nl needs to ~Yec~lte a particular fi~nCtiQn~ the process simply calls the fi~nction by its id~ er. A layer of soIl~a c residing within the client co"lponenl, conl nonly 0 lcre.lcd to as a "client stub," traps the fiunction call. If the client stub dtlclll~nes that the software code necessz~y to purOllll the called function actually existswithin another server component, the client stub creates a message enclosing anydata passed with the fiunction call, as well as any n~cess~y pac~ ti~ing and addressh,g. The client stub then sends the ...f ~.aet to the server coll,?on~ .-1 via the real time Opc~ alil~g system e ~ g in the software system. The server module collt~s a layer of software code, known as the server stub, that receives the mes~e The server stub strips apart the m~ess~e and actually calls the correct local function with any data pulled from the message. The local function executes as if it were originally called locally, returning any h~l lllalion requested. The server stub creates a response based on the returned h~lll,alion, and sends the ,ponse to the client cG",por,enl via the operaling system. Upon receipt of the response, the client stub pulls out the returned info"~,alion and passes the information to the local software process that originally called the function. The local software process then continues unaware that any inter-module communiGation occurred.
The following sections provide details conccllling the manner in which each base-class protocol can be implem~nted in an exemplary embodiment of medical im~ng system 10, in accordance with the present invention. In particular, sections A-D provide exemplary definitions and requirements of services provided by each of components 20, 22, 24, 26, 1 epl esellled for purposes of illustration in the C~
object-oriented prog,~ ,-.;ng l~n~ge, with comments included wherè applicable.

Where Ct~ code is used below to e.~e",plir~ the functionality of a particular co...l~onf~ the label "host" may be used to refer to input ima~ne device 12 and the label "laser imager" or "Lr' may be used to refer to output imagj~ device 18.
A. The Input Driver Base-Class Protocol s The input driver base-class protocol, in this eY9-.. pl~y embo~ nt includes seven remote procedure calls that input driver co",ponc.lt 20 is ~ ilcd to provide for its client components, interface executive colnponenl 28 and input illte~ cte. cG..~pone .l 22. With the remote procedure calls, a clientcollll)onel~l can directly interface with an external input imagjng device 12 via input 0 driver component 20. The seven remote procedure calls are described below in terms of the types of p~ an,~ters h~n~led and the functions p~ - rul ",ed.
1. xmit_mPcc~e Pa,a",elers:
Type:
message char *
Returns:
Tvpe:
Driver return code DRIVER_RC
The above RPC passes a message to the input driver co",~one"l to l~ansn"~ to input im~;jn~ device 12. All comrnunication requile,.lenls for tr~ncmiccion ofthe message to input im~ing device 12 are handled by input driver component 20.
2. receive_message Parameters:
2s Tvpe:
message char *
Returns:
Type:
Driver return code DRIVER_RC

The above RPC rel,icvcs a mPsC~e from input driver col"pone,l~ 20 that has been sent from the host. Again, all cG.. --.---Iication requi~."~,lls for l,~i~c~;c~;on ofthe message to input imD~ device 12 are h~n~led by input driver co",pol~.,l 20.
3. set_xmit_limcoul Pa,~elers:
s Type:
timeout int Returns:
Type:
0 Driver return code DRIVER RC
The above RPC sets a timeout value that input driver component 20 uses when s~..... u1;.~g a ~essd~e to input im~ng device 12.

4. set_async_func Pa- a~"elers: Type:
client ptr FE_CLIENT_PTR
method ptr FE_METHOD_PTR
Returns:
Type:
Driver return code DRIVER RC
The above RPC gives the input driver component 20 a handle to an asynchronous handler associated with the client component. The above RPC provides a means by 25 which input driver component 20 informs the client component of an asynchronous event that has occurred. The only asynchronous event that will occur relative, to input driver component 20, is MSG_PENDING, which indicates that a message has been fully received by the input driver component from the input im~ging device 12 and is ready for input interpreter component 22.

W O96/16373 PCTAUS9~/13436 5. set_debug_level P~aQ,~t~: Type:
debug level DEBUG_LEVEL
Returns:
Type:
Driver return code DRIVER_RC
The above RPC allows the client cGlllpon.,.lls to set the debug level of input driver co...l)or -~l 20. The debug levels are NO_DEBUG, LOW_DEBUG, 10 MEDIUM_DEBUG, and HIGH DEBUG. This pal ~n~ ter affects the i,~. l,lalion displayed during debugging.

6. start_comm Pal alnet~:
Tvpe:
none lS Returns:

Driver return code DRIVER_RC
The above RPC activates communication between input driver component 20 and input im~ging device 12.

7. stop_comm Parameters:
Type:
none Returns:
2s Type:
Driver return code DRIVER_RC
The above RPC disables communication between input driver component 20 and input imaging device 12.

As in-~ic~ted above, each RPC returns from input driver co...l~on~-.l 20 one ofthree driver return codes: (l) RPC_OK, (2) PORT_BUSY, and (3) NO_MESSAGE. The driver return codes can be defined in C~ as follows:
/ISet return types for I/O Driver interface 5 typedef enum {
RPC OK, //RPC was issued and acknowledged PORT_BUSY, //Transmit RPC failed, port already tr~n~
NO_MESSAGE //Receive RPC failed, no .~es~aee pending } DRIVER_RC;
10 The actual base-class protocol for input driver conlpon~,nl 20 can be defined in Ct~
as follows:
class INPUT_INTERFACE
{

plote~,led:
I~T32 return_code; /l RC for OS operations // Expect generic pipe interface from lower level hardware ports PORT_ID port; //This port ID
DEBUG_LEVELS debug_level; //Current debug level FE_CLIENT_PTR client;
20 FE_CLIENT_METHOD PTR async_event_handler;
public:
INPUT_INTERFACE(PORT_ID newport);
~~PUT_INTERFACE(void);
//RPC's that are available to clients 25 //Hide hardware interface via an event driven RPC interface virtual DRIVER_RC xmit_rnessage(char *message) = 0;
virtual DRIVER_RC receive_message(char $message) =0;
virtual DRIVER_RC set_xmit timeout(int timeout) =0;
virtual DRIVER_RC set_async_filnc(FE_CLIENT_PTR, 30 FE_CLENT_METHOD PTR)=0;
virtual DRIVER_RC start_comm(void);

virtual DRIVER_RC stop_comm(void);
void set_debug levels(I)EBUG_LEVELS);
};
B. The Input Inl~.~,~ter Base-Class ~rotocol.
sThe input illte~ eter base-class p,otocol, in this e-e~?l~ Y
emlbO~ f....l, inrludes four remote procedure calls that input i~lel~Jl'eler coll.?oncn 22 is required to provide for its client conlpone.lt, interface executive colllpon~l-t 28. With the remote procedure calls, interface executive cGI~lponelll 28 can co.~ icate with input inl~ ler cGIllponenl 22. The four remote ploc~lule 0 calls for input interpreter cGI~lponent 22 are des_lil,ed below in terms ofthe t,vpes of par~llelel~ hq-ldle~ and the functions pclrullned.
1. rcvConfiguration Pal~ ters:
Type:
pointer to palal,leters lS Param_Blk Returns:
Type:
void n/a 20 The above RPC passes a pointer to input interpreter colllponelll 22 that points to configuration palalnelers for the co~"ponent. The pala,neters have been stored since the last power-down sequence of system 10. The pa, a",eters are stored in a read-only block of a memory associated with output im~ing device 18. Thus, any cl~nges made by input interpreter com~onent 22 will not be reflected on the next25 power-up.

WO 96/16373 PCI~/US95/13436 2. Ii_event_handler Pa, a~nete~ ~:
Tvpe:
laser imager event IO EVENl Returns:
Type:
void n/a The above RPC receives as~/ncl.ronous events from input driver conll)onel~t 20.
10 The ~.~"cl~onous events, which include the receipt of ,..ess~es from an input;...~-~g device 12, are des~.ibed above with r~f~l~ ..ce to input driver cG~..ponen 20.
3. io event_handler Pa~"~ele~: Tvpe:
io event Returns: Type:
void n/a The above RPC receives asy..chl onous events from output im~gin~ device 18 via output interpreter componenl 24 and output driver component 26 The 20 as~". hronous events received from output im~in~ device 18 are desclil,ed in more detail below with reference to output interpreter component 24 4 set_debug_level Parameters: Tvpe:
debug level DEBUG_LEVEL
Returns Type Driver return code DRIVER_RC
The above RPC allows the client component, interface executive component 28, to 30 set the debug level for input interpreter co-"pol1ent 22 The debug levels include WO 96/16373 PCI~/US95/13436 NO DEBUG, LOW_DEBUG, MEDIUM_DEBUG, and HIGH_DEBUG. This p.u~,..,tel affects the il~.,.-alion displayed during debugging.
As noted above, input h~ clcr c;o""~onelll 22 provides a ...ecl~c~ for hsn~lin ~nclu onous events received from output i~ g device 5 18. The events sme to inform input h~lcl pl eter co",pon~l 22 of a status change at output ;-~-ag,~ device 18. Various events i~d;c~ the status of output ima~n~
device 18 may include: (1) FP_status change which in~ ?tes a film processor -s-~or:~ted with the output ;...a~in~ device has ch~ged its status, (2) PR_status_change which intli~,stes ims~yn~ harJ~d,e associated with the output 10 ;...a~ e device has cl~ed its status, (3) IMS_status_change which indiG~tes an image m~n~ePm~nt system ,e~,~,on~il.le for fo,~lallillg image data within the output ;~5~h~, device has cl~ ed its status, (4) JOB_status_change which indic~tes an ima~in~ job has cl~ ged its status, and (5) XFR_status_change which in(~ic~tes a"~,~rt;, job, involving a bzckground ll~n~rer of image data, has cl~ eed its status.
15 The function of the above status events is to avoid the need for input inte"~reler cGlllpGnenl 22 to continuously poll output jm~ne device 18.
The actual base-class protocol for input interpreter cG",ponenl 22 can be defined in C~ as follows:
class FRONTEND_EXECUTIVE {
protected:
INT32 return code; ll RC for OS operations int exec id;
Semaphore event_reply; ll async event received Semaphore event_free; ll async event mailbox free Mailbox event_mbox; ll event mailbox FRONTEND EXECUTIVE(int, LI INTERFACE *,INPUT INllERFACE *);
~FRONTEND EXECUTIVE(void);
LI INTERFACE *li handle; //Handleto LI interface INPUT_INTERFACE *input handle; //Handle to IO interface DEBUG_LEVELS debug level; //Debug level for module Param Blk pa,~"elers; //Pointer to pa~a"~eters WO 96/16373 PCI~/US95113436 LI async data li_async_data; //Data from LI events public:
virtual void io_event handler(IO EVENT event)=0; /finput driver ev handler virtual void li event handler(LI_INTERFACE EVENT,LI async data)=0;
5 virtual void rcvConfiguration(Param_Blk)=0; //receive pointer of pararn block virtual void set debug_level(l)EBUG_LEVELS level); llset to new debug level };
C. The Output Inl~ .r~;ler Base-Class Protocol The input illte-~ ter cG,ll~)on~,nl 22 interfaces with output ulle~ et~r 0 col~pon~ .~ 24 via a set of im~7ng objects. The im~n~ objects serve as p~a~n~t~.s for the remote procedure calls and contain all ofthe available i~rul~nalion conc~.lung the characteristics of output ima~ing device 18 and the imagine process. The input inl~l~,reler conlpontnl 22 can use any part ofthe il~llllalion and dis.cgald the rest. There are six im~ng object dçfinitiQn~
15 inrl~din~ (1) a box object, (2) a format object, (3) an image object, (4) a test image object, 5) a string object, and 6) a variety of general im~gin~ parameter objects.
A format object is used to describe an entire sheet of im~ging media on which output im~i~ device 18 will form an image. The forrnat object holds il~ll,lalion relating to film type, film size, border color, border density, etc. The 20 charactersitics of the format object can be defined in C~ as follows:
class FORMAT {
public:
FORMAT(FORMAT_ID); // Constructor FORMAT(void); // Constructor void init(void); // Tnit~ 7e pa,~nlelers to dçf~ tc FORMAT ID id; // Format to which this box belongs TABLE bkgnd_color_table; // Background/border color media table TABLE bkgnd_color_mixing_table;// Background/border color mixing table LEVEL bw_border_level; ll B&W border level 30 COLOR color_brd_level; ll Border Color levels LEVEL bw_density_max; ll B&W maximum density WO 96/16373 PcrluS9S/13436 FILM_TYPE film_type; // Type of film to use FILM ST7 F film size; // Size of film to use A box is a ~ n~yll~r area of the film sheet de~ e~ to hold an image.
s The box has many characteristics inrludine location, size, contrast, color, etc. The box d~ ;on~ are ~soc:~ted with a particular format. That is, several boxes are used in conj~ln~tior- with a pal~ lar format. The following C~ code desclil,es the box object and its characteristics:
class BOX {
0 public:
BOX~OX_ID id,FORMAT ID id); // Constructor BOX(void); // Constructor void init(void); // Tniti~1i7e pa,am~ters to d~f~ults BOX_~ id; // Box id #
FORMAT_ID format_id; // Format the box TABLE beta_xl; /l Ho,i~ol,lal axis beta pass 1 TABLE beta~l; ll vertical axis beta pass 1 TABLE beta_x2; // Hol i~o,l~al axis beta pass 2 TABLE beta~2; /l Vertical axis beta pass 2 TABLE color media_table; ll Color media table to use TABLE contrast_table; ll B&W contrast table to use TABLE color_collll ~l_table; ll Color contrast table to use TABLE color mixing_table; ll Color mixing table to use FRAME frame; ll Frame to use around border LOCATION x_iocation; ll Hol i~olllal pixel location LOCATION y_location; ll Vertical pixel location Switch ~lhluling~ ll Turn ,.,i.,u,ing on and off Switch rotation; ll Turn rotation on and off OUTPUT_SIZE output_size_xl; ll X output size pass 1 OUTPUT_SIZE output_size_yl; ll Y output size pass 1 OUTPUT_SIZE output_size_x2; ll X output size pass 2 OUTPUT_SIZE output_size_y2; l/ Y output size pass 2 OF~SET window x offset; ll Window X offset from corner O~SET window_y offset; ll Window Y offset from corner LENGTH window x length; ll HGliZOlltal length of window s LENGTH w;,.duw y length; ll Vertical length of window };
An image is ~ ,~_.1led by irnage data containing digital image values. The image data is stored in an image Ille.llo~ so~ ed with output ;~..a~ device 18. The image object is used to ~Cco~ te certain chara~e,ii,tics lo with the image. As intlicated by the above code, the characteristics may include pixel length, pixel width, pixel depth, color format, etc. When p~ ulg, an image is used to fill the boxes defined for the format that is to be used. The following C~
code desc.ibes the image object and its characteristics:
class IMAGE {
public:
IMAGE(void); ll constructor IMAGE(IMAGE_ID id); ll constructor void init(void); l/ Tniti~1i7e parameters to defiql.ltc IMAGE ID id; ll Identification Number COLOR FORMAT mode; ll color image folmat LENGTH x_length; ll ho.izo-"dl image length in pixels LENGTH y_length; ll vertical image length in lines DEPTH image depth; ll depth of image 8-12 bits DllRATION ~imeou~, ll acquire timeout for this image Switch pc.~ n~ , 11 image will be held for a while };
A test image object is used to symbolize images used for testing purposes. The images are software generated and have di~l en~ attributesthan an image. The following C++ code describes the test image object and its 30 characteristics:
class TEST IMAGE {

WO 96/16373 PCT/US95tl3436 public:
TEST_IMAGE(void); /l constructor TEST_IMAGE(IMAGE_ID id); // constructor void init(void); // Tniti~1i7.e p~n~elel~ to d~fi~
s IMAGE_ID id; ll Tdentifir~tion Number COLOR_FORMAT mode; ll color image format LENGTH x_length; ll hol.zo,llal image length in pixels LENGTH y_length; ll vertical image length in lines DEPTH image_depth; ll depth of image 8-12 bits 0 DURATION timeout; ll acquire timeout for this image TEST_IMAGE_TYPE image_type; ll type of test pattern LEVEL red_density; ll Constant density - red density;
LEVEL green density; ll Constant density - green density;
LEVEL blue_density; ll Constant density - blue density;
};

A string object is used to hold ASCII text in the image n~ o.y. The string object also allows the use of parameters such as length, intensity, type, etc. The following C~ code describes the string object and its characteristics:
class STRING {
public:
STRlNG(void); ll constructor STRrNG(IMAGE_ID id); l/ constructor void init(void); ll Initialize parameters to def~l-lt~
STRING ID id; ll id of string TEXT_TYPE type; ll Type of the text char *text; ll string LEVEL bw_foregnd_intensity; ll B&W forground intensity LEVEL bw_bac~gnd_intensity; ll B&W forground intensity COLOR color_foregnd_intensity; ll Color foreground intçn.~ities -COLOR color_b~cl~d_i,lte~ y; /l Color background ;..lenc;~;es LENGTH width; t/ width of string LENGTH lead; /l # of blank lines between ASCII lines };
s The general p~nelers object is used to hold all process confi~lration p&~ ,lers. This object can be used to set the pa,~,.elers in the laser imager, or to read the current settings ofthe p~an,~,lers. Fy~mrles of some p~l..~te~ are default beta tables, default color contrast, default destin~tion default film size and type, etc. A few pa ~..et~..s are read-only, and thus cannot be set, such as the10 amount of memory available, the current software revision, the total prints queued, etc. The follo ving C~t code describes the general pa.a,.lcter object and its characteristics.
class PARAMETERS {
public:
PARAMETERS(void); t/ Constructor void set_d~f~ultc(void); // Tniti~1i7e to def~ ts DURATION acq_timeout; ll Acqui~ition timeout 1.. 65535 seconds TABLE def beta_xl; l/ Default ho,izo"lal axis beta pass 1 TABLE def beta yl; // Default vertical axis beta pass 1 TABLE def beta_x2; // Default ho"zonlal axis beta pass 2 TABLE def beta_y2; ll Default vertical axis beta pass 2 LEVEL def bw_border; l/ Default B&W Border level COLOR def color_border; // Default color border level COLOR_FORMAT def ~;Ço"nal, l/ Default acquisiton image format TABLE def bw contrast; // Default contrast table while in B&W
TABLE def color_contrast; /l Default contrast table while in color TABLE def color_mix; /l Default mixing table while in color LEVEL def max_density; ll Default maximum density value DEPTH def depth; /l Default bits per pixel 30 DESTINATION def destin~tion; ll Default destin~tion for print images LEVEL def bw_dmax; ll Default B&W m~ximllm density value.

IMAGE_TYPE def image_type; // Default accepli~lc image type FILM_TYPE def film_type; // Default media type FILM SIZE def film size; // Default media size LENGTH def image xsize; // Default width of image in pixels LENGTH def image_ysize; // Default length of image in lines Switch f~xed_ro~ e // Switch for fixed fol.. ~ll;~
FIXED FORMAT fixed format; // Fixed format number /** Read only pa~ le~els **/
long int fixed_image pattern; /l Image acquisition pattern MEMORY memory; // Memory status structure OP_MODE op_mode; /l Operational mode RELEASE revision; // Current revision SYSTEM system; // Tm~gin~ system of the Laser Imager int total queued; // Total prints queued in the system int total_con,plcted; l/ Total prints completed in current jobs int total_failed; // Total prints failed in current jobs };
One of the major responsibilities of output interpreter component 24 is to relay the status ofthe output im~ging device 18 to the client component, input interpretercomponent 22. The status relay process has two steps. When output interpreter component 24 notes a status change in output im~ging device 18, the event handler in the client component is called directly by the output interpreter component. The event handler is passed a status event. Again, the possible status events, whichwere described above with reference to the input interpreter base-class protocol, include (1) the FP_status_change, (2) the PR_status_change, (3) the IMS_status_change, (4) the JOB_status_change, and (5) the XFR_status_change.
The output interpreter component 24 notifies the client, input inle.preter component 22, ofthe above status changes, so that the input hllel~,leler component does not need to continuously poll the laser imager.
It is the responsibility of the client, input interpreter component 22, to either ignore the status change or request filrther infolll,ation.

WO 96tl6373 PCT/US95113436 All status h~""a~ion is co"l-q~ ed within five status objects. There is status object for the film processor, the printer, the image mqnq~gement system, jobs, and background jobs (l~,sf~ ). Each status object has a status field which can be easily cl~L ~ to see if ~.allungs or errors exist. If wallfillgs or errors exist, further 5 t~ l;on ofthe ~alllings structure or the error structure can be done. Again, the client can choose to use only the il~""&lion it needs. The following C~ codeshows the definitiQt- for each of the status objects and the structures they contain:
/**Film Processor Status object typedefs and class dçfinitio~l **/
dass Film Processor {
public:
Film_Processor(void); ll Constructor void clear(void); ll clears status object int id; ll Id int WarmingTime; ll Time till warm FP_Type type; ll Film Processor Type FP_Status status; ll Film Processor status FP_Warnings ~allllngs, ll current walllings in Film Processor FP_Errors errors; ll current errors in Film Processor };
typedef enum {
Antares_FP, ll Antares film processor.
LT_SE154_FP ll LT film processor.
No_FP, ll No film processor conl-e-iled Spectrum_FP ll Spectrum film processor.
2s } FP_Type;
typedef struct {
-n~i~.od Busy : l; ll Processor is in clean-up or busy with media un~ d NoFP : l; ll No film processor docked l~n~i~ned OpenLoop: l; ll Not doing calibration 30 lln~igned Ready : l; //Readyto processfilm gl-edWarming: l; //Warmingup ed Warnings: l; /I Warnings exist llnci~edErrors : l; //Errorsexist } FP Status;
typedef struct {
s ~ y.ed CheckChem: 1; 11 Ch~n~;cl~y iS getting bad.
cjg~-ed Generic : l; //Miccf~ neouc ;gr~A HiOvf : 1; 11 One or more overflow tanks is getting high ~nA;~ed LoChem : l; 11 One or more ç~miQtry tanks is getting low } FP Wh-...ngs, 0 typedef struct {
msigned FPDown : l; 11 Processor is not operational mci~ed FullOvf: l; 11 One or more overflow tanks are full unci~ned Generic: 1 ; // ~iccell~neous uncigned MediaJam: 1; 11 Media j~rnmed in the film processor lS Illlc;~edOutChem :1; 11Oneormorefilmcl~ cl~ytanksareempty } FP Errors;

/**Image ~nqgmçnt System Status object typedefs and class definition**/
class Image_Mgmnt_System {
20 public:
Image_Mgmnt_System(void); 11 Constructor void clear(void); 11 clears status object IMS_status status; 11 Image Management System status IMS errors errors; 11 current errors in Image Management System };
typedef struct {
mcigned PowerUp: l; /I First status since it has been powered up.
uncigned Errors : l; 11 Errors exist in the system } IMS_status;
typedef struct {
lmcigned BadConfig : l; 11 IMS is configured improperly -n.cigned BadTblEprom: l; /I Table EPROMS have an inco~ ecl-cllrn unciet ed I~VR~r~rr : 1;// Non volatile ram error in an input module mci~ed IMSDown : l; // IMS is not operational.
Ilnci~ed OMNVRan~rrl: 1; // Non volatile ram error in output module 1 5 ~ ed OMNVR~rr2: 1; /I Non volatile ram error in output module 2 ci~ned MemBll~Err :1; /110% or more of image Ill~,.llGl~iS bad } IMS errors;

/** Printer Status object ~,eders and class d~ ;on **/
class Printer {
public:
Printer(void); 11 Constructor void clear(void); /I clears status object int id; /I Printer Id 5 int SheetsRe ~ ;ng~ 11 # of sheets left FILM TYPE MediaType; 1/ Type of film loaded FILM_SIZE Me~ ci7e; /I Size of film loaded int ImgPixels; 11 # of imageable pixels int Tmgr ines; 1/ # of imageable lines in media Quality quality; 11 Current quality condition PR_type type; /I Printer Type PR_status status; 11 Printer status flags PR_warnings warnings; 11 current warnings in Printer PR_errors errors; // current errors in Printer };
typedef struct {
unsigned Warnings: l; 11 Warnings exist in the system un.cigned Errors : l; 11 Errors exist in the system } PR_status;
typedef enum {
Draft, Photo } Quality;
typedef enum {
Spectrum PR, 11 Spe.,tnll" printer.
Antares_PR, 1/ Antares printer.
LT SEl 54 PR, // LT printer.
No_PR, // No printer conne~ led XL_PR // XL (RoadruMer) printer } PR_type;
typedef struct {
unci~ned MediaLow : l; // Media is low (less than 20 sheets).
unci~ed Busy : 1; // The printer has a transient problem.
I1n.ci~n~d PrCalib : l; /I Printer is generating a calibration sheet.
} PR_wa~ul~gS
15 typedefstruct {
I-nci~ned BadCass : l; 11 Media caCcette is inoperable.
uncigrled CassErr : l; // Cassette error occurred.
nci~ned CassJam : l; /I Media jam at c~csette.
un.cigned CoverOpen : l; // One of the covers is open.
20 uncigned ExpJam : l; // Media jam at exposure point.
Ilncigned MediaOut : l; // No media in printer.
uncigned NoCass : l; // No media c~ssette in printer.
nci~ed PanelErr : l; // Printer LCD panel in non operable llnci~ned PrDown : l; // Printer is not operational 25 Imci~ned RecMagFull: l; // The Rec Magazine is full and needs to be emptied.
unci~ned RecMagMiss: l; // The Receive Magazine is not in the printer.
unsigned ToExpJam : l; // Media jam transporting to exposure point.
Ilncigned ToProcJam : l; // Media jam transporting to film processor.
} PR_errors;
/** Job Status object typedefs and class definition **/

3s class Job {
public:
Job(void);/I Constructor void clear(void); 1/ clears status object int id; // JOB Id int PrintsComplete; // # prints printed prop~,.ly int PrintsFailed; // # prints printed ;,.,pr~pe, ly int PrintsQueued; // # prints waiting to be printed int FilrnsComplete; // # sheets printed pl ope.l~
0 int FilmsFailed; 11 # sheets printed improperly int FilmsQueued; 11 # sheets waiting to be printed JOB status status; // JOB status JOB errors errors; 11 current errors in JOB
};
lS typedefstruct {
unci~ed Done : l; 11 Job is complete n~i~ed Killed: l; 11 Job was killed un~iened Stopped: 1 ; 11 Job was slopped unci~ned Wait : l; 11 Print is in print queue un~iEned Errors : I; 11 Job has errors } JOB_status;
typedef struct {
un~iEned Aborted : I; 11 Abort colll,lland issued llnsigned BadBand : I; 11 Images not cont~ined in a single band l~ci~edBadMedia : l; //Medianot available.
n.ci~ned BadTable : I; /1 Invalid table specified ed CrossPrtErr: I; 11 Illegal configuration' un.~i~ned FPErr : I; 11 Film processor has failed.
un~iEned ImgAbut : I; 11 Images illegally abut each other 30 un.~i~ned IMSErr : l; 11 Images illegally abut each other ~n~igned LinePixelErr: I; 11 Too many pixels A;~,ned ~rRadCnt : l; // Two identic~l errors c;~d ~xR~nriTnlp : 1;// max images per band ..c;81 ed MaxHorImg : 1;// max holizolllal images ed ~inRa~ld : l; // Fewer than min lines per band 5 Imcignçd Parity : l; 1/ Parity error within an image ;g,~ed PrErr : 1; // Printer has failed unsigned RecMagErr : l; // Receive ~7ine missing or full.
1- si~çd WrongQual : l; // Quality not available } JOB_errors;

/** Transfer Job Status object typedefs and class definition **/
class Xfr {
public:
Xfr(void); // Constructor void clear(void); // clears status object int id; // JOB Id Length X_size; // Horizontal image size (ifjob complete) Length Y_size; // Vertical image size (ifjob complete) XFR_status status; // JOB status XFR errors errors; // current errors in JOB
};
typedef int T .çn~h;
t,vpedef struct {
~Insigned Wait : l; // Job is in queue un.cignedDone : l; //Job iscomplete ncigned Killed: l; // Job was killed llncigned Errors: 1; // Job has errors } XFR_status;
typedefstruct {
l~ncignçd Aborted : l; //Abortcommandissued ~ c;el~ed AcqErr : l; //Acquisition error.

ed BadDepth : l; ll The depth sperified cannot be set.
u~;gn&d BadMode : 1; /l InCGIIeCl current mode.
lln~i~ed ConnectErr : 1; /l Connection error uncigr~ed EibParamErr: l; ll Bad patamcler in NVRAM
s ~ I~.edEibSrcErr : l; //Bad sourcevalueinNVRAM
unci~edEibTranFrr: l; 11Errorwhile1.anr~ p.EIBpd ~,-~,lers ed FifoErr : 1; llFIFO overflow u~-s;g,~ed MemBoundErr: 1; ll Outside boundary of available Ill~,.llGIy ;g,.ed MemErr : 1; llMemoryerrorduring store 0 l~ -ed MemFull : 1; l/ Image memory is full u..~;~..ed NVRamErr : 1; // Misc error with NVRAM
nci~ned ParityErr : 1; //Parityerror -edResErr : 1; //storetoreservedmemoryfailed ."~ci~ed SetUpErr : 1; /l Con~iguration error 15 unsi~ed SizeErr : 1; //Imagesizeerror lm~i~ed TimeOut : 1; ll System timed out during image store } XFR errors;
The output interpreter component 24, in this exemplary embodiment, provides fifteen types of remote procedure calls. With the use of the above described im~ging objects and the remote procedure calls, the client can fully operate output im~ging device 18. Note that all of the parameters co,.lained in the im~ing objects described above are initialized to an "unassigned value". If the p~ ~.,e~er is not changed by the client, the output interpreter component 24 will ignore it. This feature allows the client to use only the parameters that it needs Each of the remote procedure calls provided by output interpreter component 24 is described below. Unless otherwise indic~teti, the return for each of the following remote procedure calls is a Laser Imager Response Object of type LI_response, which will be further described later in this disclosure.
1 Media Print RPCs a. print Parameters: Type:
copies (opt) int W O 96/16373 PCTrUS95/13436 The above RPC initi~tes a general print from a laser imager fimctioning as output ;...a~ g device 18. The above RPC is deci~ed to be used with fLlced-ro~ g The format is a currently selected fixed format. Copies is an optional par~"cterind:c~l;~ the number of copies to produce. The images that have been acquired s since the last print will be used for the print.
b. print Pala~ ; Tvpe:
format int image list LIST
copies (opt) int 0 density (opt) int destination (opt) DESTrNATION
The above RPC initi~tes a print from the laser imager. Format is the format ID to use. Image list in~ tes which images to use to fill the format. Copies is an 15 optional pal amcler inr~ic~ting the number of copies to produce. Density is an optional integer which is used when a density test patch is desired. The integervalue co" csl,onds to an image ID. Destination is an optional parameter that defines a dectin~tion for the output rather than the default.
c. print_test Pa- ~"~cters: Tvpe:
format int image list LIST
dens_id IMAGE_ID
copies (opt) int destin~tion (opt) 2s DESTINATION
The above RPC initi~tes a print from the laser imager. Format is the format ID to use. Image list indicates which images to use to fill the format. Dens_id is an integer that r c,Ol cse"ls the image id of a density test patch. Copies is an optional parameter indicating the number of copies to produce. Destination is an optional30 pa, ~"~cter which defines a destination for the output rather than the default.
d. abort Parameters: Tvpe:

3~

job ID JOB_ID
The above RPC aborts a job having the co,. . sponding id.
e. abort Pa,ameters: Tvpe:
none n/a 5 The above RPC aborts all jobs that have been started.
2. Fo",.alling RPCs a. define Pa~arll~ t~ Tvpe:
forrnat object FORMAT
The above RPC defines a format with the exact pa,~ lers as found in the forrnat object. All par~,.~ lers equal to NOT_ASSIGNED are not included in the dPfinitiol~
b. define Pal~"elers: Type:
box object BOX
The above RPC defines a box with the exact para",elers as found in the box object.
All pa,~"ele,~ equal to NOT_ASSIGNED are not included in the definition.
c. modify Pa~ a",~ t~ . ~: Type:
box object BOX
The above RPC modifies the box that m~tçhes the id specified in the box object.
All p~a"~ele~ equal to NOT_ASSIGNED in the box object are not modified.
d. modify Pa~ a",elers: Type:
box object BOX
x_shift LENGTH
y_shift LENGTH
The above RPC modifies the box that matches the id specified in the box object.
The location of the box is shifted by the amounts specified in x_shift and y_shift.
All p~a",elers equal to NOT_ASSIGNED in the box object are not modified.
e. modify Pa~ a",elers: Type:
format object FORMAT
The above RPC modifies the format that m~t~es the id specified in the box object.
All para",elers equal to NOT_ASSIGNED in the format object are not modified.
~ remove Pa~ lers: Tvpe:

W O96/16373 PCTrUS95113436 none n/a The above RPC deletes the last image acquired.
g. remove Pa,~-"elers: Type:
box object BOX
def (opt) Bool all (opt) Bool The above RPC deletes the box with an id m~tchi~ that of the received BOX
object. DEF is an optional p&~".,ter that when set to TRUE causes the job to be d~,f~ ,d and processed in the bacL~und. If not received, DEF is set to FALSE.
o ALL is an optional pa,~neter that when set to TRUE causes all defined boxes to be deleted If not received, ALL is set to FALSE.
h. remove Pa- a".cters: Type:
format object FORMAT
def (opt) Bool all (opt) Bool The above RPC deletes the format with id m~tçlling that of the received FORMAT
object. DEF is an optional pa.~".eter that when set to TRUE causes the job to bedeferred and processed in the background. If not received, DEF is set to FALSE.
ALL is an optional parameter that when set to TRUE causes all defined fo. ",als to 20be deleted If not received, ALL is set to FALSE.
i. remove Pal a-.... eters: T~pe:
image object IMAGE
def (opt) Bool all (opt) Bool 25 The above RPC deletes the image with id m~tching that of the received IMAGE
object. DEF is an optional parameter that when set to TRUE causes the job to be deferred and processed in the background. If not received, DEF is set to FALSE.
ALL is an optional pa.a-..eler that when set to TRUE causes all defined images to be deleted If not received, ALL is set to FALSE.
j. remove_all Pai a~e~ers: Type:
def (opt) Bool The above RPC deletes all images, boxes, fo....ats and tables defined in the laser imager. DEF is an optional pat~ ter that when set to TRUE causes the job to be deferred and processed in the background. If not received, DEF is set to FALSE.
h. remove_fixed_images P~anl~lers:
s Type:
none n/a The above RPC deletes all images stored via fixed format store RPCs.
3. Image Manipulation RPCs lo a. store Pa- ~mele. ~: Type:
none n/a This remote procedure call is strictly used with fixed form~tting This remote procedure call acquires the next image into the next available fixed image location.
The locations range from 1 to N where N is the format specific.
b. store Pal a-.,eters: Type:
id FIXED_ID
This remote procedure call is strictly used with fixed form~tting. This remote procedure call acquires the next image into the location specified by id. The locations range from I to N were N is the format specific.
c. store Pa~a~"~ters: Tvpe:
image IMAGE
The above RPC acquires the next image. The return information regarding image size is placed in LI_response.
d. store P~l ~",e~ers: ~
2s image TEST_I~GE
The above RPC acquires the next image as a test pattern. The return i,~o. ",ation egal di.lg image size is placed in LI_response.
e. store Parameters: Type:
string STRING

The above RPC stores the text and the id in the STRlNG object. This allows the client co...pone-n to recall the text at any time via the id. The return h~l...alion re~af~ling string size is placed in LI_r~onse.
f. lra,.srGl P~llcte.~; Type:
s image IMAGE
The above RPC ll~lsr~r~ the next image as a ba~l~groLnd job. The return h~lll.alion fegdr~ g image size is available when image ll~rer is complete.
g. reserve Pa-~m. tels: Type:
image IMAGE
The above RPC alloe~es enough image memory to hold the image described by the IMAGE object.
4. Process Configuration / Status RPC
a. set Pa- amGte. ~: Type:
pa.~n~ler object PARAMETER
lS The above RPC sets the jm~gin~ pal~l.elers for the laser imager. All parameters set to NOT_ASSIGNED will be left un-~h~nEe~
5. Status RPCs a. show Pa. anl~te- ~: Type:
p~a~c~el object 20 *PARAMETER
The above RPC retrieves the imaging parameters for the laser imager.
b. show_fixed Parameters: Type:
pa.~-,.eler object *PARAMETER
25 The above RPC retrieves the fixed ~....a~ing imaging pa- ~-.-eters for the laser imager. All other ,..c.-.b~l~ in the parameter object are left llnch~nged. All other .bG~ ~ in the parameter object are left ~Inch~nged.
c. show_mem Parameters: Type:
pa~a" eler object *PARAMETER
The above RPC retrieves the memory conditions of the laser imager.

d. show Parallleters: Type:
image object *IMAGE
The above RPC r~ es the length and width ofthe irnage with id .~ chil~g the id 5 given in the irnage object. All image inrullllalion is placed in the image object.
e. show P~"et~: Type:
printer object *PRINlER
The above RPC retrieves the status ofthe printer with id "IA~ the id given in lothe printer object. All printer inro""alion is placed in the printer object.
f. show P&l~ elel~: Type:
job object *JOB
The above RPC retrieves the status of the job with id ",~ the id given in the job object. All job i~l",alion is placed in the job object.
g. show Parameters: Type printer object *XF~
The above RPC retrieves the status of the ~ rel job with id m~tclling the id given in the llan5rel job object. All transfer job information is placed in the transfer job object.
h. show_formats Parameters: T e string *char The above RPC retrieves a string of id's of the defined formats.
i. show_images Parameters: Tvpe:
string *char 2s The above RPC retrieves a string of id's of the acquired images.
j. show_con_tables Parameters: Tvpe:
string *char The above RPC retrieves a string of id's of the defined contrast tables.
k. show_con_tables Parameters: Tvpe:
string *char The above RPC retrieves a string of id's of the defined color contrast tables.

1. set_debug_level Pal a~ t~ . Tvpe:
debug level DEBUG_LEVEL
Returns: Tvpe:
Driver return code DRIVER_RC
The above RPC allows the client colnl)on~,nl to set the debug level of input ild~"},n,t~,r c~...po~ 22. The debug levels ue NO_DEBUG, LOW_DEBUG, MEDIUM_DEBUG, and HIGH_DEBUG. This pal~cler affects the il~rolll,alion 0 displayed during debu~ing One advantage of the interface to output ;nlel ~1l c;ler cGIllponclll 24 is that every remote procedure call returns a similar object. This object is called, most applopliâlely, the laser imager It;sponse object, as in-lic~ed above. Within the laser imager response object is a plethora of il,rollllalion 15 legaJding the result ofthe remote procedure call. However, the client may chose to eY~mine only the il~ullllalion relevant to its needs. The laser imager response object has three main fields. The first is a simple boolean value entitled success.
The boolean value reflects whether the request associated with the remote procedure call was accGIIlplished or whether it failed. This inrollllâtion may satisfy 20 the needs of most client colllponents. The second field, success_data, returns any values that the client component expects if the co",l"alld was successfi~l. Normally, there will not be any i,~""alion for a successful co.,..n~nd However, one example of il~l Illalion returned for a succes~fi~l con"lland would be the image size that is returned after a succes~fi~l store image co.~....~n~l The third field, errors, is used to 2s explain why the remote procedure call failed. This field is actually a coll,p,ehensive bit field of errors that the laser imager may incur. Again, this field is only valid if success is false.
The C~ code listed below describes the laser imager response object. The class defines the response received from the laser imager a~er 30 a conlllland has been issued. If the command executed successfi~lly, the SUCCESS
flag is set to TRUE. Any data that is received upon a succescfi1l completion will be stored in Success_Data. If the co....-l~nd failed, the SUCCESS flag is set to FALSE. The cause of the failure is stored in the Failures structure class LI_,c~ponse {
friend SS_EXECUIIVE;
Co.. ~ .d cmd; // SS co.. ~nd public:
LI_rçsl)oree(void); /l constructor Bool success; ll Com~n~ld eYecuted to con"~ ion Succçss_Data success_data; ll Only valid upon successfi-l co...ple~ i- n Failures errors; // If cGm~and failed, errors causing failure };
typedef struct {
.ed AcqErr : l; //~Gq~ tionError un~i~ed AcqLockout l; // .Acqui~tion never attempted, not available ~ ign~d BadBoxId : l; ll Box ID does not exists for modification n~i~nçdBadDepth : l; //Pixeldeptherror uncigned BadFmtId : l; // Format ID does not exist u~ .çcl BadPar : l; //BadPa-~.. ~ler llnci~ned BadCConTbl : l; // Bad Color Contrast Table lln~ignedBadCMediaTbl : l; //BadColorMediaTable un~ nedBadConTbl : l; //Bad ContrastTable lln~igned BadCMixTbl : l; // Bad Color Mixing Table un~igned BadDensTest : l; ll Image is not a valid density test patch unci~nedBadDest : l; //Invaliddestin~tion 2s u~ ed R~tlTn~gTd : l; ll Image was not found un~i~nçd BadJobId : l; ll Job was not found un~i~ned BadMedia : l; //Mediatypecorrect n~igned BadMode : l; l/ Incorrect input mode (color / b&w) lln~igned BoxInUse : l ll Box is currently being used 30 lln~igned Busy : l; ll Module is already doing an image transfer un~igned CConInUse : l; ll Color Contrast table currently being used ~, ~ ;g,.ed ConInUse : 1; ll Contrast table is currently being used d co~ ~rrr l; ll Hardware cQnllf~cl;Qn problem unci~d EibPararnErr: 1; ll EIB pa~aa.eler error uncigr~d EibSrcErr :1; // Invalid EIB source s u~;gn~d EibTranErr : 1; // EIB l,~lsr~, pa~al" te~ invalid u~ g"rd Empty : l; // Mbox is currently empty d FifoErr : l; /lFIFO overflow ;gJ-~i FmtFull : 1; /l would be more than 255 boxes in a format u~ ed FmtInUse : 1; llFormat currentlybeingused 10 ~ ;~edFmtOvrLap : 1; llTheboxesinthisformatoverlap ;g..ed FmtOffSheet: 1; ll box in this format will not fit on media ~nc;gl-ed FmtTMCon : 1; ll Too many contrast tablesin this format uncigned FmtTMCCon : 1; ll Too many color cont tables in this format ul-~;~J-ed FmtTMCMix : 1; ll Too many color mix tables in this format 15 ~ ;~.ed FmtTMCMedia: 1; ll Too many color med. tables in this format unsi~ed FmtTMImgs : 1; ll Too many images specified in image list ;~-ed Full : 1; ll MBOX is full unci~ed InModInUse : 1; ll Input Module is currently being used l~ncigned ImgInUse : 1; ll Image is currently being used 20 unci~ed ImgInvalid : l; ll Image has not been fully stored yet mcigned JobDone : l; // Job has already termin~ted ncignedMagErr : 1; //Magnificationerror ncigned MaxFmts : l; /l There would be more than 255 ro.~--a~s ~lncigned MaxJobs 1; ll Would exceed max # concurrent jobs 25 uncign~d MemBoundErr: l; ll Invalid image memory address mci~rled MemErr : l; ll Memory error occured during store ncigned MemFull : l; ll Image Memory is full ncignedMissPar : l; //MissingParameter on~igned MovErr : l; ll Move would cause box location to become neg 30 unci~ned NoMem : 1; ll Not enough memory to execute con.l..and llnci~ed NVRamErr : l; 11 PIlJblc~n with the Non-Volatile memory u~.Qi~d ParityErr : l; 11 Ha~d~a-e parity error c;~ed PassErr : l; 11 Double pass required, single pass module ~.ed QueueFull : l; 11 Print Queue full. No more jobs possible.
s llnci~ç(l ResErr : l; 11 Image size did not match reserved ,..c,..o-y ~u~- ig,-ed SetUpErr : l; 11 Request does not match system Col~i~ulalion A SizeErr : l; 11 Size in Img Header does not match image size u . ~d StoErr : l; 11 Video or Digital signal error during acquisition u~. ;~ed TimeOut : l; 11 Image ~cquictiQn could not be CGIllt~l~ ed 0 l~ncig~ed TooLong : l; 11 Message is too long to fit in the mbox unsier~ed Unkillable : l; 11 Job(s) cannont be killed ~nc:~ed UnknownCmd : l; 11 Unknown co~nl~and issued ~nA;g,.~d WinErr : l; 11 Window specified is incorrect size } Failures;

The following structure holds data that input im~gjng device 18 (the laser imager) returns if the co.. alld ~Yçc-ltçs collc~;lly. Thus, this data is only valid if no errors occurred during execution.
typedef struct {
ID id; 11 Place holder for a return ID
LENGTH x_size; 11 Place holder for an Image size LENGTH y_size; 11 Place holder for an Image size LIST list; 11 Place holder for an ID list } Success_Data;
The actual base class for output interpreter component 24 can be defined in C~t as follows:
class LI_INTERFACE t public:
30 LI_INTERFACE(PORT_ID new_id, OUTPUT_INTERFACE *p);//constructor ~LI_INTERFACE(void);

INT32 return code; /I RC for OS operations DRIVER RC out driver rc; 11 RC from output driver DEBUG LEVELS debug level; 11 Debug level for module Se~.~al-ho.e rpc_reply; //RPC l~s~,onse complete s Se ~ ~I-ho~e rpc_free; /I RPC mailbox free S~.. arhole event_reply; 11 async event received Se ~.al-hG,e event_free; 11 async event mailbox free PORT ID exec id;
Mailbox rpc mbox; 1I RPC mailbox Mailbox event mbox; 1/ event mailbox OUTPUT INTERFACE *output_handle;
FE PTR client; 1I client module using us FE METHOD PTR client async handler; 1I pointer to async handler virtual Bool output ev handler(enum IO_EVENT event) -0 lS //asynch event handler virtual void set async_func(FE_PTR,FE METHOD_PTR)=0;
llset ptr to FE handler 20 /*** Laser Imager Client Interface **$/
1/ Basic Trans~,aren~ Co.-lmand virtual LI_response send(char *); //send generic text virtual LI_response receive(char *); //receive generic text Il Print Co....~ ds 2s virtual LI response print(int copies=1)=0; //Fixed format print virtual LI_response print(FORMAT_ID id,LIST $images, int copies=l,DESTINATION d=Film_Processor_l)=0;
virtual LI_response print_test(FORMAT_ID id,LIST *images, IMAGE_ID dens_id,int copie.. 1, DESTINATION d=Film_Processor_l)=0;
virtual LI_response abort(JOB_ID id)=0;

W O96/16373 PCTrUSg5/13436 virtual LI_, .,~onse abort(void)=O; //Abort all jobs // FG~ Cc~
virtual LI_re~l,Q~t define(BOX box)=O; //Define a box virtual LI r~spon3e define(FORMAT format)=O; //Define a forrnat virtual LI_re~01~3e modify(~3OX box)=O; //Modif,v a box virtual LI_1.,i.~ons~ modify(LENGTH X SHIFT, LENGTH Y SHIFT, BOX

box)=O;
virtual LI rejpo1lse modify~FORMAT format)=O; /tModif,v a format 0 virtual LI r~i")onse remove(FIXED ID); //~emove image from a position virtual LI_response remove(BOX box,Bool de~FALSE,Bool all--FALSE);
//Del box virtual LI rei,ponse remove(FORMAT format,Bool def-F~T.SF,Rool~5 all=FALSE);
virtual LI .e~ponse remove(IMAGE im~,Rool def-FALSE,Bool all=FALSE);
virtual LI le~ponse remove_fixed_images(void); //Remove all fixed images virtual LI_response remove_all(Bool def-FALSE); //Delete everything 11 Manipulation Comm~n~ls virtual LI_response reserve(IMAGE image)=O; //Reserve memory virtual LI_response store(void)=O; //Store next image virtual LI_response store(FIXED_ID)=O; //Store image for a position virtual LI_response store(IMAGE image)=O; //Store an image 25 virtual LI_response store(TEST_IMAGE image)=O; //Store a test image virtual LI_response store(STRING string)=O; //Store a test image virtual LI_response transfer(IMAGE image)=O; //Transfer an image Il Mailbox Co..,.~n-ls virtual LI_re~onse clear(MAILBOX mbox)=O; //Clear a mailbox 30 virtual LI_response receive(MAILBOX mbox,char *msg)=O;

l/Get a msg into a mbox virtual LI_Iesponse send(MAlLBOX mbox,char *msg)=0;
//Send a s mPssa~e to a mbox //~IO~SS confi~ l;on / status CG~ s vir~al LI re~on~e set(PARAMETERS ptr)=0; llset imagin.~ pa.~l.~,t~"~
virtual LI_rc 5pC!I~ show_fixed(PARAMETERS ~);
virtual LI_r~spon~ show_mem(PARAMETERS *ptr); //show image llle.lloly lo virtual LI_re~ onse show(PARAMETERS *ptr)=0; //show imag. params.
virtual LI response show(IMAGE *ptr)=0; //show info of image virtual LI '. ~.onse show(Film_Processor *ptr)=0; //show status of a FP
virhual LI_resl)onse show(Image_Mgmnt_System *ptr)=0; //show IMS status virtual LI_re.. ~,ollse show(Printer *ptr)=0; //show status of Printer virtual LI_res~,onse show(Job *ptr)=0; //show status of a Job virtual LI_response show(Xfr *ptr)=0; //show status of Xfr job virtual LI_ ,;~yonse show_rollllats(char *ptr)=0; //string of defined frmts virtual LI_lesponse show_images(char *ptr)=0; //string of defined images virtual LI_response show_con_tables(char *ptr)=0; //string of cont tables virtual LI_response show_ccon_tables(char *ptr)=0; //string of color con tbls };

D. The Output Driver Base-Class Protocol The output driver base-class protocol, in this exemplary 2s embo~iimçnt is virtually idçntic~l to the input driver base-class protocol. The output driver component 26 provides five remote procedure calls for output interpreter component 24. With the five remote procedure calls, output interpreter conlponenl 24 can directly interface with an output im~gin~ device 18, such as alaser imager. Each of the five remote procedure calls is described below:
1. xmit_message Parameters: Tvpe:
message char *

Returns: Type Driver return code DRIVER RC
-The above RPC passes output driver con.pon~; .l 24 a m~CQ~gc to Ira.ls~.ul to input ;...agJ~ device 12 via ~ipelinP 30. The output driver co~ onç~ 26 handles all requ.len.e.l~s for co.. nira~;Qn with output im~jng device 18.
2 receive message P~.-ele.~: Type:
IllPc5A~e char *
Returns: Type:
Driver return code DRIVER_RC
The above RPC r~t.i~ es a mess~ge from output driver con.pollenl 26 that has been 15 sent from output im~ing device 18 Again, output driver component 26 handles all requi. e...ellls for communication with output im~in~ device.
3 set_xmit_timeout Pal a~nete~ s: Type timeout int Returns: Type Driver return code DRIVER_RC
The above RPC sets the timeout value that output driver component 26 should use when sçn~ling to the output im~in~ device 18.
4 set_async_func Pa. a",eters Type client ptr FE_CLENT_PTR
method ptr FE_METHOD_PTR
Retums Type Driver retum code DRIVER_RC

The above RPC gives output driver co",pon~.nl 26 a handle to the as~"ch- unOUS
handler of the client compollenl, output inte"" ele, component 24. The above RPCis used to inform the client co",ponenl of asynchronous events that have occurred.
The only event is MSG_PENDING which in~lic~tçs a ~ c~a~f~ has been fully s received from output ;~a~ device 18 and is ready for the output inlc~ ter CG.~rOr.f.~l 24.
5. set_debug_level Pal~,lelers: Type:
debug level DEBUG LEVEL
0 Returns: Type:
Driver retum code DRIVER_RC
The above RPC allows the client co,,,pollcnl to set the debug level for output driver colllpol1enl. The debug levels are NO_DEBUG, LOW_DEBUG, 15 MEDIUM_DEBUG, and HIGH_DEBUG. This parameter affects the il~u~"alion displayed during debugging.
As noted above, each RPC returns one of three driver return codes: ( 1) RPC_OK, (2) PORT_BUSY, and (3) NO_MESSAGE. The driver return codes can be defined in C~ code as follows:
20 /ISet return types for I/O Driver interface typedef enum {
RPC_OK, //RPC was issued and acknowledged PORT BUSY, //Transmit RPC failed, port already transmitting NO_MESSAGE /tReceive RPC failed, no message pending 2s } DRIVER_RC;

The actual base class protocol for output driver component 26 can be defined in C~ code as follows:
class OUTPUT_INTERFACE
3o {
public:

OUTPUT_INTERFACE(PORT_ID r.e~ o,l);
~OUTPUT_INTERFACE(void);
virtual DRIVER RC xmit mes~ge(char *rnessage) = 0;
virtual DRIVER RC receive m~s~aEe(char *...ess~e) =0;
5 virtual DRIVER RC set_xrnit_timeout(int li-"eoul) =0;
virtual DRIVER RC set_async_func(CLENT_PTR, CLIENT_METHOD_PTR) =0; //
PORT ID port; //This port ID
Having des_,il,ed the eYempl~ry embodim~nts ofthe invention, additional 10 advantages and modific~tions will readily occur to those skilled in the art from consideration of the specification and practice of the invention disclosed herein.
Th~"efore, the speçific~tion and ex~"p'es should be considered exemplary only, with the true scope and spirit of the invention being intlic~ted by the follo~,ving clairns.

Claims (9)

What is claimed is:

1. A software system for communicating image information between at least one of a plurality of different input imaging devices and at least one of a plurality of different output imaging devices, said software system comprising;
one or more input driver components, each of said input driver components being configured to receive image information from one of said input imaging devices, said image information being received according to one of a plurality of different input driver protocols, wherein each of said input driver protocols isspecifically associated with one of said input imaging devices;
one or more input interpreter components, each of said input interpreter components being configured to generate first imaging requests based on the image information received by one of said input driver components, said first imaging requests being generated according to one of a plurality of different input interpreter protocols, wherein each of said input interpreter protocols is specifically associated with one of said input imaging devices;
one or more output interpreter components, each of said output interpreter components being configured to generate second imaging requests based on the first imaging requests generated by one of said input interpreter components, said second imaging requests being generated according to one of a plurality of different output interpreter protocols, wherein each of said output interpreter protocols is specifically associated with one of said output imaging devices;
one or more output driver components, each of said output driver components being configured to communicate the second imaging requests generated by one of said output interpreter components to one of said output imaging devices, said second imaging requests being communicated according to one of a plurality of different output driver protocols, wherein each of said output driver protocols is specifically associated with one of said output imaging devices;
and an interface executive component for defining one or more communication pipelines, each of said pipelines communicatively interconnecting one of said input imaging devices, one of said input driver components, one of said input interpreter components, one of said output interpreter components one of said output driver components, and one of said output imaging devices.

2. The software system of claim 1, wherein:
each of said input driver components includes a first interface for communicating the image information to one of said input interpreter components according to a first base-class protocol generic to each of said input driver components and understood by each of said input interpreter components;
each of said input interpreter components includes a second interface for communicating the first imaging requests to one of said output interpreter components according to a second base-class protocol generic to each of said input interpreter components and understood by each of said output interpreter components; and each of said output interpreter components includes a third interface for communicating the second imaging requests to one of said output driver components according to a third base-class protocol generic to each of said output interpreter components and understood by each of said output driver components.

3. The software system of claim 2, wherein each of said first base-class protocol, said second base-class protocol, and said third base-class protocol isdefined according to an object-oriented hierarchy.

4. The software system of claim 2, wherein:
each of said output driver components is further configured to receive first responses to the second imaging requests from one of said output imaging devices, said first responses being received according to one of said output driver protocols;
each of said output interpreter components is further configured to generate second responses based on said first responses received by one of said output driver components, said second responses being generated according to one of said output interpreter protocols;
each of said input interpreter components is further configured to generate third responses based on said second responses generated by one of said output interpreter components, said second responses being generated according to one of said input interpreter protocols; and each of said output driver components is further configured to generate second responses to the second imaging requests generated by one of said output interpreter components, said second responses being generated according to one of said output driver protocols;
each of said input driver components is further configured to communicate said third responses generated by one of said input interpreter components to one of said input imaging devices, said third responses being communicated according toone of said input driver protocols; and each of said pipelines defined by said interface executive component is a bi-directional pipeline communicatively interconnecting one of said input imaging devices, one of said input driver components, one of said input interpreter components, one of said output interpreter components, one of said output drivercomponents, and one of said output imaging devices for bi-directional communication between one of said input imaging devices and one of said output imaging devices.

5. The software system of claim 4, wherein:
each of said output driver components includes a fourth interface for communicating the first responses to one of said output interpreter components according to a fourth base-class protocol generic to each of said output driver components and understood by each of said output interpreter components;
the third interface of each of said output interpreter components is configured to communicate the second response to one of said input interpreter components according to said third base-class protocol generic to each of said output interpreter components and understood by each of said input interpreter components; and the second interface of each of said input interpreter components is configured to communicate the first response to one of said input driver components according to said second base-class protocol generic to each of said input interpreter components and understood by each of said input driver components.

6. The software system of claim 5, wherein at least one of said input imaging devices includes a medical device and at least one of said output devices includes a laser imager.

7. The software system of claim 5, wherein said interface executive component defines each of said pipelines according to a client-server relationship such that each of said input interpreter components is a client of one of said input driver components, each of said input interpreter components is a client of one of said output interpreter components, each of said output interpreter components is a client of one of said output driver components, and said interface executive component is a client of each of said input driver components, each of said input interpreter components, each of said output interpreter components, and each of said output driver components.

8. The software system of claim 7, wherein communication between said input interpreter components, said input driver components, and said outputinterpreter components is carried out by remote procedure calls generated by said input interpreter components and executed by said input driver components and said output interpreter components, wherein communication between said output interpreter components and said output driver components is carried out by remote procedure calls generated by said output interpreter components and executed by said output driver components, and wherein communication between said interface executive component, said input driver components, said input interpreter components, said output interpreter components, and said output driver components is carried out by remote procedure calls generated by said interface executive component and executed by said input driver components, said input interpreter components, said output interpreter components, and said output driver components.

9. The software system of claim 1, wherein said software system resides in an imaging system.