All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Foss <robert.foss@linaro.org>
To: Tomasz Figa <tfiga@chromium.org>
Cc: Bingbu Cao <bingbu.cao@linux.intel.com>,
	Dongchun Zhu <dongchun.zhu@mediatek.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	linux-media <linux-media@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Ben Kao <ben.kao@intel.com>
Subject: Re: [PATCH] media: ov8856: Remove 3280x2464 mode
Date: Fri, 27 Nov 2020 14:38:24 +0100	[thread overview]
Message-ID: <CAG3jFyvxLCk=U7Dt8O3poja7yHiRR5B3jq9Xbh_Nsigrjrckcw@mail.gmail.com> (raw)
In-Reply-To: <CAAFQd5AVs4EeV+q87SSdUW3uW_LComGV=HG5J2XaacDvbAgYXg@mail.gmail.com>

Thanks for digging into this everyone!

Assuming Tomasz doesn't find any stretching, I think we can conclude
that this mode works, and should be kept. Thanks Dongchun for parsing
the datasheet and finding the Bayer mode issue for the two other
recently added resolutions.

On Fri, 27 Nov 2020 at 11:26, Tomasz Figa <tfiga@chromium.org> wrote:
>
> On Thu, Nov 26, 2020 at 7:00 PM Robert Foss <robert.foss@linaro.org> wrote:
> >
> > On Wed, 25 Nov 2020 at 08:32, Tomasz Figa <tfiga@chromium.org> wrote:
> > >
> > > Hi Bingbu,
> > >
> > > On Wed, Nov 25, 2020 at 1:15 PM Bingbu Cao <bingbu.cao@linux.intel.com> wrote:
> > > >
> > > >
> > > >
> > > > On 11/24/20 6:20 PM, Robert Foss wrote:
> > > > > On Tue, 24 Nov 2020 at 10:42, Bingbu Cao <bingbu.cao@linux.intel.com> wrote:
> > > > >>
> > > > >> Hi, Robert
> > > > >>
> > > > >> I remember that the full size of ov8856 image sensor is 3296x2480 and we can get the 3280x2464
> > > > >> frames based on current settings.
> > > > >>
> > > > >> Do you have any issues with this mode?
> > > > >
> > > > > As far as I can tell using the 3280x2464 mode actually yields an
> > > > > output resolution that is 3264x2448.
> > > > >
> > > > > What does your hardware setup look like? And which revision of the
> > > > > sensor are you using?
> > > > >
> > > >
> > > > Robert, the sensor revision I am using is v1.1. I just checked the actual output pixels on our
> > > > hardware, the output resolution with 2464 mode is 3280x2464, no black pixels.
> > > >
> > > > As Tomasz said, some ISP has the requirement of extra pixel padding, From the ov8856 datasheet,
> > > > the central 3264x2448 pixels are *suggested* to be output from the pixel array and the boundary
> > > > pixels can be used for additional processing. In my understanding, the 32 dummy lines are not
> > > > black lines.
> > >
> > > The datasheet says that only 3264x2448 are active pixels. What pixel
> > > values are you seeing outside of that central area? In the datasheet,
> > > those look like "optically black" pixels, which are not 100% black,
> > > but rather as if the sensor cells didn't receive any light - noise can
> > > be still there.
> > >
> >
> > I've been developing support for some Qcom ISP functionality, and
> > during the course of this I ran into the issue I was describing, where
> > the 3280x2464 mode actually outputs 3264x2448.
> >
> > I can think of two reasons for this, either ISP driver bugs on my end
> > or the fact that the sensor is being run outside of the specification
> > and which could be resulting in differences between how the ov8856
> > sensors behave.
>
> I just confirmed and we're indeed using this mode in a number of our
> projects based on the Intel ISP and it seems to be producing a proper
> image with all pixels of the 3280x2464 matrix having proper values.
> I'm now double checking whether this isn't some processing done by the
> ISP, but I suspect the quality would be bad if it stretched the
> central 3264x2448 part into the 3280x2464 frame.
>
> Best regards,
> Tomasz

  reply	other threads:[~2020-11-27 13:38 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-16 15:50 [PATCH] media: ov8856: Remove 3280x2464 mode Robert Foss
2020-11-24  7:40 ` Dongchun Zhu
2020-11-24  8:43   ` Sakari Ailus
2020-11-24 10:10     ` Dongchun Zhu
2020-11-24 10:45       ` Robert Foss
     [not found]     ` <CAG3jFytX_=RcKyLkNOSCEmNHnruxSP_=PNFuGRdrevJ17x4ndQ@mail.gmail.com>
     [not found]       ` <961bb1b9384a4261949e9afd1e37d43e@MTKMBS31N1.mediatek.inc>
2020-11-24 10:18         ` Robert Foss
2020-11-24  9:40 ` Bingbu Cao
2020-11-24 10:20   ` Robert Foss
2020-11-25  4:11     ` Bingbu Cao
2020-11-25  7:32       ` Tomasz Figa
2020-11-26 10:00         ` Robert Foss
2020-11-27 10:26           ` Tomasz Figa
2020-11-27 13:38             ` Robert Foss [this message]
2020-12-09  5:07               ` Tomasz Figa
2020-11-24 11:27 ` Tomasz Figa

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='CAG3jFyvxLCk=U7Dt8O3poja7yHiRR5B3jq9Xbh_Nsigrjrckcw@mail.gmail.com' \
    --to=robert.foss@linaro.org \
    --cc=ben.kao@intel.com \
    --cc=bingbu.cao@linux.intel.com \
    --cc=dongchun.zhu@mediatek.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=tfiga@chromium.org \
    /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.