Giter Site home page Giter Site logo

Comments (9)

domagojkorman avatar domagojkorman commented on September 22, 2024 1

Not strictly related to this feature request but I am actually very curious what you think of this performance issue. Were you aware that Fotoapparat dropped Camera2 due to this? Do you think they were mistaken?

I am not sure what they mean by "not as performant". I did notice that Camera2 required much more work though.

To keep it short, I agree with your points. This is really short feature request so I will do it myself sometimes today.

Thank you for the explanation.

from android-goldeneye.

domagojkorman avatar domagojkorman commented on September 22, 2024

Hi @zpapp ,

could you please explain to me what is the benefit of this feature?

Generally, the idea behind the library is to not bother whether in the background it uses Camera1 or Camera2 API. Also, I noticed some issues regarding VideoRecording with newer devices using Camera1 API.

from android-goldeneye.

zpapp avatar zpapp commented on September 22, 2024

Hi,

thanks for the quick response!

The most obvious benefit is that it will give the users a way out when (not "if" :) ) it turns out that the isIncompatibleDevice list is incomplete.

A less obvious benefit is that a user may prefer Camera1 for any number of subjective reasons. For example, the authors of Fotoapparat, a library I am sure you are familiar with, decided to not use Camera2 at all because it was "not as performant" as Camera1.

Not strictly related to this feature request but I am actually very curious what you think of this performance issue. Were you aware that Fotoapparat dropped Camera2 due to this? Do you think they were mistaken?

idea behind the library is to not bother whether in the background it uses Camera1 or Camera2 API

Obviously it's not for me to say what goals you should set but from my perspective this seems unnecessarily ambitious. If you manage to create a library that provides a relatively safe and convenient wrapper around both Camera1 and Camera2, that will be an amazing achievement in itself. I sure as hell wouldn't want the additional responsibility of deciding which one is "best" on any one of the thousands of Android device models, multiplied by all the possible Android versions.

I noticed some issues regarding VideoRecording with newer devices using Camera1 API.

Yes, I saw your comments about this on Reddit. I don't see this as a counter-argument to my request. I am not asking you to force the user to use Camera1 instead of Camera2, I am asking for the option to explicitly choose which one they prefer.

from android-goldeneye.

zpapp avatar zpapp commented on September 22, 2024

Thanks for adding the forceCamera1Api function!

Could you please also expose the condition that is otherwise (in the absence of forceCamera1Api) used to select Camera2, as a boolean property on GoldenEye.Builder? I would use this to offer the choice between Camera1 and Camera2 to the user only if the library considers Camera2 a valid option.

So basically this (at the moment):

Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP && isLegacyCamera().not() && IncompatibleDevicesUtils.isIncompatibleDevice(Build.MODEL).not()

from android-goldeneye.

domagojkorman avatar domagojkorman commented on September 22, 2024

Could you please explain the use case and why you think this is needed? I am not sure why would the user ever want to choose manually between Camera1 and Camera2.

from android-goldeneye.

zpapp avatar zpapp commented on September 22, 2024

why would the user ever want to choose manually between Camera1 and Camera2

The reasoning is the same as the one I provided in my second comment in this thread. What it boils down to is that the end user is the ultimate authority when it comes to deciding whether Camera1 or Camera2 works better for them on their particular device.

So I want to offer the users a choice -- except when the library won't let me use Camera2 for whatever reason, in which case there is no choice. This means I need to know what the library is going to do when I don't call forceCamera1Api. Does this make sense?

EDIT: I wanted to mention that I am not sure if GoldenEye.Builder is the most appropriate "home" for this property. In my use case this property would be queried independently from actually building the GoldenEye instance, so I wouldn't necessarily want to create a Builder just to figure out what a builder might do. Depending on how you feel about adding a companion object to an interface, you might want to add it to GoldenEye instead. And then it would have to be a function with a Context parameter.

Something like this:

companion object {
        fun isCamera2Available(context: Context) = Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP
                && isLegacyCamera(context).not()
                && IncompatibleDevicesUtils.isIncompatibleDevice(Build.MODEL).not()

        /**
         * There were more issues than benefits when using Legacy camera with Camera2 API.
         * I found it to be working much better with deprecated Camera1 API instead.
         *
         * @see CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL_LEGACY
         */
        @RequiresApi(Build.VERSION_CODES.LOLLIPOP)
        private fun isLegacyCamera(context: Context): Boolean {
            return try {
                val cameraManager = context.getSystemService(Context.CAMERA_SERVICE) as? CameraManager
                val characteristics = cameraManager?.cameraIdList?.map { cameraManager.getCameraCharacteristics(it) }
                val characteristic = characteristics?.firstOrNull {
                    it.get(CameraCharacteristics.LENS_FACING) == CameraCharacteristics.LENS_FACING_BACK
                } ?: characteristics?.get(0)
                val hardwareLevel = characteristic?.get(CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL)
                hardwareLevel == CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL_LEGACY
            } catch (t: Throwable) {
                false
            }
        }
    }

from android-goldeneye.

domagojkorman avatar domagojkorman commented on September 22, 2024

@zpapp while I do not agree with you that the end user should have this decision because they don't even know what is Camera1 and Camera2, I think that manual selection feature can be improved and I am OK with it.

from android-goldeneye.

zpapp avatar zpapp commented on September 22, 2024

they don't even know what is Camera1 and Camera2

They don't need to. All they need to know there is an option they can change that may make their camera work better.

I think that manual selection feature can be improved and I am OK with it.

Great, thanks!

from android-goldeneye.

domagojkorman avatar domagojkorman commented on September 22, 2024

Exposed methods

  • GoldenEye.preferredCameraApi(Context) - check which Camera API should be used
  • setCameraApi(CameraApi) - manually set whatever Camera API you want to use. It throws exception if Camera2 is passed on devices older than Lollipop where Camera2 does not exist.

from android-goldeneye.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.