Develop Reference

What is the Android Camera2 API equivalent of Camera.Parameters.getHorizontalViewAngle() and Camera.Parameters.getVerticalViewAngle()?

It's all in the title, but in the now-deprecated Android Camera API, there were two methods: Camera.Parameters.getHorizontalViewAngle() and Camera.Parameters.getVerticalViewAngle().
Now, with the current Camera2 API, it seems there is no equivalent to these in the docs. I'm assuming that this is because FOV angles are more complicated and nuanced than a simple horizontal and vertical value, but I can't find any information online about how to calculate the total field of view for an Android device using the newer Camera2 API.

The basic formula is
FOV.x = 2 * atan(SENSOR_INFO_PHYSICAL_SIZE.x / (2 * LENS_FOCAL_LENGTH))
FOV.y = 2 * atan(SENSOR_INFO_PHYSICAL_SIZE.y / (2 * LENS_FOCAL_LENGTH))
This is an approximation assuming an ideal lens, etc, but generally good enough.
This calculates the FOV for the entire sensor pixel array.
However, the actual field of view of a given output will be smaller; first, the readout area of the sensor is often smaller than the full pixel array, so instead of using PHYSICAL_SIZE directly, you need to first scale it by the ratio of the pixel array pixel count to the active array pixel count (SENSOR_INFO_ACTIVE_ARRAY_SIZE / SENSOR_INFO_PIXEL_ARRAY_SIZE).
Then, the field of view depends on the aspect ratio of the output(s) you've configured (a 16:9 FOV will be different than a 4:3 FOV), relative to the aspect ratio of the active array, and the aspect ratio of the crop region (digital zoom) if it's smaller than than the full active array.
Each output buffer will be the result of minimally further cropping the cropRegion for the corresponding capture request to reach the correct output aspect ratio. (http://source.android.com/devices/camera/camera3_crop_reprocess.html has diagrams).
So let's say we have a sensor that has a pixel array of (120,120), and we have an active array rectangle of (10,10)-(110,110), so width/height of 100,100.
We configure two outputs, output A is (40,30), output B is (50, 50). Let's leave the crop region at the maximum (0,0)-(100,100).
The horizontal FOV for output A and B will be the same, because the maximum-area crop will result in both outputs using the full active array width:
output_physical_width = SENSOR_INFO_PHYSICAL_SIZE.x * ACTIVE_ARRAY.w / PIXEL_ARRAY.w
FOV_x = 2 * atan(output_physical_width / (2 * LENS_FOCAL_LENGTH))
However, the vertical FOVs will differ - output A will only use 3/4 of the vertical space due to the aspect ratio mismatch:
active_array_aspect = ACTIVE_ARRAY.w / ACTIVE_ARRAY.h
output_a_aspect = output_a.w / output_a.h
output_b_aspect = output_b.w / output_b.h
output_a_physical_height = SENSOR_INFO_PHYSICAL_SIZE.y * ACTIVE_ARRAY.h / PIXEL_ARRAY.h * output_a_aspect / active_array_aspect
output_b_physical_height = SENSOR_INFO_PHYSICAL_SIZE.y * ACTIVE_ARRAY.h / PIXEL_ARRAY.h * output_b_aspect / active_array_aspect
FOV_a_y = 2 * atan(output_a_physical_height / (2 * LENS_FOCAL_LENGTH))
FOV_b_y = 2 * atan(output_b_physical_height / (2 * LENS_FOCAL_LENGTH))
The above works when the output aspect ratio is <= active array aspect ratio (letterboxing); if that's not true, then the output horizontal dimension is reduced and the vertical dimension covers the whole active array (pillarboxing). The scale factor for the horizontal direction is then active_array_aspect/output_aspect.
If you want to calculate the FOV for a zoomed-in view, then substitute the crop region dimensions/aspect ratio for the active array dimensions/aspect ratio.

private float getHFOV(CameraCharacteristics info) {
SizeF sensorSize = info.get(CameraCharacteristics.SENSOR_INFO_PHYSICAL_SIZE);
float[] focalLengths = info.get(CameraCharacteristics.LENS_INFO_AVAILABLE_FOCAL_LENGTHS);
if (focalLengths != null && focalLengths.length > 0) {
return (float) (2.0f * atan(sensorSize.getWidth() / (2.0f * focalLengths[0])));
}
return 1.1f;
}

While Eddy Talvala's answer gives you a solution, that is only viable for objects at a distance. However, as https://en.wikipedia.org/wiki/Angle_of_view#Macro_photography notes, for close subjects, you cannot assume the distance between lense and sensor to be equal to the focus distance. This distance cannot be queried but calculated S_2 = S_1 * focal length / (S_1 - focal length)
In this case S_1 is the minimal focus distance which can be computed from LENS_INFO_MINIMUM_FOCUS_DISTANCE when LENS_INFO_FOCUS_DISTANCE_CALIBRATION is not uncalibrated, in which case LENS_INFO_MINIMUM_FOCUS_DISTANCE has a unit of diopter (1/m).
So the final formula becomes:
// focal length/physical size is in mm -> convert from diopter (1/m) to mm
S_1 = 1000 / LENS_INFO_MINIMUM_FOCUS_DISTANCE
S_2 = LENS_FOCAL_LENGTH * S_1 / (S_1 - LENS_FOCAL_LENGTH)
FOV.x = 2 * atan(SENSOR_INFO_PHYSICAL_SIZE.x / (2 * S_2))
I measured this and compared with the computation for a Mi 9T Pro with following results:
name
value
Focal Length
4.77 mm
Physical Sensor Size
6,4x4,8 mm
minimum focus distance
10 diopter
hyperfocal distance
0.123 diopter
calculated FOV.y hyperfocal
53.4°
calculated FOV.y macro
51.2°
Framesize (y)
9.6 cm
Distance
10.2 cm
measured FOV
50.4°

AR.Drone functions usages in Android

Can someone clarify how to make a drone fly using the DroneProxy API class?
I'm using AR.Drone 2.0.
What I want to make is an indoor independent flying application. I want to input coordinates like a 2 meters left, then 3 meters right, turn right, then 10 meter to front, turn left, and few meters to front.
I tried to do this via methods below, but I cannot understand why it flies just for a few centimeters by one value input.
/**
* Sends ArDrone the gaz value. Makes drone to move up or down
*
* #param value - value between -1 and 1.
*/
public void setGaz(final float value) {
droneProxy.setControlValue(CONTROL_SET_GAZ, value);
}
/**
* Sends ArDrone the Roll value. Makes drone to move left or right
*
* #param value - value between -1 and 1.
*/
public void setRoll(final float value) {
droneProxy.setControlValue(CONTROL_SET_ROLL, value);
}
/**
* Sends ArDrone the Pitch value. Makes drone to move forward or backward
*
* #param value - value between -1 and 1.
*/
public void setPitch(final float value) {
droneProxy.setControlValue(CONTROL_SET_PITCH, value);
}
/**
* Sends ArDrone the gaz value. Makes drone to turn left or right
*
* #param value - value between -1 and 1.
*/
public void setYaw(final float value) {
droneProxy.setControlValue(CONTROL_SET_YAW, value);
}

I suggest, use methods instead:
droneControlService.moveDown(0);
droneControlService.moveUp(0);
droneControlService.turnRight(0);
droneControlService.turnLeft(0);
droneControlService.moveForward(0);
droneControlService.moveBackward(0);

generate differentiable colors similar to one color

lets say I have a web app and I need to show some text with different color that are obvious by eyes but all similar to for example red for example one pink and another dark red and ...
I use server side and in my servlet I remove the last 3 part of my color FF0000 and add for example 100
the code is as follow
for(int i=0;i<10;i++)
{
"FF0000".subSring(0,6-3)+i*100
}
but the problem is that all colors are kind of the same and noone can differentiate them
How can I solve this?(also I am ok with jquery solution as well)

Here is my suggestion:
Retrieve the RGB values by using jQuery CSS of a DOM element.
Convert it to HSL values.
Play with the Lightness value (0,1) for color variation (of the same color).
DEMO:JSnippet Demo
Here are the main function I use (Conversion functions are in the demo):
/**
* Gets any CSS color value and returns an array of variation
* With objects that holds the variations rgb values.
*
* #param String cssColor The CSS color
* #param Number vars How Many variation
* #return Array Array of objects - first is the original rgb.
*/
function getColorReturnVar(cssColor, vars) {
results_rgb = [];
results_hsl = [];
inc = 0;
$test = $("<div />").css({
background:cssColor,
width:'1px',
height:'1px'
});
$('body').append($test);
rgb = $test.css('backgroundColor');
$test.remove();
rgb = rgb.replace(/rgb\(|rgba\(| |\).*/gi,"").split(',');
results_rgb[0] = {r:parseInt(rgb[0]),g:parseInt(rgb[1]),b:parseInt(rgb[2])};
results_hsl[0] = rgbToHsl(results_rgb[0].r, results_rgb[0].g, results_rgb[0].b);
if (results_hsl[0].l < 0.5)
inc = Math.floor(((1-results_hsl[0].l)/(vars+3)) * 100) / 100;
else
inc = (Math.floor(((results_hsl[0].l-0)/(vars+3)) * 100) / 100)*-1;
for (var i=1; i< vars+1; i++) {
results_hsl[i] = { h:results_hsl[i-1].h,s:results_hsl[i-1].s,l:results_hsl[i-1].l + inc };
results_rgb[i] = hslToRgb(results_hsl[i].h,results_hsl[i].s,results_hsl[i].l);
}
return results_rgb;
}

Mapping logical coordinates to graphical fails when scaling

I encountered a slight problem with my game's rendering system when I tried to scale certain objects. I think it must be the way I map objects with logical coordinates to graphical ones on the screen.
Renderable
/**
* Retrieve the image representing the object that should be rendered.
* #return The image sprite representing the object.
*/
public Texture getSprite();
/**
* Retrieve the x-coordinate where the object should be rendered.
* #return The x-coordinate of the object.
*/
public float getScreenX();
/**
* Retrieve the y-coordinate where the object should be rendered.
* #return The y-coordinate of the object.
*/
public float getScreenY();
Texture
......
......
/**
* Retrieve the width of the texture.
* #return The width of the texture.
*/
public int getWidth();
/**
* Retrieve the height of the texture.
* #return The height of the texture.
*/
public int getHeight();
......
......
This system works perfectly when I draw stuff like interfaces etc, which have no logical coordinates in my game world.
Let's take a look at an object that have logical coordinates and see how I map the coordinates to graphical ones and thus causing a problem when I scale the texture when drawing.
Tile
#Override
public float getScreenX() {
return x * width;
}
#Override
public float getScreenY() {
return y * height;
}
Let's say the size of the texture for any tile is 16*16 but for some reason I want to draw it at 32*32. This will cause a problem since the tile's graphical x- and y-coordinate messes up.
Note: I know that I can fix this by allowing the user to set a scale when loading the image into the system but I want it to be more flexible.
TL;DR: How can I accomplish a better mapping between logical coordinates in the game world to graphical ones while still being able to scale when I want to? There should be a better way to map instead of letting the logical objects be in charge of their graphical coordinates.

Javadoc multiple variables on single line

I have a class like the following...
class A{
/**
* Blah blah
*/
Type1 var;
/**
* What do I do here?
*/
Type2 var11, var12;
}
How can I javadoc var11, and var12 if they are both on the same line?
I am curious to see if this is possible, I know I can put them both on an individual line and javadoc from there.

I was curious so I tried it out
/**
* data stuff
*/
int x , y ;
The resulting javadoc repeated the same doc comments for both x and y.
I imagine this behavior would be useful if two fields were essentially the same with minor differences.
class Circle
{
....
/**
* center coordinates
* The x/y coordinate of the center of this circle.
*/
int x , y ;

unfortunately there is no way to differentiate single line declaration of multiple variables :(
It may be useful to note however that the benefit of this does allow for a single javadoc to provide documentation for categorical variables which may otherwise take unnecessary lines.
/**
* custom colors (MUST BE DISPOSED!)
*/
Color lightblue, someotherblue, lightred;
of course this can be combined with initialization as well
/**
* These are the spec's behind batch-box font size / Height / Width
*/
private int iFontHeight = 9, iboxheight = 58, iboxwidth = 125;