Your board-level camera streams happily in YUY2, but the moment you select the grey (Y800) mode the viewer throws 'The parameter is incorrect (87)' - and the YUY2 image is so dark that the gain slider looks like the only hope, except it snaps back dim the instant you let go. That combination is the standard signature of a UVC camera module on Windows, and it has one cause you can fix in a minute and one you should fix in the station design. This guide ranks the likely causes, gives a test and a fix for each, compares the pixel formats a UVC camera actually offers, and works the bandwidth arithmetic that decides which mode to standardise on. You finish with a format written into the spec and an exposure procedure that keeps grey images bright without touching a slider again.
What error 87 tells you
Error 87 is Windows reporting that a parameter handed down the capture chain is invalid, and here that parameter is the media type: the format, resolution and frame rate your viewer asked the camera to deliver. A Windows capture application builds a chain of filters - camera source, then decoders and converters, then the renderer. Every filter must accept the media type or convert it. Y800 carries 8-bit greyscale, one byte per pixel with values from 0 to 255 - the same data machine-vision software calls Mono8. Viewer installations almost always ship converters for colour formats such as YUY2 to RGB, and almost never one for 8-bit greyscale. The connection is refused, and the application surfaces the operating system's invalid-parameter error instead of a plain explanation.
The camera is not faulty: the negotiation failed, not the device. If YUY2 streams in the same viewer, the USB link, sensor and driver all work. The USB camera format negotiation guide walks that negotiation step by step when the rejection shows up at startup instead of when you switch modes.
Three likely causes, tested in order
Work down the list; the first cause accounts for nearly every report.
1. The viewer has no greyscale converter
Test: stream YUY2 from the same camera in the same viewer. If YUY2 runs and Y800 fails, the chain is missing the greyscale decoder. Fix: run the camera in a format the chain already decodes - YUY2, UYVY or MJPEG - and take the greyscale image from the YUY2 luma plane as shown below. A viewer or SDK that decodes grey natively removes the problem completely.
2. The mode is not offered at that resolution and frame rate
Test: open the camera in a second application that lists every supported format, resolution and frame-rate combination. Some modules offer grey modes at only a subset of resolutions. Fix: pick a combination the list confirms. The pixel format is fixed per stream, and no dialog setting invents one the camera never advertised.
3. Firmware or driver misdescribes the formats
Test: a vendor SDK or a non-Windows host exposes grey modes that the Windows viewer does not see, or every grey mode fails at every resolution while colour modes run. Fix: update the module's firmware or driver from the manufacturer's own download source. A mismatched format descriptor is the maker's bug to fix, and a confirmed one is worth reporting to them.
The pixel formats a UVC camera offers
A UVC camera advertises a short list of formats and the viewer picks one per stream. YUY2 packs YUV 4:2:2: every pixel keeps its own luma byte and each pixel pair shares one chroma pair, so it costs 2 bytes per pixel. Y800 and Mono8 are one byte per pixel of pure intensity. MJPEG arrives compressed, typically 0.3 to 1.5 bytes per pixel depending on scene detail. RGB24 is uncompressed colour at 3 bytes per pixel.
| Format | Bytes per pixel | Grey detail | Windows viewer support |
|---|---|---|---|
| Y800 / Mono8 | 1 | native greyscale | often missing - error 87 |
| YUY2 | 2 (YUV 4:2:2) | full-resolution luma | near-universal |
| UYVY | 2 | full-resolution luma, different byte order | common |
| MJPEG | 0.3-1.5 compressed | grey after decode | near-universal |
| RGB24 | 3 | converted from luma | near-universal |
Standardise on YUY2 for uncompressed capture on Windows: it runs everywhere and carries full-resolution greyscale inside it. Use MJPEG when the frame rate you need exceeds the uncompressed bus budget, computed below. Reserve Y800 for software that decodes it natively - machine-vision SDKs - not generic viewers. Frame rate also interacts with exposure; the RGB camera frame rate limits guide shows how format and exposure each cap fps.
Worked example: 1080p at 60 fps, YUY2 versus Y800
Inputs: 1920 × 1080 pixels per frame at 60 frames per second, a typical high-frame-rate UVC mode; 2 bytes per pixel for YUY2 and 1 for Y800 from the format definitions above; and USB 3.0's line rate of 5 Gbit/s, which leaves 4 Gbit/s for data after 8b/10b line coding.
- Pixels per frame: 1920 × 1080 = 2,073,600.
- YUY2: 2,073,600 px × 2 B = 4,147,200 B per frame; × 60 fps = 248,832,000 B/s; × 8 bit/B = 1,990,656,000 bit/s ≈ 1.99 Gbit/s.
- Y800: 2,073,600 px × 1 B = 2,073,600 B per frame; × 60 fps = 124,416,000 B/s; × 8 bit/B = 995,328,000 bit/s ≈ 0.99 Gbit/s.
YUY2 at 1080p60 takes about half the 4 Gbit/s ceiling and Y800 a quarter, so both fit with room for other devices on the bus. That makes the decision simple: when the viewer refuses Y800, decoding grey from the YUY2 stream costs nothing in frame rate - it is the fix, not a compromise. The threshold to respect is roughly 4 Gbit/s for one uncompressed camera stream. At 3840 × 2160 the pixel count quadruples, so YUY2 needs 4 × 1.99 ≈ 7.96 Gbit/s: no viewer will carry 4K60 uncompressed, so that mode runs MJPEG or steps down in frame rate.
The dark image is exposure, not the brightness slider
The YUY2 stream works but is dim, brightness helps a little, and the gain slider seems to work only while you hold it. Two mechanisms are at work. Brightness shifts the output curve after capture and cannot collect more light, which is why it helps only slightly. The reverting gain means an automatic mode owns the control: with auto gain or auto exposure enabled, the camera re-asserts its computed value every frame, so a manual entry lasts exactly as long as the mouse button is held. Some viewers also write the value only while pressed. Either way, the fix is to take the controls away from the auto modes first.
- Turn off auto exposure and auto gain for this camera. On colour sensors the auto algorithms meter from specific pixels, and the auto exposure and auto gain guide explains why the result can sit dark even in good light.
- Set exposure before gain. Exposure is integration time, so raise it until motion blur becomes the limit. The raw numbers are camera-specific units rather than milliseconds; the camera exposure and gain units guide shows how to interpret them.
- Set gain last and keep it small. Gain amplifies signal and noise together: exposure is free image quality, gain is borrowed.
- If auto gain still clamps the image dark under adequate lighting, check the maker's site for a firmware update that widens the auto-gain range; several smart camera modules shipped narrow and fixed it in a later image.
- If the exposure you need exceeds the blur budget, add light - a brighter machine vision light is the honest fix.
Getting grey data anyway
You wanted grey mode for a reason, and YUY2 already contains it. The byte order per group of four is Y0, U, Y1, V, so reading the bytes at offsets 0 and 2 yields one intensity byte per pixel at full resolution - exactly the data Y800 would have carried. One pass over each frame in your own code does it; no filter installation, no extra hardware. Dropping the chroma bytes discards only colour, which grey mode would have thrown away anyway.
For a production station, remove the dependency on viewer behaviour altogether. Machine-vision cameras speak USB3 Vision or GigE Vision to a GenICam SDK: the SDK lists pixel formats such as Mono8 directly and decodes them itself, so no DirectShow chain sits between you and the sensor. The board level camera selection guide covers the trade-offs of building one in, across the board-level cameras and area scan cameras categories.
The MV-CB060-10UM-B is a 6 MP mono board-level camera on USB3, shipped as a bare board to mount inside your own housing.
- Sensor format
- 1/1.8"
- Interface
- USB3
- Resolution
- 6-10 MP
- Shutter
- Rolling
These USB3 machine-vision cameras span compact board-level modules to multi-megapixel area scan heads, and each exposes its pixel formats to the SDK, so Mono8 grey becomes a menu selection instead of a negotiation.
- Sensor format
- 1/1.8"
- Lens mount
- C-mount
- Sensor format
- 1/1.7"
- Interface
- USB3
- Sensor format
- 1/1.8"
- Lens mount
- C-mount
Prevent it in the next build
- List the camera's formats before ordering: stream each candidate mode in your real viewer and in your SDK. The board camera evaluation checklist turns this into a pass/fail sheet.
- Write the working format plus manual exposure and gain values into the station spec, and set them in code at startup rather than by slider.
- Budget the bus: keep one uncompressed camera under roughly 4 Gbit/s and give it its own host-controller port rather than a shared hub.
- If grey at a fixed frame rate is a hard requirement, specify a machine-vision camera from the start instead of a UVC module.
The decision, case by case
- Viewer throws error 87 on grey (Y800): the camera is healthy. Run YUY2, extract the luma plane, move on. Do not make the build depend on a converter filter installed by hand on every station.
- Dark YUY2 image: auto modes off, exposure up first, gain last and small; firmware from the maker only when auto gain clamps the image on its own.
- Native grey needed at rate or in production: machine-vision camera, Mono8 selected in the SDK.
- Next step: size the camera in the camera finder or walk the camera configurator; for a second opinion on a module you already have, contact the applications team.
Questions
Does error 87 mean the camera or its USB cable is faulty?
No. The camera streams YUY2 on the same cable in the same viewer, which proves the link, sensor and driver work. Error 87 appears when the viewer's filter chain cannot place a converter for the greyscale media type, so the negotiation is refused before the camera sends a frame. If a second viewer or an SDK also fails to stream any format, then suspect the cable or port - but a grey-mode-only failure never points at hardware.
Can I take greyscale from YUY2 without losing detail?
Yes, at full resolution. YUY2 is a YUV 4:2:2 packing: each pixel carries its own luma byte and each pair of neighbouring pixels shares one chroma pair. Reading the luma bytes - the first and third of every four - gives one intensity byte per pixel, the same data the Y800 or Mono8 mode would have delivered. Only the colour information is dropped, which is precisely what grey mode discards anyway.
Why does the gain setting revert the moment I release the slider?
An automatic mode owns the control. With auto gain or auto exposure enabled, the camera recalculates the value every frame, so a manual entry survives only while the application keeps writing it. Disable the auto modes first, then set exposure and gain manually in the camera's own raw units. If the auto modes still clamp the image dark under adequate light, look for a firmware update from the module maker that widens the auto-gain range.
Which cameras never hit this viewer problem?
Machine-vision cameras that speak USB3 Vision or GigE Vision to a GenICam SDK. The SDK enumerates pixel formats such as Mono8 directly and decodes them itself, so no Windows capture chain and no greyscale converter is involved. They are the right choice whenever grey images at a set frame rate are a hard requirement, while a UVC module remains fine for viewing and proof-of-concept work in YUY2.



