Thank you for your answer.
Actually i am working on a module based on NXP imx8 processor. ( linux)
The module includes also two microdisplays which are managed by MachXO2
fpga. Data or images displayed in the microdisplays come from hdmi input.
I have lenses in front of each microdispaly, so we see deformations.
Firstly i thougth that the deformations seen come from
the source ( hdmi video input) thas is why i was looking for a way to
capture the HDMI video input and apply cameracalibte and cameraundistort
filters to it.
Then i realized that the deformations are due to lenses placed in front
of each microdisplay. When i removed them i didn't see any distortion.
The issue or the question : is there any way to correct this distortion
using gstreamer elements while keeping my optic (lenses).
I tried to be clear so that you could understand my issue and you could help
me.
Best regards
Related
I have a custom USB camera with a custom driver on a custom board Nvidia Jetson TX2 that is not detected through openpose examples. I access the data using GStreamer custom source. I currently pull frames into a CV mat, color convert them and feed into OpenPose on a per picture basis, it works fine but 30 - 40% slower than a comparable video stream from a plug and play camera. I would like to explore things like tracking that is available for streams since Im trying to maximize the fps. I believe the stream feed is superior due to better (continuous) use of the GPU.
In particular the speedup would come at confidence expense and would be addressed later. 1 frame goes through pose estimation and 3 - 4 subsequent frames are just tracking the object with decreasing confidence levels. I tried that on a plug and play camera and openpose example and the results were somewhat satisfactory.
The point where I stumbled is that I can put the video stream into CV VideoCapture but I do not know, however, how to provide the CV video capture to OpenPose for processing.
If there is a better way to do it, I am happy to try different things but the bottom line is that the custom camera stays (I know ;/). Solutions to the issue described or different ideas are welcome.
Things I already tried:
Lower resolution of the camera (the camera crops below certain res instead of binning so cant really go below 1920x1080, its a 40+ MegaPixel video camera by the way)
use CUDA to shrink the image before feeding it to OpenPose (the shrink + pose estimation time was virtually equivalent to the pose estimation on the original image)
since the camera view is static, check for changes between frames, crop the image down to the area that changed and run pose estimation on that section (10% speedup, high risk of missing something)
I'm new to ROS and OpenCV and am trying to figure things out. It seems to do anything with vision the camera needs to be calibrated. I found what looks to be a simple method of calibration in the ROS tutorials here: https://wiki.ros.org/camera_calibration/Tutorials/StereoCalibration
However one of the tutorial's assumptions is "a stereo camera publishing left and right images over ROS." I have no idea how to do this. Thanks to anyone that can help me.
This might be a separate issue but when I use the stereo camera in OpenCV it only recognizes it in one index (my built in webcam on my laptop would be 0 and the MYNTEYE would be 1). When it does display it puts both lens views in the same window so it looks like the camera is cross-eyed.
Use MYNT-EYE-ROS-Wrapper for using it
https://github.com/slightech/MYNT-EYE-ROS-Wrapper
Call
roslaunch mynteye_ros_wrapper mynt_camera_display.launch
to run the wrapper
The modified the published topic from minteye node to feed into stereo calibration node accordingly
I'm trying to get the calibration values to put in the m210_stereo_param.yaml, like it's suggested in the official developer website (OnboardSDK for Linux). The objective is to have good values to test the depth perception sample. The website suggest different approach for the calibration, and I chose the OpenCV one.
I found an example of calibration on this Github repository: Opencv - stereo_calibrate_rc (some explanations are given on this link: Stereo Camera Calibration in Opencv 3)
The problem is that after getting the final Matrix (in the intrinsics.yaml and extrinsics.yaml), I modified the values in the m210_stereo_param.yaml, and tried to run the sample. I got this result (which is not correct, even the default values of the m210_stereo_param.yaml had a better result).
Do you have any idea of what is going wrong with the calibration ? It's quite complicated to found a clear approach to get values to put in the yaml.
Solve, the problem was that the xml file containing the list of images need to looks like this :
"data/left01.jpg"
"data/right01.jpg"
"data/left02.jpg"
"data/right02.jpg"
"data/left03.jpg"
...
And mine xml file was more like this :
"data/left01.jpg"
"data/left02.jpg"
"data/left03.jpg"
...
"data/right01.jpg"
"data/right02.jpg"
So, if you use this example, check if your xml file alternate left-right pictures.
I asked the the tech support of DJI and he told me that the M210 does not support the calibration. In this case, you should not have these problems. Just use the original one.
I am trying to replicate the image quality that is achieved when using the Logitech webcam driver to capture a still image.
The Logitech forum has several threads about the subject unfortunately they all point to a website which is down. such as here.
I am currently able to use DirectShow and a frame grabber to capture images, but they are nowhere near the quality of the snapshot button. Could anyone point me to the direction of a working c++/c example of a snapshot button?
After some research I found this about the Still Image pin, is this the correct method for implementing a snapshot like button?
The webcam I am using the c910 and is capable of taking 10 mega-pixel still images.
Thanks for any help.
My best guess, which I'll use to gather some upvotes (or downvotes), and which will be valid until someone disassembles the application or the driver, is:
Something alike http://www1.idc.ac.il/toky/videoproc-07/projects/superres/srproject.html was used at the application level to enhance the resolution of the images collected as a video.
Rationale: having a friend pulling his hair over simpler things inside the driver, I can only imagine how difficult it should be to code such an algorithm INSIDE the driver with extremely limited set of libraries.
I won't mind taking downvotes here, since I'm too interested in this subject, but please have some information available on the subject.
I did not have a chance to deal with this directly, however I suspect that high resolution images captured from the camera are a result of taking a sequence of images followed by "superresolution" post-processing. This functionality might be unavailable via DirectShow API, since it mostly covers video streaming. However, the camera driver might also make it available via Windows Image Acquisition API, where you might have better luck taking oversampled snapshots of the quality you are looking for.
I was trying to get RGBDemo(mostly reconstructor) working with 2 logitech stereo cameras, but I did not figure out how to do it.
I noticed that there is a opencv grabber in nestk library and its header file is included in the reconstructor.cpp. Yet, when I try "rgbd-viewer --camera-id 0", it keeps looking for kinect.
My questions:
1. Is RGBDemo only working with kinect so far?
2. If RGBDemo can work with non-kinect stereo cameras, how do I do that?
3. If I need to write my own implementation for non-kinect stereo cameras, any suggestion on how to start?
Thanks in advance.
if you want to do it with non-kinect cameras. You don't even need stereo. There are algorithms now that are able to determine whether two images' viewpoints are sufficiently different that they can be used as if they were taken by a stereo camera. In fact, they use images from different cameras that are found on the internet and reconstruct 3D models of famous places. I can write you a tutorial on how to get it working. I've been meaning to do so. The software is called Bundler. Along with Bundler, people often also use CMVS and PMVS. CMVS preprocesses the images for PMVS. PMVS generates dense clouds.
BUT! I highly recommend that you don't go this route. It makes a lot of mistakes because there is so much less information in 2D images. It makes it very hard to reconstruct the 3D model. So, it ends up making a lot of mistakes, or not working. Although Bundler and PMVS are awesome compared to previous software, the stuff you can do with kinect is on a whole other level.
To use kinect will only cost you $80 for the kinect off of ebay or $99 off of amazon and another $5 for the power adapter off of amazon. So, I'd highly recommend this route. Kinect provides much more information for the algorithm to work with than 2D images do, making it much more effective, reliable and fast. In fact, it could take hours to process images with Bundler and PMVS. Whereas with kinect, I made a model of my desk in just a few seconds! It truly rocks!