How to simulate exposure variants from an image

A stored image can provide useful brighter and darker test cases without changing camera settings. The safest method keeps the original untouched, performs arithmetic in floating point, and checks clipping before saving each variant. This workflow is for testing inspection algorithms, image displays, and preprocessing pipelines. You will create a repeatable brightness sweep, preserve the source pixel representation, and identify which conclusions still require fresh camera captures.

What synthetic brightness variants actually represent

Multiplying pixel values can approximate an exposure change when those values are proportional to collected light. Adding a constant instead produces an intensity offset. Both transformations can test software, but they answer different questions.

Keep the source image as the reference, rather than calling it correctly exposed without checking it. It may already contain saturation, weak contrast, or processing that changes its tonal response.

Use synthetic variants for sensitivity testing, not as evidence that an inspection will tolerate equivalent camera exposure changes. For interpreting acquisition settings, the separate guide to camera exposure and gain units explains why camera controls need their own validation.

Preserve the original and identify its pixel representation

1. Save an untouched reference and record how its pixels are encoded.

Decode the image before modifying it. A compressed file's bytes are not a directly editable pixel array; the guide to image bytes versus pixel data explains that distinction.

Record these properties before creating variants:

• Image width, height, and channel count.
• Integer or floating-point storage type.
• Meaningful signal range and valid bit depth.
• Channel order and color interpretation.
• Whether the values are linear, gamma-encoded, or unknown.
• Any documented black-level offset.

For an unsigned 8-bit grayscale image, the representable range is 0–255. However, a right-aligned 12-bit signal stored in an unsigned 16-bit array may use only 0–4095. Using 65535 as its white level would change the intended signal interpretation.

Do not infer valid bit depth from the array type alone. Check the acquisition settings and file metadata, including whether meaningful bits are right-aligned or left-aligned.

Keep the reference outside the transformation loop. Every variant must start from that reference, not from the previous output. Otherwise, repeated scaling and rounding accumulate changes.

Choose exposure-stop scaling or an offset test

2. Select the transformation and define its parameters before generating files.

For linear image values with zero representing black, an exposure-style adjustment uses a power-of-two multiplier. One positive stop doubles the signal; one negative stop halves it.

Here, e is the requested stop change, X_float is the source converted to floating point, and U is the intended maximum output code. The black-level form assumes that the offset is known and should remain fixed.

Do not estimate a black-level offset simply by taking the darkest pixel in an ordinary scene. That pixel may represent a dark object rather than the camera's black reference.

A practical first sweep is −1, −0.5, 0, +0.5, and +1 stops. The corresponding multipliers are approximately 0.5, 0.707, 1, 1.414, and 2. These are test parameters, not promises about how a particular camera will respond.

For gamma-encoded color images, multiplying the stored values is not equivalent to multiplying light intensity. If the transfer function is known, decode to linear light, apply the multiplier, and encode again. Otherwise, use direct code-value scaling only as a deliberately limited software test.

An additive test uses a different equation:

Adding 20 to source values of 20 and 100 produces 40 and 120. Their ratio changes from 5:1 to 3:1. Multiplying both by 2 produces 40 and 200, preserving that ratio before clipping. This is why an offset should not be described as an exposure adjustment.

Perform arithmetic before converting back to integers

3. Convert to floating point, calculate the variant, and measure out-of-range values before saving.

Integer arithmetic can saturate, wrap, truncate, or reject an operation, depending on the software environment. Explicit conversion prevents those behaviors from silently defining your experiment.

The following language-independent pseudocode shows the required order:

reference = decode(source_file)
original_type = pixel_type(reference)
source_float = convert_to_float(reference)

for each stop_change in requested_stop_changes:
    scale = power(2, stop_change)
    candidate = black_level + scale * (source_float - black_level)

    below_range = count(candidate < 0)
    above_range = count(candidate > output_maximum)
    sample_count = count_all_samples(candidate)

    bounded = clip(candidate, 0, output_maximum)
    rounded = round(bounded)
    encoded = convert_to_type(rounded, original_type)

    save_losslessly(encoded, variant_filename)
    record(stop_change, scale, below_range, above_range, sample_count)

Set black_level to zero only when that assumption is appropriate. Set output_maximum from the intended signal encoding, not automatically from the container type.

For color images, this example counts individual channel samples. If you need the fraction of affected pixels, count a pixel once whenever any channel falls outside the range. Record which definition you use.

Avoid automatic contrast stretching during export. A writer that rescales every variant to fill its output range can erase the brightness differences you intended to create.

Also avoid lossy compression for quantitative comparisons. Choose a lossless format that supports the required pixel type, then reopen the saved file to verify its values. Keeping the same integer storage type alone does not guarantee that valid-bit metadata or color interpretation survived.

Work through a small clipping example

4. Generate a small, inspectable test before processing a full image collection.

Consider four linear 8-bit source values: 32, 96, 160, and 240. For this example, black is zero and the maximum output code is 255.

The brighter variant contains two values above the allowed maximum:

Those two samples become identical after clipping. Their original difference is no longer available to the inspection algorithm.

Distinguish values outside the allowed range from values exactly at an endpoint. A calculated value of 255 is representable; a calculated value of 320 requires clipping. Counting every saved value equal to 255 would mix these cases.

For a real image, record the above-range and below-range fractions for each variant. Also examine the inspection region separately. A small clipped reflection outside the measurement area may matter less than a clipped character stroke inside it.

Do not divide each output by its own maximum before comparing variants. That normalization would cancel much of the intended brightness sweep.

Verify the saved files and the inspection response

5. Reopen each output and check both pixel integrity and task performance.

First verify that dimensions, channel count, storage type, and intended code range match the experiment. Compare a few known pixel coordinates against your calculated values. The zero-change output should match the decoded reference when no other conversion has been introduced.

Then use fixed display limits when reviewing images side by side. Automatic display normalization can make a darker variant look almost identical to its reference.

Useful checks include:

• A histogram using the same bin definitions for every variant.
• Fractions outside the allowed range before clipping.
• Endpoint occupancy after encoding.
• Mean or median intensity within a fixed inspection region.
• Detection score, measurement error, or accepted-part count.
• Processing time and any failure indication from the inspection pipeline.

A histogram cannot show where an intensity change occurred. When spatial detail matters, combine it with fixed-coordinate pixel comparisons or difference images. The guide to image similarity using histograms or pixel values explains how to choose between those comparisons.

Do not set a universal acceptable clipping percentage. Acceptance depends on the feature being measured. A useful test records both the image statistics and the inspection outcome, then checks where performance begins to fail.

Know when a new camera capture is necessary

6. Confirm the relevant cases with controlled acquisition before accepting the inspection.

Digital brightening cannot reconstruct detail already lost to saturation. Darkening a saturated source merely turns a flat white region into a flat gray region.

Synthetic scaling also does not reproduce the complete noise behavior of a different exposure. It scales the noise already present, while a real capture changes photon statistics and the contribution of acquisition noise. Longer exposure may additionally change motion blur, which static brightness arithmetic cannot create.

Start with repeatable source acquisition and save camera frames for offline testing. When recapturing, hold lighting, aperture, gain, image processing, and scene geometry fixed wherever possible. Change the intended exposure variable and log the actual settings.

If you are choosing acquisition hardware for that validation, compare area scan cameras through the camera finder. Interface compatibility and access to the required image representation matter more here than a product's headline resolution.

The LS-CMR-0053 is a GigE area scan camera. Treat it as an acquisition option to evaluate against your capture requirements, not as a requirement for generating offline variants.

The LS-CMR-0166 is a USB3 area scan camera. Confirm its suitability for your host connection and intended acquisition workflow before selecting it.

There is no reason to replace a working camera solely to multiply stored pixels. Hardware becomes relevant when your validation requires new, controlled captures.

Common mistakes that invalidate the experiment

Calling every bright image overexposed. A brighter synthetic image is not necessarily saturated, and saturation in a saved file does not establish where clipping happened in the acquisition chain.

Applying arithmetic to encoded file bytes. Decode the file first, then operate on its pixel samples.

Using unsigned arithmetic before conversion. Convert to floating point before subtraction or multiplication, particularly when testing darker variants or black-level correction.

Changing the output range between files. Keep the intended encoding fixed throughout the sweep. A wider intermediate range is useful for calculation, but changing the saved range changes the experiment.

Confusing exposure with display brightness. A display can brighten an image without changing its stored measurements. Conversely, an automatic viewer can conceal genuine changes in stored values.

Treating correlated variants as independent evidence. Several versions of one scene still share its objects, defects, geometry, and original noise. Keep related variants together when separating training and evaluation data.

Pre-run checklist and next step

Before generating the full set, check that:

• The original is archived and never overwritten.
• Valid bit depth, alignment, and color encoding are documented.
• Every variant starts from the same decoded reference.
• Floating-point arithmetic occurs before clipping and integer conversion.
• Stop changes, multipliers, and range limits are recorded.
• Clipping statistics distinguish samples from pixels.
• Saved files pass a reopen-and-compare check.
• Inspection acceptance is based on the task, not appearance alone.
• Important failures will be checked with new camera captures.

Start with a small sweep and inspect the intermediate values before automating a larger batch. If controlled recapture is the next requirement, use the camera configurator or contact applications support with your source format, test range, and inspection failure examples.