gk7201v200: ship an sc2336 IQ profile, and fix sc2335's day dehaze typo - #2499
Conversation
A GK7201V200 + SC2336 camera ran the SC2232 profile the gk7205v500 family links as default.ini, and gave a soft, blocky picture. With the SC2336 profile from the camera's own firmware in its place the reporter called it "MUCH better", in the same room at the same exposure (#2234). majestic loads /etc/sensors/iq/<sensor>.ini ahead of default.ini, so shipping it as sc2336.ini is enough. The file is that profile converted to this tree's form -- CRLF to LF, [cl_*] day sections to the plain names -- with two data fixes, both in sections majestic refused in the reporter's log: - [dynamic_dehaze] listed 9 IsoThresh ending "6400,128" against 8 AutoDehazeStr. The 128 rung is a typo (12800 in the other profiles); dropped, with ExpThreshCnt 9 -> 8, it leaves the 8 strengths as given. - [dynamic_gamma] and [ir_dynamic_gamma] had gammaExpThreshLtoH on the ISO scale in an exposure-keyed section; set to the HtoL values, as #2477 did for the other ev200 profiles. sc2335.ini's day [dynamic_dehaze] has the same typo with 9 strengths, so majestic rejected it as not ascending; 128 -> 12800, as its own night section has. No package here installs sc2335.ini, so this reaches no image built from this tree.
|
Local For reference, the 09-27 nightly's rootfs was 4924 KB. The offline checks listed in CLAUDE.md all pass. |
PR Summary by QodoAdd an SC2336 IQ profile and fix SC2335 dehaze thresholds
AI Description
Diagram
High-Level Assessment
Files changed (3)
|
Code Review by Qodo
1. New sensor profile never reaches cameras
|
Problem
On a GK7201V200 + SC2336 camera the picture is soft and blocky. The gk7205v500 family links the SC2232 profile as
default.ini, and with nosc2336.inion the image, majestic loads that. Reported in #2234 (comment).This PR ships an SC2336 profile as
/etc/sensors/iq/sc2336.ini. Majestic loads/etc/sensors/iq/<sensor>.iniahead ofdefault.ini, so an SC2336 camera picks it up with no setting.The file is the SC2336 profile from that camera's own firmware, converted to this tree's form: CRLF to LF, and
[cl_*]day sections renamed to the plain names. It carries two data fixes, both in sections majestic refused in the reporter's log:[dynamic_dehaze]: 9IsoThreshvalues ending6400,128, against 8AutoDehazeStrvalues. The128rung is a typo; the other profiles have 12800 there. It is dropped, andExpThreshCntgoes from 9 to 8, which leaves the 8 strengths as given.[dynamic_gamma]and[ir_dynamic_gamma]:gammaExpThreshLtoHwas on the ISO scale in an exposure-keyed section. It is set to theHtoLvalues, as hisi ev200 iq: gammaExpThreshLtoH is exposure, not ISO #2477 did for the other ev200 profiles.It also fixes
sc2335.ini's day[dynamic_dehaze], which has the same…,6400,128typo with 9 strengths. Majestic rejects that as not ascending. It becomes12800, as the file's own night section has. No package in this tree installssc2335.ini, so this part changes no image built from here.Hardware tested on
The reporter's XiongMai GK7201V200 + SC2336 (chip id
0x72010200), on the 09-27 image with this branch's exactsc2336.inifetched into/etc/sensors/iq/and the overlay'sdefault.inicopy removed: #2234 (comment). They report the picture is the same as with their vendor profile, the one in the before/after snapshots at #2234 (comment). I did not run it myself.Evidence
The reporter's log with the vendor profile loaded, before the two fixes:
After, from the reporter's console with this file, as posted in the comment linked above:
The two refusals above are gone. The diff against the vendor file, after the
[cl_rename, is exactly those three lines.Local
gk7201v200_litebuild: rootfs 4940/5120 KB, uImage 1834/2048 KB (details in the comment below).Scope
general/package/all-patches/linux/(those go to OpenIPC/linux)general/overlay/or in a sharedload_<vendor>script hardcodes a value specific to my boardLD_PRELOAD, and no binaries that cannot be rebuilt from source