Explain gain behaviour on Samsung sensor

Using Megapixels preview and the gain slider, analog gain seems to blend 2 kinds of gain.

0-~60 goes from reddish to dark, 60-max goes from dark to colorful.

At the 0 extreme, there's quite interesting behaviour with what would be overexposed at max retaining detail, resulting in a high dynamic range. This could have something to do with the sensor, but it could also be due to the color matrix supplied to Megapixels.

When setting 0x307b register to 0x20 as seen in https://github.com/A20e/android_kernel_samsung_exynos7885/blob/android-9.0/drivers/media/platform/exynos/fimc-is2/sensor/module_framework/cis/fimc-is-cis-3l6-setA.h#L20 (it's 0x80 by default), gain seems to behave in a much more predictable way. Also, the static sensor noise seems to be gone from high resolution modes.

What triggers this effect is clearing bit 7.

added camera label

I have a couple observations:

• this bit needs to get added to the kernel. We don't know if it's post-processing or something about sensor configuration. If it's postprocessing, then it should get the same treatment as the focus pixel filter, as to not damage raw data. On for naive clients?
• the registers there may be a treasure trove of improvements. From the chat, it seems the reason this bit was found is that Megapixels makes comparing pictures easier than v4l2-ctl. Perhaps we can make it even easier with special debugging modes.

added needswork label

When enabling this bit and taking a dark frame, I'm getting something really weird. First, there's bright noise:

and when I zoom out, I'm seeing a Moire pattern at several zooms. Is that a reflection of different subpixels being of different colour or is something wacky going on here?

A blown highlight on a wooden floor should not look like that, so there's something about gain indeed:

Curiously, it looks more-or-less fine in Megapixels.

mentioned in merge request !396

Okay, I have just confirmed: changing 307b to 00 from 80 causes the baseline noise level to increase quite a lot, at least under the conditions of not touching any gains. Best seen when the image is multiplied by 32, and the lens covered.

There seems to be indeed no more stripey noise, but that was much less pronounced. Under what conditions does the flipped bit improve image quality?

The Moire patterns seem to be coming from the Bayer pattern, because focus pixels contribute to them.

In my experience, taking good looking photos became much easier with that bit unset. Before I had to rely on weird digital gain behavior and had the colors weirdly clipped whenever I tried to take a photo in not very well lit conditions (like https://social.librem.one/@dos/106201114854649235 or https://social.librem.one/@dos/106201085234529611). It was much easier to get "artistic" shots like https://social.librem.one/@dos/106215900718766886 than proper photos (that room wasn't dark, it just had stripes of sunlight coming in).

Also, try setting the preview to full res. Before that change trying to take photos indoors (with lights on) would make noise overtake the actual image. Afterwards it looks really well, similar to low res image. Before I had to always apply dark frame subtraction using an image taken with exactly the same gain and exposure conditions as the processed image, as otherwise there would be a lot of static noise - like the first one in https://source.puri.sm/Librem5/linux-next/-/issues/44#note_148408. Now I'm getting images like the second one without having any image specific postprocessing (just dark level set to 16).

To sum up: before I could only get nice looking photos because of manual intervention (taking a dark frame reference together with pretty much every photo I wanted to postprocess). Now I don't have to do that at all.

I should probably make explicit that I run https://source.puri.sm/Librem5/linux-next/-/merge_requests/396 which includes plenty of other register changes as well.

mentioned in issue #325

I'm moving the noise investigations here, as it's more than just gian and I'm not seeing a solution yet: https://source.puri.sm/Librem5/linux-next/-/issues/325

Okay, I concede: 307b removes banding, and adds baseline noise. Fair tradeoff.

Is it really a "baseline noise" and not just the effect of data pedestal being added?

it does look like noise after subtracting the pedestal:

    cv2.imwrite('_.png', (c - 16) * 32)

You were somewhat right, multiplying by the 32 resulted in some bad numerics.

I'm not sure if we can make any inferences about the pedestal, but I managed to get a nearly uniform-0 picture when subtracting... 15.

That also explains that blown highlight picture: it just overflowed after I multiplied it. Duh.