Cannot swap camera lens. No supported surface combination is found for camera device - Id 1

[re.le...@gmail.com]

Hello!

I have an issue with not being able to change camera lens to front camera.

Issue happens on Samsung s8+(Android 8 and Android 9) and Samsung s6(Android 7). 

On Motorola One Action(Android 10) I have no such issues as well as one custom Android device running Android 9 are switching lens as intended.

Furthermore I had no such issues in past. Unfortunately I dont know exactly on which CameraX version it did work fine. 

Also I am unbiding/binding all the time when setting different ISO, exposure options etc. through Camera2Interop and that seem to work as intended on all devices. It just does not want to unbind and then bind to new lens. 

Here is the picture of log when error happens.

From the logs it is visible that I am trying to pass adequate lens integer to CameraSelector, besides it works fine on Motorola.

I will try to test it out on other devices as well.

Thank you in advance.

[Scott Nien]

Hi , 

Can you try the CameraXBasic to see if the switching camera is working ?  Please update the CameraX version to rc01 if you are not using latest version of CameraXBasic. 

That will help us quickly clarify whether it is a issue of your custom logic or not.  
If the issue does not happen on CameraXBasic but only on your app,  it would be useful if you can share some code snippets. 

--
You received this message because you are subscribed to the Google Groups "Android CameraX Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to camerax-develop...@android.com.
To view this discussion on the web visit https://groups.google.com/a/android.com/d/msgid/camerax-developers/4fbe1dcb-cd27-4a64-8209-ac70203856den%40android.com.

[Charcoal Chen]

Hi,

In the attached log screenshot, some informations are truncated. The following line of log information might be helpful to clarify this issue.

    java.lang.IllegalArgumentException: No supported surface combination is found for camera device - Id : 1. May be attempting to bind too many use cases. Existing surfaces: [] New configs: [androidx.camerea??????????????

Could you please provide the following information to clarify this issue?

1. The rest part of above line of log.

2. The hardware level of the front camera of the Samsung S8+ and S6 devices.

3. What use cases were bound to the camera and what were the configurations when creating those use cases? For example, target rotation or target resolution might be set for these use cases.

[re.le...@gmail.com]

Hello!

Thanks for the fast response.

CameraXBasic works fine. 

I was able to track down the issue and I am able to switch cameras.

So the problem was I was setting imageBufferFormat on ImageCapture use case to YUV_420_888 and apparently some camera sensors can handle this format some dont. 

Unfortunately I really need this image format to be used by capture use case. I am doing image analysis in this format on background image stream(ImageAnalysis use-case) and captured pictures also need to go through same post-process in this exact type without any additional compression or conversion if possible. 

I need to trigger this method: public void onCaptureSuccess(@NonNull ImageProxy image) where I can get ImageProxy from capture and post-process it. 

Thanks for the help in advance.

[re.le...@gmail.com]

Edit/Update

Just to correct my self I am already trigering this type of capture: public void onCaptureSuccess(@NonNull ImageProxy image)  so no problems there. 

It also seems I dont really need YUV on capture, rather any uncompressed image will do as long as its not already compressed. 

Upon my initial testing ImageProxy.getFormat() seems to return JPEG.

Thanks for your replies. 

[Charcoal Chen]

Hi,

The supported streams configurations depend on the camera device's capability. CameraX encoded the guaranteed configurations tables listed in CameraDevice#regular-capture web doc. According to the provided information, your requirement is to have streams configuration composed of PRIV (for Preview) + YUV (for ImageAnalysis) + YUV (for ImageCapture). Only FULL-level or LEVEL-3 camera devices can support it.

A workaround approach currently I can think is, maybe your can implement your own SurfaceProvider for Preview and register to receive image frame data for image analysis. By this way, you will only need two streams that might be PRIV + YUV supported by LEGACY-level or YUV + YUV supported by LIMITED-level camera device. BTW, in this way, the image obtained by ImageCapture can't reach the maximum size supported by the device. You can refer to the guaranteed configurations tables listed in CameraDevice#regular-capture web doc. It might be limited as PREVIEW size on LEGACY-level device or RECORD size on LIMITED-level device.

[re.le...@gmail.com]

Hi, 

Thanks for response. 

I checked tables you sent. This will be some valuable information. I might try YUV+YUV. It seems that most devices will have at least LIMITED HW level for any given camera sensor... but I might be wrong. 

Also it seems that LIMITED combination of YUV+YUV+JPEG might be good. But can I have JPEG on Preview and YUV on both ImageAnalysis and Capture? As I cant find any method on Preview class to set image format. Is this possible by implementing a custom Preview or SurfaceProvider?

Thanks in advance

[Martin Schulze]

I hope I can contribute a bit here. I am working on an app that has all three use cases (preview, analysis, still capture) and my colleague is migrating it from Camera2 to CameraX.

We hit the same wall on the Galaxy A50: Our app wants to give the user a preview, do live analysis for automatic capture and do some "offline" analysis on the fullsized, captured image in lossless (YUV) format.

Using two YUV readers was already a problem with Camera2 on the A50. We solved the issue by having our full size capture go into a Renderscript allocation's input surface instead of an ImageReader.  I assume that this transformed the underlying session from PRIV+YUV+YUV to PRIV+PRIV+YUV.

[Martin Schulze]

I just noticed that my previous post might be a bit unclear on that: Our fix described above was only on Camera2. We have not yet found a way to convince CameraX to do the same.

[re.le...@gmail.com]

Hi, 

Well, for the time being I resorted to simple solution. I rewired capture command to not issue capture command to CameraX pipeline, but rather this command takes an Image that is at given time in ImageAnalysis use case callback. This does not provide max resolution image but for now it offers a quick and easy workaround for getting YUV image. 

This is for sure not ideal and I will have to find more permanent solution... but hey, it works and its an uncompressed image :)

[Eino-Ville Talvala]

Hi Martin,

I'm actually somewhat surprised that worked, and it may be a fix that only applies to some subset of devices.  Renderscript generally actually asks for YUV under the hood as well, but it's probably somewhat device-specific. But either way, a full-resolution PRIV is just as unsupported in general as full-resolution YUV on the more limited camera devices.  We keep pushing the manufacturers to improve their camera support to make workarounds like that less necessary.

But I'm glad you found a path that works for you, on that particular device.

- Eddy

————————————————————
authentic.network
INDUSTRY365 UG (haftungsbeschränkt) 
Beckerstraße 13
09120 Chemnitz
Deutschland

Telefon:   +49 371 40 08 450
E-Mail: he...@authentic.network

--
You received this message because you are subscribed to the Google Groups "Android CameraX Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to camerax-develop...@android.com.

To view this discussion on the web visit https://groups.google.com/a/android.com/d/msgid/camerax-developers/831cf5d9-75e5-478b-9d17-bc6e11bc6740n%40android.com.

[Martin Schulze]

> This does not provide max resolution image but for now it offers a quick and easy workaround for getting YUV image. 

Unfortunately, this does not work for us. We need at least around 2000 pixels on the shorter side for our usecase which is pushing against the limits of what some devices can do.

> I'm actually somewhat surprised that worked, and it may be a fix that only applies to some subset of devices.  Renderscript generally actually asks for YUV under the hood as well, but it's probably somewhat device-specific.

I was surprised too. It was an accidental fix. However, having a working solution with Camera2 makes it much more painful to loose again with CameraX.

I must admit, that I only guessed at what might be the underlying cause, since we previously simply had a YUV ImageReader and that would fail. So I just assumed that it would not be using a YUV reader.

Just in case it matters: we only use Renderscript for conversion to a RGBA buffer which is then consumed via C++ code. So we'd be okay with lossless RGBA output too.

> But either way, a full-resolution PRIV is just as unsupported in general as full-resolution YUV on the more limited camera devices. 

I guess we could live with only supporting hardware level "full" and above. 

However,  our device database shows many devices where android.scaler.mandatoryStreamCombinations says it supports YUV (FHD) +YUV (Full Resolution) capture, even on some limited devices like the A10 or A51.

Others don't report android.scaler.mandatoryStreamCombinations but may work too.

Each additional device that works is a plus for us.

> But I'm glad you found a path that works for you, on that particular device.

Well, the workaround does not work on CameraX but we'd really like to profit from the simplified code. The A50 is especially problematic: due to its big market share, we cannot ignore this device.

It seems the whole Galaxy A series show the same problem and improvement on Camera2.

We looked into workarounds with CameraX, e.g. getting a full resolution image for analysis. 

However, even if the device would support that, we cannot request more than full HD through CameraX. We'd be okay with only ~2-5FPS on the analysis stream.

In the end we want to support as many devices as possible, so we'd really like to be able to go to full resolution wherever available.