[Exynos 9611] Pink tint on Galaxy M21

[betelqeyza]

Info:
Android 16 (crDroid 12.7).
Stock vendor.
Executed python patch_libexynoscamera3.py libexynoscamera3.so --hardware-level FULL --skip-depth --model GalaxyM21 --android-version 16 --version 1 --enable-cap RAW.
Used both BSG 8.1 and 9.6.

Result:
Looking pinkish like the other 9611 models, toggling HDR doesn't fix. Please let me know if you need any further information.

[TBM13]

Thanks for the information. The curse of 9610/9611 persists.

I have something I'd like to try to fix it. If you're interested send me your lib so I can patch it

[betelqeyza]

Thanks for the information. The curse of 9610/9611 persists.

I have something I'd like to try to fix it. If you're interested send me your lib so I can patch it

Of course I'd like to be interested, here's the lib.

[TBM13]

It'd be super helpful if you could take:

• A log of you taking a picture on Gcam with the lib that you patched yourself.
• A DNG (raw) picture where the pink tint is visible, also using the lib you patched yourself.

Then do those two things again but with this lib:

Module_GalaxyM21_NoReverseRaw.zip

[betelqeyza]

I’m not sure if I took the correct log file but I was able to retrieve the raw image and Gcam logs.

[TBM13]

It seems like the logs are only from Gcam, but what I'm interested in is the logs from the camera lib itself. It'd be great if you can take them without using any filters

[betelqeyza]

Oh I'm sorry my mistake, I have added with the logcat data now.

[TBM13]

Still investigating this. I've confirmed that the Exynos 9610/9611 series outputs pre-processed DNGs, which is the problem.

A manual fix to make the DNGs usables is to use a tool like ExifTool to change the BlackLevel to 3096 3096 3096 3096 and AsShotNeutral to 1 1 1. I believe this could be done on the lib itself and maybe that'd fix it, but that's just a workaround. I'll see if I can find exactly why this is happening in the first place.

If you are impatient, in the meantime you could test different GCams with these settings:

• Black level higher than 128. BSG 8.1's max black level is 100 so that one probably won't work right now. Maybe i'll send another lib later with the black level set so you don't need to change it on Gcam, but not right now.
• Somehow disable AWB corrections, I believe this can be done on BSG 8.1 by going into the settings of a camera module -> AWB Correction -> Enable Manual entry of values and set each value to 1 or 1.0. I'm not sure if this is the correct setting though.

For reference this is how one of the images you sent me looks:

And this is how it looks after setting AsShotNeutral to 1 1 1 (which hopefully should be equivalent to disabling the AWB corrections on gcam). It looks washed (because the black level is too low), but the colors are way better.

And this is how it looks after also changing the BlackLevel to 3096 3096 3096 3096 (which should be equivalent to ~193 on GCam values). That's probably not the right value but it should be something similar to that, maybe a little lower.

[TBM13]

Give this lib a try and let me know if the pink tint is still present (try all the different black level values, default, 0, 64, etc.)
Module_M21_NoPureBayerReprocessing.zip

If the pink tint is still there I'll ask you again for a DNG picture (taken with the black level set to default) and a log of you taking a picture, just like before.

[Thunderoar]

this issue is my prime motivation to fix the pink tint xd, ive made a kernelsu module that patches the gcam. SGCAM_DEX_Patcher.zip . wrecked my head on patching the .so so i just patched gcam instead to hardcode its dng/raw to take 1 1 1 xd. the AsShotNatural 1 1 1 is a beautiful fix, and the 193 black level works!

heres the comparison

non-patched, awb off, hdr+ on

non-patch, awb on (google pixel2 awb) hdr+ on

patched, awb off, hdr+on

ofc there are like yk intense noise on dark part but thats entirely tunable now atleast. and yeah the lagged preview still remained in my version, ill postpone that for the time being.

thanks for the guidance tbm13! also thanks to you betelqeyza for pointing out this issue, else id just give up xd. but since this is gcam patching, this issue remains ig

[TBM13]

@Thunderoar Do you mind sending your stock lib? I'd love to send you a patched lib with the same fix I sent to @betelqeyza (and unfortunately never got a reply). It should hopefully fix the issue at its root

[Thunderoar]

@TBM13 wah thank you for the quick reply! heres the stock lib libexynoscamera3_64,32.zip. as a note ive tried installing the Module_M21_NoPureBayerReprocessing.zip previously but met with black preview on gcam, probably device compatibility stuff, ah also i didnt state beforehand, my device is samsung a51, probably shouldve made a new.. issues? but since it is still exynos9611 its kinda related ig

[TBM13]

@Thunderoar Sorry for the delay. Try them and let me know how it goes. The libs have RAW enabled + the potential fix.

libexynoscamera3_64.32_noPureBayerReprocessing.zip

As a note ive tried installing the Module_M21_NoPureBayerReprocessing.zip previously but met with black preview on gcam, probably device compatibility stuff

That's right. Camera libs are device-specific.

[TBM13]

(You might still have to play with the black level, like setting it to 64 on GCam)

If these libs don't fix the issue I'd appreciate if you sent a DNG taken while using these libs. A clean log from you opening GCam would also be helpful (clear previous logs, start taking just before opening GCam and stop taking them as soon as the camera preview appears)

[Thunderoar]

okay so ive tried your libs and gcam crashed, for reference i use - MGC_8.9.097_A11_V25.
since its much more reliable at logging, my device only use the lib64 as extra context

ive put relevant logs inside here
tbm13-camdebug-no_pure_bayer_reprocessing.zip

ive also put the baseline of this repo lib logs that works but pink tint here, it has dng in it too!
tbm13-camdebug-ground_truth_patched_repo.zip

i actually took a crack at the lib patching itself to fix the pink tint, no dice.
attempted to disable pure bayer reprocessing too previously but same crash.
but enabling raw reverse processing which is v7 patches do work! gcam launched, but still pink tint,
theres dng of v7 in their folder at thunderoar-lib-patched-logs.zip if its relevant

heres the attempts, all of these python patches are here if you wanted to take a look!
python_libexynoscamera3_patches.zip

all the file logs for all these below are here!
thunderoar-lib-patched-logs.zip

v4-disable-pure-bayer-returnval - crashed after launch
→ Patches getUsePureBayerReprocessing return value to 0.
HAL told Pure is OFF but internally still runs Pure.
Split-brain → fatal error (4). BROKEN.

v5-disable-pure-bayer-fieldstore - crashed after launch
→ Patches the cached field computation instead of the return value.
HAL consistently forces Pure OFF. DIRTY mode engaged.
Still crashes because DIRTY mode can't handle RAW streams. BROKEN.

v6-disable-pure-bayer-flite-tag-fix - crashed after launch
→ v5 + fixes FLITE_BUF manager tag from 7→1 in DIRTY mode.
Producer/consumer tag mismatch fixed, but DIRTY mode still
fundamentally rejects RAW streams. BROKEN.

v7-enable-rawreverse-reprocessing - camera launched fine, preview okay still lagged ofc, but produces pink picture, the dng/jpeg are provided in their folder
→ Patches isUseRawReverseReprocessing to always return 1.
Pure mode stays ON. Non-Samsung apps (GCA) now enter the
same RAW delivery path as Samsung Camera. Produces valid
27MB DNG files. Camera error traces = 0. WORKS.

v8-enable-rawreverse-plus-3aadng - camera launched fine, black preview, stuck
v8-enable-rawreverse-plus-3aadng.py
→ v7 + forces isUse3aaDNG to return 1.
Enabling 3AA DNG path breaks stream configuration.
HAL rejects with ENOSYS (-38) at configureStreams. BROKEN.

v9-enable-rawreverse-pipe-203to204 - camera launched fine, black preview, tap capture does something but stuck
→ v7 + changes pipe 203→204 in captureStreamThreadFunc.
Pipe routing change causes cancelRequest to fail with
"Function not implemented". BROKEN.

v10-enable-rawreverse-selectbayer-wrong-reg - crashed after launch
→ v7 + replaces getPipeId() with mov w2,#204 in m_selectBayer.
WRONG REGISTER: wrote to w2 instead of w0.
Return value is garbage → HAL crashes. BROKEN.

v10b-enable-rawreverse-selectbayer-fixed - crashed after launch
→ Same as v10 but with correct encoding: mov w0,#204.
Still crashes — m_selectBayer validates frame's entity
structure against returned pipe ID; mismatch → fatal error. BROKEN.

bottomline, i really dont know what really haunts these exynos9611 libs,
defo will not touch/try to patch the libs further for now xd.
do tell me what i missed to include!

patching gcam works okay because its literally patching the faulty dng for the gcam to process
patching lib defo affects lots of the processing pipeline thats causing these crashes

also thank you for your attention to this issues btw @TBM13 !