Save an image sequence with numbered filenames

What you need before capture

Prepare these items before starting the loop:

• A graph image that is refreshed for each capture.
• An existing output folder that your application can write to.
• A frame counter with a defined starting value.
• A number-formatting function and a path-building function.
• An image writer with an explicit file-path input and an error output.

Use a new, empty folder for each capture run. Numbered filenames prevent collisions within a run, but restarting the counter in an old folder can still target existing files. Keep previous captures separate rather than deleting them automatically.

Build the filename and path inside the loop

The folder can stay constant during a run. The filename must change for each frame. In a graphical dataflow program, functions such as Format Into String and Build Path provide these two separate operations.

1. Create and check the output folder before entering the loop. Confirm that it exists and is writable. Do not assume that an image-writing function also creates missing directories. If your application creates the folder, handle any creation error before starting capture.

2. Initialize the frame counter. Start at zero unless the intended sequence importer requires another starting value. Keep this counter separate from a general loop counter if some loop passes do not save an image.

3. Format the counter as a filename inside the loop. For a formatter that supports printf-style integer formatting, %06d.jpg produces names such as 000000.jpg, 000001.jpg and 000002.jpg. A fixed prefix is also useful: graph_%06d.jpg produces graph_000000.jpg. The extension must match the encoder you actually use.

4. Join the folder and filename with a path-building function. Supply the output folder as the base path and the generated filename as the final component. Avoid manually adding directory separators. A path-building function handles the platform's path syntax more reliably than string concatenation.

5. Connect the complete path to the image writer. Capture the current graph image and pass it, together with the generated path, to the writer on the same loop pass. Check the data dependencies so the image is captured after the graph data has been updated.

6. Handle the result before advancing the counter. After a successful write, increase the frame counter. On a write error, stop capture and report the error, target path and frame number. Do not continue silently and present an incomplete folder as a complete capture.

Inspect the generated path during a short trial. You should see the folder remain unchanged while the final filename advances. Formatting the filename outside the loop from a fixed starting value leaves every write targeting the same name.

Make the numbers sort in capture order

Zero padding matters when a file browser or sequence importer sorts names as text. Without padding, frame_10.jpg can appear before frame_2.jpg. With equal-width numbers, frame_000002.jpg sorts before frame_000010.jpg.

Choose a width that covers the largest frame number you expect in one run. In printf-style formatting, the width in %06d is a minimum, not a limit. Six digits keep the numeric portion the same width from 000000 through 999999; larger values expand beyond that width and can break the intended text order.

Avoid unnecessary format inputs. A literal prefix in graph_%06d.jpg needs only the integer counter. A format such as %s_%06d.jpg needs both a string prefix and an integer, supplied in the correct order. If you have only a frame counter, remove the string conversion rather than leaving its input unresolved.

Use the counter for ordering and, if needed, record capture times separately. A timestamp alone may repeat when several frames are captured within its displayed precision.

Diagnose overwrites and repeated prompts

Check the complete output path before changing graph rendering or image settings. These symptoms point to different parts of the workflow:

• One file changes repeatedly: the writer probably receives the same path each time. Inspect the formatted number and the final path on successive passes.
• A save dialog appears on every pass: the writer may be receiving an empty path or using an interactive save mode. Supply an explicit path and check the function's documented behavior.
• Writing stops at the first frame: check whether the folder exists, the application has write access, or the target filename already exists under a no-overwrite policy.
• The filename is malformed or formatting fails: check the format syntax, input types and number of conversion inputs.
• Names advance but every image looks the same: inspect the graph update and image-capture order. Distinct filenames do not prove that fresh image data reached the writer.
• A new run changes files from an earlier run: the counter restarted in a reused folder. Separate runs into different folders.

Keep the writer's error information connected through the loop. The error code and source text are more useful than guessing whether a failure came from permissions, an invalid path or unavailable storage.

Keep filename order separate from capture timing

A sequence of correctly numbered files does not establish a capture rate. For a target of 24 frames per second, the average interval is about 41.7 milliseconds, calculated as 1,000 milliseconds divided by 24. Updating the graph, capturing it, encoding the image and writing it all consume time.

Measure the actual capture intervals. A fixed wait added after a write does not account for the time already spent processing that frame. If capture cannot keep pace, decide whether the application should slow down, stop or record missed capture opportunities. Do not silently claim that the requested timing was achieved.

If you later assemble the images into a movie at a fixed frame rate, the movie's duration follows its frame count and assigned rate. It does not necessarily reproduce the elapsed time of an irregular capture. Keep a separate timing log when that distinction matters.

Check the saved sequence before a long run

Start with a short capture and a graph that changes visibly. Then check the result:

• Compare the number of saved images with the application's count of successful writes, not merely its loop iterations.
• Sort the filenames as text and confirm that their numeric order is correct.
• Check that the first and last frame numbers match the expected range.
• Open the first, a middle and the last image. Confirm that each decodes and contains the expected graph state.
• Restart capture into a different folder and confirm that the previous run remains unchanged.
• Confirm that an ordinary write error is reported with the affected filename rather than ignored.

Keep capture validation separate from final media preparation. Once you have assembled the sequence into a movie, use the image and video preparation guide for the delivery-file basics. If the result is intended for a sign, the content checker can inspect the exported media's resolution, shape and codec. Those checks complement the filename workflow; they do not establish that every intended graph frame was captured.

Questions