Buffer info width not available: fix the chunk payload type

Last month's acquisition script now throws genicam.gentl.NotAvailableException with BUFFER_INFO_WIDTH in the message, on a camera and cable nobody touched. Your image code did not change, and that is the clue: the failure happens before an image exists. The buffer that came back carries a chunk payload rather than a 2D image, so there is no width for the consumer to read. It is written for engineers driving GenICam cameras through a GenTL consumer such as harvesters. You will decode the exception, confirm the payload type in one pass, and pick between the two fixes: plain image payloads from the camera, or a current consumer build that handles chunk buffers.

What the exception actually says

A GenTL consumer talks to a GenTL producer — the .cti file your camera SDK installs — and every buffer arrives with a set of info values identified by standard names: BUFFER_INFO_WIDTH, BUFFER_INFO_HEIGHT, BUFFER_INFO_PAYLOAD_TYPE. NotAvailable does not mean the width is zero or corrupted. It means the producer reports no such value for this buffer. The message says so outright, naming both the info and the payload type: 'BUFFER_INFO_WIDTH' is not available for this buffer(payload type: PAYLOAD_TYPE_CHUNK_DATA). The status id is -1014.

Harvesters builds its image array by reading the buffer's width — the self._buffer.width line inside _to_np_array in your traceback. No width published, no array built, and the exception fires before your code sees a frame. That is why nothing in your processing stack is guilty: the failure sits between what the camera sent and what the producer reported about it.

Why a chunk payload arrives without a width

Chunk mode is a camera setting. When it is active, the camera appends per-frame values — exposure time, timestamp, line status — to every frame it sends, and the payload type becomes chunk data. That is exactly what chunk data on camera frames is for: metadata that travels with the pixels instead of over a second channel.

In the GenTL model a chunk-type buffer still holds the image, and the geometry travels alongside it as buffer info. The producer in this case does not publish BUFFER_INFO_WIDTH for chunk buffers, and consumer builds that assume the width is always present raise instead of coping. The case proves both halves: the same camera threw on harvesters 1.2.3, 1.2.4 and 1.2.6, then delivered its BayerRG8 frame on a current build. The script was identical the whole time; only the payload type and the consumer build decided success.

Three causes, tested in order

Work down the list; each test takes a minute.

1. Chunk mode is active on the camera. The exception text is the test: it names PAYLOAD_TYPE_CHUNK_DATA. Confirm where it came from by opening the remote device node map and reading the mode switch in the camera's chunk category. If your pipeline never consumes a chunk value, this is your cause and Fix 1 is yours.
2. The consumer build predates chunk handling. Print the installed library version, then run the same script on the current release. In the case, 1.2.3, 1.2.4 and 1.2.6 all threw; the current build returned the frame. This also explains a script that worked last month: an environment update moved the behavior. An earlier release surfaced a cousin of this fault as NotImplementedException, so even the exception name drifts between builds.
3. The producer omits geometry for chunk buffers at any version. Switch chunk mode off and fetch once. If plain image payloads work on the current consumer but chunk buffers still fail, the producer never reports width for chunk payloads. Keep chunks off, or take the case to the SDK's support channel.

Fix 1: put the camera back on plain image payloads

Do this on the camera side:

1. Stop the stream with ia.stop_acquisition().
2. Open the remote device node map (ia.remote_device.node_map in the harvesters example) and set the chunk mode switch off — the boolean that makes the camera append chunk values to every frame.
3. If the camera loads a stored configuration at power-up, write this state to its user set so a reboot cannot undo it.
4. Set values with their exact symbolic names; a near-miss enumeration is its own exception, as in GenICam enumeration invalid value.
5. Restart acquisition and fetch one buffer; components[0].data should now hold width × height × bytes-per-pixel elements — the worked example below does that arithmetic.
6. If you later want exposure or timestamp per frame, enable the individual chunk you consume, starting with the Image chunk, as in Chunk data exposure time error: enable the Image chunk first.

The switch sits on the camera, whichever GigE or USB3 area scan camera you drive through a producer, for example:

Fix 2: update the consumer and read chunks deliberately

Pin a current consumer release in your environment file. The case is the cleanest demonstration of version dependence you will find: one script, three older builds throwing NotAvailableException, the current build returning the BayerRG8 image.

If you keep chunk mode on, change how you treat the buffer. A chunk payload is image data plus appended values; read the chunk values you enabled from each buffer before it goes back to the queue, and branch on the buffer's reported payload type instead of assuming the first component is a bare image. Reading the values per frame is also how you get honest exposure data when the metadata channel misbehaves — see read actual exposure per frame when metadata says unsupported.

A fetch wrapper that logs the failure turns a crash into one diagnostic line:

from genicam.gentl import NotAvailableException

try:
    with ia.fetch_buffer() as buffer:            # ia from create_image_acquirer(0)
        data = buffer.payload.components[0].data
except NotAvailableException as error:
    print(error)  # names the buffer info, the payload type and the id

The frame stays raw, by the way: BayerRG8 is demosaiced downstream, and OpenCV is the usual tool for it.

Worked example: a 4000 × 3000 BayerRG8 frame, before and after

The example camera is a 12 MP USB3 area scan camera with a 1/1.7" rolling-shutter sensor, listed at 4000 × 3000 resolution and 30 fps. It comes from the area scan cameras range.

The pixel format is BayerRG8 — the format the fixed acquisition in the case delivered: 8 bits per pixel, one byte per pixel, no packing. The failing environment is Python 3.7 on Windows 10 with consumer builds 1.2.3 through 1.2.6.

The rule, in words: a 2D image component occupies width × height × bytes-per-pixel bytes, and BayerRG8 stores one byte per pixel.

The arithmetic: 4000 px × 3000 px = 12,000,000 pixels. At one byte per pixel that is 12,000,000 bytes, about 12 MB per frame. At 30 fps a single stream moves 12,000,000 × 30 = 360,000,000 bytes per second — 360 MB/s, beyond the roughly 118 MB/s a 1 GigE link carries at best, which is why this camera class streams over USB3.

Before the fix you never reach that number. The fetch raises NotAvailableException on BUFFER_INFO_WIDTH with payload type PAYLOAD_TYPE_CHUNK_DATA, id -1014, and component.data is never built. After the fix — chunk mode off on the camera, or the current consumer build — the fetch returns a buffer whose first component is the image, and this test proves it:

WIDTH, HEIGHT = 4000, 3000        # px, from the camera's specification
EXPECTED_BYTES = WIDTH * HEIGHT   # 12,000,000 bytes in one BayerRG8 frame

with ia.fetch_buffer() as buffer:
    data = buffer.payload.components[0].data
    assert len(data) == EXPECTED_BYTES  # passes: 12000000 == 12000000

The decision, with its threshold: fix the payload type first, then require the byte count. If the assertion passes, the exception is gone and the component is a plain 2D image. If the fetch still throws, the buffer is still chunk data, and the change belongs on the camera side, not in your image code.

Prevention: decide the payload type once per pipeline

1. Default chunk mode off. If no per-frame chunk value is consumed anywhere in the pipeline, plain image payloads are the whole contract: every producer reports their geometry, so no consumer build can trip.
2. Assert the frame size on the first buffer of every run. bytes = width × height × bytes-per-pixel for unpacked formats; wider and packed formats change the element count, not the pixel count, as in why your 16-bit image buffer has half the expected pixels.
3. Pin the consumer version. The case worked, broke and worked again purely across builds, and an older build even raised the same situation under a different exception name. Pin the release; upgrade deliberately.
4. Store the intended camera configuration in its user set at commissioning. A field reboot then cannot silently reload chunk mode.
5. When chunks are consumed, enable only what you read, and pull the values per buffer before the frame is requeued — that is where honest per-frame exposure numbers come from.

When NotAvailableException is not about chunks

A missing buffer info has other faces, and the message is what separates them:

• Size info missing on a color buffer. That usually means the format the buffer carries and the format your code assumed disagree; align the pixel format first — see color image buffer with no size info.
• Element counts that halve. A Mono16 frame fills half the elements you expect when the pixel size in code disagrees with the payload — see Mono16 buffer with half the elements.
• Camera-side settings delivered out of band. If a camera comes up with the wrong pixel format or a stale configuration, fix it at the register level — see access GigE camera registers at runtime from your control code.

In every variant, read the exception name and message before touching code: NotAvailable points at a value the producer did not supply, not at a value that is wrong.

If you are selecting the camera side of a new acquisition, the camera finder filters by interface, resolution and shutter type, and the build-a-system configurator walks camera, lens, light and controller in one pass. For everything around acquisition code, the systems topic page collects the guides, and the contact page reaches the application team.