[libcamera-devel] softISP for libcamera

[Pavel Machek]

Hi!

> > Yes, this way we do loose part of image data. Using the full 10 bits
> > for further processing would improve the image quality.
> > 
> > > Let me explain. RGB888 has 8 bits per pixel, non-linear. So debayer
> > > should really take 10 bits, and apply the correction. It may be called
> > > gamma or something, I'm sure list knows.
> > 
> > Right. Going from RAW10's 10 bits (linear) to RGB888's 8 bits (non-linear)
> > should be better done during the gamma correction stage. Rather than cutting
> > the 2 LS bits off before any processing is done.
> 
> For a GPU-based ISP, possibly, but for a CPU-based implementation, the
> extra processing will be very costly. I really wouldn't bother with the
> 2 LSBs.

I guess it depends on exact bit layout of the bayer image, but the
gamma correction for 10 bit data could be done with simple table lookup.

> I also don't expect any tone mapping in a CPU-based implementation to be
> honest, unless the implementation is meant for testing purpose only, for
> instance to prototype code before moving the implementation to the GPU.
> In production use case, anything beyond very basic processing will
> likely consume too much CPU.

Lets see. Modern CPUs are quite fast. But yes, lets get something
done/merged first and then we can tweak and optimise.

I was just surprised reading the code and not seeing additional bits,
so /* we ignore low 2 bits */ and /* we should do gamma correction
here but we don't */ would be welcome ;-).

Best regards,
								Pavel
-- 
People of Russia, stop Putin before his war on Ukraine escalates.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.libcamera.org/pipermail/libcamera-devel/attachments/20231205/cb9a4f57/attachment.sig>