6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5805
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Stereoscopic camera capture - now implemented.

Thu Jun 30, 2016 9:39 am

SebK wrote:Thanks for the quick and detailed reply! I will follow your instructions regarding the debug output and post my results.

Also good to know that the size restriction should only apply to the image width. Strange thing though that I was unable to record a full height top-bottom video in 640x960. That only resulted in a 29 byte output file. I will try this again to confirm.
It's possible that there is something generally up with top/bottom - stereoscopic isn't something I've rigourously tested for regressions. "Recent" work has only been making sure I could run a few recordings with the V2.1 cameras, testing on the CM3, and a fix for MJPEG encoding (https://github.com/Hexxeh/rpi-firmware/ ... 3aaaf14d62).
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

SebK
Posts: 7
Joined: Wed Jun 29, 2016 3:18 pm

Re: Stereoscopic camera capture - now implemented.

Thu Jun 30, 2016 10:23 am

Update:
I added start_debug=1 to the /boot/config.txt, restarted the CM and tried to record a video with the following command

Code: Select all

raspivid -3d tb -w 640 -h 960 -o tbfull.h264
The result of this is the expected 26 byte (correction: not 29 as stated previously) output file.
The call of sudo vcdbg log assert only printed the following line

Code: Select all

002967.380: assert( card not initialised ) failed; ../../../../../filesystem/media/sdcard/sdcard.c::sdhost_close line 1045
Side note: The problem also becomes apparent in the preview window. When I call the above raspivid command the preview picture is frozen. Oddly, it is not frozen if I do not specify an output file.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5805
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Stereoscopic camera capture - now implemented.

Thu Jun 30, 2016 10:45 am

OK, thanks for running those checks - saves me a few minutes.
I have my CM stereoscopic setup with me, so I'll fire it up at lunchtime to see if there is anything obviously wrong.

If you don't specify an output file then the encoder is never activated and the image format remains as planar.

That has given me a little thought as to a tweak on buffer allocations that was made a while back.
I don't know if you've rebuilt raspivid before, but a quick mod to
https://github.com/raspberrypi/userland ... id.c#L1458

Code: Select all

   //  set up the camera configuration
   {
      MMAL_PARAMETER_CAMERA_CONFIG_T cam_config =
      {
         { MMAL_PARAMETER_CAMERA_CONFIG, sizeof(cam_config) },
         .max_stills_w = state->width,
         .max_stills_h = state->height,
         .stills_yuv422 = 0,
         .one_shot_stills = 0,
         .max_preview_video_w = state->width,
         .max_preview_video_h = state->height,    //!!! INCREASE ME
         .num_preview_video_frames = 3 + vcos_max(0, (state->framerate-30)/10),
         .stills_capture_circular_buffer_height = 0,
         .fast_preview_resume = 0,
         .use_stc_timestamp = MMAL_PARAM_TIMESTAMP_MODE_RAW_STC
      };
to increase that buffer height by a bit (eg an extra 128 lines) may be the answer. Some extra vertical padding got added to the encoder's image format, but I wonder if it got forgotten about that it needed to be added to each channel, and then we'll fail to be able to allocate the needed iamges as the buffer is too small.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5805
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Stereoscopic camera capture - now implemented.

Thu Jun 30, 2016 1:16 pm

The change I was thinking of was back in Nov 2015, so quite a while ago.

Using the command

Code: Select all

raspivid -3d tb -w 640 -h 960 -o tbfull.h264
with the image I happened to have lying around on my CM and it worked fine, and then played back fine with omxplayer as a top/bottom split.
I've done an rpi-update to get the latest firmware and that is OK too without modifying raspivid.

Add in -dec and it does stall the pipe. I can see in the logging that it is failing to get any buffers.
If I change the line I'd suspected to being ".max_preview_video_h = state->height*2," then it works. +128 didn't, so something is well off.
I need to dig into the firmware code to see which level is going wrong, but at least we've got a workaround for now.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

SebK
Posts: 7
Joined: Wed Jun 29, 2016 3:18 pm

Re: Stereoscopic camera capture - now implemented.

Thu Jun 30, 2016 4:27 pm

I am currently running version 1.3.12 of raspivid. Since it seems I am not doing something wrong with the program calls I will try to update the firmware via rpi-update and check if I can get your 640x960 example to work, too. :D

I'll try to update the userland raspivid source code according to your suggestions and post the results.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5805
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Stereoscopic camera capture - now implemented.

Thu Jun 30, 2016 4:33 pm

SebK wrote:I am currently running version 1.3.12 of raspivid.
Er, yes, we're very bad at bumping that revision string in any of the raspicam apps :-/ The firmware and kernel version are much more significant.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

SebK
Posts: 7
Joined: Wed Jun 29, 2016 3:18 pm

Re: Stereoscopic camera capture - now implemented.

Fri Jul 01, 2016 1:17 pm

Hehe, ok, I'll stick to firmware and kernel versions from now on. :D
uname -a gives me
Linux rpicompute 4.4.14+ #895 Sun Jun 26 13:39:34 BST 2016 armv6l GNU/Linux
and vcgencmd version gives me
Jun 27 2016 17:25:36
Copyright (c) 2012 Broadcom
version 1e7b8e2c9a7319f7b22869f1334c66e2cfc99f4a (clean) (release)
after I performed an update via rpi-update

The built in raspivid still gives no successful result at 640x960 pixels in tb mode.
I changed line 1458 in userland/host_applications/linux/apps/raspicam/RaspiVid.c to

Code: Select all

.max_preview_video_h = state->height*2
and recompiled. My custom build now allows 640x960 full tb 3d videos but none in decimate format.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5805
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Stereoscopic camera capture - now implemented.

Fri Jul 01, 2016 1:38 pm

SebK wrote:
Linux rpicompute 4.4.14+ #895 Sun Jun 26 13:39:34 BST 2016 armv6l GNU/Linux
and vcgencmd version gives me
Jun 27 2016 17:25:36
Copyright (c) 2012 Broadcom
version 1e7b8e2c9a7319f7b22869f1334c66e2cfc99f4a (clean) (release)
after I performed an update via rpi-update
That sounds pretty reasonable.
SebK wrote:The built in raspivid still gives no successful result at 640x960 pixels in tb mode.
I changed line 1458 in userland/host_applications/linux/apps/raspicam/RaspiVid.c to

Code: Select all

.max_preview_video_h = state->height*2
and recompiled. My custom build now allows 640x960 full tb 3d videos but none in decimate format.
I'll have to retest.
Can I ask if you're using the V1.3 5MPix or V2.1 8MPix camera boards? It shouldn't make a difference, but something obviously is. FYI I'm using 2 V2.1 8MPix sensors.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5805
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Stereoscopic camera capture - now implemented.

Fri Jul 01, 2016 2:35 pm

I've just had a look at the code handling buffer size calcs for stereoscopic images. It does forget to look at the decimation flag on top/bottom, so will try to allocate twice the height it needs.

I still can't quite see why it doesn't work for you when you've increased max_preview_video_h, but I'll look instead at fixing the firmware than further hacks to userland. In the meantime, try increasing that value further as I'm fairly certain it is that that is going wrong.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

SebK
Posts: 7
Joined: Wed Jun 29, 2016 3:18 pm

Re: Stereoscopic camera capture - now implemented.

Fri Jul 01, 2016 5:12 pm

6by9 wrote:Can I ask if you're using the V1.3 5MPix or V2.1 8MPix camera boards? It shouldn't make a difference, but something obviously is. FYI I'm using 2 V2.1 8MPix sensors.
Good point. I am indeed using a different camera board than you: the V1.3 5MPix camera board.

SebK
Posts: 7
Joined: Wed Jun 29, 2016 3:18 pm

Re: Stereoscopic camera capture - now implemented.

Tue Jul 05, 2016 6:01 pm

6by9 wrote: I still can't quite see why it doesn't work for you when you've increased max_preview_video_h, but I'll look instead at fixing the firmware than further hacks to userland. In the meantime, try increasing that value further as I'm fairly certain it is that that is going wrong.
Increasing the initial value times 4 did the trick for me. I successfully tested recording a decimate tb video with 1792x1080 pixels and a full height tb video with 640x960 pixels.

jholster
Posts: 9
Joined: Fri Nov 27, 2015 5:11 am

Re: Stereoscopic camera capture - now implemented.

Sun Aug 14, 2016 7:38 pm

I'm also having the "stalled pipeline" problem with top-bottom mode, i.e. nothing comes out from raspivid. The SBS mode works fine. Here is my setup:

Compute module with dual 5 megapixel cameras

$ vcgencmd version
Aug 10 2016 20:40:48
Copyright (c) 2012 Broadcom
version c62d8dc8087e79a3e3e16846fc37ac9efa878731 (clean) (release)

$ uname -a
Linux alarmpi 4.4.17-1-ARCH #1 Fri Aug 12 20:11:01 MDT 2016 armv6l GNU/Linux

$ vcgencmd get_camera
supported=2 detected=2

$ cat /boot/config.txt
gpu_mem=256
start_x=1

$ raspivid -3d tb --mode 4 --nopreview -t 0 -o - | hexdump
(no output)

$ raspivid -3d sbs --mode 4 --nopreview -t 0 -o - | hexdump
(works; bytes flow)

I have tested various combinations of --width (divisible by 128), --height, --mode, -fps, and --decimate parameters. As long as -3d tb is enabled, the stream does not start at all.

Not strictly related but for general interest: I'm piping the h264 stream over wifibroadcast to another Pi connected to OSVR headset. The OSVR display has smallest latency in 1080x1920 native mode because the LCD is refreshed "sideways", thus the need for top-bottom mode & 90 degree rotated cameras. The 1080x1920 mode technically works also with SBS stream with display_rotate=3 in /boot/config.txt, but the rotation causes multi-second latency, not suitable for realtime video (FPV flying). Anyway, I've verified with mono stream that the whole chain mostly works, the only remaining major problem being TB output from raspivid.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5805
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Stereoscopic camera capture - now implemented.

Mon Aug 15, 2016 10:45 pm

jholster wrote:I'm also having the "stalled pipeline" problem with top-bottom mode, i.e. nothing comes out from raspivid. The SBS mode works fine. Here is my setup:
...
$ raspivid -3d tb --mode 4 --nopreview -t 0 -o - | hexdump
(no output)

$ raspivid -3d sbs --mode 4 --nopreview -t 0 -o - | hexdump
(works; bytes flow)

I have tested various combinations of --width (divisible by 128), --height, --mode, -fps, and --decimate parameters. As long as -3d tb is enabled, the stream does not start at all.

Not strictly related but for general interest: I'm piping the h264 stream over wifibroadcast to another Pi connected to OSVR headset. The OSVR display has smallest latency in 1080x1920 native mode because the LCD is refreshed "sideways", thus the need for top-bottom mode & 90 degree rotated cameras. The 1080x1920 mode technically works also with SBS stream with display_rotate=3 in /boot/config.txt, but the rotation causes multi-second latency, not suitable for realtime video (FPV flying). Anyway, I've verified with mono stream that the whole chain mostly works, the only remaining major problem being TB output from raspivid.
I've only done a quick test, and admittedly with dual 8MPix cameras, but top-bottom mode appears to be working for me.
I've just done an rpi-update, so that is a clean firmware.
As noted above, there is something that is wrong in the firmware that I still need to address. Doubling .max_video_height let it run for me. I'm a touch out of date with the firmware source (I need to pop into Pi Towers and update), so it's possible that the firmware has been fixed, but I'd be surprised.

I'll retest tomorrow with dual 5MPix cameras. I'm not expecting it to be different, but we'll see. If I can get updated then I'll try addressing the firmware issue. I'll also drop back to a CM1, just in case.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

jholster
Posts: 9
Joined: Fri Nov 27, 2015 5:11 am

Re: Stereoscopic camera capture - now implemented.

Thu Aug 18, 2016 6:17 am

6by9 wrote:Doubling .max_video_height let it run for me.
The mentioned max_preview_height modification to RaspiVid.c only fixes the live preview problem, am I right? I'm using --nopreview flag so this must be different issue.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5805
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Stereoscopic camera capture - now implemented.

Thu Aug 18, 2016 7:06 am

jholster wrote:
6by9 wrote:Doubling .max_video_height let it run for me.
The mentioned max_preview_height modification to RaspiVid.c only fixes the live preview problem, am I right? I'm using --nopreview flag so this must be different issue.
No, the max_preview_ parameters defines the max size of images to be allocated for preview or video encode. It therefore totally applies in your case.
Nopreview also doesn't totally disable preview, just redirects it to a nullsink component.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

jholster
Posts: 9
Joined: Fri Nov 27, 2015 5:11 am

Re: Stereoscopic camera capture - now implemented.

Fri Aug 19, 2016 4:19 am

I can confirm that max_preview_height modification works for me as well, if I set --height to single channel height instead of total height (unlike -3d sbs which takes --width as total width i.e. doubled).

I still have problems with playback geometry but that's maybe another problem.

rodizio
Posts: 39
Joined: Sat May 07, 2016 2:40 am

Re: Stereoscopic camera capture - now implemented.

Mon Nov 07, 2016 11:56 am

I have recently played around with 3D live video on the Pi (by running two Pi's with two cams as transmitters and modified hello_video.bin instances on the receivers, one rendering the left image, the other rendering the right image as a quick hack), but got really sick after 2 minutes. This doesn't happen when playing side by side 3D videos on Youtube though.

After reading up on that topic, I found this is probably caused by un-synchronized frame display between the left and right eye.


Is frame capture synchronized when using the compute module and two cameras with raspivid 3d modes?

Is there a way to synchronize frame capture (maybe not perfect, but as good as possible) when using two Pi Zeros instead of a compute module? Maybe by using the serial or GPIO ports to synchronize? Since the compute module is quite big, and there is no Pi3 CM available, I'd rather use two Pi Zeros.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5805
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Stereoscopic camera capture - now implemented.

Mon Nov 07, 2016 12:27 pm

rodizio wrote:I have recently played around with 3D live video on the Pi (by running two Pi's with two cams as transmitters and modified hello_video.bin instances on the receivers, one rendering the left image, the other rendering the right image as a quick hack), but got really sick after 2 minutes. This doesn't happen when playing side by side 3D videos on Youtube though.

After reading up on that topic, I found this is probably caused by un-synchronized frame display between the left and right eye.
That, and also that the 2 images aren't well enough aligned to avoid confusing the brain. Ideally you would apply a geometric distortion to calibrate the camera rig, but that does require an accurate calibration process for every system - not totally practical.
rodizio wrote:Is frame capture synchronized when using the compute module and two cameras with raspivid 3d modes?
The 2 cameras are on independent oscillators, so they will drift over time. Generally speaking you should be good for around 15minutes based on typical oscillator tolerances.
The GPU does get a usec accurate timestamp at the start of each frame from each sensor. It is on my list of things to play with to insert minor frame rate alterations on one sensor to keep it closer in sync with the other, but it's a pretty low priority.
rodizio wrote:Is there a way to synchronize frame capture (maybe not perfect, but as good as possible) when using two Pi Zeros instead of a compute module? Maybe by using the serial or GPIO ports to synchronize? Since the compute module is quite big, and there is no Pi3 CM available, I'd rather use two Pi Zeros.
Serial - not really viable. GPIO - potentially possible based on the small changes in frame rate approach mentioned above. You've got an issue in that userland hasn't got close enough access to the frame events or GPIO to make it truly accurate. It does get the accurate timestamps, but you then have to synchronise clocks between the devices, which is a bigger job in itself.

CM is the same size as a SODIMM - 67x32mm. Zero is 65x30mm. Not a huge difference, although you do need to make up a carrier board for the CM which will add to the thickness (shouldn't need to add to the width much).
Yes the standard CMIO board is bigger, but that is only intended as a basic dev kit rather than to be used in products.
CM1 is the same spec as the PiZero, so I don't quite get your comparison there. CM3 is imminent, but I don't know exact timescales.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

rodizio
Posts: 39
Joined: Sat May 07, 2016 2:40 am

Re: Stereoscopic camera capture - now implemented.

Mon Nov 07, 2016 11:11 pm

Thanks for the info. Sounds not too good though ...

When I spoke of the compute module, I meant complete with I/O board, designing and building a smaller solution would be too much effort.

Reason for two Pi Zeros being better than one compute module is simple: It's twice the horsepower ;) There are additional forward error correction packets being sent, these need CPU ressources, the Pi0 is already maxxed out with around 6Mbit raspivid video bitrate ...

tomas1k
Posts: 1
Joined: Thu Jan 26, 2017 3:10 pm

Re: Stereoscopic camera capture - now implemented.

Thu Mar 09, 2017 5:18 pm

First of all, thanks to 6by9 for his hard work on this matter.

After all these post and information I'm trying to get an idea of where are we now with respect to 3d stream resolutions using the compute module.

I just bought a CM3 with the I/0 board and 2 v2.1 NOIR cameras. I wonder if with the new CM3 the allowed resolutions to create 3d streams have changed. Can somebody point out in which state is this problem now? It would be nice to have a reference table of resolutions and frame rates for the stereoscopic video.

Besides, I read that the V4L2 has been made oficial and that now it is part of the kernel. Is v4l2 capable of higher resolutions for the stereo mode?

Finally, I read in this same thread that Motion JPEG do not have the h264 limitations. Which limitation does it have? can we do TB full hd? Side-by-side 720p?

Thanks,
Tomás.

RealityWizard
Posts: 5
Joined: Sun Jan 15, 2017 1:06 am

Re: Stereoscopic camera capture - now implemented.

Tue Mar 14, 2017 9:45 pm

I am looking into making a 3D video recording and want to use just one pi. I have not read all of the preceding posts (there are a lot) and do not know for sure where this has gone, but it seems that it is still underdeveloped. What I want to do is possibly use a USB 3D camera such as the kinect or intel realsense or a 3D webcam. This should be relatively easy.

I would really appreciate any input into this project as I am quite the new user.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5805
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Stereoscopic camera capture - now implemented.

Wed Mar 15, 2017 9:46 am

tomas1k wrote:I just bought a CM3 with the I/0 board and 2 v2.1 NOIR cameras. I wonder if with the new CM3 the allowed resolutions to create 3d streams have changed. Can somebody point out in which state is this problem now? It would be nice to have a reference table of resolutions and frame rates for the stereoscopic video.
Same GPU, therefore no fundamental differences in what is supported.
A list could be produced, but it'd be a long one so not necessarily helpful. Which output formats did you want included - there are about 10 options (some will be the same)? Adding in the options off the two camera modules doubles the permutations too.

The main restriction is still the H264 block needing a multiple of 128 per image and <=1920 wide. There is now the option to select H264 level 4.2 and overclock the block, but that's not going to magically make the hardware support 1080P60, just avoid the software sanity checks of what the hardware is specified to cope with under all situations.
The limit at 1344 high is something set up incorrectly that should be possible to fix if I can find the time. There is still a maximum limit which looks to be 2048 lines, so 1080P TB is still just out of reach.

The ISP should be able to manage 120MPix/s fairly easily, and potentially >160MPix/s (it depends on how efficiently you keep it stacked with work), and that's without overclocking.
tomas1k wrote:Besides, I read that the V4L2 has been made oficial and that now it is part of the kernel. Is v4l2 capable of higher resolutions for the stereo mode?
The V4L2 API has no support for stereoscopic at all. I wasn't going to create custom controls for it.
Being in the kernel has no significant advantage as all the heavy lifting is done on the GPU.
tomas1k wrote:Finally, I read in this same thread that Motion JPEG do not have the h264 limitations. Which limitation does it have? can we do TB full hd? Side-by-side 720p?
MJPEG doesn't have the limitation on max width, but the standard plumbing on raspivid is likely to still have restriction on multiples of 128. Replumbing it to connect camera->output[0] (normally used for preview) to the encoder may avoid that. IIRC The max pixel rate through JPEG is around 180MPix/s.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5805
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Stereoscopic camera capture - now implemented.

Wed Mar 15, 2017 10:20 am

RealityWizard wrote:I am looking into making a 3D video recording and want to use just one pi. I have not read all of the preceding posts (there are a lot) and do not know for sure where this has gone, but it seems that it is still underdeveloped. What I want to do is possibly use a USB 3D camera such as the kinect or intel realsense or a 3D webcam. This should be relatively easy.
This is an inappropriate thread to be posting on then - it is all about stereoscopic support using a pair of Pi cameras.
"Underdeveloped" implies something is missing that you want, but you've not said what. Development resource on the firmware is limited, and stereoscopic is of interest to very few Pi owners as it requires a ComputeModule. It therefore gets a fairly low priority unless there is a big issue.

Intel Realsense and Kinnect are more about depth mapping than stereoscopic. AIUI They are generally either monochrome or IR sensors with back end processing. Some allow you to get the raw images, but the format of those image varies significantly.
What a random USB 3D camera does is unknown. Is it colour or mono? Which pixel format? How is it controlling 3D seeing as V4L2 has no API calls for it?

What are you wanting to do with the images? Most USB webcams produce the YUYV image format which is not widely used on the GPU, so don't expect to be able to pass it into the H264 or MJPEG encoder for example.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

ethanol100
Posts: 540
Joined: Wed Oct 02, 2013 12:28 pm

Re: Stereoscopic camera capture - now implemented.

Wed Feb 14, 2018 6:39 pm

I have a problem, when I select for example "-md 5" in "-3d sbs" mode both cameras using a different camera mode.

Code: Select all

raspivid -cd MJPEG -b 25000000 -fps 40 -md 5 -w 3072 -h 1232 -v -ss 3000 -ag 4 -dg 1 -awb off -awbg 1,1 -o test.mjeg
Result:
Image

Do I break any rule for 3D stereo here?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5805
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Stereoscopic camera capture - now implemented.

Wed Feb 14, 2018 7:09 pm

ethanol100 wrote:
Wed Feb 14, 2018 6:39 pm
I have a problem, when I select for example "-md 5" in "-3d sbs" mode both cameras using a different camera mode.

Code: Select all

raspivid -cd MJPEG -b 25000000 -fps 40 -md 5 -w 3072 -h 1232 -v -ss 3000 -ag 4 -dg 1 -awb off -awbg 1,1 -o test.mjeg
Result:
Image

Do I break any rule for 3D stereo here?
You look OK. At a guess I'm missing a call to the second sensor to select mode 5, so it's defaulting to something else. I'll have a look tomorrow.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Return to “Camera board”