Ask Your Question
2

YUYV/YUV422 in image_transport

asked Apr 09 '11

Tõnu Samuel gravatar image Tõnu Samuel
101 1 2 16

Most of USB webcams used in hobby robotics support YUYV coding natively. Currently both OpenCV and ROS by default convert this image to BGR format and this is not most efficient decicion for most problems. I wrote about it also into OpenCV list:

http://opencv-users.1802565.n2.nabble.com/HSV-image-input-YUYV-image-transport-td6246826.html

Is there are options to keep YUYV image somehow "raw" in image_transport or can new imaeg encoding added to ROS? What is your opinion?

delete close flag offensive retag edit

Comments

Most used cameras and their encodings: PS3 Eye - YUV422 only, Logitech Quickcam Pro 9000 - YUV422 (plus MJPEG, RGB3, BGR3, YU12, YV12), Logitech C910 - YUV422 (plus MJPEG). I see YUV422 is the only and right choice. Those are best and cheap webcams for robotics. Tõnu Samuel (Apr 10 '11)edit
I think I do not wait until others make decicion but write new node. This node attach V4L2 camera, read YUYV image and publish it as three monochrome images on ROS. So anyone can subscribe to BW topic only or take colour channels too. This is fast, efficient and elegant. Tõnu Samuel (Apr 10 '11)edit
I see now related work in camera_umd repository file uvc_cam.cpp. So all we need is standardize YUV422 in ROS. Hey people from WillowGarage, are you listening? Tõnu Samuel (Apr 10 '11)edit
To do this sort of thing someone needs to put it through the REP process. The best people to do this are people who have an unmet use case. http://www.ros.org/reps/rep-0000.html I suggest you take a look, it's not too hard to write a REP and you'll get lots of feedback on the list. tfoote (Apr 11 '11)edit

1 Answer

Sort by » oldest newest most voted
2

answered Apr 09 '11

Eric Perko gravatar image Eric Perko flag of United States
5281 27 53 101
http://ericperko.com/

updated Apr 09 '11

I'd think adding the most standard YUV encodings (how many YUV encodings are there?) to sensor_msgs so that they could be used for the "encoding" field of sensor_msgs/Image would be good. That should let you essentially "pass-through" the YUYV image to another node while maintaining encoding information.

This wouldn't help with code that operates on BGR images (aka basically all of OpenCV) or likely things like image_view, so any inclusion of YUYV into sensor_msgs as a valid encoding might also want to include conversion functions between YUV encoding and BGR encoding (conversion helpers might be better placed somewhere in the image_pipeline).

link delete flag offensive edit

Comments

Seems YUV422 is only one we need. Tõnu Samuel (Apr 10 '11)edit
I'm in favor. Also PrimeSense devices produce YUV422, so we already have some conversion code in the openni_kinect driver that should go into OpenCV instead. As Tully said, someone needs to draft an REP stating exactly what the new encodings are, and how they should be supported in e.g. cv_bridge. Patrick Mihelich (Apr 13 '11)edit

Your answer

Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
[hide preview]

Question tools

Follow

subscribe to rss feed

Stats

Asked: Apr 09 '11

Seen: 445 times

Last updated: Apr 09 '11