Forem: Dhruv Anand

From GPS Coordinates to Screen Pixels: The Full AR Projection Math

Dhruv Anand — Sun, 19 Apr 2026 20:30:32 +0000

I've been building an Android app that overlays aircraft labels on a live camera feed when you point your phone at the sky. You fetch a plane's position from an ADS-B API, you have your own GPS location, and the goal is to draw a label at the correct pixel on screen.

The problem sounds straightforward until you try to implement it. There are four distinct coordinate spaces between the aircraft's GPS position and that pixel. Wrong output, no exception, no warning. The math compiles fine either way.

I tried to look for something similar but I couldn't really find any proper resource that gets it all done, they all work with either one of those coordinate spaces, not integrate them all together. So here is all that I had implemented to get it all working, for you guys!

This post walks through the entire pipeline from first principles: every formula, every sign rule, and a full numerical walkthrough using real captured values so you can verify your own implementation against known results.

The Pipeline at a Glance

The full transformation chain looks like this:

Geodetic (lat, lon, alt)
  ↓  Stage 1 — flat-earth approximation
ENU — East, North, Up (metres)
  ↓  Stage 2 — R⊤ from the Android rotation vector sensor
Device frame (dX, dY, dZ)
  ↓  Stage 3 — one sign flip
Camera frame (Cx, Cy, Cz)
  ↓  Stage 4 — perspective divide + FOV normalisation
Screen pixels (xpx, ypx)

Each stage is a separate coordinate system with its own axis convention. Confusing any two of them produces a result that looks plausible, points in roughly the right direction, and is still wrong.

Stage 1: Geodetic to ENU

What ENU is

ENU stands for East-North-Up. It is a local Cartesian frame centred on your position. The aircraft's ENU vector is its displacement from you in metres along three orthogonal axes: East, North, and Up. The user is always at the origin.

This frame is called a local tangent plane because it approximates Earth's surface as flat in the immediate vicinity of the observer. That approximation is valid for distances well under 100 km, which covers the entire ADS-B reception range for any ground station or aircraft receiver.

The flat-earth conversion

Given:

User position: $(ϕu,λu,hu)(\phi_u, \lambda_u, h_u)$
Aircraft position: $(ϕa,λa,ha)(\phi_a, \lambda_a, h_a)$
$mR_E = 6{,}371{,}000 \text{ m}$ (mean Earth radius)
Altitude from the API in feet, converted: $hm=hft×0.3048h_m = h_{ft} \times 0.3048$ The ENU components are:

(\lambda_a - \lambda_u) \times \frac{\pi R_E}{180} \times \cos!\left(\frac{\pi \phi_u}{180}\right)

(\phi_a - \phi_u) \times \frac{\pi R_E}{180}

U = h_a - h_u

Why the cosine appears in E but not N

This is the single most common implementation mistake. The $cos⁡(ϕu)\cos(\phi_u)$ term exists because meridians (lines of constant longitude) are not parallel — they converge toward the poles.

At the equator, one degree of longitude spans:

\frac{\pi R_E}{180} \approx 111{,}195 \text{ m/deg}

At latitude $ϕ\phi$ , the same one degree of longitude spans:

\frac{\pi R_E}{180} \cos\phi \;\text{ m/deg}

Lines of latitude, by contrast, are parallel. One degree of latitude spans the same arc length regardless of where you are. That is why the $N$ component has no cosine correction.

At $ϕu=24.86°\phi_u = 24.86°$ N (the reference location used in the walkthrough below), $cos⁡(24.86°)≈0.907\cos(24.86°) \approx 0.907$ , so a one-degree longitude difference corresponds to about 9.3% fewer metres than the same latitude difference. An implementation that omits this factor will produce East-West positions that are correct at the equator and increasingly wrong as latitude increases, with no visible error at low latitudes to alert you.

Derived quantities

Once you have $(E, N, U)$ , bearing, elevation, and range follow directly:

d_{horiz} = \sqrt{E^2 + N^2}

d_{3D} = \sqrt{E^2 + N^2 + U^2}

\beta = \arctan2(E,\, N) \times \frac{180}{\pi} \pmod{360}

\varepsilon = \arctan2(U,\, d_{horiz}) \times \frac{180}{\pi}

Note the argument order in $arctan⁡2(E,N)\arctan2(E, N)$ for bearing: North is the reference direction, so it goes in the second position. Swapping these gives bearings rotated 90 degrees.

These values are not consumed by the projection math directly, but they are invaluable for debugging. If the projected screen position is wrong, comparing computed bearing and elevation against a known map position immediately tells you whether the error is in Stage 1 or in a later stage.

Accuracy

At 50 nautical miles (approximately 93 km, the practical ADS-B range limit), the relative error is around 0.11%, corresponding to roughly 100 metres of positional error. At the projection level, this is under 2 pixels on a 1080-wide screen with a 66-degree horizontal FOV. The approximation is entirely adequate for this application.

For distances above 100 km, the Haversine formula gives exact great-circle distance:

\sin^2!\frac{\Delta\phi}{2} + \cos\phi_u \cos\phi_a \sin^2!\frac{\Delta\lambda}{2}

R_E \arctan2!\left(\sqrt{a},\, \sqrt{1-a}\right)

Stage 2: ENU to Device Frame via the Rotation Matrix

What the rotation matrix does

Android's TYPE_ROTATION_VECTOR sensor fuses the accelerometer, gyroscope, and magnetometer to output a quaternion representing the phone's orientation relative to Earth. Calling SensorManager.getRotationMatrixFromVector(R, values) converts that quaternion to a $\times 3$ rotation matrix stored in a FloatArray(9) in row-major order:

\begin{pmatrix} R[0] & R[1] & R[2] \ R[3] & R[4] & R[5] \ R[6] & R[7] & R[8] \end{pmatrix}

The column interpretation is the most important thing to understand about this matrix. Each column of $R$ is a unit vector describing where one device axis points in the ENU world frame:

Column 0: world direction of the device's $X_d$ axis (right edge of phone)
Column 1: world direction of the device's $Y_d$ axis (top edge of phone)
Column 2: world direction of the device's $Z_d$ axis (out of screen, toward your face) In other words, $R$ transforms vectors from device frame into ENU world frame:

\mathbf{v}{ENU} = R\, \mathbf{v}{device}

Going the other direction: R transpose

The projection engine needs the inverse transform. Given an ENU vector (the aircraft's position relative to the user), we want its representation in the device frame so we can reason about whether it is in front of or behind the camera.

Because $R$ is orthonormal (it is a rotation matrix, so $R−1=R⊤R^{-1} = R^\top$ ), the inverse is just the transpose:

\mathbf{v}{device} = R^\top\, \mathbf{v}{ENU}

Expanding this using the row-major index layout of Android's FloatArray(9):

\cdot E + R[1] \cdot N + R[2] \cdot U

\cdot E + R[4] \cdot N + R[5] \cdot U

\cdot E + R[7] \cdot N + R[8] \cdot U

Magnitude preservation as a sanity check

Because $R⊤R^\top$ is orthonormal, it preserves vector magnitudes exactly:

|R^\top\,\mathbf{v}{ENU}| = |\mathbf{v}{ENU}| = d_{3D}

This means after computing $(d X, d Y, d Z)$ , you can immediately check:

\sqrt{dX^2 + dY^2 + dZ^2} \stackrel{?}{=} d_{3D}

If these do not match (accounting for floating-point rounding), there is a matrix indexing error somewhere. This check costs essentially nothing and catches the most common implementation mistake immediately.

Stage 3: Device Frame to Camera Frame

Axis conventions

Android's sensor frame and the camera frame have different axis conventions for the Z direction:

Axis	Device frame ( $Z_d$ )	Camera frame ( $C_z$ )
Meaning	Out of screen, toward your face	Into the scene, away from lens

These point in opposite directions. The full mapping for a phone held upright in portrait mode is:

Device axis	Physical meaning	Camera axis
$X_d$	Right edge of phone	$C_x$ (camera right)
$Y_d$	Top edge of phone	$C_y$ (camera up)
$Z_d$	Out of screen	$C_z$ (negate)

So the camera frame components are:

C_x = dX, \quad C_y = dY, \quad C_z = -dZ

The negation on $C_z$ is the only required correction for portrait mode. No matrix, no remap call, just one sign flip.

The occlusion test

An aircraft is behind the camera if and only if $Cz≤0C_z \leq 0$ . At this point, perspective division would be undefined or produce a nonsensical result on the wrong side of the image plane. Any point with $Cz≤0C_z \leq 0$ must be classified as off-screen before proceeding.

Stage 4: Perspective Projection to Screen Pixels

The pinhole camera model

A point $p=(Cx,Cy,Cz)\mathbf{p} = (C_x, C_y, C_z)$ in camera space projects onto the image plane via similar triangles. Setting the focal length to 1 (normalised):

n_x = \frac{C_x}{C_z}, \qquad n_y = \frac{C_y}{C_z}

This is the perspective divide. An object twice as far away ( $C_z$ doubled) produces half the projected displacement from centre. This is what gives AR overlays their correct sense of depth and scale.

Field of view normalisation

The perspective divide alone gives values whose scale depends on the camera's focal length. Normalising by the half-FOV tangent maps the visible frustum to $[- 1, + 1]$ (Normalised Device Coordinates, NDC):

\text{NDC}_x = \frac{n_x}{\tan(\theta_H / 2)} = \frac{C_x}{C_z \cdot \tan(\theta_H / 2)}

\text{NDC}_y = \frac{n_y}{\tan(\theta_V / 2)} = \frac{C_y}{C_z \cdot \tan(\theta_V / 2)}

where $θH\theta_H$ and $θV\theta_V$ are the horizontal and vertical field of view angles. An aircraft is inside the visible frustum when:

C_z > 0 \quad \text{and} \quad |\text{NDC}_x| \leq 1 \quad \text{and} \quad |\text{NDC}_y| \leq 1

For a typical Android rear camera in portrait mode: $θH≈66°\theta_H \approx 66°$ , $θV≈50°\theta_V \approx 50°$ .

NDC to screen pixels

Given screen dimensions $(W, H)$ in pixels:

x_{px} = \frac{\text{NDC}_x + 1}{2} \times W

y_{px} = \frac{1 - \text{NDC}_y}{2} \times H

The $\text{NDC}_y$ in the second formula is the Y-axis flip. Screen coordinates have $y = 0$ at the top-left corner, increasing downward. Camera $C_y$ points up. These are opposite conventions, and the formula corrects for it. If you write $NDCy+12×H\frac{\text{NDC}_y + 1}{2} \times H$ instead, aircraft above the horizon appear below screen centre and vice versa.

The full projection formula

Substituting NDC back in:

x_{px} = \left(\frac{C_x}{C_z \cdot \tan(\theta_H/2)} + 1\right) \frac{W}{2}

y_{px} = \left(1 - \frac{C_y}{C_z \cdot \tan(\theta_V/2)}\right) \frac{H}{2}

Equivalence to the camera intrinsics matrix

This formula is identical to the standard camera intrinsics model $K$ . The intrinsic matrix for this projection is:

\begin{pmatrix} f_x & 0 & p_x \ 0 & f_y & p_y \ 0 & 0 & 1 \end{pmatrix}

where:

f_x = \frac{W}{2\tan(\theta_H/2)}, \quad f_y = \frac{H}{2\tan(\theta_V/2)}, \quad p_x = \frac{W}{2}, \quad p_y = \frac{H}{2}

With $W = 1080$ , $θH=66°\theta_H = 66°$ : $pxf_x = 1080 / (2\tan 33°) \approx 831.5\,\text{px}$ .

The scalar formula and the matrix formulation are the same computation. Understanding the equivalence matters when you want to incorporate lens distortion correction later, which requires working in the intrinsics framework.

Off-Screen Direction Classification

When an aircraft is not in the frustum, a good AR overlay shows an edge indicator pointing toward it. The decision tree is:

$Cz≤0C_z \leq 0$ : aircraft is behind the camera. Show a BEHIND indicator or suppress.
$C_z > 0$ and $NDCx<−1\text{NDC}_x < -1$ : off the left edge.
$C_z > 0$ and $NDCx>+1\text{NDC}_x > +1$ : off the right edge.
$C_z > 0$ and $NDCy>+1\text{NDC}_y > +1$ : above the top edge.
$C_z > 0$ and $NDCy<−1\text{NDC}_y < -1$ : below the bottom edge. For the indicator screen position (with edge padding $p$ ):

LEFT:  x = p,     y = clamp(ypx, p, H-p)
RIGHT: x = W-p,   y = clamp(ypx, p, H-p)
UP:    x = clamp(xpx, p, W-p),  y = p
DOWN:  x = clamp(xpx, p, W-p),  y = H-p

The $x_{px}$ , $y_{px}$ values from the projection formula (extrapolated even when off-screen) give the correct rotation angle for the indicator arrow, so compute them regardless of frustum status.

Full Numerical Walkthrough

You can skip this boring part

Real captured values from a live debugging session.

Given

Symbol	Description	Value
$ϕu,λu\phi_u, \lambda_u$	User position	24.8600° N, 80.9813° E
$ϕa,λa\phi_a, \lambda_a$	Aircraft position	24.9321° N, 81.0353° E
$h_a$	Aircraft altitude	18,000 ft = 5,486.4 m
$\times H$	Screen	1080 × 1997 px
$θH,θV\theta_H, \theta_V$	Camera FOV	66°, 50°
Azimuth / Pitch / Roll	Phone orientation	33.0°, −4.3°, −6.5°

Stage 1: Geodetic to ENU

\frac{\pi R_E}{180} = 111{,}195 \text{ m/deg}

\cos(24.86°) = 0.9073 \implies \frac{\pi R_E}{180}\cos\phi_u = 100{,}891 \text{ m/deg}

\times 100{,}891 = 0.0540 \times 100{,}891 = 6{,}048 \text{ m}

\times 111{,}195 = 0.0721 \times 111{,}195 = 8{,}017 \text{ m}

\text{ m}

Stage 2: Bearing and elevation

d_{horiz} = \sqrt{6048^2 + 8017^2} = \sqrt{36{,}578{,}304 + 64{,}272{,}289} = 9{,}716 \text{ m}

d_{3D} = \sqrt{9716^2 + 5486^2} = \sqrt{94{,}400{,}656 + 30{,}095{,}396} = 11{,}167 \text{ m}

\beta = \arctan2(6048,\, 8017) \times \frac{180}{\pi} \approx 37.0°\text{ (NNE)}

\varepsilon = \arctan2(5486,\, 9716) \times \frac{180}{\pi} \approx 29.4°

Stage 3: Rotation matrix

The rotation matrix captured from getRotationMatrixFromVector() at the session:

\begin{pmatrix} 0.829 & 0.544 & -0.135 \ -0.549 & 0.836 & -0.001 \ 0.112 & 0.075 & 0.991 \end{pmatrix}

Applying $vENUR^\top\,\mathbf{v}_{ENU}$ via column indexing:

dX = 6048(0.829) + 8017(-0.549) + 5486(0.112) = 5{,}014 - 4{,}401 + 614 = 1{,}227

dY = 6048(0.544) + 8017(0.836) + 5486(0.075) = 3{,}290 + 6{,}702 + 411 = 10{,}403

dZ = 6048(-0.135) + 8017(-0.001) + 5486(0.991) = -817 - 8 + 5{,}437 = 4{,}612

Applying the sign fix: $C_x, C_y, C_z) = (dX, dY, -dZ) = (1{,}227,\; 10{,}403,\; -4{,}612)$

Magnitude check:

\sqrt{1227^2 + 10403^2 + 4612^2} = \sqrt{1{,}505{,}529 + 108{,}222{,}409 + 21{,}270{,}544} \approx 11{,}179 \text{ m}

Against $d_{3D} = 11{,}167$ m. The 12 m difference is rounding from truncating $R$ to 3 decimal places. ✓

Stage 4: Perspective projection

n_x = \frac{C_x}{C_z} = \frac{1227}{-4612} \approx -0.266

n_y = \frac{C_y}{C_z} = \frac{10403}{-4612} \approx -2.255

Both NDC values are large negatives because $C_z < 0$ — the aircraft is behind the camera in this captured frame (the phone was not pointing at the aircraft). The off-screen indicator fires: $Cz≤0C_z \leq 0$ , $C_x > 0$ , so direction is RIGHT.

This is the correct result. At azimuth 33.0° with the aircraft at bearing 37.0°, the aircraft is only 4° away horizontally. The pitch of −4.3° with elevation 29.4° means the phone is pointing far too low — the net vertical angle to the aircraft is 33.7°, well above the 25° half-FOV for the vertical axis. The phone needs to tilt up considerably to bring the aircraft into frame.

Error Budget

Every approximation in the pipeline introduces a bounded error. These are independent, so the total worst-case screen error is roughly their sum.

Source	Max positional error	Screen error at 50 nm	Mitigation
Flat-earth vs. Haversine	~130 m at 100 km	< 2 px	Acceptable; use Haversine beyond 100 km
Spherical vs. WGS-84 ellipsoid	~55 m at 100 km	< 1 px	Negligible
User altitude = 0	$h_{user}$ metres	1–5 px near mountains	Read GPS altitude
Sensor latency (normal pan)	~0.1°	< 3 px	Acceptable
Sensor latency (fast pan, 60°/s)	~0.6°	~16 px	Low-pass filter
Lens distortion (not corrected)	< 10 px at corners	< 10 px	Camera2 distortion coefficients

The flat-earth error derivation: expanding $arcsin⁡(x)≈x+x3/6\arcsin(x) \approx x + x^3/6$ and retaining the leading correction term gives relative error $≈d2/(12RE2)\approx d^2 / (12 R_E^2)$ . At 93 km this is 0.11%.

Quick Reference

ENU (flat-earth)
  E = Δλ × (π·RE/180) × cos(φ_user)
  N = Δφ × (π·RE/180)
  U = h_aircraft - h_user

Distance and bearing from ENU
  d_3D = sqrt(E² + N² + U²)
  β    = atan2(E, N) → [0, 360)
  ε    = atan2(U, sqrt(E² + N²))

World to device (R transpose — column indexing)
  dX = R[0]·E + R[3]·N + R[6]·U
  dY = R[1]·E + R[4]·N + R[7]·U
  dZ = R[2]·E + R[5]·N + R[8]·U

Device to camera (portrait mode)
  Cx = dX,  Cy = dY,  Cz = -dZ

Perspective projection
  NDCx = Cx / (Cz · tan(θH/2))
  NDCy = Cy / (Cz · tan(θV/2))

Screen pixels (origin top-left)
  xpx = (NDCx + 1) / 2 × W
  ypx = (1 - NDCy) / 2 × H

Visible when: Cz > 0 AND |NDCx| ≤ 1 AND |NDCy| ≤ 1

Default FOV (portrait, typical rear camera)
  θH ≈ 66°,  θV ≈ 50°

Here is also the full math reference document that I have created: Math Reference Document

Questions about any stage of the pipeline or anything else are welcome.
Hope this was helpful.

How to Rice Windows.

Dhruv Anand — Thu, 30 Dec 2021 05:29:21 +0000

Ricing Windows

Make your Desktop look sick & clean.

Here is a list if software and applications that I have used to rice my desktop.

Web Browser ▻ Firefox
Music Streaming ▻ Spotify
Messaging Platform ▻ Discord
Text Editor ▻ Visual Studio Code
Terminal▻ Windows Terminal
File Manager ▻ Files
Wallpaper Manager ▻ Lively
App Launcher ▻ PowerToys Run
Status Bar ▻ PolyBar
Music Widget ▻ ModularPlayers
Dock ▻ Nexus

Head over to my GitHub repository ↴

dhruvnnd / Windows-Rice

How to rice Windows.

Windows Ricing

Wallpaper : Spaceman Wallpaper →
- I have used for a live wallpaper.
Top bar :
- Use to add Widgets.
Dock :
Music Controller :

Applications

Web Browser

Firefox New Tab Page: nightTab

Discord

for Plugins & Themes to enhance Discord.

Theme :
Plugins

Plugins	Links
AppNotifications	https://betterdiscord.app/plugin/AppNotifications
BetterImageViewer	https://1lighty.github.io/BetterDiscordStuff/?plugin=BetterImageViewer
GameActivityToggle	https://betterdiscord.app/plugin/GameActivityToggle
SpotifyControls	https://betterdiscord.app/plugin/SpotifyControls

Spotify

Commandline tool to customize Spotify client.

Theme : Dribbblish Color scheme : Nord-dark
Extensions : Dribbblish, Popup-Lyrics, Full App Display

Editor

NeoVim

Colorscheme : OneDark

Terminal

Windows Terminal

Colorscheme : One Half Dark
System Info : Screenfetch

File Manager

Files

Custom Theme : Glass

App Launcher

PowerToys Run

View on GitHub

Minimal Time Management App

Dhruv Anand — Fri, 20 Aug 2021 13:13:09 +0000

Being a high-school student and having everything online, it gets quiet difficult to manage time and get tasks done.
So, I did some research and got to know about a technique called Pomodoro.

And I started looking for a good Pomodoro Timer app but did not find any good app. Either they were paid or lacked a few features.

So, I made myself my own Pomodoro Timer app. It is very minimal.
It is built using ElectronJS & JavaScript.

I would love to share the app with you guys and receive your feedback.

Check out the App on GitHub and download it and even give it a Star.

Minimal Pomodoro Timer App

Dhruv Anand — Thu, 19 Aug 2021 11:53:32 +0000

I am a High-School Student and I have trouble managing my time and getting things done.
I came across a technique called Pomodoro.
So, I started looking around for a good Pomodoro app but none satisfied me.

So, I developed my own Pomodoro App which is minimal and easy to use.

It would really be appreciated if you could have a look at it

dhruvnnd / Pomodoro-App

Minimal Pomodoro Timer to help you complete your tasks.

Pomodoro Timer

A light-weight & minimal Pomodoro Timer to help you manage time and complete your tasks.

What is Pomodoro?

The Pomodoro Technique is a time management method developed by Francesco Cirillo in the late 1980s. The technique uses a timer to break down work into intervals, traditionally 25 minutes in length, separated by short breaks. Each interval is known as a Pomodoro ~ Wikipedia

Features

Minimal and Lightweight User Interface
Easy to use and basic functionality.
Keyboard shortcuts. Press Spacebar to Start/Pause the Timer.
Configurable Pomodoro & Short Break duration.

Installation

Go to the Releases page and download the latest version of the app.

Usage

The app is currently available only for Windows x64 only.

Download the app from the Releases page.
Run the setup.exe
Use the App! 🥳

Contribution

If you encounter any bug or issue or if you wish to request for a new feature, create…

View on GitHub

Minimal Notepad using Python (Tkinter)

Dhruv Anand — Sat, 24 Jul 2021 05:05:00 +0000

dhruvnnd / D-Pad

Lightweight & Minimal Text Editor

D-Pad

Lightweight Text Editor with minimal features.

⚠️ >>> 📣 This app is not being developed <<< ⚠️

Why do you need this?

This app has minimum features so it provides the ability to be run on a potato Jokes aside, this app is built from the ground up and is totally BUG-FREE. So you will have a really smooth experience using this.

This app does have minimal features but there are enough of them to get your work done.

Features

Basic Text Editing
Text Operations: Cut, Copy & Paste
Open & Save Files
Menu Items
Functioning Sidebar
Keyboard Shortcuts
Font Selector
Text Formatting
Text Color/Highlight
Customisable Application Themes

Contribution

You, my friend, are totally free to review the source code and contribute to this project, after all, this is what open-source means.

Read the Contributing guidelines.

💖 Support

♥ The best way you can me is by…

View on GitHub

Lightweight Notepad made with Python

This is a personal project of mine made for a Hackathon,
It is a lightweight Text Editor made using Python & Tkinter.

It would mean a lot to me if you would have a look at my project and give it a Star.
Also, feel free to Contribute to the project and add new features.

Python Tkinter Standalone Application

Dhruv Anand — Sat, 24 Jul 2021 04:35:31 +0000

If any one has made a TKinter application and wants to convert it to an executable, here's how you can do it.

For this, we will be using Pyinstaller

Installing `Pyinstaller`

pip install pyinstaller

Converting to Executable

Once you have installed Pyinstaller, there is just one more step remaining.

Locate to the directory where your .py file is located. (The Python program you want to convert to application)
Open the Command Prompt in that directory.
- Quick Tip: in the File Explorer, click on the Address Bar and type cmd to open the Command Prompt in that directory.
After that, type this command in the Command Prompt pyinstaller --onefile --windowed --icon=<your-icon.ico> <file.py>

Explaining the command:

pyinstaller : To bundle the Python application and all its dependencies into a single package.
--onefile : To have just one Executable file.
--windowed : This will not open the Terminal every time you run the app.
icon : Set the icon of the app.
Write the name of your file to be converted to an Executable.

If this helped you, you can follow me on GitHub and have a look at my projects and star them.

Trying to get my head into DSA as a 15 year old...

Dhruv Anand — Fri, 23 Jul 2021 09:54:32 +0000

I have started to learn Data Structures & Algorithms using Python.

Is there any advice for me that I should follow so that I do not give up.

I am really passionate about computers and programming, so I'd love to hear all of your suggestions.

Forem: Dhruv Anand

From GPS Coordinates to Screen Pixels: The Full AR Projection Math

The Pipeline at a Glance

Stage 1: Geodetic to ENU

What ENU is

The flat-earth conversion

Why the cosine appears in E but not N

Derived quantities

Accuracy

Stage 2: ENU to Device Frame via the Rotation Matrix

What the rotation matrix does

Going the other direction: R transpose

Magnitude preservation as a sanity check

Stage 3: Device Frame to Camera Frame

Axis conventions

The occlusion test

Stage 4: Perspective Projection to Screen Pixels

The pinhole camera model

Field of view normalisation

NDC to screen pixels

The full projection formula

Equivalence to the camera intrinsics matrix

Off-Screen Direction Classification

Full Numerical Walkthrough

Given

Stage 1: Geodetic to ENU

Stage 2: Bearing and elevation

Stage 3: Rotation matrix

Stage 4: Perspective projection

Error Budget

Quick Reference

How to Rice Windows.

Ricing Windows

Make your Desktop look sick & clean.

dhruvnnd / Windows-Rice

How to rice Windows.

Windows Ricing

Applications

Web Browser

Discord

Spotify

Editor

Terminal

File Manager

App Launcher

Minimal Time Management App

Minimal Pomodoro Timer App

dhruvnnd / Pomodoro-App

Minimal Pomodoro Timer to help you complete your tasks.

Pomodoro Timer

What is Pomodoro?

Features

Installation

Usage

Contribution

Minimal Notepad using Python (Tkinter)

dhruvnnd / D-Pad

Lightweight & Minimal Text Editor

D-Pad

Why do you need this?

This app does have minimal features but there are enough of them to get your work done.

Features

Contribution

Read the Contributing guidelines.

💖 Support

Lightweight Notepad made with Python

Python Tkinter Standalone Application

Installing Pyinstaller

Converting to Executable

Explaining the command:

Trying to get my head into DSA as a 15 year old...

Installing `Pyinstaller`