Image sequence import: why only the first frame loads

An image batch can contain valid files yet open as a single still image. Selecting several filenames does not necessarily activate sequence playback, and changing the extension rarely fixes a discovery problem. This troubleshooting procedure is for engineers preparing existing frames for offline vision tests. You will separate file discovery from image decoding, build a small reproducible test, and verify that every expected frame reaches the processing pipeline. Keep the original batch unchanged until the cause is clear.

Identify where the sequence stops

Start with the importer's documented operating modes. Opening one image, opening multiple independent images, and opening a numbered sequence may use different commands. Some sequence tools expect you to select only the first file; others require a directory, filename pattern, or explicit list.

Check the following causes in order before converting the whole batch:

If acquisition itself also freezes, use the separate camera preview channel checks. A frozen display does not prove that a sequence importer discovered only one file.

Preserve the originals and inspect the batch

Make a working directory containing copies of the source images. Keep exported originals, original video, and any timestamps separately. Renaming files in place can destroy the evidence needed to reconstruct their order.

Create a manifest with these fields:

• Original filename and intended sequence index.
• Timestamp, when available, including its source and units.
• Decoded width and height.
• Channel count and pixel type.
• Whether the target application's image reader can open the file independently.

Check the first, middle, and last images, plus the file immediately after the apparent stopping point. If every file opens alone, that strongly suggests a discovery or sequence-compatibility problem rather than universally unsupported image encoding.

Verify the actual file type, not just the suffix. Renaming an image from .jpg to .png does not convert its encoding. Conversion requires decoding and writing a new image, which can also change intensity values or metadata.

For future exports, the frame-saving and offline enrollment guide covers capture-side organization. The task here is to make an existing batch reproducible without assuming how it was originally saved.

Correct numbering according to the importer

Use the importer's documented sequence rules as the authority. Consecutive numbering is a common requirement, but it is not universal. An importer accepting an explicit file list may allow gaps that a filename-pattern importer rejects.

A diagnostic sequence might contain:

frame_0000.png
frame_0001.png
frame_0002.png

Keep the prefix, suffix, extension, and numeric width consistent. Check whether numbering must start at zero, one, or the selected starting index. Also check whether the tool searches only the selected directory.

Unpadded names can produce an unexpected text-sorted order:

frame_1.png
frame_10.png
frame_2.png

Fixed-width numbering makes text order agree with numeric order within the chosen width. Four digits cover indices from 0000 through 9999. Choose the width for the complete batch before renaming it.

A missing index can stop an importer that searches for the next consecutive name. Other importers skip missing files or report an error. Test the actual behavior rather than assuming one rule applies everywhere.

If you renumber a working copy, retain an original-to-new filename map. A continuous test sequence can simplify import, but it must not imply that the source recording had no missing frames.

Run a minimal sequence test

Use a small test to separate filename discovery from image-content problems:

1. Copy three independently readable images into an otherwise empty directory.
2. Give them names matching the documented sequence pattern.
3. Confirm that all three decode to the same dimensions, channel count, and pixel type.
4. Open the documented sequence mode and supply the required source selection.
5. Disable looping and automatic skipping, where those options exist.
6. Step through the sequence while logging the source filename or index.

Choose visibly different source frames, or use clearly marked diagnostic copies. Three nearly identical images make successful advancement difficult to distinguish from a frozen display. Do not use annotated copies for intensity measurements or algorithm acceptance testing.

If this small sequence works, extend the test gradually. For example, try 10 frames, then 100, then the complete batch. When failure returns, inspect the first rejected file and the boundary immediately before it.

If the small sequence fails, avoid repeated bulk conversion. Record the exact command, selected path, filename pattern, and error message. These details usually reveal more than changing several export settings simultaneously.

Make decoded image properties consistent

A shared extension does not guarantee compatible decoded images. A directory can contain color, grayscale, and high-bit-depth images with the same suffix. Some sequence sources establish their output format from the first image and reject later differences.

Compare properties using the image reader that feeds your vision application. A desktop viewer may automatically rotate, scale, or convert images and therefore hide relevant differences.

If normalization is necessary, write a separate derivative set using a documented conversion process. Record resizing, channel conversion, orientation correction, and intensity scaling. Retain the originals for any later measurement review.

The guide to saving high-bit-depth camera images explains why display-friendly conversion can discard useful intensity information. Do not reduce bit depth merely to make import succeed unless the inspection requirements permit that loss.

Budget decoded memory and preserve timing

If a short batch works but a longer one fails, investigate memory and loading strategy. Compressed file size does not describe the memory required after decoding.

For an unpacked image, estimate the pixel payload as:

For a hypothetical grayscale image with 1920 × 1080 pixels and one byte per pixel:

1920 × 1080 × 1 × 1 = 2,073,600 bytes per frame
2,073,600 × 300 = 622,080,000 bytes
622,080,000 / 1,048,576 ≈ 593 MiB

That is only the image payload. Decoder buffers, processing copies, display buffers, and application overhead require additional memory. Determine whether the importer preloads the entire sequence or streams individual frames before choosing a remedy.

Timing needs separate treatment. Numbered images establish order, not necessarily capture intervals. Mobile video may have variable frame intervals, and exported images may omit presentation timestamps.

For example, 300 frames played at 30 frames/s represent 10 seconds under a uniform-rate assumption. That arithmetic does not prove the original recording lasted exactly that long. Preserve timestamps when testing speed, acceleration, tracking, or event duration. The sequence segmentation and tracking guide explains the downstream importance of consistent frame identity.

Try direct video import when it preserves the evidence

Opening the original video can avoid filename-pattern problems and retain timing information that an image export omitted. It is an option only when the application's decoder supports the actual video stream.

The filename extension identifies a container convention, not a complete decoding specification. A tool may recognize the container but lack support for its codec, profile, pixel format, or other stream properties.

Test a short section before relying on direct video import:

• Confirm that decoding advances beyond the first frame.
• Check dimensions, orientation, channel order, and intensity handling.
• Establish whether playback is sequential or depends on seeking.
• Check how timestamps and end-of-stream are reported.
• Compare decoded content against independently verified source frames.

The recorded video replay guide covers replay behavior beyond initial import. If the container opens in one application but not another, use the video backend compatibility checks.

Direct video import is not automatically the better measurement source. Lossy encoding can alter edges and fine texture. If the original recording is already compressed, exporting lossless images avoids further compression loss but cannot restore discarded information.

Verify complete processing, not just playback

A moving preview is useful evidence, but it is not a complete acceptance test. Verify the source and processing stages separately.

Count the files discovered, images decoded, frames processed, and errors reported. Those counts need not always match: an application may intentionally reject selected frames. Every difference should nevertheless have an explicit reason.

Inspect known frames at the beginning, middle, and end. Log their source identifiers at the point where the inspection receives them, rather than only at the import dialog. This detects an application repeatedly processing an old buffer while its source list advances.

Then test end-of-sequence behavior. The application should stop, report completion, or loop according to its documented setting. It should not silently treat the last image as a new acquisition.

Record the working filename rule, normalization steps, importer options, and software version alongside the manifest. Repeating the test should produce the same ordered input and the same frame count.

Separate file preparation from hardware selection

Do not replace a camera or controller to repair an unproven filename problem. For offline imports, the immediate questions are reader compatibility, sequence rules, and available processing resources. Review vision controllers only when a dedicated station has a demonstrated requirement; camera ports alone do not establish importer compatibility.

If you later need controlled acquisition rather than previously recorded video, compare area scan cameras through the camera finder. Interface selection belongs to that acquisition decision, not to the diagnosis of an existing file batch.

The LS-CMR-0053 is a GigE acquisition option.

The LS-CMR-0166 is a USB3 acquisition option.

Neither camera choice establishes compatibility with an offline sequence importer. Before ordering acquisition hardware, verify software support, required image properties, lens compatibility, exposure control, and the intended recording workflow.

Before closing the import investigation, confirm:

• The documented sequence mode is selected.
• Filenames follow its ordering and gap rules.
• Every intended file opens independently.
• Decoded image properties are consistent.
• Processing reaches the expected final frame.
• Timing assumptions and any missing frames are documented.

For unresolved compatibility questions, send the filename pattern, decoded image properties, software version, and exact error description through technical support. If the file workflow is already proven and you need a new acquisition source, start with the camera configurator.