This breaks out camera handling to cameras.py, with each camera implementing an interface specified by the abstract class cameras.Camera. Each camera must implement:
get_frame(), which must return a numpy.ndarray frame of (h x w x color), in BGR colorspace
close()
__init__() (with no arguments beyond self, so it can be called in MAPLE constructor)
The superclass provides each subclass with a write_jpg(filename, quality=95) and write_png(filename) method for free, which uses OpenCV calls by default. This can be overwritten with calls to the camera library for optimization, as I have done with the pyicic camera.
Configuring
Cameras to use can be specified by giving a fully qualified (dot separated module + class) name as the value to the camera_class key, in the MAPLE.cfg file, so that the end user won't really have to change the code to specify the camera. I've added some commented lines to MAPLE.cfg to show how you could change the camera to the OpenCV camera.
I also added a keyword argument to the MAPLE constructor to pass in a Python class directly, which should also be something subclassing the cameras.Camera interface class. This uses less magic than the first approach, so it can serve as a kind of backup, and some people may wish to specify the camera in the same code that invokes the MAPLE constructor.
Using your dictionary of default values for the MAPLE class, I've kept the same default behavior (with no change to MAPLE.cfg), which is to use the pyicic camera.
Possible problems
In one case, you guys had previously kept the pyicic camera live for a period while taking many frames. As it is written, the cameras are mostly stateless, so if starting and stopping the live mode of the pyicic camera causes too much of a performance hit, I might need to provide some way to optionally keep cameras ready for acquisition. Another possible solution to the above is to just put a call to start_live in __init__ and a call to stop_live in close.
I don't have any cameras compatible with the pyicic library, so it would probably be good to test this code with your camera, to make sure I didn't break anything.
Other minor changes
There were some calls to the pyicic save_image with a.png extension, that seemed to be actually saving JPEG formatted data, according to the documentation, so I changed the extension of those files to .jpg to reflect what seemed to be the output format. You might prefer to use the write_png function instead, if you want to keep the same filename format.
Interface
This breaks out camera handling to
cameras.py, with each camera implementing an interface specified by the abstract classcameras.Camera. Each camera must implement:get_frame(), which must return anumpy.ndarrayframe of (h x w x color), in BGR colorspaceclose()__init__()(with no arguments beyondself, so it can be called in MAPLE constructor)The superclass provides each subclass with a
write_jpg(filename, quality=95)andwrite_png(filename)method for free, which uses OpenCV calls by default. This can be overwritten with calls to the camera library for optimization, as I have done with the pyicic camera.Configuring
Cameras to use can be specified by giving a fully qualified (dot separated module + class) name as the value to the
camera_classkey, in theMAPLE.cfgfile, so that the end user won't really have to change the code to specify the camera. I've added some commented lines toMAPLE.cfgto show how you could change the camera to the OpenCV camera.I also added a keyword argument to the MAPLE constructor to pass in a Python class directly, which should also be something subclassing the
cameras.Camerainterface class. This uses less magic than the first approach, so it can serve as a kind of backup, and some people may wish to specify the camera in the same code that invokes the MAPLE constructor.Using your dictionary of default values for the MAPLE class, I've kept the same default behavior (with no change to MAPLE.cfg), which is to use the pyicic camera.
Possible problems
In one case, you guys had previously kept the pyicic camera live for a period while taking many frames. As it is written, the cameras are mostly stateless, so if starting and stopping the live mode of the pyicic camera causes too much of a performance hit, I might need to provide some way to optionally keep cameras ready for acquisition. Another possible solution to the above is to just put a call to
start_livein__init__and a call tostop_liveinclose.I don't have any cameras compatible with the
pyiciclibrary, so it would probably be good to test this code with your camera, to make sure I didn't break anything.Other minor changes
There were some calls to the pyicic
save_imagewith a.pngextension, that seemed to be actually savingJPEGformatted data, according to the documentation, so I changed the extension of those files to.jpgto reflect what seemed to be the output format. You might prefer to use thewrite_pngfunction instead, if you want to keep the same filename format.Closes #14