Re: EPICS support for 2-D detectors/cameras

[tieman <tieman@aps.anl.gov>]

Mark,

I've had thoughts of redesigning my Image Server for several years now.  
The software is actually capable of handling most of the disadvantages 
you list, however, it fails miserably in many other areas :(  The 
biggest disadvantage is certainly the reliance on a windows only widget 
toolkit but there are a growing number of limitations centered on the 
growing use of machine vision type cameras and very high frame rates.

I've thought about the standard EPICS IOC route.  The Image Server was 
always an application first and a PV server second.  I still believe 
there is value in that philosophy but can see the value in going 
standard EPICS. 

I don't see a danger in sticking with the Portable Channel Access 
Server.  There's enough code reliant on it now that I don't see it going 
away.  It does not suffer from the 16K barrier if built to avoid it but 
I generally disagree with EPICS as a means to move image data.  I've 
already done a small amount of preliminary work in developing a new code 
base using the PCAS but it's nothing that can't be thrown away.

An interesting option would be the JavaIOC.  My real fear there is 
longevity.  If something happens to Marty (and I certainly hope nothing 
every does!) and no other facility picks it up, then the JavaIOC dies or 
you become daddy.  Neither is appealing to me.  Still, it is a tempting 
option and if I had time to play I might give it a try.

The rough design I was thinking about is

1)  A core acquisition driver that is common for all detectors.
2)  Camera drivers for each camera type.  This would be very similar to 
the driver already in the Image Server but better abstracted from the 
core code than the Image Server manages.  This would be the only code 
one would need to write to add a new detector.  This part has worked 
very well in the Image Server and does wrapper vendor interfaces 
well--including vendor GUIs.
3)  ROI drivers for various ROI types.  This would actually be a list of 
drivers to support multiple ROIs.  Different ROIs would be capable of 
different calculations, may be different shapes (some people use 
calculations of the ROI as point detectors at times), etc...
4)  Communication drivers for communicating with the outside world.  
These would include EPICS and various file formats and others oddities.  
This would also be a list of drivers--mostly so data could be forked to 
multiple locations (a local USB drive for archival and also to a remote 
processing cluster for real time analysis, etc)  There would be two main 
types of communication drivers: synchronous and asynchronous.  
Synchronous drivers would handshake with the acquisition driver to 
ensure data integrity.  Asynchronous drivers would be allowed to drop 
data to allow the acquisition loop to run full tilt.

The core acquisition driver, camera and ROI drivers would register with 
the communication driver to provide access to the application.  The GUI 
would be fully decoupled allowing the application to run cross platform 
and the GUI to be determined by the user.  A "standard" GUI would be 
developed.  I thought about ImageJ.  I've written several plugins for 
ImageJ and there are loads of plugins available to do just about 
anything.  It's really not the best platform for anything performance 
oriented (it might be difficult to use to focus the detector, for 
instance) but a lot features are already there.

Another key feature is that each driver would be allowed to register 
it's own set of fields with the communication drivers.  This means each 
instance might have a different set of supported PVs.  This has become a 
big issue with the Image Server and one of the motivations for a 
rewrite.  The Image Server started with the "one set of PVs fits all" 
approach and its failed.  To continue to maintain a full set of PVs for 
every camera even if they aren't used is trouoblesome and confusing to 
the user.  The core PVs can be the same for all cameras, but does every 
camera need to support "Pixel Clock", "Black balance", "Frame Rate" and 
"White Balance".  It hasn't been too combersome to provide a "camera 
type" PV and let the control script sort it out.  The differences are 
almost universally in the configuration stage.

In addition to the detectors Mark lists, a new solution would need to 
support:

1)  Cooke SensiCam
2)  Sarnoff Camera
3)  Detector Pool developed systems (Gold, Mercury)
4)  Coreco Frame Grabber--this is a bit more complicated.  The frame 
grabber uses a standard API for all cameras (LVDS and CameraLink mostly) 
but only provides an RS-232 connection for camera control.  Each camera 
implements it's own configuration control via firmware (camera commands 
are rarely ever the same--even from the same manufacturer)
5)  uEye USB Camera
6)  Apogee cameras
7)  Fairchild camera
8)  And I've found it very useful to have a software generated test pattern

The Image Server also supports a few additional cameras, but I am not 
aware these systems are still in use and likely this support can be dropped.

9) MicroImager from QSystems--now owned by Pi/Acton (Roper)
10) Andor Technologies
11) Epix frame grabber
12) Twain (already dropped)

Plus I am aware of 2-3 potential new detector systems not covered by the 
above that users are considering purchasing within the next year.

I haven't walked too far down this road yet (a hesitant step or two) 
because I don't think it should be my decision.  I've raised the issue 
several times (Mark and some others may remember a meeting a few years 
ago where Mark, Steve Shoaf and I each presented our approaches to area 
detectors) but things have been stable and thus no reason to do anything 
different.  I agree with Mark that it would be nice to have a single 
solution for areas detectors and the community should speak up for what 
they need.

Brian