How does the backend know what excitation wavelengths the machine has?
How does the backend know what dichroic mirrors and emission filters are placed in the plate reader (if it is a plate reader that allows for exchange of these light path items)?
What bit-format is the output, and is it possible to change from e.g. an 8-bit to a 16-bit data acquisition (if the plate reader has sensors capable of acquiring data with that granularity)?
Is the focal_height attribute given in mm from the top or the bottom, i.e. can the plate_reader be used to take measurements from both the top and/or bottom (e.g. if the bottom is a transparent flat surface - I know the ClarioSTAR has the hardware-firmware capabilities to accommodate for this).
What is the data_type of a reading? In the above and docs examples you show the data can instantly be plotted using matplotlib’s imshow which usually requires a numpy array?
Interesting. Do you know whether the Cytation 5 can be ordered in different configurations (e.g. LED vs laser light sources, different possible excitation wavelengths available)?
Is there already a pr.request_available_excitation_wavelengths() function?
Seems like something we’ll have to figure out in the future… especially when we start integrating automated fluorescence microscopes in which light paths might be changed between experiments
(and in the future possibly during experiments )
I meant, for some plate readers, flow cytometers and microscopes the photo-sensors (e.g. PMT, CCD, CMOS, …) can gauge light signals in 8-, 16-, 32-bit values, and the user can choose in the control software what one wants to record in. This means that each light value (per well for plate reader, or per pixel for an image) can have a value ranging from 0 - 2^8/2^16/2^32.
For acquisition of large datasets this would be a very useful feature to expose to PLR
Related to this data acquisition type, a lot of plate readers (like the ClarioSTAR) have a “gain” option.
If I remember correctly, this means the photo-sensors can variably amplify the signal they receive to fall into the bit-range that they can record. E.g. if one assesses a low GFP-expressing cell one might want to do so with a high gain (then the data is not just nothing).
But using the same gain in the next experiment on a high GFP-expressing cell will saturate the, let’s say 16-bit, sensor. Then all values will be recorded as 2^16 = 65_536, and no conclusions can be drawn because everything maxed out the sensor.
How do PLR-integrated plate readers deal with gain?
Yes, I think this would be very useful.
One might have issues with condensation on the lid/seal or the focal length from the top, or tries to assess fluorescence of adherent cells. In those cases measuring from the bottom could still mean an assay can be performed on the available plate reader.
I do not know and from a quick skim of the website that does not appear to be the case.
yes
It’s not entirely clear. For the ClarioSTAR, I read 32 bit integers.
Here, it’s 3 sigificant digits encoded as ascii, eg “0.420” as ['0x30', '0x2e', '0x34', '0x32', '0x30'] (yeah…). That’s the best we can get out of the API anyway, even if the sensor reads in greater detail.
I did see this in Gen5. Will check tomorrow.
Thank you for the context, I like learning bio in this way!
Looks like not only the LED can be changed but also the objective, and the “imaging filter cube” (which I’d assume houses both the dichroic mirror and the emission filter):
(thank you Brown uni )
This user manual even got some nice visualisations to showcase what we are talking about:
a Sony CMOS, 16-bit grayscale camera to take x-y plane images → i.e. it creates a spreadsheet/2D-array/matrix with each cell having a value between 0-2^16 arbitrary units of photon-intensity, &
a PMT which is not measured in information_in_bits/pixel but instead is given as a dynamic range in 7 “decades”, i.e. values between 0-10^7 = 10,000,000.
This raises a couple of more questions and massive integration tasks:
Does the current Cytation 5 integration only enable “Fluorescence Intensity” measurements using the PMT-based detection?
The above has an 8x12 layout, indicating to me that indeed this is the data of a complete 96-well plate, with each well containing 1 measurement.
This + your data recorded with a decimal point (which likely represents a continuous analog signal) indicates to me that we are looking at FI measurements using the Cytation 5’s PMT.
If we’d look at images I’d expect multiple 16-bit matrices / well, each for a different field of view in that well.
I’d recommend we deal with this similarly to how we deal with heater-shakers, where we made a heater class and a shaker class, and then a class combining the two?
This means we should create a Microscope class for machines that use cameras (e.g. CMOS, CCD, …) for light detection,
and contrast it to the existing PlateReader class which uses single-point light intensity detectors (like a PMT or photodiodes).
The Cytation 5 would then be the first example of a mixed MicroscopePlateReader class?
I believe that this way we can delineate the integration tasks for the microscope functionalities and for the missing plate reader functionalities (e.g. gain integration - which is an absolute requirement for plate readers; and different shaking_modes like Linear, Orbital, and Double-orbital).
Microscopes depend on the light source wavelength + dichroic + emission filters to excite at a particular wavelength and record at a specific, different wavelength.
Plate readers don’t necessarily need this for all measurements because they can modifiably select specific wavelengths using a different machine called a monochromator.
This explains why here…
…one can just say emission_wavelength=528 - the monochromator selects that wavelength.
That does not work the same way for the Microscope function. There you have to select the filter_cube (dichroic mirror+emission filter).
Hence, the Microscope class will have to be extremely dynamic in nature: to enable the digital representation of rapid changes to the physical machine.
the Cytation 5 as a Microscope has a “six-position automated turret for user-replaceable objectives” → this means the Microscope class must have functions that
Yes, exactly. As of right now, just a PlateReader, but I will add imaging soon. It’s a little more complicated because imaging data is actually sent over a firewire cable, which doesn’t easily convert to usb. WIP.