DEV Community

Super Funicular
Super Funicular

Posted on

How Far Away Can a Phone Camera Still Read a Number Plate? The Arithmetic Before You Mount It

#android #mobile #security #tutorial

You mounted the old phone. The video is 1080p. The footage looks fine on the screen. Then something actually happens, you go back to the recording, and you cannot read the plate, the face, or the number on the meter.

This is the most common disappointment in phone-as-camera setups, and it is almost never the app's fault. It is arithmetic. The good news is that the arithmetic is simple enough to do standing in the doorway with a tape measure, and it will tell you where to put the phone before you drill anything.

How far away can a phone camera still read a number plate?

Short answer: It depends on how wide the scene is in the frame, not on how many megapixels the phone has. Surveillance guidance puts reading a vehicle registration at roughly 500 pixels per metre of scene. A 1080p recording is 1920 pixels wide, so the whole frame has to be under about 3.8 metres across at the plate.

That is a shop counter or a gateway, not a driveway and definitely not a street. Most people aim a phone at a scene ten metres wide and expect plate-reading detail out of it. The pixels are not there to be had.

Why does my phone camera video look sharp on the screen but unreadable when I zoom in?

Short answer: Because your screen is showing you far fewer pixels than you think. A detail that occupies 12 pixels in the recording looks acceptable scaled down to phone-screen size, and falls apart the moment you enlarge it. Zooming in afterwards cannot add pixels that the sensor never sampled at that part of the scene.

Both answers come down to one measurement, and it is not a camera spec.

The only number that matters: pixels per metre of scene

The US Department of Homeland Security's Digital Video Quality Handbook states the calculation plainly: pixel density "is equal to the imager's pixel dimensions divided by the corresponding field of view linear dimension (feet)." Same idea in metres.

So:

pixels per metre = horizontal video width in pixels ÷ how many metres wide the scene is

A 1080p recording is 1920 pixels wide. Point it at a 4-metre-wide shopfront and every metre of that shopfront gets 480 pixels. Point the same phone at a 16-metre-wide yard and every metre gets 120.

Notice what is not in that formula. Sensor size is not in it. Lens focal length is not in it. Megapixels are not in it — your camera may capture 48 MP stills and still record video at 1920 pixels wide. The video surveillance design tool JVSG makes the point explicitly: "Pixel density calculations do not take into account sensor size, or lens parameters."

This is why the practical instruction is not "put the phone 4 metres away." Different phones have different angles of view, so the same distance gives a different scene width on different handsets. The instruction is: mount the phone, open the preview, and measure how wide the real scene is at the thing you care about. A tape measure and the live preview beat any distance table.

What each pixel density actually buys you

The reference figures come from IEC 62676-4, the international application-guidelines standard for video surveillance. I have not read the standard itself — the current edition is paywalled at CHF 405 on the IEC webstore — so the numbers below are as reported by Axis Communications and JVSG, both of which name IEC 62676-4 as their source.

There is a catch that matters in 2026, and most of the internet has not caught up with it. The old 2014 edition used four categories, the familiar DORI scheme. The 2025 edition replaced it with seven. Axis summarises the new scheme as distinguishing "the need to overview, outline, discern, perceive, characterize, validate, and scrutinize."

What you want 2025 category Pixels per metre Max scene width at 1080p at 720p
Someone is there Overview 20 96 m 64 m
Something happened Discern 80 24 m 16 m
That is a person I know Perceive 125 15.4 m 10.2 m
Identify a stranger's face Characterize 250 7.7 m 5.1 m
Read a vehicle registration Validate 500 3.8 m 2.6 m
Certainty about identity Scrutinize 1500 1.3 m 0.9 m

The right-hand columns are just the formula above, inverted: scene width = video pixel width ÷ required pixel density.

The 2025 change is a doubling, and it is the single most useful thing on this page. Under the old DORI scheme, plate reading sat near the Identification level, 250 px/m. Under the 2025 edition, "retrieve vehicle registration number" is the Validate level — 500 px/m. If you have read a guide that says 250 px/m reads a plate, it is citing the superseded edition. Both Axis and JVSG report the new 500 figure.

Two honest caveats on this table. First, Axis states outright that "there is no guarantee that complying with this simplified rule of thumb will enable a camera to fulfill the operational requirements" — it is a design starting point, not a promise. Second, the sources disagree on details: Axis's 2014 table has four rows, JVSG lists six, and the two differ on whether Observation is 62 or 63 px/m. Where they disagree I have used the figures both report.

For plates specifically, vendor figures are more concrete than the standard. Axis's licence-plate guidance says "we need 74 pixels across the full width of the plate to resolve the individual lines" and that "most LPR software require around 100-150 pixels over the full width of the plate." The underlying optics rule it gives is worth memorising: "there needs to be at least two pixels across the smallest structure that we want to resolve in the image." Note these are figures for a European plate; a US plate is narrower, so the same pixel count covers a different real width. Bosch's own plate-recognition paper declines to publish a universal number at all, saying "the ANPR software supplier will specify the minimum number of pixels required."

The second limit nobody checks: can the lens even focus there?

Pixel density tells you whether the detail is theoretically in the frame. Focus decides whether it is sharp. And here Android will tell you the answer directly, which surprises most people.

Camera2 exposes LENS_INFO_MINIMUM_FOCUS_DISTANCE, documented as "shortest distance from frontmost surface of the lens that can be brought into sharp focus." The sentence right after it is the one to remember: "If the lens is fixed-focus, this will be 0."

A fixed-focus camera is not a defect. It is explicitly permitted. Android's Compatibility Definition Document says a device "SHOULD have either hardware auto-focus or software auto-focus implemented in the camera driver" and "MAY have fixed-focus or EDOF (extended depth of field) hardware." SHOULD and MAY, not MUST. Autofocus has never been mandatory on Android. On a fixed-focus rear camera there is a near limit you simply cannot cross, and no app can move it — the documentation is blunt that autofocus modes are "only effective if... the lens is not fixed focus (i.e. android.lens.info.minimumFocusDistance > 0)."

If your camera does focus, the mode matters for a static scene. Camera2's CONTROL_AF_MODE_CONTINUOUS_VIDEO is described as behaviour where "the AF algorithm modifies the lens position continually to attempt to provide a constantly-in-focus image stream," and whose focusing "should be suitable for good quality video recording; typically this means slower focus movement and no overshoots." Compare CONTINUOUS_PICTURE, which means "focusing as fast as possible" — the wrong trade for a camera watching one fixed spot for eight hours.

What Android's own documentation does not tell you

Six gaps I could not close from any first-party page:

  1. Nothing states that digital zoom loses detail. Google documents the mechanism — cropping "for digital zoom and other use cases where a smaller FOV is desirable," then "scaling the sensor input to match the output's configured resolution" — and never states the consequence. That crop-and-upscale means no new detail is my inference, not Google's sentence.
  2. No CDD requirement mentions focus distance or zoom at all. A whole-document check of the Android 15 and Android 17 CDDs returns zero occurrences of "minimum focus distance" and zero of "digital zoom." Nothing is guaranteed here.
  3. Continuous-video autofocus behaviour is a "should", not a "MUST". It is a recommendation to the people writing the camera driver. I found no compatibility requirement pinning it.
  4. The docs never say what a LEGACY device reports for minimum focus distance. The key is marked optional and "may be null," and is only guaranteed present at hardware level LIMITED and above. That a LEGACY phone might return null is inference.
  5. The word "hunting" does not appear anywhere. There is no first-party statement that continuous autofocus hunts on a static scene, only that continuous-video mode aims for "no overshoots."
  6. No published pixel-density figure comes from a phone maker. Every number in the table above comes from fixed-camera surveillance vendors. Nobody at Google, Apple or Samsung publishes an equivalent.

And one first-party change worth dating, because it moved this year: Android 17 removed the universal 2-megapixel floor for rear cameras. In the Android 15 CDD, section 7.5.1 said any device with a rear-facing camera "MUST have a resolution of at least 2 megapixels." The Android 17 CDD lists that under "requirements removed in Android 17" and re-scopes it to handheld devices only. If you cite "Android requires 2 MP," date it.

Putting the phone somewhere useful, in order

  1. Decide what you need to be able to do, in the table's language. "See that someone came in" and "read the plate" are twenty-five times apart in pixel density. Most people need Discern or Perceive and accidentally design for Scrutinize.
  2. Set the recording resolution first, then read the pixel width off it. 1080p gives you 1920; 720p gives you 1280. This is the numerator and nothing else changes it.
  3. Mount the phone roughly, open the live view, and measure the scene. Have someone hold a tape measure across the frame at the distance you care about, then read the frame edges. That number is your denominator.
  4. Divide. If you need 500 px/m and your frame is 8 m wide at 1080p, you have 240 — you are short by half. Move the phone closer or point it at a narrower slice.
  5. Narrow the scene rather than raising the resolution. Halving the scene width doubles pixel density for free. Raising 720p to 1080p only gains 50%, and costs storage and heat.
  6. Check the close limit. If you have moved in tight — a till, a meter, a gauge — confirm the camera still focuses there. Fill the frame with printed text and see whether it resolves. On a fixed-focus lens it will not, and no setting will fix it.
  7. Do not solve it with zoom. Zoom crops the sensor read-out. It makes the subject bigger on your screen without adding samples.

Where this app fits, and where it does not

Background Camera RemoteStream is built for exactly this kind of setup: an old Android phone recording with the screen off, video kept locally on the device rather than pushed to anyone's cloud, and a built-in web server so you can open the live view in a browser on another device on the same network — which is how you check the framing without unmounting anything.

Being honest about the limits: none of the above is something an app can fix. Pixel density is decided by where you put the phone and how wide the scene is. If the lens is fixed-focus, that is hardware. We do not publish a distance table for specific handsets, because the honest version of that table needs the angle of view of every phone, and we have not measured them. What the browser live view genuinely helps with is step 3 — you can see the frame from where you are standing with the tape measure, instead of guessing.

Related reading

More at superfunicular.com.

Sources

All first-party documentation read 2026-09-04.

Top comments (0)