genicam/harvesters

Image Acquisition Library for GenICam-based Machine Vision System

harvesters's Issues

Explicitly indicate users that nothing was fetched on the fetch_buffer() call when it's timed out.

Is your feature request related to a problem? Please describe.
In the current implementation, an ImageAcquisitionManager returns None if nothing was fetched on the fetch_buffer() call but it seems to be something implicit and it's not so obvious.

Describe the solution you'd like

• If it's acquiring images:
  • If any non-zero value was specified on the fetch_buffer(timeout=) call, raise genicam2.gentl's TimeoutException when it's timed out.
  • Otherwise, wait until it fetches a buffer anyway.
• If it's not acquring images:
  • Immediately raise the TimeoutException.

Describe alternatives you've considered
None.

Additional context
None.

Support BGR formats.

Is your feature request related to a problem? Please describe.
BGR formats are not special. They should be supported by the Harvester GUI.

Describe the solution you'd like
Support displaying BGR formats on the canvas.

Describe alternatives you've considered
None.

Additional context
None.

genicam2 package?

Hello,
genicam2 is listed as a dependency, but I can't seem to find this package anywhere.
Any hint on how to acquire it?

Thanks!

Support the "keep the latest/oldest buffers" feature.

Is your feature request related to a problem? Please describe.
If we continuously acquire images, the buffer which one he chooses can vary. Someone would prefer to choose the oldest one but the other might prefer to choose the latest one. Maybe Harvester should support both ways.

Describe the solution you'd like
Support keep_oldest and keep_latest modes.

Describe alternatives you've considered
None.

Additional context
None.

Harvester GUI crashed when I tried to open the Attribute Controller after stopping image acquisition.

Describe the bug
Harvester GUI crashed when I tried to open the Attribute Controller after stopping image acquisition.

To Reproduce
Steps to reproduce the behavior:

1. Connect a camera that supports the chunk feature.
2. Start image acquisition.
3. Stop image acquisition.
4. Open the attribute controller.
5. You'll see the App crashes.

Expected behavior
The App should not crash.

Screenshots
None.

Desktop (please complete the following information):

• All supported OSs.

Additional context
None.

Allow clients to specify a device to open using a set of unique device information.

Is your feature request related to a problem? Please describe.
Currently clients pass a list index to core.Harvester.get_image_acquisition_agent method to specify a device to open. However, there might be a case where the client knows a set of information to specify a single device. Harvester Core should support a way to accept such a set of information.

Describe the solution you'd like
Add parameters to core.Harvester.get_image_acquisition_agent so that a client can list up a set of information to specify a single device to open. At least the following information must be supported:

• unique_id: DEVICE_INFO_ID
• vendor: DEVICE_INFO_VENDOR
• model: DEVICE_INFO_MODEL
• tl_type: DEVICE_INFO_TLTYPE
• user_defined_name: DEVICE_INFO_USER_DEFINED_NAME
• serial_number: DEVICE_INFO_SERIAL_NUMBER
• version: DEVICE_INFO_VERSION

Describe alternatives you've considered
None.

Additional context
None.

Try the GitHub Issue Tracker

This is a test. We use this ticket as a sandbox.

The firstly applied aspect ratio is always used.

Describe the bug
The firstly applied aspect ratio is always used. If you firstly applied 400 x 300 canvas, then it'll be used again even if you changed the ROI.

To Reproduce
Steps to reproduce the behavior:

1. Start image acquisition.
2. Stop image acquisition.
3. Change ROI.
4. Start image acquisition.
5. You'll see the 1st ROI setting is still applied to the canvas.

Expected behavior
Aspect ratio must be updated every time when ROI is changed.

Store downloaded (zipped) XML files.

Is your feature request related to a problem? Please describe.
Controlling GenICam compliant devices means the host has to get a camera description XML file and it is obviously vital for any case where we want to debug.

Describe the solution you'd like
Harvester should store the XML files every time it downloaded an XML file from the target module.

Describe alternatives you've considered
None.

Additional context
None.

Make the sleep duration configurable.

Is your feature request related to a problem? Please describe.
The sleep duration between each execution of a worker thread can affect the performance of execution speed. It might be hidden from users in general but perhaps we may want to adjust the duration to optimize the performance in a particular case.

Describe the solution you'd like
Make the sleep duration configurable.

Describe alternatives you've considered
None.

Additional context
This request should be applied to only Python built-in Thread class that is used by ImageAcquirer class by default. On the other hand, there's no restriction for usage of ThreadBase class so if you go implement it, you can freely design it.

Harvester GUI freezes if the attribute controller is opened while it's acquiring images.

Describe the bug
Harvester GUI freezes if the attribute controller is opened while it's acquiring images. It seems to be relevant to the number of nodes that has been displayed/expanded.

To Reproduce

1. Launch Harvester GUI.
2. Connect a camera and start image acquisition.
3. Open the attribute controller.
4. You'll see Harvester GUI immediately freezes.

Expected behavior
Harvester GUI must not be frozen.

Additional context
You may see the similar phenomenon when you try to expand the node tree clicking the Expand button in the toolbar in the attribute controller.

Support displaying YUV formats.

Is your feature request related to a problem? Please describe.
As of June 2018, Harvester GUI has not supported displaying any YUV format.

Describe the solution you'd like
YUV formats are more or less standard today so Harvester GUI should also support it.

I assume it can be done by implementing the demosaicing algorithm in OpenGL shading language. This should be excel at the performance point of view.

Describe alternatives you've considered
No alternatives.

Additional context
No additional context.

Support Bayer10 formats.

Is your feature request related to a problem? Please describe.
Support the following Bayer formats:

• BayerGR10
• BayerRG10
• BayerGB10
• BayerBG10

Describe the solution you'd like
Harvester GUI should support those formats.

Describe alternatives you've considered
None.

Additional context
None.

Attribute Controller crashes when the visibility level is changed.

Describe the bug
Attribute Controller crashes when the visibility level is changed.

To Reproduce
Steps to reproduce the behavior:

1. Launch Harvester GUI.
2. Load a GenTL Producer.
3. Open Attribute Controller window.
4. Change the visibility level.
5. You'll see Harvester GUI is crashed.

Expected behavior
Harvester GUI must not crash if the visibility level is changed.

Make Image class' data type configurable.

Is your feature request related to a problem? Please describe.
It's good to make numpy.ndarray as the default image data type of Harvester but someone may want to have it in other types such as Python's built-in bytes.

Describe the solution you'd like
Make Image class' data type configurable.

Describe alternatives you've considered
None.

Additional context
None.

Deprecate the tear_down method.

Is your feature request related to a problem? Please describe.
The tear_down method of ImageAcquirer class is not necessary and very confusing with the destroy method.

Describe the solution you'd like
Deprecate the tear_down method of ImageAcquirer class.

Describe alternatives you've considered
None.

Additional context
None.

Support Bayer14 formats.

Is your feature request related to a problem? Please describe.
Support the following Bayer formats:

• BayerGR14
• BayerRG14
• BayerGB14
• BayerBG14

Describe the solution you'd like
Harvester GUI should support those formats.

Describe alternatives you've considered
None.

Additional context
None.

Harvester fails to handle `Coord3D` pixel formats.

Describe the bug
Harvester fails to handle Coord3D pixel formats. As a result, those pixel formats are mapped as None.

To Reproduce
Steps to reproduce the behavior:

1. Set up the target device so that it transmits a Coord3D pixel format.
2. Start image acquisition.
3. Try to print a component that consists of the Coord3D pixel format.
4. See error.

Expected behavior
Harvester must be able to handle Coord3D pixel formats.

Screenshots
None.

Desktop (please complete the following information):

• Harvester: 0.2.2.

Additional context
None.

Get rid of the statistics measure thread from the Harvester Core.

Is your feature request related to a problem? Please describe.
It's not necessary to implement the statistics measurement thrad in the Harvester Core.

Describe the solution you'd like
Get rid of the statistics measurement thread from the Harvester Core.

Describe alternatives you've considered
None.

Additional context
None.

The Harvester GUI can't set True to IBoolean nodes.

Describe the bug
The Harvester GUI can't change the value of IBoolean nodes.

To Reproduce
Steps to reproduce the behavior:

1. Launch the Harvester GUI.
2. Connect a device and open the attribute controller window.
3. Try setting True to an IBoolean node.
4. You'll see the value turns False.

Expected behavior
The Harvester GUI must be able to change the value of IBoolean nodes.

Screenshots
None.

Desktop (please complete the following information):
None.

Smartphone (please complete the following information):
None.

Additional context
None.

Harvester GUI abruptly displays an old image.

Describe the bug
Harvester GUI abruptly displays an old image.

To Reproduce
Steps to reproduce the behavior:

1. Launch Harvester GUI and connect a device.
2. Start image acquisition.
3. Keep watching the canvas. You'd see a skip on the displayed images.

Expected behavior
It should always display consecutive images.

Support multibyte pixel formats.

Is your feature request related to a problem? Please describe.
Support multibyte pixel formats.

Describe the solution you'd like
Harvester GUI should support those formats.

Describe alternatives you've considered
None.

Additional context
None.

Support the Chunk Data feature.

Is your feature request related to a problem? Please describe.
The Chunk Data feature is one of the important features that GenICam provides.

Describe the solution you'd like
Harvester Core should support the Chunk Data feature.

Describe alternatives you've considered
None.

Additional context
None.

Do not provide any reshaped NumPy array of an image expecting a specific usage.

Is your feature request related to a problem? Please describe.
As of version 0.1.0, Harvester Core provides clients a NumPy array that has been reshaped so that it fits to the usage of VisPy canvas. In general, however, we should provide the array in a generic shape; I mean the decision should be made by the client himself but not Harvester Core. Everything will be okay if Harvester Core provides sufficient information that is required when the client reshapes the NumPy source array to another.

Describe the solution you'd like
In general, clients go through the following steps to get the image data in an expected shape:

1. Fetch a 1D NumPy array from Harvester Core.
2. Inquire Harvester Core the required information such as Width, Height, X Offset, Y Offset, or Pixel/Data Format.
3. Having that information, he reshapes the 1D array into a 2D array. Sometimes he may need to newly create the output array knowing the pixel location of the source image involving some calculations.

So we require Component2DImage class the following items:

• Define the data property which returns a 1D NumPy array. This will be used as the source of the image data conversion.
• Define the represent_2d_pixel_location method in Component2DImage class which returns a 2D NumPy array which represents just the pixel location in each row. Having that information, client may calclurate the output image.

Describe alternatives you've considered
None.

Additional context
None.

Harvester GUI crashes if the Attribute Controller widget is opened while it's acquiring images.

Describe the bug
Harvester GUI crashes if I try to open the attribute controller widget while it's acquiring images.

One exception is the case where I loaded TLSimu. It doesn't reproduce the phenomenon. It is reproducible only if I loaded a GenTL Producer and connected to a tangible device.

The only workaround that I know is stopping acquiring images just before opening the attribute controller. Once it appeared, you can restart acquiring images.

To Reproduce
Steps to reproduce the behavior:

1. Launch Harvester GUI.
2. Load a GenTL Producer.
3. Start image acquisition.
4. Try to open the Attribute Controller widget.
5. You'll see Harvester crashes.

Expected behavior
Harvester must keep working even if we try to open the attribute controller while it's acquiring images.

Desktop (please complete the following information):

• OS: Windows 7 and macOS 11.13
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

Support Bayer12 formats.

Is your feature request related to a problem? Please describe.
Support the following Bayer formats:

• BayerGR12
• BayerRG12
• BayerGB12
• BayerBG12

Describe the solution you'd like
Harvester GUI should support those formats.

Describe alternatives you've considered
None.

Additional context
None.

Harvester GUI freezes if a node is edited over the attribute controller.

Describe the bug
Harvester GUI freezes if a node is edited over the attribute controller.

To Reproduce
Steps to reproduce the behavior:

1. Launch Harvester GUI.
2. Connect a camera and start image acquisition.
3. Open the attribute controller; assuming it doesn't expand the node tree by default.
4. Edit a node, BlackLevel for example.
5. You'll see Harvester GUI freezes.

Expected behavior
Harvester GUI must not be frozen.

Make the number of images to hold configurable.

Is your feature request related to a problem? Please describe.
There might be a case where a top-most consumer drops images due to its performance; assuming a case where the consumer tries to get images but some of them have been dropped. To prevent such a situation Harvester Core should be able to hold an arbitrary number of images on behalf of the consumer until it turns available.

Describe the solution you'd like
Make the number of images to hold configurable.

Describe alternatives you've considered
No.

Additional context
No.

Harvester GUI crashes if it's resized while it's acquiring images.

Describe the bug
Harvester GUI crashes if it's resized while it's acquiring images.

To Reproduce
Steps to reproduce the behavior:

1. Launch Harvester GUI.
2. Start image acquisition.
3. Resize the app over and over.
4. You'll see it crashes. Sometimes it gives you the following messages:

• WARNING: QPainter::begin: A paint device can only be painted by one painter at a time.
• WARNING: QPainter::setCompositionMode: Painter not active
• WARNING: QWidget::repaint: Recursive repaint detected

Expected behavior
Harvester GUI must not crash even if it's resized while it's acquiring images.

Harvester should re-throw exceptions that were caught at the create_image_acquisition_manager() call.

Is your feature request related to a problem? Please describe.
In the current implementation, Harvester silently catches GenTL exceptions that were raised during the Harvester object tired to open the target remote device module.

If the Harvester object caught an exception, it will return a None object for the method call and it doesn't mean anything to the users.

Describe the solution you'd like
Instead of returning a None, Harvester should just re-throw the exception to the client and the client should decide how to handle the exception.

Describe alternatives you've considered
None.

Additional context
None.

HarvesterGUI sometimes slips the black image into the sequence of valid images.

Describe the bug
HarvesterGUI sometimes slips the black image into the sequence of valid images.

To Reproduce
Steps to reproduce the behavior:

1. Launch Harvester GUI.
2. Start image acquisition.
3. You'll see the black image is slipped into the sequence of valid images.

Expected behavior
HarvesterGUI must display only valid images.

The pause button is not checkable.

Describe the bug
The pause button is not checkable.

To Reproduce
Steps to reproduce the behavior:

1. Launch the Harvester GUI.
2. Connecting a camera and start image acquisition.
3. Click the pause button.
4. You'll see the pause button doesn't stay in the pushed state.

Expected behavior
The pause button must be implemented as a checkable button. Once it's pushed it must stay in the pushed state and it's pushed again it must stay in the non-pushed state.

Screenshots
None.

Desktop (please complete the following information):
None.

Smartphone (please complete the following information):
None.

Additional context
None.

Support displaying 3D formats.

Is your feature request related to a problem? Please describe.
As of June 2018, Harvester GUI has not supported displaying any 3D format.

Describe the solution you'd like
3D formats are getting popular today so Harvester GUI should also support it.

I assume it can be done by implementing the demosaicing algorithm in OpenGL shading language. This should be excel at the performance point of view.

Describe alternatives you've considered
No alternatives.

Additional context
No additional context.

Support image acquisition from multiple streaming devices.

Is your feature request related to a problem? Please describe.
This is just a suggestion but as of June 2018, a single Harvester Core object only supports image acquisition from a single streaming device even though it allows loading multiple GenTL Producers.

This specification covers the minimal functionality but someone may want a single Harvester Core object to acquire images from multiple devices.

Describe the solution you'd like
It might be worth supporting image acquisition from multiple streaming devices.

Describe alternatives you've considered
It's up to the decision but there should be an option to go as is. Actually having multiple Harvester Core objects gives you the same functionality.

Additional context
No additional context.

UnicodeDecodeError raised when connecting a device

Description

Following the example on the main page:

>>> from harvesters.core import Harvester
>>> h = Harvester()
>>> h.add_cti_file("/opt/mvIMPACT_Acquire/lib/x86_64/mvGenTLProducer.cti")
>>> h.update_device_info_list()
>>> for i, info in enumerate(h.device_info_list):
...     print('{0}: {1}'.format(i, info.display_name))
... 
0: Point Grey Research VID1E10_PID3300_15294589
>>> h.connect_device(0)

The last function call raises the following error:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/atsejaas/.local/share/miniconda3/lib/python3.6/site-packages/harvesters/core.py", line 316, in connect_device
    self._encodings[encoding]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 113: ordinal not in range(128)

To Reproduce

OS: Red Hat Enterprise Linux Workstation 7.4.
The GenTL Producer: part of Matrix Visions mvIMPACT Acquire software.
Camera: Point Grey Grasshopper3 GS3-U3-23S6C.

Support Bayer16 formats.

Is your feature request related to a problem? Please describe.
Support the following Bayer16 formats:

• BayerGR16
• BayerRG16
• BayerGB16
• BayerBG16

Describe the solution you'd like
Harvester Core should support those formats.

Describe alternatives you've considered
None.

Additional context
None.

The Harvester GUI keeps fetching buffers while it's pausing drawing images on the canvas.

Describe the bug
The Harvester GUI keeps fetching buffers while it's pausing drawing images on the canvas.

To Reproduce
Steps to reproduce the behavior:

1. Launch the Harvester GUI.
2. Connect a camera.
3. Start image acquisition.
4. Click the pause button.

Expected behavior
The Harvester GUI must not fetch buffers while it's pausing drawing images on the canvas.

Screenshots
None.

Desktop (please complete the following information):
None.

Additional context
None.

Support for accessing multiple cameras through a single Harvester Core object

It would be nice if Harvester would support connecting multiple cameras. This would be useful especially in the field of spectral imaging, where multiple cameras could be controlled with the same interface (Harvester).

I would imagine that this wouldn't be too difficult to implement. Connecting the devices would happen in a usual way with the connect_device function, but a new process would be created for the each camera to be connected. If one calls the connect_device function with a camera that is already connected, an exception would be raised.

I feel the identifier, ImageAcquisitionManager, is a little bit long.

Is your feature request related to a problem? Please describe.
I feel the identifier, ImageAcquisitionManager, is a little bit longer. As a fact, it eventually gives us the create_image_acquisition_manager method which is also quite long.

Describe the solution you'd like
I would like to have a shorter name such as ImageAcquirer instead of ImageAcquisitionManager. With this identifier, we would have the create_image_acquirer method instead of create_image_acquisition_manager.

Describe alternatives you've considered
None.

Additional context
None.

The Harvester GUI crashes if the GenTL Buffer module doesn't support BUFFER_INFO_WIDTH or BUFFER_INFO_HEIGHT, or a device which doesn't provide the information.

Describe the bug
The Harvester GUI crashes if the GenTL Buffer module or the device don't support BUFFER_INFO_WIDTH or BUFFER_INFO_HEIGHT or a device doesn't provide the information.

To Reproduce
Steps to reproduce the behavior:

1. Load a GenTL Producer which doesn't support BUFFER_INFO_WIDTH or BUFFER_INFO_HEIGHT.
2. Connect a device which doesn't provide the information.
3. Start image acquisition.
4. You'll see it crashes.

Expected behavior
The Harvester GUI must support a GenTL Producer which doesn't support those commands or a device which leaves those fields blank.

Screenshots
None.

Desktop (please complete the following information):
None.

Smartphone (please complete the following information):
None.

Additional context
None.

Image acquisition rate doesn't reach to the expected value

Describe the bug
Image acquisition rate doesn't reach to the expected value we expect. It's prominence especially if the device's transmission rate is high.

To Reproduce
Steps to reproduce the behavior:

1. Launch the Harvester GUI.
2. Set AcuiqisitionFrameRate high as much as possible.
3. Start image acquisition.
4. Check the image acquisition rate which is displayed in the status bar.

Expected behavior
Of course, there would be a limit which depends on Harvester's performance but we should boost it by applying any possible trick.

Screenshots
None.

Device (please complete the following information):

• Width: 2448
• Height: 2048
• PixelFormat: Mono8
• AcquisitionFrameRate: 500
• OS: Windows 7

Additional context
None.

Actual acquisition frame rate is slower than the value AcquisitonFrameRate reports.

Describe the bug
Actual acquisition frame rate is slower than the value AcquisitonFrameRate reports.

To Reproduce
Steps to reproduce the behavior:

1. Launch Harvester GUI.
2. Load MATRIX VISION's GenTL Producer for example.
3. Connect a camera to Harvester.
4. Start image acquisition.
5. See measured acquisition frame rate that is displayed in the status bar.

Expected behavior
Acquisition frame rate should equal the value that is reported by AcquisitionFrameRate.

Harvester Core blocks terminating the main script while it's acquiring images.

Describe the bug
Harvester Core blocks terminating the main script while it's acquiring images.

To Reproduce
Steps to reproduce the behavior:

1. Launch a Python interpreter.
2. Prepare an image acquisition manager.
3. Start image acquisition.
4. Strike Ctrl+c.
5. You'll see the interpreter doesn't terminate.

Expected behavior
Signaling an event such as Ctrl+c, Harvester Core should gracefully terminate itself even if it's acquiring images or not.

Screenshots
None.

Desktop (please complete the following information):
None.

Additional context
None.

Some of the GenICam features are not present in the cameras node map

Describe the bug

I noticed that some of the GenICam features (with feature level "Recommended" and "Optional") are not present in the cameras node map. However, I'm not really sure if this is a bug or intented behaviour.

Expected behavior

I would assume that if a camera doesn't have a specific feature implemented, the access mode of the corresponding node should be either 0 or 1.

• OS: Red Hat Enterprise Linux 7.4
• Camera: Point Grey Research, Grasshopper3 GS3-U3-23S6C

The Harvester GUI displays the lower 8bit part of 16bit component formats.

Describe the bug
The Harvester GUI displays the lower 8bit part of 16bit component formats.

To Reproduce
Steps to reproduce the behavior:

1. Launch the Harvester GUI.
2. Start image acquisition with a 16bit component pixel format.
3. See the canvas. You'll see it's not the one you expect.

Expected behavior
The Harvester GUI must display the upper effective 8bit part of a pixel data.

Screenshots
None.

Desktop (please complete the following information):
None.

Smartphone (please complete the following information):
None.

Additional context
None.

Support logging feature.

Is your feature request related to a problem? Please describe.
Supporting the logging feature is vital for people who those use/develop a library. Harvester should also support the logging feature.

Describe the solution you'd like
Support logging feature that relies on Python's logging module.

Describe alternatives you've considered
None.

Additional context
None.

Segmentation fault when ImageAcquisitionManager is created and quit() is called in interpreter

Describe the bug
When Harvester is initialized and ImageAcquisitionManager is created, exiting the interpreter causes a segmentation fault.

To Reproduce
Simply the following code in the interpreter will do:

>>> from harvesters.core import Harvester
>>> h = Harvester()
>>> h.add_cti_file("/path/to/cti_file")
>>> h.update_device_info_list()
>>> iam = h.create_image_acquisition_manager(0)
>>> quit()
Segmentation fault

Expected behavior
Python interpreter should be able exit without the segmentation fault.

Desktop (please complete the following information):

• OS: Red Hat Enterprise Linux 7.4

Support displaying Bayer formats applying appropriate demosaicing algorithm.

Is your feature request related to a problem? Please describe.
As of June 2018, Harvester GUI supports displaying raw Bayer formats but doesn't support applying the appropriate demosaicing algorithm.

Describe the solution you'd like
Bayer formats are very popular today so Harvester GUI should also support it.

It'd be nice if users can switch on or off applying the demosaicing algorithm.

I assume it can be done by implementing the demosaicing algorithm in OpenGL shading language. This should be excel at the performance point of view.

Describe alternatives you've considered
No alternatives.

Additional context
No additional context.

Log buffer manipulation.

Is your feature request related to a problem? Please describe.
We have learned logging might affect the performance on image acquisition but it's pity to not log buffer manipulation such as acquring, fetching, or queueing. Harvester Core should conditionally support logging such actions.

Describe the solution you'd like
If an environment variable HARVESTER_LOG_BUFFER_MANIPULATION then also log the buffer manipulation.

Describe alternatives you've considered
None.

Additional context
None.

Rename the represent_2d_pixel_location.

Is your feature request related to a problem? Please describe.
Shorten the method name. It's not necessary to qualify which dimension is being talked about.

Describe the solution you'd like
Use represent_pixel_location instead.

Describe alternatives you've considered
None.

Additional context
None.