Store LED/filter settings with images

[campagnola]

Every image should have metadata on the illumination / filtering / imaging devices used to generate the image (when available).

This feature should be implemented in the Microscope class.

Should build on acq4#45

[campagnola]

After some more thought, this is not so similar to the PR I linked above. They were concerned with tracking a filter placed in front of a photodetector, whereas here we are looking at illumination attached to a microscope. Here is my suggested approach:

1. Create a LightSource device class. Its main responsibility is to report information on the current illumination source.
   • Should have a describe() method that returns a string describing the currently active light source(s)
   • Should have a sigLightChanged signal that is emitted when illumination changes.
   • Does not implement any actual light control; this will be handled by subclasses.
2. Create an LEDLightSource class (subclass of LightSource)
   • Connects to a separate DAQGeneric device that controls the TTL lines connected to the LED(s).
   • Provides methods like listLightSources() and enableLightSource().
   • The list of available LEDs is provided by the user in the device configuration file
3. Provide a mechanism for "attaching" a light source to a Microscope device
   • Add a line to the Microscope device configuration that specifies which LightSource device it will use
   • Add a method to the Microscope class that provides access to the attached LightSource
4. When images are collected on a camera, they should include information about the light source
   • The Camera device class in acq4/devices/Camera/Camera.py has a getScopeState method that is used to provide metadata about the microscope it is connected to.
   • The same class has an objectiveChanged method that reacts when the microscope objective has changed and records the new state of the microscope. Use this as a template for collecting information about the light source as well.

[davereid98133]

Hey Luke...Not sure if I should ask questions here, or in an email...but here they are:

In the LightSource device class, what should the describe() method return?  What should the description look like?  An indication of what channels are hooked up?  What each channel connects to?  The current ON/OFF status?

In the LEDLightSource class:

What should the listLightSources() return?  What is the difference between this and the LightSource.describe() method?

Is the enableLightSource() a method to connect to the NI DAQ board?  Or should that be used for the actual on/off controls?

Should the list of available LED's just indicate the DAQ channel?  Or do they have names beyond that..."LED Alpha", for example?

[campagnola]

Let's say we have 3 lamps. The configuration for this might include a DAQGeneric device that defines the DIO ports used to control the LEDs and a LEDLightSource device that defines the properties of the lamps and provides a nice interface for the microscope to control / interrogate the lamps:

LEDChannels:
    driver: 'DAQGeneric'
    channels:
        M490L4:
            device: 'DAQ'
            channel: '/Dev1/line0'
            type: 'do'
        M530L4:
            device: 'DAQ'
            channel: '/Dev1/line2'
            type: 'do'
        IR1:
            device: 'DAQ'
            channel: '/Dev1/line3'
            type: 'do'

LEDs:
    driver: 'LEDLightSource'
    leds:
        blue:
            channel: 'LEDChannels', 'M490L4'
            model: 'Thorlabs M490L4'
            wavelength: 490*nm
            power: 50*mW
        green:
            channel: 'LEDChannels', 'M530L4'
            model: 'Thorlabs M530L4'
            wavelength: 530*nm
        infrared:
            channel: 'LEDChannels', 'IR1'
            wavelength: 850*nm

Microscope:
    driver: 'Microscope'
    lightSources: ['LEDs']

I imagine LightSource.describe() returning something like a list of dicts, where each dict contains information about an LED that is illuminated:

[
    {'name': 'blue', 'model': 'Thorlabs M490L4', 'wavelength': 490e-9, 'power': 50e-3}
    {'name': 'infrared', 'wavelength': 850e-9}
]

We could also have a describeAll() method that returns this information for all lamps, regardless of their state. The sigLightChanged signal could then send two values--the name of the lamp and a boolean value giving its current state like ('blue', True). The output of describe() should end up written in the image file metadata exactly as the objective lens is currently recorded.

[davereid98133]

Luke...thanks for the clarification/direction. I should have something ready for you to look at in the next couple of days.

Dave

[davereid98133]

Hey Luke...

Another question, about the last item on the list up above: When it comes to using the "objectiveChanged" method in the Camera class as a template, do I want have an "IlluminationChanged" method separately? Or should I add the grabbing of the illumination state into the ObjectiveChanged method? Meaning, do you want to be alerted every time the illumination changes, or only get the illumination state when something else happens?

I think this is the last portion of this to get sorted out. What is the best way for me to do some testing of this stuff....because I'm certain there's going to be a fair amount of debugging/troubleshooting that will need to happen before its working correctly. Are you around next week? Are you going to SfN?

[campagnola]

I suggest having separate objectiveChanged and illuminationChanged methods, and we definitely need the latter method to be called every time there is a change in illumination state.

We can probably test this entirely at your desktop. There are fake camera and DAQ classes (check acq4/config/example/devices.cfg to see how to configure these). I think that will be enough?

[davereid98133]

Sounds good. Thanks for the assistance. I may come grab you sometime on Monday to help things started up on my desktop so I can do the troubleshooting here.

[davereid98133]

Hey Luke...sorry for the delay in getting back to you, but I got side-tracked on some other things. So I tried doing the "mock" settings in the devices.cfg to do the testing at my desktop, but I'm not sure if I've got things set up correctly. Any chance of you looking at it either this afternoon or tomorrow? Thanks...

[campagnola]

Closed by #21 and #28