You spent years driving the camera from a desktop tool, and now the HMI is a web page: the button that used to launch the camera executable does nothing. That is not a permissions problem you can script around. A page in a browser cannot start programs on the machine it runs on, so the camera tool has to move off the operator's PC and behind the network. What follows is the architecture that works - camera images served over HTTP as JPEG snapshots or an MJPEG stream - the bandwidth arithmetic for a real 12 MP camera, and the checks to run before the tile goes live on the plant floor.
Why the browser will not launch your camera executable
A web page can fetch URLs, draw and run scripts inside its own tab. It cannot start a process on the client machine. If it could, every site an operator visited could run any installed program, so browser engines block local execution at the core - and a browser-based HMI runtime runs on those same engines. The call that opens the camera .exe from a desktop HMI simply does not exist in the web one.
The two workarounds people reach for first both fall short. A custom URI scheme - the mechanism that opens a mail client from a mailto: link - can hand a link to a local program, but the scheme must be registered on every client, the program then runs outside the HMI window and its login, and locked-down panels drop the hand-off silently. The browser's permission-based camera access can open a camera attached to the client, after an explicit user prompt and over a secure connection - but it addresses a webcam or a UVC device on that client, never the inspection camera on the factory switch. What a UVC device needs on the controller side is its own question, covered in USB UVC camera support on an industrial controller.
The design that works: serve the image over HTTP
Turn the camera feed into a web resource, and let the browser do what it is good at: displaying pictures. An industrial camera speaks GigE Vision or USB3 Vision to a host, not HTTP, so a small service on the vision computer sits in the middle. It grabs frames through the camera SDK, scales each frame to the tile size, JPEG-encodes it and serves it; the HMI page holds nothing but an image tag pointed at that URL. The full wiring for one camera is in embedding a machine vision camera stream in a web HMI, and the screen side in displaying an MJPEG stream in an HMI screen.
Serve two endpoints - call them /snapshot.jpg and /stream.mjpg:
- /snapshot.jpg answers one request with one image/jpeg frame. Poll it once a second for a status tile.
- /stream.mjpg holds the connection open and writes frame after frame using the multipart mixed-replace media type, each part an image/jpeg. Mainstream desktop browser engines render that in a plain image tag; some stripped-down embedded webviews do not, so bring the tile up once on the actual HMI client.
If the camera is a surveillance-style IP camera it already speaks HTTP or RTSP, and the job becomes re-serving rather than capturing - restreaming an RTSP stream for display in an HMI browser covers that path. The same feed can carry data as well as pictures: decoding barcodes from a live RTSP or MJPEG video stream runs off the preview service output. For placement of cameras in a plant HMI generally, this guide on viewing IP camera streams in an HMI web browser is a useful companion.
Host the service where the camera is: on the machine that already runs the vision software, or on a fanless industrial mini PC mounted beside it.
Snapshot, stream, device camera or file upload?
| Method | What the browser gets | Refresh | Cost per tile | Right tool for |
|---|---|---|---|---|
| Snapshot JPEG, polled | one still frame per request | 1 Hz | 0.32 Mbit/s | status tiles, many clients, slow links |
| MJPEG stream | continuous JPEG frames | 5-10 fps | 1.6-3.2 Mbit/s | live motion, up to about ten tiles |
| Client camera permission | the operator's own webcam | live | no network load | photos taken at the station |
| File upload | pictures the operator picks | once | one-time | attaching evidence to a record |
Costs assume 40 kB frames at 640 × 480, the inputs used in the worked example below. The display-side trade-offs are laid out in a live camera image in an HMI runtime: snapshots versus streams, and the cost of too many live streams in why an MJPEG stream slows HMI pages.
Sizing the stream: a 12 MP camera feeding a 640 × 480 tile
Inputs:
- Camera output: 4000 × 3000 px at 30 fps, from a 12 MP USB3 camera, the LS-CMR-0166.
- Display tile: 640 × 480 px, measured from the HMI screen layout - change this for your panel.
- Preview rate: 10 fps, fast enough for an operator to follow motion.
- Encoded size: 40 kB per JPEG frame, typical for 640 × 480 at mid quality - measure yours and scale linearly.
The sensor delivers 4000 × 3000 = 12,000,000 px per frame; the tile shows 640 × 480 = 307,200 px. Divide one by the other: 12,000,000 ÷ 307,200 ≈ 39, so the preview carries about one fortieth of the pixels the camera produces. Sending raw 8-bit mono sensor frames instead would cost 12 MB per frame, 360 MB/s at 30 fps; multiplied by 8 bits that is about 2,880 Mbit/s - reasonable for the camera's own cable, absurd for a browser tile.
The preview costs 40 kB × 10 fps = 400 kB/s, which is 3,200 kbit/s ≈ 3.2 Mbit/s per tile. One frame period at 10 fps is 1 ÷ 10 = 0.1 s = 100 ms, and with two to three frames of socket buffer the operator sees the scene 200-300 ms late.
Decision: serve every preview downscaled to its tile at 10 fps and budget 3.2 Mbit/s per camera. Above about ten tiles on one client, or the moment a tablet joins over Wi-Fi, drop previews to 5 fps at 1.6 Mbit/s each, or poll snapshots at 1 Hz for 0.32 Mbit/s. Treat 300 ms as the floor of what this preview can show; an operator who must align faster than that needs a direct display, not a browser tile.
Choose the camera for the inspection, not for the tile
The tile in the example needs 307,200 px - about 0.3 MP, pocket change next to any inspection camera in the area scan cameras finder. Display never drives camera resolution: pick sensor pixels from the smallest defect you must measure, with the camera resolution calculator, then let the service downscale whatever arrives. Shutter belongs to the measurement too: rolling-shutter tearing is cosmetic in a preview and ruins a measurement of a moving part.
Three cameras, three roles:
| Specification | LS-CMR-0166 | MV-CH120-11UC | MV-CS200-10UM |
|---|---|---|---|
| Sensor model | Sony IMX226 | Sony® IMX304 | Sony® IMX183 |
| Resolution | 4000 × 3000 (12MP) | 4096 × 3000 | 5472 × 3648 |
| Max. frame rate | 30 fps | 30.3 fps @ 4096 × 3000 Bayer RG 8 | 19.2 fps @ 5472 × 3648 Mono 8 |
| Pixel size | 1.85 μm | 3.45 μm × 3.45 μm | 2.4 μm × 2.4 μm |
| Sensor size | 1/1.7" | 1.1" | 1" |
| Data interface | USB 3.0 | USB 3.0, compatible with USB 2.0 | USB3.0, compatible with USB2.0 |
| Sensor type | – | CMOS, global shutter | CMOS, rolling shutter |
| Dynamic range | – | 72.2 dB | 65.5 dB |
| SNR | – | 40.2 dB | 41.5 dB |
| Gain | – | 0 dB to 24 dB | 0 dB to 24 dB |
| Exposure time | – | UltraShort exposure mode: 1 μs to 14 μs; Standard exposure mode: 15 μs to 10 sec | 44 μs to 0.83 sec |
| Exposure mode | – | Off/Once/Continuous exposure mode | Off/Once/Continuous exposure mode, supports Global Reset and Rolling |
| Price | $560.00 | $2,339.00 · quoted | $759.00 |
Values as printed in each product's data sheet; open a part for its drawing and full specifications.
The LS-CMR-0166 from the example above doubles as a bench camera. For moving parts, the MV-CH120-11UC brings a global shutter to the same 12 MP class over USB3. When the measurement needs the pixels, the MV-CS200-10UM carries 20 MP. Filter by interface, shutter and resolution in the camera finder.
Strobed light and the free-running preview
A free-running preview and a strobed inspection light fight: the light fires briefly on each inspection trigger, while the preview grabs frames continuously, so most preview frames land in the dark interval and the tile sits black. Two fixes:
- Run the light's channel at a continuous dimmed level for preview, and let the inspection trigger strobe it to full power - most digital controllers accept a continuous level and a strobe input on the same channel.
- Have the preview service fire the strobe itself for each frame it serves. That costs a strobe output and caps the preview rate at the light's recovery time; take that trade only when the operator must see the strobed state.
One controller that does both jobs:
- Output
- Constant voltage 24 V
- Channels
- 4 channels
- Control
- Digital
Match the rest in the light controllers category: channel count to your lights, output type to the fixture.
Checks before the tile goes live
- Test on a plant-floor client, not a desk machine. Managed enterprise browsers can block local addresses and permission prompts even when the development browser loads everything.
- Match the page's security. An HMI served over HTTPS blocks plain-HTTP image URLs as mixed content; put the stream behind the same proxy.
- Bust the snapshot cache. Add a changing query parameter to each snapshot request, or the browser keeps the first frame - the failure mode and fix in restarting an MJPEG stream by closing the client socket.
- Read the stream as bytes. A multipart frame can split across reads; a reader that assumes one image per read produces corrupt JPEG data with extraneous bytes.
- Work grey and partial tiles in order. Start with MJPEG versus RTSP and snapshot JPEG URLs for a grey camera widget; for frames that load half-way, see fixing partial image loads in a web browser view.
- Scale before you add streams. Past a handful of cameras, follow the pattern in displaying multiple IP camera streams on one HMI screen.
- Authenticate once, centrally. A stream that opens on the server but not on the clients is usually a login problem - read an IP camera stream that works on the server but not on clients.
When the browser tile is the wrong answer
- The station needs photos from the operator's own device: use the browser's permission-based camera access, prompt and all. It is a webcam path, not an inspection path.
- An engineer must drive the camera maker's local analysis tool interactively: run that screen on the vendor's thick-client HMI runtime, and keep the web HMI for overview tiles.
- The operator aligns parts against feedback faster than the preview floor of 300 ms: put a direct display at the station.
- The record needs one photo per part: a file-upload component, or a server-side snapshot at the inspection trigger, beats a continuous stream.
Checklist before you order
- Camera chosen by measurement pixels - defect size to sensor resolution - never by tile size.
- A host picked for the stream service, on the same switch or link as the camera.
- Tile sizes and counts measured; per-client bandwidth summed against the worked-example figures, with 5 fps or polling as the fallback.
- Light plan: continuous preview level plus strobe input on the inspection channel.
- Stream behind authentication and the same security as the HMI page.
- One locked-down panel client tested end to end before rollout.
Ready to pick parts? The configurator starts at the camera step:
The configurator matches a camera, lens, light, light controller and cables to each other, step by step, and lists only parts that fit what you already picked.
Questions
Can the HMI page launch the camera program if I register a URI scheme?
Technically yes, and it is still the wrong tool for a production screen. A custom scheme registered in the client operating system lets a link hand off to a local program, the way a mailto: link opens a mail client. Every operator PC needs the registration, the program then runs outside the HMI window and its login, and locked-down panels drop the hand-off without an error. Keep it for a supervised engineering station.
Does an industrial camera serve the MJPEG stream itself?
Usually not. GigE Vision and USB3 Vision cameras deliver pixel data over their own protocol, which a browser cannot speak. Surveillance-style IP cameras often carry a built-in HTTP MJPEG or RTSP output you can display directly. For an industrial camera, a small service on the vision computer pulls frames through the SDK, encodes them at tile size, and serves the stream - and that service is also where you add authentication and logging.
How many camera tiles can one HMI client show?
At 10 fps and 40 kB frames, each tile costs about 3.2 Mbit/s, so bandwidth is rarely the first limit: four tiles is 12.8 Mbit/s, comfortably inside a 100 Mbit link. The first limit is decode and repaint on the panel. Plan eight to ten MJPEG tiles on a standard panel client, and past that drop to 5 fps (1.6 Mbit/s each) or poll snapshots. Serving many clients from one stream service saves camera-side load, not panel load.
Does the camera preview need HTTPS?
A plain image tag with an MJPEG or snapshot URL works over HTTP, with one condition: if the HMI page itself is HTTPS, the browser blocks the plain-HTTP image as mixed content. Put the stream behind the same reverse proxy so both share one origin and certificate. Only the browser's permission-based camera access strictly requires a secure connection and a user prompt; a plain image stream never triggers that prompt.
Why is the preview dark while the inspection light strobes?
The preview camera free-runs, but the light fires only on inspection triggers, so most preview frames land inside the dark interval. Run that light's channel at a continuous dimmed level between inspections and let the trigger strobe it to full power - most digital controllers take a continuous level and a strobe input on one channel. Full overdrive then stays reserved for the frames the measurement actually uses.
Is the camera's 30 fps wasted on a 10 fps preview?
No - the rates are decoupled by design. The camera runs at the speed the inspection needs, and the preview service encodes every third frame at 10 fps. When the camera idles between parts, the service can keep serving the last good frame until the next trigger. That decoupling is the reason preview bandwidth stays fixed no matter what the sensor does upstream.