Design Notes

Need to really separate GUI, processing and drivers

'Image' is the general thing to be handed around
	Driver - DirectByteBuffer
	GUI/SWT - byte[]
	GUI/AWT - ByteBuffer
	FFT - Usually double[] but we can probably port it to int[] - is that a good idea?
	

	
Req. Features:
	Live view, inc:
		Live changes to settings
		Auto aparture
		Live graphs w/ autoscaling
		Live FFT and processing
	
	Graphs on any image/fft
		Will need general graphing class attached to a GUI component
		This ought to be an open source one upgraded a lot
	
	Saving/loading images and full processing etc from them
	
	Could do all of this from within imageJ ???
		No, don't want to be tied to their framework
		
	
Some central framework with a sense of:
	Image Source - loading/capture/live stream etc
	GUI display of image and things to do to that image
	Where do options for the image source go?
	Processing stream for 'continuous' image source, needs image to be passed through
		or change image data in place and pass through change notification.
		
	Each processing/doing stuff components needs also a GUI component to control it.
	But.... should also be possible to run entire processing framework without the GUI
	i.e. over ssh and command based.
	
	Build command line based version first, then wrap in a GUI?
		So now we need some general command/message pipeline.
		
	Its all a bit too abstract for now, so...
		Build capture, processing, display etc components w/o GUI and
		just string together with scripty java programs.
		Once I've got a feel for them, wire a GUI/pipeline up.