Skip to content
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

Use kYUV422 images to increase the acquisition frequency #84

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jokla
Copy link

@jokla jokla commented Mar 10, 2017

Get kYUV422 images from the 2D cameras and convert them after to RGB. The image is lighter, it has 2 channels instead of 3. This allows getting VGA images from one camera at 15Hz instead of 9Hz using WiFi at 5GHz.

@nlyubova
Copy link
Member

Hello,
it seems that using compressed images helps to improve the frame rate.

Therefore, I would prefer not to merge this PR now.

@jokla
Copy link
Author

jokla commented Nov 14, 2017

Hi!

I agree with you, using compressed images will help on the PC side.
The pull request aimed to transfer a lighter image from the robot to the PC (via Ethernet or WiFi).
In my case, I needed to get images from both cameras simultaneously, and this was a way to get a good frequency over WiFi (that was the bottleneck).

@Karsten1987
Copy link
Contributor

Would it make sense to modify this PR so that you could use the kYUV422 image format via the boot_config.json ?

@nlyubova
Copy link
Member

@Karsten1987 it seams that we can get same or higher rate using compressed RGB images and there is no significant difference in quality, and they are available by default

@jokla
Copy link
Author

jokla commented Jan 19, 2018

@Karsten1987 Unfortunately I don't have a Pepper robot to modify the PR and test it.

If this PR is not useful anymore we can close it for me. Thanks!

@nlyubova
Copy link
Member

@jokla your PR is useful anyway. It would be good to have both YUV and RGB implemented.
However, it will be hard to test now if you don't have Pepper and me neither...

By the way, did you try compressed RGB last time?

@jokla
Copy link
Author

jokla commented Jan 20, 2018

@nlyubova I have never tried the compressed RGB. I think it was implemented after I stop working with Pepper.
I agree that it would be nice to have both implemented. Probably together they would allow to get images simultaneously from both cameras at high resolution and at a good frame rate.

Copy link
Member

@nlyubova nlyubova left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I propose to keep RGB format by default and merge it, in case if it works for both Pepper and Nao

@@ -126,7 +121,7 @@ CameraConverter::CameraConverter( const std::string& name, const float& frequenc
camera_source_(camera_source),
resolution_(resolution),
// change in case of depth camera
colorspace_( (camera_source_!=AL::kDepthCamera)?AL::kRGBColorSpace:AL::kRawDepthColorSpace ),
colorspace_( (camera_source_!=AL::kDepthCamera)?AL::kYUV422ColorSpace:AL::kRawDepthColorSpace ),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please keep RGB by default?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants