3D camera pixel format locked read-only: set the scan type first

You connect an industrial 3D camera over GigE Vision, the acquisition filter finds the device, and the first real configuration write — the pixel-format input many suites label inPixelFormat — is refused with a read-only error. The camera is healthy, and no permission switch is missing. The PixelFormat node is locked because the camera still runs its 2D area-scan mode, and GenICam turns a node read-only whenever the state it depends on is wrong. This troubleshooting guide gives you the one setting that clears the lock, the choice between the two 3D formats that appear once it is set, the exact write order, and the bandwidth each format costs on a GigE link.

Why is the pixel format read-only on your 3D camera?

Because DeviceScanType still selects 2D capture. GenICam gives every feature an access mode — read-write, read-only, write-only, or not available — and a camera sets PixelFormat read-only whenever the active scan type makes the requested format an illegal value.

Coord3D formats describe point data, so they are legal entries only while the camera produces 3D output. In the 2D mode, the enumeration behind the pixel-format list holds greyscale and colour entries such as Mono8, and a write naming a Coord3D value fails the access check before it ever reaches the sensor. The dialog you are hunting for — a read-write toggle — does not exist anywhere in the chain, because the lock is a consequence rather than a setting.

Two neighbouring symptoms are worth separating from this one. A format that accepts writes but snaps back points at the camera's fixed list. A single entry greyed out in an otherwise writable list usually means the transport cannot carry it. Your case is the third kind: the whole node refuses writes until a different node is written first.

Where do you find DeviceScanType in your software?

In the camera's GenICam feature tree — near the root, usually inside a device-control category — which any compliant tool can display: the camera maker's own viewer, a GenTL-capable browser, or the device-settings panel behind your acquisition filter.

Open whichever of those you have, stop acquisition, and read the node's access mode before touching anything. If your analysis suite hides the tree behind its filter, set the scan type once in the vendor's viewer and reconnect: the mode lives in the camera, so the next connection picks it up. One rule holds regardless of tool — only one consumer should have the device open while you change modes, or the second holder's stream forces the lock straight back on.

What value should DeviceScanType take for 3D capture?

Areascan3D. That enumeration value tells the camera to produce full-frame 3D data, it returns PixelFormat to read-write, and it swaps the format list from 2D entries to the Coord3D family, in which Coord3D_ABC16 and Coord3D_C16 appear.

The scan-type list also carries 2D values, and the standard defines a line-style 3D counterpart for cameras that stream profiles rather than frames. Your software's 3D tools decide which you need: a suite consuming area-style depth images wants Areascan3D even when the sensor is a line-profiler at heart, because the host assembles the height map. When you pick a 3D capture profile in the maker's own software, it writes this same node behind the scenes — which is why the problem only surfaces once you move to third-party, standards-based acquisition.

Which format should you set: Coord3D_ABC16 or Coord3D_C16?

Take Coord3D_C16 for a depth map, Coord3D_ABC16 for a full point cloud. C16 carries one 16-bit coordinate per pixel at 2 bytes; ABC16 carries three — the A, B and C axes, in practice X, Y and Z — at 6 bytes per pixel, exactly three times the payload.

Most commercial 3D toolsets want the depth map plus the camera's calibration data and construct geometry themselves, so C16 is the sensible choice for inspection and measurement. Reach for ABC16 when the consumer is a point-cloud library that expects organized XYZ per pixel and does not want to combine a depth map with calibration itself. The standard also defines Coord3D_ABC16_Planar, which ships the same three channels as three consecutive planes instead of interleaved pixels; pick it only when your library names it explicitly.

In what order do you write the settings?

Stop acquisition, write DeviceScanType to Areascan3D, reconnect the filter so the format list refreshes, write PixelFormat, then restart the stream — five minutes in that order, while any other order invites the same read-only refusal or a stale format list.

1. Stop the stream in every tool that has the camera open, the vendor viewer included, and let the device sit idle.
2. Set DeviceScanType to Areascan3D.
3. Reconnect the acquisition filter, or re-open the device, so the software re-reads the format enumeration. A filter that keeps the list from connect time will otherwise keep offering 2D entries.
4. Set PixelFormat to Coord3D_C16 for a depth map, or Coord3D_ABC16 for a full cloud.
5. Restart acquisition and pull exactly one frame. A C16 stream arrives as a 16-bit single-channel image; an ABC16 stream arrives as three channels.

Before you call it done, confirm three things: the format list now shows the Coord3D entries, only one consumer holds the camera, and the frame you pulled decodes with the channel count you expect.

How much bandwidth does each 3D format need?

At an illustrative profile resolution of 1280 × 1024 pixels, one frame is 2.62 MB as Coord3D_C16 and 7.86 MB as Coord3D_ABC16; over a GigE Vision link carrying a practical 100 MB/s that supports roughly 38 fps and 13 fps respectively.

The 100 MB/s figure has a basis: 1000BASE-T moves 1 Gbit/s, which is 125 MB/s of raw bits, and GigE Vision packetisation plus Ethernet overhead leave 90–110 MB/s of usable image payload with jumbo frames enabled. With standard 1500-byte frames, plan on roughly two-thirds of that. For switch sharing, cabling and multi-camera planning, read GigE camera network planning: switch ports and bandwidth.

The decision follows from the arithmetic. Depth-map inspection at 30 fps fits one GigE cable in C16 with headroom to spare. A full ABC16 cloud at that resolution tops out near 13 fps, so either accept the rate, shrink the region of interest, or put that stream on a 10-gigabit interface.

What if PixelFormat is still read-only after the switch?

Close every other consumer first: most often the lock survives because the vendor viewer or a second filter instance still holds the stream open, and nodes that reshape the payload stay locked until the device sits idle.

Work the causes in order of probability:

1. A second consumer holds the camera. Close the vendor viewer and every program that enumerated the device, then re-read the access mode. The lock clears the moment the last stream closes.
2. The filter cached the feature tree. The tree still lists only 2D formats. Reconnect the filter, or reload the whole program, so it re-reads the camera.
3. The firmware predates the camera's 3D support over GigE Vision. If the maker's own viewer also offers no 3D scan type and no Coord3D formats, update the camera using only the maker's own package and release notes, then repeat the write order above.
4. The format belongs to another component. Some host drivers fetch the point-cloud X and Y channels themselves and ask you to leave those components alone, so the writable format list depends on the component currently selected in the tree. Find the component selector, select the depth component, and write the format there.

What should you plan once the depth stream runs?

Mask before you measure: read the confidence map that ships beside the depth component before trusting any Z value, because glossy, dark or steep surfaces produce holes a plain depth map does not flag. The bit-flag decoding is covered in 3D camera confidence image values, and the mounting geometry is covered in the 3D camera working distance and positioning guide.

If a robot carries the camera, settle the controller and protocol questions before you tune the stream — see 3D camera robot integration. Whatever sensor you standardize on, keep two routes into it: the vendor SDK for full control, and the standards interface for the vision software — exactly the split that produced the read-only surprise in the first place.

The classes that cover most new 3D stations:

Browse the full 3D sensors range or the camera finder for the sensor, then size the rest of the station in the system configurator. If the integration question outgrows a guide, send it to the applications team through the contact page.