At the moment, as part of a workaround for a Spinnaker API change, SpectrumAnalyzer saves calibration data to a file when it can't save it to a camera.
This change was first induced by the Blackfly S, and provided by @Luc around the beginning of June, 2023.
Currently, the "Import from file" button in the "Calibration" dialog fails with an error when trying to import a recently-saved calibration file: "Type does not fit in available buffer space!" My local copy of the code has been modified to look for ".dat" files instead of ".spc" files.
This Undocumented Feature makes it difficult to recover from operator or other errors.
SpectrumAnalyzer New and/or Undocumented Feature DIscussion
-
automatic_jack
- Posts: 11
- Joined: Fri May 26, 2023 3:15 pm
Re: SpectrumAnalyzer New and/or Undocumented Feature DIscussion
Yeah I think Luc is aware and planning to work on it but I think he is taking a bit of a step back right now. If you wanted to take a look or find someone with the skills to fix this that would be helpful. The code is included as part of the download package and the other thread has sone pointers
I sell OpenRaman kits and pre-builds at https://ramanbuilds.andychase.me
Re: SpectrumAnalyzer New and/or Undocumented Feature DIscussion
Concerning the error you get, it's normal (well, sort of -- let me explain).
SPC files have a very specific content structure where each byte in the file is coding for something (more about that here: https://www.thepulsar.be/article/implem ... ce-in-c--/). Inside SPC files, you'll find the spectrum data, the blank and all settings to post-process the data (filtering etc.) including the calibration data.
Calibration data itself, because it had to fit in a very limited amount of space on the camera (something like 4 or 5 32 bits words) is very rudimentary and is basically just the coefficients of a cubic polynomial + some checksum & ident to differentiate random bytes (new camera or reseted camera) from a camera that actually contains a calibration.
To implement the quickfix, I simply detect when the camera reports an error when I'm trying to push/pull bytes from it and save the data to disk as a "data" .dat file. Inside that file you have the very same info that I try to store on the camera, so tje 4/5 32 bits words and nothing more.
The button "import calibration from file" was implemented in the original software to load a SPC file and extract the calibration vector to apply it on the currently-connected camera. So it cannot read .dat files because they have a different format. That's for the "it's normal" part of my reply.
On the other hand, your remark points something very interesting that I did not think about in the first time: save the full calibration spectrum + calibration data as SPC file on disk. That would be much smarter because you could not only use the "import from file" option but also reprocess or inspect any calibration data, just like a regular spectrum. On BFS camera, it's even theoretically possible to upload the complete SPC file on the camera but I'm not sure it's the way to go... I initially believed that having the camera holding the calibration was more practical because you could put the setup on a different computer and still have the calibration. It's a nice feature but I'm questioning how many user actually use 2 or more computers with the same spectrometer :-/ I do it often using a laptop & my desktop development PC but maybe this lead to over-engineering something that could have been much simpler!
Now comes the tricky part. The software, while well made, was done in only 2 weeks during some Eastern Holidays years ago. I bypassed a lot of good practices rules to get something working fast (which is not necessarily a bad thing). Conclusion is that the software is somewhat between an "alpha" and "beta" state. With time, I also created a very powerful "core" library that refactors a large part of the code (+ automated testing + linux support -- more on that here: https://www.more-cpp.com/). Ideally, I should migrate the complete SpectrumAnalyzer program to this new lib but that will take time.
As Andy pointed out, I also had to step back a bit a few months ago already. I'm currently looking for alternatives to work full time on stuff like OpenRAMAN but that's not done yet. So, in the meanwhile, feel free to update the codebase & share your modifications
It's open-source!
SPC files have a very specific content structure where each byte in the file is coding for something (more about that here: https://www.thepulsar.be/article/implem ... ce-in-c--/). Inside SPC files, you'll find the spectrum data, the blank and all settings to post-process the data (filtering etc.) including the calibration data.
Calibration data itself, because it had to fit in a very limited amount of space on the camera (something like 4 or 5 32 bits words) is very rudimentary and is basically just the coefficients of a cubic polynomial + some checksum & ident to differentiate random bytes (new camera or reseted camera) from a camera that actually contains a calibration.
To implement the quickfix, I simply detect when the camera reports an error when I'm trying to push/pull bytes from it and save the data to disk as a "data" .dat file. Inside that file you have the very same info that I try to store on the camera, so tje 4/5 32 bits words and nothing more.
The button "import calibration from file" was implemented in the original software to load a SPC file and extract the calibration vector to apply it on the currently-connected camera. So it cannot read .dat files because they have a different format. That's for the "it's normal" part of my reply.
On the other hand, your remark points something very interesting that I did not think about in the first time: save the full calibration spectrum + calibration data as SPC file on disk. That would be much smarter because you could not only use the "import from file" option but also reprocess or inspect any calibration data, just like a regular spectrum. On BFS camera, it's even theoretically possible to upload the complete SPC file on the camera but I'm not sure it's the way to go... I initially believed that having the camera holding the calibration was more practical because you could put the setup on a different computer and still have the calibration. It's a nice feature but I'm questioning how many user actually use 2 or more computers with the same spectrometer :-/ I do it often using a laptop & my desktop development PC but maybe this lead to over-engineering something that could have been much simpler!
Now comes the tricky part. The software, while well made, was done in only 2 weeks during some Eastern Holidays years ago. I bypassed a lot of good practices rules to get something working fast (which is not necessarily a bad thing). Conclusion is that the software is somewhat between an "alpha" and "beta" state. With time, I also created a very powerful "core" library that refactors a large part of the code (+ automated testing + linux support -- more on that here: https://www.more-cpp.com/). Ideally, I should migrate the complete SpectrumAnalyzer program to this new lib but that will take time.
As Andy pointed out, I also had to step back a bit a few months ago already. I'm currently looking for alternatives to work full time on stuff like OpenRAMAN but that's not done yet. So, in the meanwhile, feel free to update the codebase & share your modifications
It's open-source!Re: SpectrumAnalyzer New and/or Undocumented Feature DIscussion
Luc
did you ever get a chance to work on this part of the software?
did you ever get a chance to work on this part of the software?
I sell OpenRaman kits and pre-builds at https://ramanbuilds.andychase.me
Re: SpectrumAnalyzer New and/or Undocumented Feature DIscussion
Hello Andy,
Not yet unfortunately -- due to health issues mainly :-/ I'm just back today from another 2 weeks at the hospital. Since end of December I can only work part time and am late on schedule.
Not yet unfortunately -- due to health issues mainly :-/ I'm just back today from another 2 weeks at the hospital. Since end of December I can only work part time and am late on schedule.