To take the pictures of this Basler Scout we have used and contribute using the Soleil's device ImgGrabber, and to analyse those taken pictures we have used the ImgBeamAnalyzer (also originally from Solei).
How we look at the images? Long time a go we have start working with Qt and as a result we have used Qub widget from esrf. This widget has been integrated in tau that has been renamed to taurus.
As an example, I have saved hundreds of snapshots of the gui with beam. The latest publish here was to celebrate the first x-ray beam at alba, but I can share much more of those pictures:
But the software we used doesn't support the Ace cameras. There is a newer software that makes deprecated this software and many of the synchrotrons that are using tango are migrating to LImA (Library for Image Acquisition). This is a very powerful software specially focussed in detectors.
This ccds that I'm talking here are not usually "detectors" in a synchrotron sense. They are not the end of the beamline from where the data of the experiment is collected. The most often activity of this cameras is beam diagnostics previous to the experiment to make sure that everything is on the expected place and the shape of the beam have the desired characteristics. Then they are used very often as a live video image in the graphical user interface (gui) from which I have placed images before.
Another situation is during beam commissioning when this cameras are used much more like a detector during a scan using Sardana. On this situation is not that important the image availability during the measurement, the most important this is the beam study of each picture and the statistical characteristics from the beam.
Then we have two very different user cases. In the upgrade to LImA both must be implemented, and yes they already are.
In the LImA Basler device the Ace cameras are already supported and there are some attributes that allows the possibility to have a gui like we have. But what was the problem? This attribute are from the "new" tango data type DevEncoded. Our system didn't support yet this data type and this has been an august development (almost the best month to work, almost every one on holidays and no one is bothering your development).
What make this data type special? This data type can contain almost anything: basically is a list of an string together with a list of bytes, where the string says what and how the things are codified in the list of bytes.
In the case of the LImA's "video_last_image" attribute, the DevEncoded is given as a "VIDEO_IMAGE" format. An issue of this flexibility is the naming, we are starting putting names without a rule and in the future this will be very difficult to unify and harmonise.
LImA is hosted in a git repository and in the file "applications/tango/LimaCCDs.py" there is a method 'read_video_last_image()' where this "VIDEO_IMAGE" is codified.
Recently this DevEncoded format has been integrated in taurus.
And as we want to see the images using guiqwt who is integrated in taurus using an extension of this software, we have integrated this DevEncoded as a interpretable data from taurus.
The result: we've been able to take and show images from a monochrome Basler ace camera:
Using a fake beam (a image of the beam printed in a paper and placed in front of a ccd) we can check how it behaves with different beam types:
Very glad and satisfied when you see this images. It doesn't look special, but knowing the effort behind that the view is different.
No comments:
Post a Comment