-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Python Queries for D435I #7418
Comments
For example, the link below contains a Python example for exporting to a ply file:
The situation regarding storage may have changed since those past cases. @dorodnic do you have any advice about this, please?
If that is correct and the alternating is governed by the metadata variable RS2_FRAME_METADATA_FRAME_LASER_POWER_MODE then you may be able to query the frame metadata details for this setting with Python code using frame_metadata_value. For example, something like the line below for storing the result in a variable called emitter: emitter= rs.frame.get_frame_metadata(frame, rs.frame_metadata_value.frame_laser_power_mode) |
Hey @MartyG-RealSense , first of all, thanks for your quick response,
|
Saving as a PNG image would result in a loss of depth information.
@dorodnic Is the emitter on-off status exposed in metadata for access in Python please? |
@MartyG-RealSense , I found that similar technique was used here and it looks like it was working, I wonder what is the difference in my case. |
Could you post your script here please so that it can be compared with the one at #6202 |
Below is the code for Python
The equivalent C++ code was also tried with no success
|
Comparing your script with the other one carefully, it looks as though the main difference in the metadata statements is simply that you put rs on the front of the instruction. Your script does: emitter = rs.depth_frame.get_frame_metadata(depth_frame, rs.frame_metadata_value.frame_laser_power_mode) And if your instruction was written in the same way as the other script (using depth_frame instead of df), it would drop the rs. and be: emitter = depth_frame.get_frame_metadata(depth_frame, rs.frame_metadata_value.frame_laser_power_mode) |
@MartyG-RealSense, I'm afraid that does not work as I get another error
|
This error message is also reported in the case in the link below: They are advised to drop the first function that is called in the bracket so that the bracket starts with rs.frame. On your line, that would make it look like this: emitter = depth_frame.get_frame_metadata(rs.frame_metadata_value.frame_laser_power_mode) |
I don't think that should make much difference and as expected, I get the same error as before
I am trying to replicate the scenario mentioned in #6202 |
An easy way to test whether it is a code error or whether retrieval of the laser metadata in this way is not supported would be to simply retrieve frame_counter instead: emitter = depth_frame.get_frame_metadata(rs.frame_metadata_value.frame_counter) |
As I mentioned in my above comment everything such as frame_counter, actual_fps, raw_frame_size, time_of_arrival etc, works but not frame_laser_power_mode or anything similar such as frame_emitter_mode, frame_laser_mode, frame_led_power. |
Please try removing the '5000' out of wait_for_frames(5000) and just have wait_for_frames() instead to check whether or not the wait period is disrupting retrieval of emitter metadata. |
@MartyG-RealSense I'm afraid that does not resolve the issue as well. It still says the frame does not support this type of metadata. I wonder if something is wrong with the way in which the .bag file was generated. Can you confirm whether anything else needs to be done or enabled in the RealSense viewer or pyrealsense to enable collecting such information? |
Anything that was active at the time of recording should get included in the bag data. For example, if you only had the Depth stream active during recording then RGB and IMU data would not be included. Do you know whether the IR Emitter was enabled during the bag recording? |
@MartyG-RealSense The emitter was turned on as well as the feature mentioned in #3066 with the Emitter On Off setting in the Intel RealSense Viewer. |
@MartyG-RealSense , I think it might be that metadata is not supported in Kernal 5.4 as mentioned in #6368. |
I have not seen reports of metadata problems with kernel 5.4. Support for the kernel is referenced here: |
I note that in your specification at the top of this case you list that you are using firmware 5.11.15.0. |
@MartyG-RealSense I will check the same and update you if I find something. |
@MartyG-RealSense I could not test anything for a week hence the delay, but your suggestion works after updating to 5.12 I could access the metadata. This issue can be closed. |
Great news - thanks for the update! |
Before opening a new issue, we wanted to provide you with some useful suggestions (Click "Preview" above for a better view):
All users are welcomed to report bugs, ask questions, suggest or request enhancements and generally feel free to open new issue, even if they haven't followed any of the suggestions above :)
Issue Description
The text was updated successfully, but these errors were encountered: