FOGTESTER SOFTWARE ANALYSIS QA PART 2_27AUG2026.pdf

ARMY OPEN SOLICITATION W9128Z-25-S-A002

PROJECT NUMBER W911QY-26-R-FOG

Q&A PART TWO

QUESTION: Will the Government furnish the FogTester TCP interface specification, including message schemas, connection lifecycle, timing, error handling, and representative request/response examples? If so, at what stage will it be available?

ANSWER: Yes, by the end of the calendar year.

QUESTION: Will the Government furnish representative dual-camera images or video stills, camera and image-format metadata, designated region-of-interest definitions, calibration measurements, haze-standard values, the calibration-file schema, and expected pass/fail results for development and acceptance testing?

ANSWER: Yes.

QUESTION: If Government-furnished test data is not available before Phase 2, may an O eror demonstrate the software workflow using clearly labeled synthetic imagery, simulated TCP messages, and non-Government calibration values, without representing scientific or interface validation?

ANSWER: No.

QUESTION: Does the Government envision the improved BarTarget capability as a separate local process communicating with FogTester exclusively through TCP, or as code incorporated into the existing FogTester application? Will source code or a test harness for FogTester be furnished after award?

ANSWER: A separate local process. FogTester will launch the process and provide the TCP port number via the command line. A test harness will be furnished.

QUESTION: Will a resulting FAR Part 12 contract incorporate DFARS 252.204-7012, 252.204-7019, 252.204-7020, or 252.204-7021, or require a current NIST SP 800-171 assessment in SPRS? Does the Government anticipate that performance will involve Federal Contract Information or Controlled Unclassified Information?

ANSWER: Yes. Performance will involve Controlled Unclassified Information.

QUESTION: Is the new application primarily a post-test analysis program that receives completed image files, or must it also initiate, monitor, pause, or terminate test operations through the FogTester TCP interface? Please identify the categories of TCP commands or interactions expected.

ANSWER: The software interactively interfaces with FogTester over TCP. It will initiate, monitor, and terminate test operations. A file containing the TCP commands will be made available (when).

QUESTION: For the 2590 x 1942, 16-bit PNG files, does 16-bit refer to a single grayscale channel or to another channel configuration? How are camera identity, acquisition time, frame sequence, and synchronization between the two cameras represented?

ANSWER: It’s 16bit greyscale, but future versions may include 24bit RGB. The existing labview program enumerates the cameras. It saves PNG images to a temporary folder, the filename contains the data series name, a timestamp, and left or right.

QUESTION: How many ROIs are normally analyzed per camera? Must ROIs be manually selected, automatically identified, tracked for image drift, or adjustable during a test sequence?

ANSWER: The targets contain multiple regions of interest, but we typically only use one. The ROIs should be automatically identified, and tracked for image drift. Manual fallback / override for centering / scaling / and tracking should be provided.

QUESTION: Verification and acceptance: Will the Government provide a representative golden dataset and expected BarTarget outputs? What numerical tolerance, processing-time requirement, or other acceptance criteria will establish equivalence with the legacy analysis?

QUESTION: Will the Government provide documentation, source code, formulas, or other technical information describing how the existing BarTarget application selects regions of interest and calculates contrast ratio? If source code cannot be provided, will the underlying mathematical methodology and expected outputs be provided?

ANSWER: Yes (source code, LV executable, explanation)

QUESTION: Are the image regions of interest fixed in location and geometry for each test configuration, manually selected by the user, or expected to be automatically detected by the new software?

ANSWER: Automatically detected, although they should not change much except for drift.

QUESTION: Will the Government provide the FogTester TCP interface specification, including message formats, commands, data fields, connection behavior, and expected request/response sequences, upon award or earlier for selected Phase 2 o erors?

ANSWER: Yes

QUESTION: On the TCP interface in Section 3, is there an existing FogTester interface specification I should build against, or is the expectation that the new application defines the interface and FogTester gets updated to match?

ANSWER: It does not exist yet, we’re working on it.

QUESTION: Section 3 mentions the operator enters test condition parameters. Are the acquired video stills written to disk by FogTester in a fixed location and format that the analysis sub-program reads, or do the images come across the TCP connection?

ANSWER: The stills are written to disk, and the file paths are sent over TCP.

QUESTION: The requirements state that the 'image analysis software application shall interact with the FogTester software application in a local host environment' and 'shall communicate with the FogTester software via a TCP port.' Will the Government furnish the FogTester TCP protocol specification, message schema, calibration file format, and any existing BarTarget source or documentation to o erors in support of accurate solution design and pricing? If not, what assumptions should o erors document in the Solution Brief?

ANSWER: The TCP specification is not finished yet. We will furnish it when it becomes available.

We will furnish the BarTarget source, an explanation, and the executable.

QUESTION: Will representative dual-camera image/video data, current BarTarget processing logic, FogTester TCP interface specifications, calibration data, and pass/fail criteria be made available during Phase 2 or after award?

QUESTION: Scope of test execution. Section 1 describes the objective as an improved BarTarget post-test analysis application, while Section 3 states users will "input test condition parameters...

perform the test, analyze the data." Should the proposed application drive test execution through the FogTester TCP interface, or is its scope limited to consuming FogTester outputs (video stills and test data) for post-test analysis, with the TCP interface used for data exchange only?

ANSWER: It will do both.

QUESTION: In what format does the existing FogTester LabVIEW program save the dual-camera video stills (e.g., raw binary, BMP, PNG, JPEG, or a video container format such as AVI/MP4)?

ANSWER: PNG, 16bit greyscale.

QUESTION: What are the typical pixel resolutions (e.g.s 1080p, 4K) and bit depths (e.g., 8-bit, 16-bit grayscale or color) of the captured camera frames?

ANSWER: Current images are 2590 x 1942, 16-bit (greyscale). Future images may be 24bit RGB.

Camera resolutions may change.

QUESTION: Will the Government provide an Interface Control Document (ICD) or an API specification detailing the exact packet structure, commands, and telemetry payloads exchanged between the FogTester control software and our analysis sub-program over the TCP port?

QUESTION: Which application is expected to act as the TCP Server (listening socket) and which acts as the TCP Client (initiating socket)?

ANSWER: The server is the LabVIEW program. The LabVIEW program may also launch the new program and pass the TCP port number as a command line argument.

QUESTION: Is there a preferred file format for saving and loading this calibration file (e.g., JSON, XML, CSV, or custom binary)?

ANSWER: CSV, Tab Delimited Giardini, INI

QUESTION: How are the “regions of interest” historically selected by the user in the legacy BarTarget app? Is the user expected to manually draw/drag bounding boxes on a GUI, or are the ROIs defined statically based on pre-configured coordinates?

ANSWER: They are defined in a tab separated text file which defines rectangles. The user draws a bounding box around the image, which then displays the ROIs. The new software should automatically detect the target, center, and scale with manual fallback / override.

QUESTION: To facilitate o -site development, will the Government provide selected sample datasets (including calibration images and video still sequences) upon contract award?

QUESTION: Will the Government provide a simulation tool or a mock executable of the FogTester control program to allow the contractor to test TCP socket communication loops o -site?

QUESTION: Will the Government-furnished computer include a compatible graphics processing unit (GPU), or should o erors include any required GPU capability in their proposed solution?

ANSWER: I would avoid GPU acceleration for this application in a proposed solution. Frame rates are in the single digits, CPU should be plenty fast, all GPUs will add is more dependencies.

QUESTION: If GPU acceleration is permitted or expected, are there minimum hardware specifications, approved vendors, power or thermal constraints, driver restrictions, or software compatibility requirements?

ANSWER: I would avoid GPU acceleration for this application in a proposed solution. Frame rates are in the single digits, CPU should be plenty fast, all GPUs will add is more dependencies.

QUESTION: Does “compatible” mean our software should write standard file formats (like native.

Docx and .xlsx or .csv files) containing the generated graphs and raw data tables? Or does the Government expect active COM/OLE automation that interacts directly with locally running instances of Word/Excel?

ANSWER: The software should write standard files (.xlsx, .csv, .pdf, .docx, etc…). The software should run without o ice being installed.