All of lore.kernel.org
 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 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.