The RK3399 does have a rather limited ISP, not something you'd want to pump 88M in. If you were to use only 1 camera and combine the two ISP nodes it has you'd have a maximum of 26M. This is also why they used a IMX258 as anything better would require to use the second interface for that single camera too.

But to clarify: it's not really as much about "any ISP" as it is about a good ISP that can do multi-camera composition. The ISP in the RockChip SoC can't even do one, it mostly just does basic cropping/rotation/resizing and controls the PHY. While technically an ISP, it's more like an interface driver at this stage. The driver is open source, but the hardware isn't. That's not always a bad thing, as in this case the hardware doesn't run on any RT blob, it's mostly just a bunch of registers for (image) stream processing.

I think in the android rom hacking world, most ISPs are used with their binary blobs (both firmware and kernel modules) but without the configuration and user land blobs, resulting in working cameras (at high pixel counts) but really bad image quality.

RK3399 ISP does much more than cropping/resizing. (It can't do rotation, btw - if it can, I wanna know where you're getting your details from, because that would be very useful :))

It's still a bit basic, I'd like more, but there much more color and image correction controls than you're acknowledging https://www.kernel.org/doc/html/latest/userspace-api/media/v...

There's also no firmware. It can be used as is without one.

Lack of documentation is also not a huge issue, since rockchip manuals for all/most parameters of the ISP are findable on the net.

What's missing are calibration tools. But those can be re-created from scratch. It's not terribly difficult.

Just saying that there are FOSS supported ISPs available. RKISP10 is fully supported in mainline Linux. You can just use it via v4l2.

IIRC the other operations are only supported on the other linux media framework (of which I can't remember the name - but it's the newer one than v4l2), and most examples I saw (a while back with a RK3399 dev board) were using libcamera at the time.

It does indeed not need firmware, but higher end IPS blocks often do, especially when you get much higher bandwidth sensors per CSI channel.

What I am wondering now about those calibration tools is if however they are built or reverse-engineered, they could read the pre-existing calibration payload.

Whole of ISP uses v4l2. You communicate with ISP by sending specially formatted buffers (C structs docs I posted) via v4l2 buffers (the same interface you'd get image data, too).

Preexisting calibration data are just XML files with params to load to the ISP and params to use to determine which set of params to load based on statistics collected from ISP (like after detecting what kind of light the scene has, you have to load params calibrated for that light type).

(I do rotation via RGA, so maybe you mean that? That's a separate HW block, not part of ISP.)