All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Verkuil <hverkuil@xs4all.nl>
To: Tomasz Figa <tfiga@google.com>,
	"Mani, Rajmohan" <rajmohan.mani@intel.com>
Cc: "Zhi, Yong" <yong.zhi@intel.com>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"sakari.ailus@linux.intel.com" <sakari.ailus@linux.intel.com>,
	"Zheng, Jian Xu" <jian.xu.zheng@intel.com>,
	"Toivonen, Tuukka" <tuukka.toivonen@intel.com>,
	"Hu, Jerry W" <jerry.w.hu@intel.com>,
	"arnd@arndb.de" <arnd@arndb.de>, "hch@lst.de" <hch@lst.de>,
	"robin.murphy@arm.com" <robin.murphy@arm.com>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>
Subject: Re: [PATCH v4 00/12] Intel IPU3 ImgU patchset
Date: Tue, 5 Dec 2017 08:46:06 +0100	[thread overview]
Message-ID: <440d2f56-82b1-d6de-68e8-4ac00e8449c6@xs4all.nl> (raw)
In-Reply-To: <CAAFQd5AnoWyayibP2o+sXKh_2WsdT_E4Q1kxosy8ySP+D3Cf2w@mail.gmail.com>

On 12/05/2017 04:22 AM, Tomasz Figa wrote:
> Hi Raj,
> 
> On Tue, Dec 5, 2017 at 9:13 AM, Mani, Rajmohan <rajmohan.mani@intel.com> wrote:
>> Hi Hans,
>>
>> Thanks for your patience and sharing your thoughts on this.
>>
>>> Subject: Re: [PATCH v4 00/12] Intel IPU3 ImgU patchset
>>>
>>> Hi Rajmohan,
>>>
>>> On 11/17/2017 03:58 AM, Mani, Rajmohan wrote:
>>>> Hi Sakari and all,
>>>>
>>>>> -----Original Message-----
>>>>> From: Zhi, Yong
>>>>> Sent: Tuesday, October 17, 2017 8:47 PM
>>>>> To: linux-media@vger.kernel.org; sakari.ailus@linux.intel.com
>>>>> Cc: Zheng, Jian Xu <jian.xu.zheng@intel.com>; Mani, Rajmohan
>>>>> <rajmohan.mani@intel.com>; Toivonen, Tuukka
>>>>> <tuukka.toivonen@intel.com>; Hu, Jerry W <jerry.w.hu@intel.com>;
>>>>> arnd@arndb.de; hch@lst.de; robin.murphy@arm.com; iommu@lists.linux-
>>>>> foundation.org; Zhi, Yong <yong.zhi@intel.com>
>>>>> Subject: [PATCH v4 00/12] Intel IPU3 ImgU patchset
>>>>>
>>>>> This patchset adds support for the Intel IPU3 (Image Processing Unit)
>>>>> ImgU which is essentially a modern memory-to-memory ISP. It
>>>>> implements raw Bayer to YUV image format conversion as well as a
>>>>> large number of other pixel processing algorithms for improving the image
>>> quality.
>>>>>
>>>>> Meta data formats are defined for image statistics (3A, i.e.
>>>>> automatic white balance, exposure and focus, histogram and local area
>>>>> contrast
>>>>> enhancement) as well as for the pixel processing algorithm parameters.
>>>>> The documentation for these formats is currently not included in the
>>>>> patchset but will be added in a future version of this set.
>>>>>
>>>>
>>>> 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).
>>>>
>>>> We will also provide an user space library in binary form to help users of this
>>> driver, to convert the public 3A tuning parameters to IPU3 algorithm
>>> parameters. This tool will be released under NDA to the users of this driver.
>>>
>>> So I discussed this situation with Sakari in Prague during the ELCE. I am not
>>> happy with adding a driver to the kernel that needs an NDA to be usable. I
>>> can't agree to that. It's effectively the same as firmware that's only available
>>> under an NDA and we wouldn't accept such drivers either.
>>>
>>
>> Ack
>>
>>> There are a few options:
>>>
>>> 1) Document the ISP parameters and that format they are stored in allowing
>>> for
>>>    open source implementations. While this is the ideal, I suspect that this is
>>>    a no-go for Intel.
>>>
>>
>> Ack
>>
>>> 2) The driver can be used without using these ISP parameters and still achieve
>>>    'OK' quality. I.e., it's usable for basic webcam usage under normal lighting
>>>    conditions. I'm not sure if this is possible at all, though.
>>>
>>
>> This is something that we have tried and are able to do image capture with
>> the default ISP parameters using ov5670 sensor.
>> Additionally we had to set optimal values for the ov5670 sensor's exposure and
>> gain settings.
> 
> Does it mean hardcoding some ov5670-specific settings in the ISP
> driver? If not, I guess it might be good enough?

It doesn't look too bad, but it's hard to tell from just a single
frame. I think you can work with Sakari on this, if he also thinks it's
good enough, then I am happy with that.

> 
>>
>> Please see if the following image looks to meet the 'OK' quality.
>>
>> git clone https://github.com/RajmohanMani/ipu3-misc.git
>> ipu3-misc/ov5670.jpg is the image file.
>>
>>> 3) Make the library available without requiring an NDA.
>>>
>>
>> We are also actively exploring this option to see if this can be done.
>>
>>> 4) Provide a non-NDA library (ideally open source) that achieves at minimum
>>>    the quality as described in 2: i.e. usable for basic webcam.
>>>
>>
>> I see this is the same as option 3) + open sourcing the library.
>> Open sourcing the library does not look to be an option.
>> I will reconfirm this.
> 
> In my understanding, that could be quite different from option 3). The
> open source library would not have to implement all of the
> capabilities, just enough to get the "OK" quality and the implemented
> part could use some simpler algorithms not covered by IP.

That's correct.

This also solves my concerns about long-term maintenance of closed source
libraries which in my experience tend to suffer from bit-rot after the vendor
no longer sells the hardware it was written for. An open source implementation,
albeit not as powerful as the NDA version, can be added to e.g. the v4l-utils
repo (or at least at a repo on linuxtv.org) and maintained much longer and
independent of the vendor.

Regards,

	Hans

> 
> Best regards,
> Tomasz
> 

  reply	other threads:[~2017-12-05  7:46 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-18  3:46 [PATCH v4 00/12] Intel IPU3 ImgU patchset Yong Zhi
2017-10-18  3:46 ` Yong Zhi
2017-10-18  6:23 ` Christoph Hellwig
2017-10-18  6:23   ` Christoph Hellwig
2017-10-18 14:42   ` Zhi, Yong
2017-10-18 14:42     ` Zhi, Yong
2017-10-20  9:09 ` Sakari Ailus
2017-10-23 21:24   ` Zhi, Yong
2017-10-23 21:24     ` Zhi, Yong
2017-11-17  2:58 ` Mani, Rajmohan
2017-11-27  9:55   ` Hans Verkuil
2017-12-05  0:13     ` Mani, Rajmohan
2017-12-05  3:22       ` Tomasz Figa
2017-12-05  7:46         ` Hans Verkuil [this message]
2017-12-06  0:46           ` Mani, Rajmohan
2017-12-20 13:57   ` Mauro Carvalho Chehab
2017-12-26 22:30     ` Mani, Rajmohan
2018-02-07 23:02     ` Mani, Rajmohan
2018-02-21  1:56     ` Mani, Rajmohan
2018-02-21  1:56       ` Mani, Rajmohan
2018-03-28  3:14     ` Mani, Rajmohan
2018-03-28  3:14       ` Mani, Rajmohan
2018-04-04  1:07     ` Mani, Rajmohan
2018-04-04  1:07       ` Mani, Rajmohan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=440d2f56-82b1-d6de-68e8-4ac00e8449c6@xs4all.nl \
    --to=hverkuil@xs4all.nl \
    --cc=arnd@arndb.de \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jerry.w.hu@intel.com \
    --cc=jian.xu.zheng@intel.com \
    --cc=linux-media@vger.kernel.org \
    --cc=rajmohan.mani@intel.com \
    --cc=robin.murphy@arm.com \
    --cc=sakari.ailus@linux.intel.com \
    --cc=tfiga@google.com \
    --cc=tuukka.toivonen@intel.com \
    --cc=yong.zhi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.