Linear RGB vs sRGB: fix dark images and point cloud colors

A camera preview can look correct while an acquired image or colored point cloud appears dark, even when exposure settings match. The difference may sit in the display pipeline rather than acquisition. This troubleshooting procedure helps you separate transfer-function errors from exposure, channel-order and rendering problems. You will trace each output independently, apply any required conversion once, and verify the saved data rather than relying on appearance alone.

1. Identify the likely failure before changing exposure

Start with the simplest distinction: are the pixel values different, or are identical values being displayed differently? A preview may apply display processing that an image publisher or point-cloud exporter does not apply.

Linear RGB values represent light intensity proportionally within their defined RGB space. sRGB-encoded values use a nonlinear transfer function suited to image storage and display pipelines. Passing linear values directly to a viewer expecting sRGB-encoded values commonly makes midtones look too dark.

Use this table to choose your first test. Appearance suggests a cause, but does not prove it.

Keep transfer-function diagnosis separate from deciding how to quantify a remaining color mismatch. The guide to comparing color between images covers that later measurement task.

2. Freeze acquisition and compare the same frame

Different captures introduce unnecessary uncertainty. Changing illumination, automatic gain or exposure can imitate a processing discrepancy.

1. Save a reference capture in the acquisition software's documented native format, if available.
2. Record exposure, gain, white balance, pixel format and enabled color processing.
3. Disable automatic adjustments temporarily where the application permits it, or record their actual values for each capture.
4. Generate the preview, image export and colored point cloud from that same capture where supported.
5. Select matching, unsaturated patches and record their channel values before viewing.

Use several neutral patches, not just a white object. An encoding error can leave black and white endpoints unchanged while moving intermediate tones substantially.

If two acquisitions are unavoidable, use a stationary target under stable illumination. Confirm that settings read back correctly rather than assuming a saved configuration has been applied. Changing settings while acquisition runs introduces another variable; the procedure for applying camera settings while streaming addresses that separate issue.

3. Establish what linear RGB actually means

The phrase linear RGB does not completely identify a color space. You also need its primaries and white point. Linear camera-native RGB is not automatically linear sRGB.

The transfer function below converts linear-light sRGB components to sRGB-encoded components. It does not perform white balance, camera color correction, gamut conversion or tone mapping. If the input uses different primaries, a documented color-space conversion is also required.

For a normalized component in the range 0 to 1:

Here, L is the linear-light component and S is the encoded component. Apply the appropriate operation independently to red, green and blue. Alpha is not a color component and should not receive this transfer function.

A simple power function with an exponent near 1/2.2 is an approximation, not the exact sRGB encoding function. Use the piecewise definition when diagnosing numerical agreement, especially near black.

For high-dynamic-range or negative working values, establish a separate display-mapping policy. Do not silently clip the measurement data merely to make a preview displayable.

4. Use a numerical example to recognize missing encoding

Take a neutral component whose linear-light value is 0.18. Its sRGB-encoded value is approximately 0.461. For an unsigned 8-bit display image, round the normalized encoded value after multiplying by 255.

If a viewer expects sRGB-encoded bytes, sending 46 instead of 118 produces a much darker displayed patch. The acquisition exposure need not have changed.

Conversely, treating an already encoded value of approximately 0.461 as linear and encoding it again produces approximately 0.709, or a byte value near 181. That is the characteristic midtone lift of double encoding.

These are numerical test values, not predictions for a physical gray target. A real target's measured values also depend on illumination, exposure, white balance and color processing.

For a local diagnostic, create a constant neutral image with channels set to 118. Send those exact bytes through each display route. If the displayed appearance differs, investigate viewer processing before altering the source data.

5. Trace image, point-cloud and native exports separately

A setting controlling one published image does not necessarily control every export. Treat each branch as its own contract until documentation or a numerical test establishes otherwise.

An image label such as rgb8 describes channel organization and component storage. It does not, by itself, establish the transfer function. Likewise, an RGBA layout does not prove sRGB encoding.

Point-cloud formats also need care. A PLY file may contain red, green and blue properties without a reliable encoding declaration for the consuming application. Record the intended interpretation alongside the file when interoperability matters.

Some point-cloud messages pack color bytes inside a field represented as a floating-point storage type. Follow the field schema and bit layout. Numerically casting that floating-point value to an integer is not equivalent to reinterpreting its packed bytes.

For multi-stream datasets, combining point clouds with RGB and infrared intensity explains why each channel needs an explicit meaning. A color transfer function should not be applied automatically to depth or infrared intensity.

6. Put one conversion at an explicit boundary

Once the source and destination contracts are known, choose where conversion belongs. The objective is not to make every buffer sRGB. It is to give each consumer the representation it expects.

1. Identify the source representation. Use the installed software's documentation and verify it with a numerical sample. Do not infer it from a filename or data type.
2. Identify the consumer's expectation. Determine whether it accepts encoded colors, linear colors, or an explicitly configurable input space.
3. Select a documented output option when available. Confirm whether it controls images, point-cloud messages, saved files, or only a subset.
4. Otherwise, convert in a dedicated processing stage. Keep the original buffer and create a separately labeled display/export buffer.
5. Prevent another conversion downstream. Check image writers, texture upload settings, renderer materials and display output processing.
6. Reopen the exported file. Verify its stored values independently of the preview used during acquisition.

Keep arithmetic in floating point while performing the transfer function. Normalize integer components before applying it, then quantize only when the destination requires integer storage.

For ordinary image averaging or blending intended to represent combined light, decode sRGB inputs first. For a trained vision model, follow the preprocessing contract used during training instead of changing the input representation without validation.

Do not replace an entire export interface merely because its color structure has a different name. Accessors, publishers, serializers and file writers must agree on both storage type and encoding. Prefer a supported configuration or documented conversion over an isolated source-code substitution.

7. Verify the fix with ramps and stored values

Build a small regression test that avoids camera variability. Include black, white, neutral midtones and independent red, green and blue patches.

Useful linear-light component values are 0, 0.0031308, 0.18, 0.5 and 1. These exercise the endpoints, transfer-function join and midtones. The encoded value for a linear component of 0.5 is approximately 0.735, corresponding to an 8-bit code near 188.

Run the test through both the image and point-cloud routes. For each route:

• Record the values before conversion, after conversion and after reopening the export.
• Check that neutral patches retain equal red, green and blue components.
• Confirm that channels are neither exchanged nor multiplied by an unintended alpha value.
• Compare values before lossy compression, resizing or rendering introduces additional changes.
• Verify that conversion changes color data without moving points or changing depth units.

Test encode/decode round trips in floating point before introducing integer quantization. Quantization can prevent exact recovery, especially in dark regions, so do not require every original linear byte to survive an 8-bit encoded intermediate unchanged.

A shaded point-cloud renderer is not a neutral image comparator. Lighting, normals, ambient terms and tone mapping can alter appearance. Use an unlit color mode for the diagnostic where available, then test the intended rendering mode separately.

8. Check the cases where encoding is not the answer

If a transfer-function correction does not explain the mismatch numerically, stop applying additional gamma adjustments. Test these alternatives in order.

Different acquisition or preview processing. Compare actual exposure, gain, white balance and tone-mapping settings. A preview can include processing that is absent from exported data.

Incorrect range or component interpretation. Verify whether the buffer uses normalized floats, unsigned integers or another documented range. Treating 16-bit values as 8-bit values is not an sRGB problem.

Channel or color-space mismatch. Swapped channels change hue. Different primaries or white points can also prevent agreement after the transfer functions match.

Color management differences. Two image viewers may interpret embedded profiles differently. Compare the same exported file under controlled viewer settings before blaming acquisition.

Misregistration. If colors appear attached to the wrong surfaces rather than uniformly dark, inspect depth-to-color registration and rectification. Encoding cannot repair spatial alignment.

Renderer-specific processing. If stored colors match but the cloud still looks different, isolate material settings, lighting, transparency and tone mapping. The remaining fault may be entirely downstream of the exported data.

9. Check the pipeline before changing hardware

A display mismatch alone is not evidence that the camera needs replacement. First document the output contracts and demonstrate where the values diverge.

For a new acquisition system, area scan cameras and 3D sensors address different capture tasks. Neither category establishes the encoding of every software output. Use the camera finder to shortlist hardware, then request confirmation of the relevant software interfaces.

The MV-CU020-90GC is a color area scan camera. Its listing is an acquisition reference, not evidence of a particular export transfer function.

The MV-DPS200P-02 is a projected structured-light camera. For a colored point-cloud workflow, verify the color representation at the exact interface you intend to consume.

Before commissioning or ordering, complete this short checklist:

• Record source primaries, white point, transfer function, component range and channel order.
• Identify every preview, publisher and exporter that processes color independently.
• Assign a single owner for each required conversion.
• Preserve measurement data separately from display-ready copies.
• Save a numerical ramp and a representative capture as regression fixtures.
• Record software versions and repeat the checks after updates.

For a new system, start with the camera configurator. For an existing mismatch, send a same-frame comparison, representative channel values and the export-path description through application support. Those details distinguish a missing conversion from a viewer or acquisition problem much faster than screenshots alone.