- The project has been forked from this GOGS page All the following versions will be considered the versions of the fork and not the project as a whole
- Added the definition of the C99 standard to the makefile to solve a build error on unix systems
- The main file has been modified to not use the UDP discovery protocol of the phantom, but instead the ip address has to be hardcoded into t he file. This is a temporary workaround and will be changed int the future
- Added a "test.py" script into the utils folder, which will use the python binding of the libuca package to test if it is possible to grab frames using this plugin. (The libuca and phantom plugin have to be build on the machine for that!)
- Changed the "mock" script to use the special library phantom-cli
- Reworked the implementation for the transmission of 10G imaga data. The previous implementation used standard socket read operations to wait for incoming data. This proved to be to slow for 10G ethernet transmission rates reaching up to ~800 MB/s. The new implementation uses the linux library packet mmap. The transmission works by setting up a ring buffer, which is directly memory mapped into the kernel space, where the actual ethernet packets are being stored. In the the receive-thread loop, these packets are then being added to a local buffer for the complete image data.
- Implemented a decoding algorithm for the 10G data transmission format. Using the 10G connection to the phantom camera, the P10 transfer format is being used. This format encodes each pixel value into 10 bit, but the libuca framework expects the output buffer to consist of 16 bit integer values per pixel. (At the moment this part of the program limits the transmission speed, as the algorithm for the decoding is too slow)
- Reworked the way the decoding is handled, when. Previously the decoding happened after the complete image data was been received and before the data was copied into the final output buffer. Now the decoding runs step by step in a separate thread, in an attempt to squeeze out some additional performance.
- Created a new decoding algorithm, which uses SSE4 intrinsics to speed up the unpacking process of the 10 bit pixel data stream into the 16 bit output buffer.
- Reworked the /utils/test.py to use the python command line library Click. The new test script now also accepts parameters, that maintain compatibility with the phantom-cli mock server.
- Fixed a bug, where single packages would disappear during 10G transmission when the edge case occurred, that an image was finished with the pre last packet in a block of the ring buffer.
- Fixed the bug with the "trigger" method not containing the "rec" command being send to the camera previous to the "trig" command, which is being expected by the camera.
- Removed the debugging messages
- First stable version to be used in production
- Changed the Chunk size for the 10G Transmission from 400 to 100, as 400 worked fine with 1000ish width frames, but using the 2000ish width frames, they have too many bytes and cause a ring buffer overflow
- Added the ability to configure the connection to the phantom using OS environmental variables, which are being read out during the init of the camera object. This change has been made to create compatibility with uca tools such as "uca-grab" and "uca-info", which do not provide the ability to define the connection parameters in code, before attempting to interact with the camera object
- PH_NETWORK_ADDRESS can be defined to provide the IP address during the init of the camera object. If this env variable is defined the connection to the phantom is established during the init of the camera object as well. There is no further need to set the "connect" flag.
- PH_NETWORK_INTERFACE can be defined to pass the string identifier of the ethernet interface onto which the 10G port of the phantom is connected. If this variable is defined, the camera object will automatically be set to 10G mode "enable_10g" flag to TRUE.
- Fixed a Bug, where the "PROP_NETWORK_ADDRESS" is a read write property of the camera object, but does not have a read option defined.
- Removed the makros at the start of the code, which defined hardcoded network configuration.
- Fixed a bug, where the program could not be compiled due to syntax error
- Added support for the "aux-mode" property of the phantom camera. It can be set with an integer from 0-2 to set the function, which the first auxiliary port of the camera will serve
- Moved the "rec" command, which is being used for the trigger command into its own function, so that it can be used separately in the future, as it turned out it will be important for hardware triggers as well.
- Added "P12L" transfer format support for the 1G transmission
- Added "P12L" transfer format support for the 10G transmission
- Creates a new algorithm using the SSE instructions tp provide sufficient processing speed for 10G reception of frames
- The "fmt" parameter is now being sent with the "ximg" command as well.
- Updated the test.py script
- IP address and Interface for 10G connection are now being passed to the phantom plugin by setting the environmental variables
- Added the "format" option to the script, where either "P12L" or "P10" can be selected.
- Added the additional camera property "external-trigger", which is a boolean flag, that indicates, whether the use of external triggering is to be enabled during the next recordings
- The "start_recording" method will now send the necessary "rec" command as a preparation to the camera, so that external triggering will work
- When the "external-trigger" flag is set the "trigger" method will not send a software trigger command, but only the "prepare_trigger" command, so that subsequent hardware triggers will work.
- So here is how the camera actually behaves: After the "rec" command has been sent, it will continuously record frames and after the "trig" command or a hardware trigger has been received, it will record "defc.ptframes" additional frames.
- Thus the grab_memread method was changed in a way, that it will only readout the LAST "defc.ptframes" from the memory and not starting at the beginning.
- Added the boolean flag "enable-memgate", which will enable the memgate mode for the camera. Memgate model will block the saving of frames to the memory, if a HIGH signal is put to the first programmable IO PIN of the camera
- Renamed the property "memread-enabled" to "enable-memread" so it is more consistent with the other existing boolean flags
- Grab process
- When using the memread mode, the start index for requesting the frames from the camera does not longer need to be calculated. The function "get_memread_start" was deprecated. The index for the first post trigger frame is always zero
- It is now possible to start grabbing frames directly after the trigger hab been issued on the camera. The grab_memread function will wait until the camera has enough recorded frames to suffice the request of a new chunk
- properties
- Added PROP_FRAME_SIZE, which holds the size of one frame
- Added PROP_MEMORY_SIZE, which holds the total size of the primary cine partition
- Added PROP_MAX_FRAMES, which is a computed property and holds the maximum number of frames fitting into the cine partition.
- PROP_POST_TRIGGER_FRAMES is now not handled automatically anymore. It has its own setter case. Within this case the memread count is also being set to the very same value.
- There has been a change to the interfacing: For using the memread mode, the memread count does not have to be set manually anymore. It will be set to the same value as the post trigger frames. Although, there still is the posibility of changing the memread count manually afterwards.
- Implemented the trigger mode functionality
- EXTERNAL mode: when the start_recording function is called, the camera will start to acquire frames, but only after an external trigger event has occurred on the first auxiliary port of the camera, the post trigger frames are being recorded and the recording is marked as finished.
- SOFTWARE mode: frame acquisition is also started by the start_recording function, but the post trigger frames are being captured after the sending of a software trigger command by the trigger function
- AUTO mode: The call to start recording will immediately also start the acquisition of the post trigger frames. There is no additional trigger event required.
- Moved the documentation from a separate git repository to this repository and updated the documentation with the latest backward incompatible API changes.
- Fixed syntax errors, which were preventing the build process
- Moved the trigger function definition internally, because it needs to be called by the "start_recording" function when set to AUTO trigger mode