D435 RGB color white balance issues when using ROS2 wrapper

[motudor]

Required Info

Field	Value
Camera Model	RealSense D435
Firmware Version	5.17.0.10
Product ID	0B07
Serial Number	138422078366
USB Type	USB 3.2
Operating System & Version	Ubuntu 22.04.5 LTS
Kernel Version	6.8.0-117-generic x86_64
Platform	Industrial PC / x86_64
Librealsense SDK Version	ROS node reports LibRealSense v2.57.7; system also has librealsense2-utils 2.58.1 installed
RealSense ROS Wrapper Version	4.57.7
ROS Distro	ROS2 Humble
Language	C++ / ROS2 / V4L2 / librealsense advanced-mode probe
Segment	Robotics / industrial vision

Issue Description

On our machine, besides using the 3D data for pick point selection, we also build a color picture of the object (by stiching together slices of the color picture) to determine the type of object using an AI network. For that, we need calibrate and set the color white balance parameter on each machine. This works fine in an earlier version of the program that does not use ROS2, but not using the ROS2 RealSense wrapper.

First, the RGB stream does not reliably start with the requested manual color settings if those settings are applied as normal ROS startup parameters. The camera initially comes up overexposed / with unstable color unless we delay applying the final RGB settings until after color frames have started arriving.

Our current workaround is:

1. Start the RealSense ROS2 camera node.
2. Wait until the first /camera/color/image_raw frame is received.
3. Wait an additional warmup delay, currently 5 seconds.
4. Apply the final RGB/depth settings via ROS parameters:
   • rgb_camera.enable_auto_exposure = false
   • rgb_camera.exposure = 7
   • rgb_camera.enable_auto_white_balance = false
   • rgb_camera.white_balance = 4550
   • rgb_camera.saturation = 31
   • rgb_camera.sharpness = 81
   • depth_module.enable_auto_exposure = false
   • depth_module.exposure = 160

This delayed startup apply makes the initial image look correct. Applying the same settings too early during ROS node startup was not sufficient/reliable.

Second, after the stream has been running, the RGB image can suddenly change tint during continuous streaming. When this happens, all exposed camera state still reports the expected values: ROS parameters, V4L2 controls, RealSense color frame metadata, and D400 advanced-mode color correction all remain unchanged and correct.

Restarting the program / reopening the RealSense stream immediately fixes the tint. Reapplying the same RGB camera settings during the bad state does not fix it.

This suggests a hidden RGB ISP / color pipeline state issue in firmware or librealsense that is not exposed through ROS parameters, V4L2 controls, RealSense frame metadata, or D400 advanced-mode color correction.

Stream / Settings

Color stream:

• 848x480 @ 60 FPS
• ROS output format: RGB8
• V4L2 node reports YUYV on /dev/video20

Applied settings:

• rgb_camera.enable_auto_exposure = false
• rgb_camera.exposure = 7
• rgb_camera.enable_auto_white_balance = false
• rgb_camera.white_balance = 4550
• rgb_camera.saturation = 31
• rgb_camera.sharpness = 81
• depth_module.enable_auto_exposure = false
• depth_module.exposure = 160

Observed Behavior

Here is a picture where the tint changes mid picture (Picture is stitched from multiple frames)

After the tint shift, periodically reapplying the same camera settings did not recover the image. Restarting the program / stream recovered it.

Image channel statistics from saved RGB images showed the visual change:

• Bad state: B/G ~= 1.10 - 1.116
• After restart / good state: B/G ~= 1.05, R/G ~= 1.04

The actual items can vary in color, so the strongest evidence is the visible tint shift plus the fact that restarting the stream restores the expected appearance while metadata remains identical.

Bad-State Frame Metadata

While the tint issue was present, /corner_finder/camera/color/metadata reported:

{
  "actual_exposure": 7,
  "gain_level": 0,
  "auto_exposure": 0,
  "brightness": 0,
  "contrast": 50,
  "saturation": 31,
  "sharpness": 81,
  "auto_white_balance_temperature": 0,
  "manual_white_balance": 4550,
  "backlight_compensation": 0,
  "hue": 0,
  "gamma": 300,
  "power_line_frequency": 3,
  "low_light_compensation": 0
}

Good-State Frame Metadata After Restart

After restarting the program / stream, the image looked correct again, but metadata was effectively identical:

{
  "actual_exposure": 7,
  "gain_level": 0,
  "auto_exposure": 0,
  "brightness": 0,
  "contrast": 50,
  "saturation": 31,
  "sharpness": 81,
  "auto_white_balance_temperature": 0,
  "manual_white_balance": 4550,
  "backlight_compensation": 0,
  "hue": 0,
  "gamma": 300,
  "power_line_frequency": 3,
  "low_light_compensation": 0
}

V4L2 State During Bad State

Direct V4L2 controls on the RGB node also looked correct:

white_balance_automatic = 0
white_balance_temperature = 4550
auto_exposure = Manual Mode
exposure_time_absolute = 7
saturation = 31
sharpness = 81
brightness = 0
contrast = 50
gamma = 300
hue = 0
gain = 64

D400 Advanced Mode State

We also queried D400 advanced mode using rs400::advanced_mode:

advanced_mode_enabled 1
color_control 0 0 0 0 0
color_correction 0.298828 0.293945 0.293945 0.114258 -0 -0 -0 -0 -0 -0 -0 -0
These values were the same in bad and good states.

So do you have any suggestions what I could try to get the white balance settings to stick?

[MartyG-RealSense]

Hi @motudor Thanks very much for your highly detailed description of your issue.

Does it make a difference if you launch with the rs_launch.py file with profile and parameter settings and a camera reset applied in the launch command, and don't set exposure to 7?

ros2 launch realsense2_camera rs_launch.py initial_reset:=true depth_module.depth_profile:=848x480x60 rgb_camera.color_profile:=848x480x60 rgb_camera.white_balance:=4550

A very low RGB exposure value such as 7 would not normally be used. The default RGB exposure value is 156. Setting the exposure in a certain range can have the negative side-effect of causing the FPS to lag.

Instead of using 60 for the RGB FPS, please try setting the RGB FPS to the minimum of 6 and the exposure value to 78 (a configuration which can negate RGB sensor lag on D435 when auto-exposure is disabled).

[motudor]

Hi!

Many thanks for your reply. I spent quite a lot of time trying to reproduce the issue here at the office - without much luck - the B/G ratio and R/G ratios I get are the same, no matter which metod I use - ROS or pure realsense.

Trying to launch using rs_launch.py is a bit disruptive to do on the real machine running production but i will see if I can find a slot when I can play with it. In the meantime I can provide any logs or debugging data from the machine if anything there would be helpful.

Running an exposure of 7 is unfortunately necessary - to get a clear picture of the object we are looking at with the lighting and distance setup of that machine, when we are running white objects. even 60 is way too overexposed. But I have not had issues with lagging fps that you mention - i do log late/dropped frames and they are very rare. My only issue is that the white balance settings won't "stick" when running the ros version - just running realsense + c++ works fine.

[MartyG-RealSense]

You may be able to get a clearer RGB picture at a distance without using a very low exposure if you set Sharpness to its maximum value of 100 instead of 81.

Rather than stitching slices of color picture together, if you need a long image viewpoint for a lengthy object such as a towel then an alternative might be to turn the camera 90 degrees on its side (as the viewpoint is wider in the horizontal direction) and then use the ROS2 wrapper's post-processing rotation filter to rotate the tall color image back to the horizontal orientation.

ros2 launch realsense2_camera rs_launch.py rotation_filter.enable:=true

The node launch version of that instruction would be:

ros2 run realsense2_camera realsense2_camera_node --ros-args -p rotation_filter.enable:=true

[motudor]

Hi,

Thanks for the suggestions.

The size of the objects we inspect can vary from 15 cm to 5 meters. Moving the camera far enough away to capture the largest objects means we lose almost all useful resolution for the smaller ones. Additionally, the machine size is constrained, so I cannot physically move the camera that far away.

That said, I think we may be focusing on the wrong problem. I do not have any issues with the exposure settings - the problem is the white balance parameter.

It's also worth mentioning that these settings work correctly when using RealSense directly through C++ on several machines. The issue only appears when we integrate the camera through the ROS wrapper.

I had the opportunity today to test this on one of the machines and found something interesting.

Test 1: Setting white balance through launch parameters

I launched the camera using the command you recommended:

ros2 launch realsense2_camera rs_launch.py \
  serial_no:=_138422078366 \
  initial_reset:=true \
  depth_module.depth_profile:=848x480x60 \
  rgb_camera.color_profile:=848x480x60 \
  rgb_camera.white_balance:=4540

This produced the following warning:

Warning: Parameter 'rgb_camera.white_balance' is not supported.

When I queried the parameter afterward, it reported:

rgb_camera.white_balance = 4600.0

The resulting images showed the same red tint that I reported earlier. (see the picture below)

Test 2: Setting white balance through a configuration file

Next, I launched the camera using a configuration file:

ros2 launch realsense2_camera rs_launch.py \
  camera_namespace:=corner_finder \
  camera_name:=camera \
  serial_no:=_138422078366 \
  initial_reset:=true \
  depth_module.depth_profile:=848x480x60 \
  rgb_camera.color_profile:=848x480x60 \
  config_file:=/tmp/realsense_color.yaml

This also produced a warning. However, when I queried the parameter afterward, it showed:

rgb_camera.white_balance = 4550.0

Despite this, the camera output still appears to use the same white balance as before. The images show the same red tint, and I do not see any visible effect from the configured value.

Question

Is white balance actually implemented and applied by the ROS wrapper?

From my testing, it appears that the parameter value can be queried successfully, but changing it does not affect the camera output.

[MartyG-RealSense]

rgb_camera.white_balance is the correct ROS parameter so I'm not sure why your D435 would say that it is unsupported on the roslaunch command. Though if the parameter is not set by you then the default white-balance value of 4600 will be automatically applied, which should not make much of a noticeable difference from a setting of 4550.

You can confirm whether your particular camera is supporting the white_balance parameter in ROS2 by listing all supported parameters with ros2 param list

Tinting on the image due to the white-balance typically occurs if the white-balance value is too low. Increasing the white-balance above the 4600 default should cause tinting not to occur and the colors of the image to become warmer. How does the image look if you set the value to 6000?

[motudor]

An interesting detail, i don't get the same warning running on my own pc, where i could not replicate the error;

This is the remote machine

The other one is on my own machine, where things are ok:

Using ros2 param list shows white balance as a valid parameter on both machines.

Besides the library versions that you see in the print screen, the main difference is that realsense-ros is built from source on my machine and installed using apt on the remote one.

I will attempt to build realsense-ros from source too on the remote machine to see what happens tomorrow, as well as the white balance value that you asked about and report back.

[MartyG-RealSense]

Thanks very much. I look forward to your next report. Good luck!

[motudor]

Hi,

I tested with building realsense-ros from source and running that.
I still get the same warning that white balance is not supported;

Setting white balance to 6000 also gives a tinted picture - but slightly more yellow i think:

[MartyG-RealSense]

Let's next try setting the parameter during runtime after launch to see if the image updates correctly.

ros2 param set /camera/camera rgb_camera.white_balance 4550