linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).