# Strange encounter in the red channel/RPi HQ Camera

**URL:** <https://forums.kinograph.cc/t/strange-encounter-in-the-red-channel-rpi-hq-camera/2748>\
**Category:** Research\
**Created:** [April 4, 2024, 11:51am UTC](https://forums.kinograph.cc/t/strange-encounter-in-the-red-channel-rpi-hq-camera/2748 "2024-04-04T11:51:42Z")\
**Posts on this page:** 1\
**Showing post:** 28

<div class="post-metadata">

**Author:** ![PM490](https://forums.kinograph.cc/user_avatar/forums.kinograph.cc/pm490/32/3176_2.png) [@PM490](https://forums.kinograph.cc/u/PM490)\
**Post date:** [October 31, 2024, 4:48pm UTC](https://forums.kinograph.cc/t/strange-encounter-in-the-red-channel-rpi-hq-camera/2748/28 "2024-10-31T16:48:20Z")

</div>

Thanks @cpixip @npiegdon

> [@npiegdon](#):
>
> Your experiment is approaching what I do with my monochrome sensor + colored light setup.

There is a key difference.  
In a RGB led (narrow band leds) with monochrome sensor, the spectrum collected by each channel is set by the led.  
In the RGB sensor and white LED, using different light settings for each RGB sensor channel, the spectrum collected by each channel is set by the sensor-channel filter (bayer filter).  
Without opening the can of worms of the [Backlight](https://forums.kinograph.cc/t/the-backlight/966), there are some advantages/disadvantages to each.

> [@cpixip](#):
>
> The short answer: the camera sensor is able to see colors which are non-valid colors in any given color space. These out-of-gamut colors cause the issues discussed here.

The best of both worlds would be to have the library limit the range of the values to keep all generated colors within a standard gamut. he Picamera2 Library manual references “colour\_space”. It indicates:

> create\_preview\_configuration() and create\_still\_configuration() both  
> default to Sycc(). create\_video\_configuration() chooses Sycc() if the  
> main stream is using an RGB format. For YUV formats it will default to  
> Smpte170m() if the resolution is smaller than 1280x720, otherwise  
> Rec709().  
> For any raw stream, the colour space will always implicitly be the  
> image sensor’s native colour space.

Unarguably the dng file and the capture\_raw may include non-valid colors.  
However, I tried setting the main color space to Rec709, which according to libcamera:

```auto
const ColorSpace ColorSpace::Rec709 = {
	Primaries::Rec709,
	TransferFunction::Rec709,
	YcbcrEncoding::Rec709,
	Range::Limited
};

```

My expectation would be that having a limited range would avoid passing non-valid colors in the main stream. To test

```auto
# ColorSpace is not in picamera2, import from libcamera
from libcamera import ColorSpace

capture_config = pihqcam.create_preview_configuration(
    colour_space = ColorSpace.Rec709(),
    queue=False,
    main={"size": global_shape_main, "format": "RGB888"},
    buffer_count=1,
    raw={"format": "SRGGB12"},
    transform=Transform(hflip=True),
    )
pihqcam.configure(self.capture_config)

```

Libcamera allows for creating a combination of primaries, transfer fuction, YcBcR Enconding, and range, but my limited python knowhow could not come up with the syntax to do with libcamera2.

In summary, the DNG and raw captures would always have non-compliant colors. If/when color space is set, in theory, the main stream (and derived files like PNG or JPEG) should comply with the color space. Further test needed to see if the red anomalies can be addressed with a colour\_space configuration.

> [@cpixip](#):
>
> @PM490 - what you are doing with your .`tif`-based approach is probaby equivalent to selecting here “No profile” when using `dngs`.

Exactly. Additionally, every image pixel has -at the cost of resolution- has true component values.

> [@cpixip](#):
>
> Of course, there’s no color science involved here at all - only our own visual system (and personal taste)…

With the startup color components predefined by the IR-and bayer filter.

> [@cpixip](#):
>
> With the kind of faded scenes @PM490 displayed above, there is not even a slight chance of getting colors correctly - you can only improve the overall appearance in such a way that the results looks ok. One way is certainly the way Pablo (@PM490 ) described above with `tif`-files. In DaVinci, one might get close to the same result by setting up the raw input like so:
> 
> ![grafik](https://forums.kinograph.cc/uploads/default/original/2X/b/b3934e6df4737e5b2bf5c1c459895e116db54178.png)
> 
> which is only possible in unmanaged color science

Thanks for the tip on how to do something similar with the combination of DNG files and Resolve.

> [@cpixip](#):
>
> Try to set your exposure as best as you can. For example, the `dng` of yours I used above features a maximum intensity value of 3859 in the green1-channel. It could easily be ramped up to 4095 - otherwise, you are missing in your capture a tiny piece of dynamic range. As this maximum value occurs in the sprocket hole - and nobody is interested in this part of your capture - you could ramp up your exposure even more. The goal would be to place burned-out parts of the original image just below the 4095 limit. This will give you a few more bits where you need them, in the dark shadow areas, but will of course also burn-out the sprocket area. Which again, nobody should be interested in.

Agree. For me the next step is to do a waveform monitor of the raw capture.

---

_[View the full topic](https://forums.kinograph.cc/t/strange-encounter-in-the-red-channel-rpi-hq-camera/2748)._