-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Image::data() uses bp_size to return a slice. #11
Comments
The image struct could have a pixel_type. |
Would it be a proper way to handle this problem? |
1 similar comment
Would it be a proper way to handle this problem? |
PR #12 fixes the issue. However, under normal circumstances this problem should not appear. "bp_size" should be the correct size of the buffer, even in unsafe mode. I could not reproduce the 0 in bp_size. Can you please let me know what you did to get this behavior? It is most likely a bug in the C API. |
I had a strange bug with my camera: image.data() returns an empty slice. I set the camera in unsafe mode.
If I understood correctly, In unsafe mode, bp_size is 0. This value is used by data to return an empty slice.
The data() function uses the following code to build the slice:
let length = self.xi_img.bp_size as usize / size_of::();
I think it would not work in the case of padding as well.
The type of T is u8. If the image is in RGB24, for instance, the calculation is wrong.
I suggest the implementation of a data_unsafe() that would take in template argument the XI image type (XI_RGB24), and deduce the buffer size from width and height. It would work only for buffers with no padding.
In the streamViewer c++ example, there is an example of how to extract the data according to the pixel type.
The text was updated successfully, but these errors were encountered: