[libcamera-devel] softISP for libcamera

[Andrey Konovalov]

Hi Hans,

On 06.12.2023 22:17, Hans de Goede wrote:
> Hi All,
> 
> I have pushed a new version of my optimization work here:
> 
> https://gitlab.freedesktop.org/camera/libcamera-softisp/-/commits/SoftwareISP-v02-hans1/
> 
> As the branch name suggests this has been rebased on top
> of the SoftwareISP-v02 branch.
> 
> There are 2 new things here:
> 
> 1. The color gains for whitebalance now use a lookup table
> instead of a fixed 0-256 multiplication factor. This allows
> color gains > 1.0 without needing to call std::min() 6 million
> times per frame (for FHD) to clamp. Gains > 1.0 are is necessary
> to avoid overexposed white areas like a lamp on the ceiling
> or a window in the roof to not turn purple.
> 
> At least in my measurements the lookups are actually
> a bit faster then the multiplication + fixed divide by 256
> used before.
> 
> And on top of this using lookup tables allows adding
> gamma correction for free. So I have added gamma correction
> now too.
> 
> Together this results in a pretty usable picture.
> My home-office has pretty bad lighting conditions at night
> and here is what the official proprietary Intel stack
> generates as image:
> 
> https://fedorapeople.org/~jwrdegoede/ov2740-intel-stack.png
> 
> And here is the softisp code with fixed white-balance
> and gamma-correction:
> 
> https://fedorapeople.org/~jwrdegoede/ov2740-softisp.png
> 
> This is with manually tweaked vertical blank time
> to drop the FPS to exactly 25 fps so that it is
> synced with the artificial light frequency, to avoid
> the typical banding sometimes seen with artificial
> lightning. I think we will need some way to control
> this to libcamera. Does libcamera already have a way
> for an app to request light-frequency filtering ?
> 
> I see on my main monitor that this looks a bit
> overexposed. Which is interesting because it looked
> less overexposed on the actual laptop ...
> 
> My plan for tomorrow / next week is to write
> a debayer-class. I plan to add the debayer-class
> as a separate commit which just adds it and
> then port the softisp code over to it in
> a separate commit. The idea being that the next
> version of this series can then just cherry-pick
> the patch adding the debayering class as is and
> then integrate / squash the changes to move
> the softisp code over to the separate class.

Sounds good to me!

Thanks,
Andrey

> Regards,
> 
> Hans
> 
> 
> 
>