From: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
To: Thomas Vajzovic <thomas.vajzovic@irisys.co.uk>
Cc: "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
Sakari Ailus <sakari.ailus@iki.fi>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: width and height of JPEG compressed images
Date: Sat, 06 Jul 2013 21:58:23 +0200 [thread overview]
Message-ID: <51D876DF.90507@gmail.com> (raw)
In-Reply-To: <A683633ABCE53E43AFB0344442BF0F0536167B8A@server10.irisys.local>
Hi Thomas,
Cc: Sakari and Laurent
On 07/05/2013 10:22 AM, Thomas Vajzovic wrote:
> Hello,
>
> I am writing a driver for the sensor MT9D131. This device supports
> digital zoom and JPEG compression.
>
> Although I am writing it for my company's internal purposes, it will
>be made open-source, so I would like to keep the API as portable as
> possible.
>
> The hardware reads AxB sensor pixels from its array, resamples them
>to CxD image pixels, and then compresses them to ExF bytes.
>
> The subdevice driver sets size AxB to the value it receives from
>v4l2_subdev_video_ops.s_crop().
>
> To enable compression then v4l2_subdev_video_ops.s_mbus_fmt() is
>called with fmt->code=V4L2_MBUS_FMT_JPEG_1X8.
>
> fmt->width and fmt->height then ought to specify the size of the
>compressed image ExF, that is, the size specified is the size in the
>format specified (the number of JPEG_1X8), not the size it would be
>in a raw format.
In VIDIOC_S_FMT 'sizeimage' specifies size of the buffer for the
compressed frame at the bridge driver side. And width/height should
specify size of the re-sampled (binning, skipping ?) frame - CxD,
if I understand what you are saying correctly.
I don't quite what transformation is done at CxD -> ExF. Why you are
using ExF (two numbers) to specify number of bytes ? And how can you
know exactly beforehand what is the frame size after compression ?
Does the sensor transmit fixed number of bytes per frame, by adding
some padding bytes if required to the compressed frame data ?
Is it something like:
sensor matrix (AxB pixels) -> binning/skipping (CxD pixels) ->
-> JPEG compresion (width = C, height = D, sizeimage ExF bytes)
?
> This allows the bridge driver to be compression agnostic. It gets
>told how many bytes to allocate per buffer and it reads that many
>bytes. It doesn't have to understand that the number of bytes isn't
>directly related to the number of pixels.
>
> So how does the user tell the driver what size image to capture
>before compression, CxD?
I think you should use VIDIOC_S_FMT(width = C, height = D, sizeimage = ExF)
for that. And s_frame_desc sudev op could be used to pass sizeimage to the
sensor subdev driver.
> (or alternatively, if you disagree and think CxD should be specified
>by s_fmt(), then how does the user specify ExF?)
Regards,
Sylwester
next prev parent reply other threads:[~2013-07-06 19:58 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-05 8:22 width and height of JPEG compressed images Thomas Vajzovic
2013-07-06 19:58 ` Sylwester Nawrocki [this message]
2013-07-07 8:18 ` Thomas Vajzovic
2013-07-10 19:43 ` Sylwester Nawrocki
2013-07-15 9:18 ` Thomas Vajzovic
2013-07-19 20:40 ` Sakari Ailus
2013-07-22 21:47 ` Sylwester Nawrocki
2013-07-23 16:07 ` Thomas Vajzovic
2013-07-19 20:28 ` Sakari Ailus
2013-07-21 20:38 ` Sylwester Nawrocki
2013-07-22 8:40 ` Thomas Vajzovic
2013-07-24 9:30 ` Sylwester Nawrocki
2013-08-06 16:26 ` Thomas Vajzovic
2013-08-21 13:34 ` Sakari Ailus
2013-08-22 16:08 ` Thomas Vajzovic
2013-08-31 22:25 ` Sylwester Nawrocki
2013-09-01 23:23 ` Laurent Pinchart
2013-07-23 22:21 ` Sakari Ailus
2013-07-24 7:47 ` Thomas Vajzovic
2013-07-24 8:39 ` Sylwester Nawrocki
2013-07-26 9:06 ` Sakari Ailus
2013-08-06 15:25 ` Thomas Vajzovic
2013-08-07 9:35 ` Sakari Ailus
2013-08-07 17:43 ` Thomas Vajzovic
2013-08-21 13:17 ` Sakari Ailus
2013-08-21 13:28 ` Laurent Pinchart
2013-08-22 15:41 ` Thomas Vajzovic
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=51D876DF.90507@gmail.com \
--to=sylvester.nawrocki@gmail.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=sakari.ailus@iki.fi \
--cc=thomas.vajzovic@irisys.co.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).