Hyperspectral scan: nice-to-have features

[vasilisniaouris]

After an in-person discussion with @cmordi, I have made a list of items that I would like to see in the near but not immediate future.

1. Add a setting to allow for persistent connection to the spectrometer, even if the program changes between the spectrometer and the spcm. This desire stems from a very serious issue with the Andor software (the spectrometer I use). The moment the software disengages, the temperature of the camera starts rising, and it can take up to 20 minutes to cool back down! Ideally, we would like to swap between spcm and spectrometer, without having to wait in-between.
2. Allow the user to plot spectra from multiple points on the same figure, instead of opening different figures.
3. Add a "single acquisition" button, which will take a single spectrum with the current settings on the spot the scan is currently at and display it on a new figure. Any subsequent single spectra taken should also be displayed on the same figure.
4. For the LF side, add a "LF is loading. Please wait...." pop-up, to make sure the user does not try to use the GUI while the LF application is opening in the background.
5. For the LF, make sure you do not initialize LF application twice (if it is already running, do not open it again).

Happy to get your input on this @gadamc @cmordi!

[vasilisniaouris]

After implementing the Andor Spectrometer Controller, this list has changes.

On issue no longer important/fixed:

1. No. 1 is no longer an issue because I found a way around the problem with Andor. However it might still be relevant for other devices in the future.
2. No. 4 is no longer an issue because I added the pop-up.

More features I find important to have for the hyperspectral scan.

1. Plot settings: change spectral region that is being shown, change displayed units (wavelength/frequency/energy), change aggregation method of how the data are plotted (e.g. sum counts, max peak, max peak wavelength etc)
2. Implement an optimization function for hyper-spectral scans (using the above selected aggregation method)
3. Currently, hyperspectral plots are not updated when SetColor or Log10 are updated after acquisition.

More features on the Qt3scan GUI:

1. Implement a Save the yaml button
2. When swapping back and forth between controllers, the yaml file is not stored. This may cause issues if someone forgets to re-load the proper yaml file. Find way to store the yaml settings for each controller? potentially fixed if we have a save as default yaml file that overwrites the default one is the simplest solution I can see. Alternatively, check 4.
3. When swapping controllers, the plotted data are lost. Maybe prompting users to save data before changing the controller would be an easy solution. Alternatively, check 4.
4. Controllers may be instantiated twice when clicked again on the pull-down menu. Either prevent that from happening or accessing controllers via a controller registry would save time. The latter would also fix issues 2 and 3 and is my preferred long-term solution. @gadamc what do you think about the registry?

[gadamc]

Hi Vasilis One thing that Max wanted was to add ability to apply some spectral filters hyperspectral scans. I could imagine various ways to do this at the application level independent device. A way to apply a generic filter function could be a good place to start. With that in place, specific filters could then be constructed and used. Should solve a handful of use cases in #1 plot settings. As for colors and log setting that’s probably an easy fix (I thought I fixed that though) Regarding the registry — that could be useful. Another idea may be to make the hardware controller classes singletons. Then they could retain their last known settings. And yeah, there’s a bunch of things you can do with the yaml files and remembering last experimental setups. I encourage you to go for it! But remember to tag the commit history periodically and update version numbers often. Another major upgrade I would consider is the tooling. I initially kept it minimal bc I thought it would be less work for new members to get involved. But now I think tooling would be overall beneficial to keep code quality high. Things like using poetry to manage the dependencies and using pre-commit hooks to run code quality tools like black, isort, pylint, mypy, autoflake. It would be a painful upgrade for all of that because you’ll have to fix a lot of poorly written code of mine (sorry). But in the end it could be worth it. Then GH actions could be used to ensure nobody merges in bad code. Finally, we could add tests…. Though we couldn’t run hardware tests via GitHub. Good luck!

…

On Tue, Mar 5, 2024 at 09:56 Vasilis ***@***.***> wrote: After implementing the Andor Spectrometer Controller, this list has changes. On issue no longer important/fixed: 1. No. 1 is no longer an issue because I found a way around the problem with Andor. However it might still be relevant for other devices in the future. 2. No. 4 is no longer an issue because I added the pop-up. More features I find important to have for the hyperspectral scan. 1. Plot settings: change spectral region that is being shown, change displayed units (wavelength/frequency/energy), change aggregation method of how the data are plotted (e.g. sum counts, max peak, max peak wavelength etc) 2. Implement an optimization function for hyper-spectral scans (using the above selected aggregation method) 3. Currently, hyperspectral plots are not updated when SetColor or Log10 are updated after acquisition. More features on the Qt3scan GUI: 1. Implement a Save the yaml button 2. When swapping back and forth between controllers, the yaml file is not stored. This may cause issues if someone forgets to re-load the proper yaml file. Find way to store the yaml settings for each controller? potentially fixed if we have a save as default yaml file that overwrites the default one is the simplest solution I can see. Alternatively, check 4. 3. When swapping controllers, the plotted data are lost. Maybe prompting users to save data before changing the controller would be an easy solution. Alternatively, check 4. 4. Controllers may be instantiated twice when clicked again on the pull-down menu. Either prevent that from happening or accessing controllers via a controller registry would save time. The latter would also fix issues 2 and 3 and is my preferred long-term solution. @gadamc <https://github.com/gadamc> what do you think about the registry? — Reply to this email directly, view it on GitHub <#144 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEYGABCNZ5A3RLZ6CPO6YDYWYBMHAVCNFSM6AAAAABDIZHZLSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZZGMZDSMJVHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[gadamc]

ps: don’t forget to graduate. :)

…

On Tue, Mar 5, 2024 at 19:37 Adam Cox ***@***.***> wrote: Hi Vasilis One thing that Max wanted was to add ability to apply some spectral filters hyperspectral scans. I could imagine various ways to do this at the application level independent device. A way to apply a generic filter function could be a good place to start. With that in place, specific filters could then be constructed and used. Should solve a handful of use cases in #1 plot settings. As for colors and log setting that’s probably an easy fix (I thought I fixed that though) Regarding the registry — that could be useful. Another idea may be to make the hardware controller classes singletons. Then they could retain their last known settings. And yeah, there’s a bunch of things you can do with the yaml files and remembering last experimental setups. I encourage you to go for it! But remember to tag the commit history periodically and update version numbers often. Another major upgrade I would consider is the tooling. I initially kept it minimal bc I thought it would be less work for new members to get involved. But now I think tooling would be overall beneficial to keep code quality high. Things like using poetry to manage the dependencies and using pre-commit hooks to run code quality tools like black, isort, pylint, mypy, autoflake. It would be a painful upgrade for all of that because you’ll have to fix a lot of poorly written code of mine (sorry). But in the end it could be worth it. Then GH actions could be used to ensure nobody merges in bad code. Finally, we could add tests…. Though we couldn’t run hardware tests via GitHub. Good luck! On Tue, Mar 5, 2024 at 09:56 Vasilis ***@***.***> wrote: > After implementing the Andor Spectrometer Controller, this list has > changes. > > On issue no longer important/fixed: > > 1. No. 1 is no longer an issue because I found a way around the > problem with Andor. However it might still be relevant for other devices in > the future. > 2. No. 4 is no longer an issue because I added the pop-up. > > More features I find important to have for the hyperspectral scan. > > 1. Plot settings: change spectral region that is being shown, change > displayed units (wavelength/frequency/energy), change aggregation method of > how the data are plotted (e.g. sum counts, max peak, max peak wavelength > etc) > 2. Implement an optimization function for hyper-spectral scans (using > the above selected aggregation method) > 3. Currently, hyperspectral plots are not updated when SetColor or > Log10 are updated after acquisition. > > More features on the Qt3scan GUI: > > 1. Implement a Save the yaml button > 2. When swapping back and forth between controllers, the yaml file is > not stored. This may cause issues if someone forgets to re-load the proper > yaml file. Find way to store the yaml settings for each controller? > potentially fixed if we have a save as default yaml file that overwrites > the default one is the simplest solution I can see. Alternatively, check 4. > 3. When swapping controllers, the plotted data are lost. Maybe > prompting users to save data before changing the controller would be an > easy solution. Alternatively, check 4. > 4. Controllers may be instantiated twice when clicked again on the > pull-down menu. Either prevent that from happening or accessing controllers > via a controller registry would save time. The latter would also fix issues > 2 and 3 and is my preferred long-term solution. @gadamc > <https://github.com/gadamc> what do you think about the registry? > > — > Reply to this email directly, view it on GitHub > <#144 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAEYGABCNZ5A3RLZ6CPO6YDYWYBMHAVCNFSM6AAAAABDIZHZLSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZZGMZDSMJVHE> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[vasilisniaouris]

ps: don’t forget to graduate. :)

hahah I never saw this! Hopefully soon!