Ability to customize CameraParameters/CaptureRequest about fotoapparat HOT 15 CLOSED

We indeed currently do not provide the possibility to change those parameters, but thanks for the suggestion. That would be the first thing which we'll do after fixing all the bugs.

from fotoapparat.

I need these features for a project in which I'm already using this library, and I would like to try to implement them. Could you provide some hints?

It looks like for v1, ParameterConverter implements converting io.fotoapparat.parameter.Parameters to android.Camera.Prameters. So Parameters and FotoapparatBuilder need to to allow specifying sensor sensitivity, aperture, and exposure time, and ParametersConverter needs to handle them.

For v2, it looks like CaptureRequestFactory is a class that will have control over the CaptureRequest (through CaptureRequestBuilder) and has access to Parameters (through ParametersProvider). So besides the same changes to Parameters, ParametersProvider needs to be updated to provide access to the new settings, and they need to be handled in CaptureRequestFactory and CaptureRequestBuilder.

Is that correct? Also what's the purpose of the above multiple classes used in v2?

from fotoapparat.

@hagabaka if you would help to implement a feature, that would be appreciated. To simplify things, since Camera2 is still work-in-progress you can just throw UnsupportedOperationException. We'll take care of that.

As for Camera1, you almost got it right.

• InitialParametersProvider is taking user preferences (which you specified in FotoapparatBuilder) and creates fotoapparat.Parameters out of them.
• ParametersConverter is converting fotoapparat.Parameters to camera.Parameters
• CapabilitiesFactory (from v1) creates Capabilities object which basically tells what kind of values camera supports (which preview sizes, what kind of auto focus, does it has flash, etc.)

Note, that FotoapparatBuilder accepts SelectorFunction instead of taking parameters directly. That is needed for two reasons:

1. It allows users to write fail-safe code (see firstAvailable())
2. Selection is executed later on a background thread, so we save some performance

Next thing to take into account, we never expose native camera classes in Fotoapparat or FotoapparatBuilder, since user should not care with which camera implementation he is working. That means each value provided by camera.Parameters should be mapped to our own type. Same as it is done with FocusMode or Flash.

If you have any other questions, feel free to ask! :)

from fotoapparat.

I started trying to add support for sensor sensitivity, and have encountered a few issues:

The only way to test for this capability with v1 seems to be explained here, which is to look for a device-dependent key like "iso-values" in Camera.Parameters#flatten(). This would give a list of accepted values. However my phone (Pixel XL) does not list any of the known keys names, and the string from device doesn't seem to contain any other information on this setting.

On v2 this can be queried using CameraCharacteristics#get(SENSOR_INFO_SENSITIVITY_RANGE), and my phone does report the range in the v2 API. However it's a range rather than a list as in v1, so I assume it would be difficult to use it with SelectorFunction. Can a Predicate be used somehow?

I'm under the impression that the finished API would look something like:

Fotoapparat
  .with(context)
  .sensorSensitivity(firstAvailable(
     sensorSensitivityValue(1000),
     highestSensorSensitivity(),
     defaultSensorSensitivity()
  ))

Does that make sense?

from fotoapparat.

API Looks good. If I understood correctly this feature is available only on Camera2?

I assume it would be difficult to use it with SelectorFunction. Can a Predicate be used somehow?

I see the problem. Our SelectorFunction is not generic enough. I suggest we change it a bit so that it accepts input type as a generic parameter:

interface SelectorFunction<Input, Output> {

    Output select(Input input);

}

Then our existing selectors can be represented like that:

SelectorFunction<List<Size>, Size> biggestSize()

And your range could be represented like that (assuming you'll create Range class):

SelectorFunction<Range<Integer>, Integer> highestSensorSensitivity()

from fotoapparat.

The feature depends on the device, but the ability to reliably query the capability is only on camera2. On my phone, the camera apparently supports it but only reports it on camera2. Still, it's known to work for some devices on camera1 as listed in the Stackoverflow answer.

I think changing SelectorFunction as you suggested will work. I'll try it out.

from fotoapparat.

So far I think the approach of making SelectorFunction more generic works.

To recap, on v1 the sensor sensitivity information, if available, is reported as a list of numbers, while on v2 it is a range. I can't have functions overrides returning different SelectorFunction types with the same name and parameters, so I created a BaseSensorSensitivityCapability type, which is extended differently in v1 and v2, and used as input for selector functions.

I still need to add code and allow the user to use the new SelectorFunctions, and to handle them with the camera APIs.

from fotoapparat.

How about instead of creating BaseSensorSensitivityCapability create an interface Range:

interface Range<T> {

    boolean contains(T value);

    T maxValue();

    T minValue();

}

Then you can implement ContinuousRange which would be used by Camera2 and DiscreeteRange for Camera1. I believe that would be cleaner since we still will be able to use SelectorFunction.

This is roughly the same idea as you had, but with a more generic name.

from fotoapparat.

OK. Should I put Range, ContinuousRange and DiscreetRange in io.fotoapparat.util, or a new package io.fotoapparat.range?

from fotoapparat.

I think io.fotoapparat.parameter.range would be right place. @Diolor any thoughts?

from fotoapparat.

I would go with the least abstract package. io.fotoapparat.parameter.range is concrete enough and follows same architecture as parameter.selector package

from fotoapparat.

So I think the sensor sensitivity/ISO part of this feature is done. It's hard to tell that it is working, but code using the added API is compiling, and debugger shows that the value is being set in Camera.Parameters or CaptureRequest.

The earlier change to SelectorFunction has broken some tests, and I haven't added tests for the added code. How can I run the tests in Android Studio?

from fotoapparat.

@hagabaka sorry for the delay.

To run tests in Android Studio you can right click the test folder and click Run. Or, you can right click on each individual test and do the same.

Could you perhaps create a Pull Request with your changes so that we can review them and integrate into the project?

from fotoapparat.

OK, I've fixed the tests and created a pull request.

from fotoapparat.

Let's close this and track progress on separate issues : #38 , #39 , #40 since #35 got opened

from fotoapparat.