Daylight magenta colour cast on hi3518ev200 + OV2735 (RAW10): recent master vs majestic 2026-04-20

[moontwister]

Required information

• SoC: hi3518ev200 (hi3516cv200 / cv200 family)
• Sensor: OV2735 (MIPI, RAW10), board = TP-Link Kasa KC110
• Bad: full no-shim firmware built with majestic fix-hisi-vb-pool1-raw10-undersized+e9ff50d (and earlier master builds)
• Good: full firmware with majestic master+d11ba3c, 2026-04-20

Distinct from #279 (JPEG pool, fixed — thanks) and #280 (IQ profile, which I walked back). Handing this to you because I couldn't isolate it cleanly and you can git-bisect with source.

Issue description

On the no-shim/master build the daylight image has a magenta cast — owner-confirmed by eye, not just stats. The full d11ba3c (2026-04-20) build is clean in the same conditions.

Tight A/B, same scene, ~minutes apart, analog gain 1× on both (so it isn't gain noise):

build	/image.jpg RGB mean	AWB R/G/B gain	CoTemp	exposure (Line)
d11ba3c (good)	[108, 110, 122] balanced	0x201 / 0x111 / 0x1fc	3773	8
e9ff50d (bad)	[137, 95, 144] — G ~40 below R/B	0x23f / 0x111 / 0x1ee	3389	2

The JPEG also balloons ~61 KB → ~700 KB purely from the cast/texture. Bayer (BGGR) and the colour matrix (CCM) are byte-identical between the two; the differences are the AWB R-gain, the convergence point, and a ~4× shorter exposure (Line 2 vs 8) on master for the same scene.

What I ruled out (controlled tests)

• master loads text IQ profile (.ini) as binary PQ blob → checksum error on default iqProfile (cv200/OV2735) #280 IQ profile — isolation-tested: removing the IQ profile entirely from d11ba3c leaves its image clean, so the failed PQ load isn't the cause.
• Gain noise — analog gain is 1× on both.
• MIPI/VI dev-attr setup — running e9ff50d with our libfixmipi LD_PRELOAD shim (which forces vendor-correct combo_dev_attr + VIU comp-mask 0xfff00000) does not fix the colour.
• .ini data_type — setting data_type=3 on the candidate didn't fix it either.

What I could NOT isolate

I tried a majestic-binary bisect (your versioned lite URLs, swapped in from /tmp) but it's confounded — the known-good d11ba3c binary also looked bad when run via binary-swap on the candidate rootfs, so the method isn't clean (rootfs / partially-matched .ini / start-method). So all I can say solidly is full e9ff50d build = magenta, full d11ba3c (04-20) build = good, and the cause is at the full-build level — possibly the majestic binary, possibly the newer opensdk/ISP libs in the candidate rootfs (it was built from current HEAD), or a combination.

Ask

Could you git bisect the master ISP/AWB path on a cv200 + RAW10 sensor between 2026-04-20 and now, or point me at full builds (or a known-good majestic SHA for cv200) to test on the KC110? The KC110 is on the bench; happy to flash specific candidates and report image quality (I'll have the owner judge the live feed — pixel stats across reflashes proved unreliable here).

[widgetii]

Thanks for filing this cleanly separated from #279 / #280, and for the controlled isolations — analog-gain-1×, identical Bayer+CCM, ruled-out IQ-profile, ruled-out MIPI shim and data_type=3 is exactly what I needed.

I audited every commit between d11ba3c and current master for anything that could touch AE, AWB, black level, bayer interpretation, or any other part of the ISP/colour pipeline on your platform + sensor type. Nothing in that window changes the colour path on this configuration. That matches your binary-swap result being confounded: if the majestic differential in this window can't reach AE/AWB/colour, swapping just the binary on a candidate rootfs wouldn't show a clean signal in either direction.

So the differential must be in the other variables that moved between your two full builds — most likely the OV2735 .ini (Isp_FrameRate is the prime suspect for the ~4× exposure delta), the sensor library and its register init, or vendor-side ISP defaults shipped in the candidate rootfs.

For the next step, the OpenIPC IQ tuning workflow is the right tool — it lets you compare AE/AWB state live against the working baseline and edit the IQ binding directly, which is where this almost certainly lives:

https://github.com/OpenIPC/wiki/blob/master/en/image-quality-tuning.md

Closing on the majestic side since the code audit is clean. If the IQ-side investigation turns up something that actually lands on us, please reopen or file a focused issue describing the behaviour and I'll take it from there. The KC110 reproducer is gold — we'll definitely want it back if anything points our way.

[widgetii]

Stepping back on this — I want to walk back the IQ-tuning direction from my close. Re-reading your numbers, the signature is much more consistent with the IR-cut filter being mechanically open in daylight than with an AWB/ISP regression, and that would also explain why nothing in my majestic-side audit moved:

• [137, 95, 144] mean — both R and B elevated, G depressed. Near-IR (700–1000 nm) hits R and B Bayer wells far more than G, which produces exactly the magenta you're describing.
• Line 2 vs Line 8 — 4× shorter AE for the same scene = more total light reaching the sensor, which is what an open IR-cut does. Analog gain 1× rules out gain noise but not IR leak.
• R-gain pushed 0x201 → 0x23f — AWB chasing the IR-driven R surge, not driving it.
• 61 KB → 700 KB JPEG fits IR-lit textures the encoder has to spend bits on.

It also explains the confounded binary-swap: swapping just the majestic binary doesn't replay the rootfs init that sets the IR-cut GPIO state at boot. The differential between the two full builds may simply be init-script / vendor-default state on a board (KC110) that doesn't have nightMode.irCutPin1/2 configured at all.

5-minute test on the KC110, in daylight, on the bad build:

1. `wget -qO- http://localhost/night/on\` and then `wget -qO- http://localhost/night/off\` (or `/night/toggle`). Grab `/image.jpg` after each. If the magenta clears in one of the states (listen for the IR-cut click), pins are configured but swapped — flip `irCutPin1` ↔ `irCutPin2` in `/etc/majestic.yaml` under `nightMode`. Wiki spells this out: https://github.com/OpenIPC/wiki/blob/master/en/auto-night-mode-without-light-sensor.md ("If it is pink, most likely your pins are in the wrong order").
2. If toggle produces no click and no image change, the pins aren't set right and the filter is stuck wherever the GPIOs powered on. KC110 isn't in the GPIO table yet — https://github.com/OpenIPC/wiki/blob/master/en/gpio-settings.md — but the known-good hi3518ev200 pairs across vendors are `1/2`, `33/34`, `52/53`, `61/60`, `63/64`, `64/65`. Worth probing those: set in yaml, `killall -HUP majestic`, toggle, watch `/image.jpg`.
3. If you can pull `/etc/majestic.yaml`'s `nightMode` block and `/sys/class/gpio/*` state from both the good `d11ba3c` build and the bad `e9ff50d` build at idle, any difference there is the smoking gun and confirms it's outside majestic.

If the toggle test fixes the cast, the follow-up is a wiki PR for KC110 GPIOs, not anything on the majestic side. If it doesn't, happy to take a proper second look here.

[moontwister]

Reopening with results — and walking back the IR-cut direction, it doesn't hold on this hardware.

IR-cut tested — it's not that

On the good build (d11ba3c), I drove the IR-cut filter open in day/colour mode (via the board's GPIO control, lightMonitor off so it wasn't auto-corrected) and had the camera owner judge the live feed:

• IR-cut open → the image goes desaturated / near-grayscale ("colours gone"), not magenta.
• IR-cut closed → normal colour.

The bad build's signature is the opposite — a colourful magenta, not a washed-out gray. So IR-cut-open isn't what produces it here. (The owner also confirmed the bad build's magenta is in plain daylight, in colour mode.)

Everything open/inspectable is byte-identical between the two builds

Full d11ba3c build (good) vs full e9ff50d build (bad), same source tree — I md5'd the entire rootfs. The only files that differ are /usr/bin/majestic and /usr/lib/os-release. Specifically verified identical:

• kernel: hi3518e_isp.ko, hi3518e_viu.ko, hi3518e_vpss.ko
• userspace: libisp.so, lib_hiae.so, lib_hiawb.so, libsns_ov2735.so

Also ruled out (controlled, owner-judged): #280 (removing the IQ profile entirely from the good build leaves it clean), gain noise (analog gain 1× on both).

Why I can't isolate it further by config

The majestic version and the .ini are coupled — the cross-combinations don't boot a pipeline:

config	result
d11ba3c + old .ini (1-lane/RAW12) + shim	✅ good
e9ff50d + new .ini (2-lane/RAW10)	❌ magenta
e9ff50d + old .ini (1-lane/RAW12) + shim	💀 no pipeline (RTSP down, empty JPEG)
d11ba3c + new .ini (2-lane/RAW10)	💀 no image

d11ba3c ignores the .ini and relies on the LD_PRELOAD shim to force combo_dev_attr; e9ff50d reads the .ini directly (post-#278) and needs its matching 2-lane values. So only the matched pairs run, and only one of them is magenta.

But here's the pointer: e9ff50d + the shim (forcing the exact same combo_dev_attr + VIU comp-mask the good build uses) is still magenta. With the rootfs byte-identical and the MIPI/VI dev-attr forced identical, that leaves the majestic binary itself — which contradicts your source audit finding no colour-pipeline change. That contradiction is what I can't resolve black-box.

Numbers (clean A/B, same scene, gain 1× both, CCM byte-identical)

	RGB mean	AWB R-gain	CoTemp	exposure (Line)
d11ba3c (good)	[108,110,122]	0x201	3773	8
e9ff50d (bad)	[137,95,144] (G −40)	0x23f	3389	2 (4× shorter)

Ask

This now needs source-level eyes — instrumentation or a git bisect on the cv200 + linear-MIPI colour path, since everything I can inspect is identical and the difference is confined to the closed binary. The KC110 (OV2735, the only RAW10 repro you have) is on the bench — give me any candidate / instrumented build and I'll flash it and report the live image (owner judging, not pixel stats).

[moontwister]

Update after running your IR-cut test plan and testing the #280 fix — and a sharper characterisation (I finally looked at the actual frames instead of pixel stats).

IR-cut tested (your 3-step plan, on the bad build) — it modulates the cast but isn't the cause

• /night/on drives gpio64 0→1, image goes grayscale (colorToGray); /night/off → broken colour again. Owner heard the click, so the filter does move.
• Pulsing the filter through both states (with majestic's irCutPin1 driving removed so it didn't fight) shifts the cast (magenta ↔ yellow) but no position gives good colour.
• Side note that may still be worth a wiki line: the KC110's IR-cut is an edge-triggered solenoid (our board-support pulses one master GPIO to flip a bistable latch), whereas majestic's nightMode drives irCutPin1 as a level. That mismatch is real, but it's not what's degrading the image.

The #280 IQ fix does not fix it

Flashed your IQ-loader candidate c6f4d0c — it loads the text IQ profile correctly (confirmed on #280), but the image is still the same yellow + grainy. And removing the IQ profile entirely from the good (April) build leaves it clean. So the colour/denoise problem is independent of the IQ load — three ways now.

What it actually looks like (same night scene, side by side)

• April d11ba3c: sharp, neutral white balance (white cabinets read white), low noise. Normal.
• master (e9ff50d pool-fix and c6f4d0c IQ-fix): strong yellow/amber cast (blue channel crushed) + heavy grain/noise.

So it's two things: AWB converging wrong (yellow) and denoise not applied (grain). (Can't attach the frames — they're the owner's kitchen — happy to share privately if useful.)

Net

Master-based majestic degrades AWB + 3DNR on cv200 + OV2735 where April doesn't; the rootfs (kernel ISP/VIU/VPSS modules, libisp, lib_hiae, lib_hiawb, libsns_ov2735) is byte-identical between the two builds; IQ profile, IR-cut, gain, and the #280 fix are all ruled out. That still points at the binary and contradicts your audit — so it needs source-level eyes specifically on the AWB convergence + 3DNR/NR setup path between d11ba3c and master, not the colour-matrix/bayer path. KC110 stays on the bench for any instrumented build.

[moontwister]

Closing the loop on this one: root cause found, and majestic was innocent — your code audit was right.

The colour cast came from cv200's ov2735_i2c_1080p.ini: [vi_dev] Mask_0 = 0x3FF0000, which majestic faithfully applies as the VI component mask. The correct value is 0xFFF00000 (cv300's ov2735 ini and the vendor firmware on this hardware both use it). With 0x3FF0000 the VI captures the wrong bit window: /proc/umap/vi shows ComMsk0=3ff0000, AE "converges" ~28x under (Line 86/2431 at the same scene), and highlights wrap into magenta.

Proof: same scene, same e9ff50d binary, changing only that ini field and restarting majestic → ComMsk0=fff00000, correct AE convergence, clean image. The /proc/umap/isp A/B you asked for is what led to it.

I also owe you the explanation for my wrong "byte-identical rootfs, must be the binary" claim: my LD_PRELOAD shim's VI fix was gated on enIntfMode != 5. The old ini had Input_mod=2, so the shim silently forced Mask_0=0xFFF00000 on the good build; the corrected ini (Input_mod=5) never triggered it. The bad mask was in the ini all along, masked by the shim — every test combination is consistent with that.

Fixed in OpenIPC/firmware#2155 (commit 78b9cb7d, fifth field). Running stock majestic master (2026-06-11) on the KC110 now with no shim and no workarounds — image is correct. Thanks for the pointer to the right diagnostic, and sorry for the noise.