Hi Mauro, > -----Original Message----- > From: Mauro Carvalho Chehab [mailto:mchehab@xxxxxxxxxxxxxxxx] > Sent: Wednesday, December 20, 2017 5:58 AM > To: Mani, Rajmohan <rajmohan.mani@xxxxxxxxx> > Cc: Zhi, Yong <yong.zhi@xxxxxxxxx>; linux-media@xxxxxxxxxxxxxxx; > sakari.ailus@xxxxxxxxxxxxxxx; Zheng, Jian Xu <jian.xu.zheng@xxxxxxxxx>; > Toivonen, Tuukka <tuukka.toivonen@xxxxxxxxx>; Hu, Jerry W > <jerry.w.hu@xxxxxxxxx>; arnd@xxxxxxxx; hch@xxxxxx; > robin.murphy@xxxxxxx; iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx > Subject: Re: [PATCH v4 00/12] Intel IPU3 ImgU patchset > > Hi, > > Em Fri, 17 Nov 2017 02:58:56 +0000 > "Mani, Rajmohan" <rajmohan.mani@xxxxxxxxx> escreveu: > > > Here is an update on the IPU3 documentation that we are currently working > on. > > > > Image processing in IPU3 relies on the following. > > > > 1) HW configuration to enable ISP and > > 2) setting customer specific 3A Tuning / Algorithm Parameters to achieve > desired image quality. > > > > We intend to provide documentation on ImgU driver programming interface > to help users of this driver to configure and enable ISP HW to meet their > needs. This documentation will include details on complete V4L2 Kernel driver > interface and IO-Control parameters, except for the ISP internal algorithm and > its parameters (which is Intel proprietary IP). > > Sakari asked me to take a look on this thread, specifically on this email. I took a > look on the other e-mails from this thread that are discussing about this IP > block. > > I understand that Intel wants to keep their internal 3A algorithm protected, > just like other vendors protect their own algos. It was never a requirement to > open whatever algorithm are used inside a hardware (or firmware). The only > requirement is that firmwares should be licensed with redistribution > permission, ideally merged at linux-firmware git tree. > > Yet, what I don't understand is why Intel also wants to also protect the > interface for such 3A hardware/firmware algorithm. The parameters that are > passed from an userspace application to Intel ISP logic doesn't contain the > algorithm itself. What's the issue of documenting the meaning of each > parameter? > Thanks for looking into this. To achieve improved image quality using IPU3, 3A (Auto White balance, Auto Focus and Auto Exposure) Tuning parameters specific to a given camera sensor module, are converted to Intel ISP algorithm parameters in user space camera HAL using AIC (Automatic ISP Configuration) library. As a unique design of Intel ISP, it exposes very detailed algorithm parameters (~ 10000 parameters) to configure ISP's image processing algorithm per each image fame in runtime. Typical Camera SW developers (including those at Intel) are not expected to fully understand and directly set these parameters to configure the ISP algorithm blocks. Due to the above, a user space AIC library (in binary form) is provided to generate ISP Algorithm specific parameters, for a given set of 3A tuning parameters. It significantly reduces the efforts of SW development in ISP HW configuration. On the other hand, the ISP algorithm details could be deduced readily through these detailed parameters by other ISP experts outside Intel. This is the reason that we want to keep these parameter definitions as Intel proprietary IP. We are fully aware of your concerns on how to enable open source developers to use Intel ISP through up-streamed Kernel Driver. Internally, we are working on the license for this AIC library release now (as Hans said NDA license is not acceptable). We believe this will be more efficient way to help open source developers. This AIC library release would be a binary-only release. This AIC library does not use any kernel uAPIs directly. The user space Camera HAL that uses kernel uAPIs is available at https://chromium.googlesource.com/chromiumos/platform/arc-camera/+/master Thanks Raj
