libv4l: Possibility of changing the current pixelformat on the fly

libv4l: Possibility of changing the current pixelformat on the fly

[Erik Andrén]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

While trying to get hflip and vflip working for the stv06xx webcam
bridge coupled to the vv6410 sensor I've come across the following
problem.

When flipping the image horizontally, vertically or both, the sensor
pixel ordering changes. In the m5602 driver I was able to compensate
for this in the bridge code. In the stv06xx I don't have this
option. One way of solving this problem is by changing the
pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal
format. When a vertical flip is required, change the format to
V4L2_SBGGR8.

My current understanding of libv4l is that it probes the pixelformat
  upon device open. In order for this to work we would need either
poll the current pixelformat regularly or implement some kind of
notification mechanism upon a flipping request.

What do you think is this the right way to go or is there another
alternative.

Best regards,
Erik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknXwXcACgkQN7qBt+4UG0GVfwCfQjWjSu2fdyrgl3BRGlum3cJi
aFAAoKBrKtTezxcnAbmmvM1cLpYOWvvf
=4D37
-----END PGP SIGNATURE-----

Re: libv4l: Possibility of changing the current pixelformat on the fly

[Hans de Goede]

On 04/04/2009 10:22 PM, Erik Andrén wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> While trying to get hflip and vflip working for the stv06xx webcam
> bridge coupled to the vv6410 sensor I've come across the following
> problem.
>
> When flipping the image horizontally, vertically or both, the sensor
> pixel ordering changes. In the m5602 driver I was able to compensate
> for this in the bridge code. In the stv06xx I don't have this
> option. One way of solving this problem is by changing the
> pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal
> format. When a vertical flip is required, change the format to
> V4L2_SBGGR8.
>
> My current understanding of libv4l is that it probes the pixelformat
>    upon device open. In order for this to work we would need either
> poll the current pixelformat regularly or implement some kind of
> notification mechanism upon a flipping request.
>
> What do you think is this the right way to go or is there another
> alternative.
>

The changing of the pixelformat only happens when you flip the data
before conversion. If you look at the current upside down handling
code you will see it does the rotate 180 degrees after conversion.

This is how the vflip / hflip should be handled too. We only have
4 (2 really since we don't care about r versus b / u versus v while
flippiing) destination formats for which we then need to write flipping
code. Otherwise we need to write flipping code for *all* supported input
formats, not to mention flipping some input formats is close to impossible
(JPEG for example).

Regards,

Hans


p.s.

One problem with this approach is that if an apps ask for a native
cam format which is not one which we can also convert to, the
flipping won't work. I think this is best solved by simply not
listing the native formats in the enum-fmt output when the cam
needs flipping.

Re: libv4l: Possibility of changing the current pixelformat on the fly

[Erik Andrén]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Hans de Goede wrote:
> On 04/04/2009 10:22 PM, Erik Andrén wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi,
>>
>> While trying to get hflip and vflip working for the stv06xx webcam
>> bridge coupled to the vv6410 sensor I've come across the following
>> problem.
>>
>> When flipping the image horizontally, vertically or both, the sensor
>> pixel ordering changes. In the m5602 driver I was able to compensate
>> for this in the bridge code. In the stv06xx I don't have this
>> option. One way of solving this problem is by changing the
>> pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal
>> format. When a vertical flip is required, change the format to
>> V4L2_SBGGR8.
>>
>> My current understanding of libv4l is that it probes the pixelformat
>>    upon device open. In order for this to work we would need either
>> poll the current pixelformat regularly or implement some kind of
>> notification mechanism upon a flipping request.
>>
>> What do you think is this the right way to go or is there another
>> alternative.
>>
> 
> The changing of the pixelformat only happens when you flip the data
> before conversion. If you look at the current upside down handling
> code you will see it does the rotate 180 degrees after conversion.
> 
> This is how the vflip / hflip should be handled too. We only have
> 4 (2 really since we don't care about r versus b / u versus v while
> flippiing) destination formats for which we then need to write flipping
> code. Otherwise we need to write flipping code for *all* supported input
> formats, not to mention flipping some input formats is close to impossible
> (JPEG for example).
> 

So you mean we should do the vflip/hflip in software, just exposing
one native format?

Best regards,
Erik

> Regards,
> 
> Hans

> 
> p.s.
> 
> One problem with this approach is that if an apps ask for a native
> cam format which is not one which we can also convert to, the
> flipping won't work. I think this is best solved by simply not
> listing the native formats in the enum-fmt output when the cam
> needs flipping.
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknYlVoACgkQN7qBt+4UG0FwqACfQtawSmcm8rtFUCGZtV9pzVd+
jmkAoKHkibnapkZkDfl4pXd8pjaJ9M0E
=odkv
-----END PGP SIGNATURE-----

Re: libv4l: Possibility of changing the current pixelformat on the fly

[Hans de Goede]

On 04/05/2009 01:26 PM, Erik Andrén wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Hans de Goede wrote:
>> On 04/04/2009 10:22 PM, Erik Andrén wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Hi,
>>>
>>> While trying to get hflip and vflip working for the stv06xx webcam
>>> bridge coupled to the vv6410 sensor I've come across the following
>>> problem.
>>>
>>> When flipping the image horizontally, vertically or both, the sensor
>>> pixel ordering changes. In the m5602 driver I was able to compensate
>>> for this in the bridge code. In the stv06xx I don't have this
>>> option. One way of solving this problem is by changing the
>>> pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal
>>> format. When a vertical flip is required, change the format to
>>> V4L2_SBGGR8.
>>>
>>> My current understanding of libv4l is that it probes the pixelformat
>>>     upon device open. In order for this to work we would need either
>>> poll the current pixelformat regularly or implement some kind of
>>> notification mechanism upon a flipping request.
>>>
>>> What do you think is this the right way to go or is there another
>>> alternative.
>>>
>> The changing of the pixelformat only happens when you flip the data
>> before conversion. If you look at the current upside down handling
>> code you will see it does the rotate 180 degrees after conversion.
>>
>> This is how the vflip / hflip should be handled too. We only have
>> 4 (2 really since we don't care about r versus b / u versus v while
>> flippiing) destination formats for which we then need to write flipping
>> code. Otherwise we need to write flipping code for *all* supported input
>> formats, not to mention flipping some input formats is close to impossible
>> (JPEG for example).
>>
>
> So you mean we should do the vflip/hflip in software, just exposing
> one native format?
>

Erm, yes that is what I was saying, but that is because I was confusing
things with the sq905 driver some other people are working on.

Now I understand what you were trying to ask. So the problem is that
the vv6410 sensor can do flipping in hardware, and then the order in
which it sends out the pixels changes from gbgbgb (for example)
to bgbgbg, for the lines which have blue, effectively changing the
pixelformat, right?

In that case I think the only solution is to simply return -EBUSY when
the vflip / hflip controls are changed while a stream is active.

As for the race window with one application querying the format (or even
setting it) and then another app changing the flip before the application
which just set the format starts the stream, we already have that wrt 2
applications doing this:
app a: setformat x
app b: setformat y
app a: start stream (thinking format is x)

Which is something which normally (luckily) never happens.

Does that sound like a plan ?

Note that this is a solution at the driver level, which IMHO is the only
way as we cannot assume libv4l is always being used.

Regards,

Hans

Re: libv4l: Possibility of changing the current pixelformat on the fly

[Erik Andrén]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Hans de Goede wrote:
> On 04/05/2009 01:26 PM, Erik Andrén wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>
>> Hans de Goede wrote:
>>> On 04/04/2009 10:22 PM, Erik Andrén wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Hi,
>>>>
>>>> While trying to get hflip and vflip working for the stv06xx webcam
>>>> bridge coupled to the vv6410 sensor I've come across the following
>>>> problem.
>>>>
>>>> When flipping the image horizontally, vertically or both, the sensor
>>>> pixel ordering changes. In the m5602 driver I was able to compensate
>>>> for this in the bridge code. In the stv06xx I don't have this
>>>> option. One way of solving this problem is by changing the
>>>> pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal
>>>> format. When a vertical flip is required, change the format to
>>>> V4L2_SBGGR8.
>>>>
>>>> My current understanding of libv4l is that it probes the pixelformat
>>>>     upon device open. In order for this to work we would need either
>>>> poll the current pixelformat regularly or implement some kind of
>>>> notification mechanism upon a flipping request.
>>>>
>>>> What do you think is this the right way to go or is there another
>>>> alternative.
>>>>
>>> The changing of the pixelformat only happens when you flip the data
>>> before conversion. If you look at the current upside down handling
>>> code you will see it does the rotate 180 degrees after conversion.
>>>
>>> This is how the vflip / hflip should be handled too. We only have
>>> 4 (2 really since we don't care about r versus b / u versus v while
>>> flippiing) destination formats for which we then need to write flipping
>>> code. Otherwise we need to write flipping code for *all* supported input
>>> formats, not to mention flipping some input formats is close to
>>> impossible
>>> (JPEG for example).
>>>
>>
>> So you mean we should do the vflip/hflip in software, just exposing
>> one native format?
>>
> 
> Erm, yes that is what I was saying, but that is because I was confusing
> things with the sq905 driver some other people are working on.
> 

Glad that you were confused as I couldn't really make out the
meaning of your answer. :)

> Now I understand what you were trying to ask. So the problem is that
> the vv6410 sensor can do flipping in hardware, and then the order in
> which it sends out the pixels changes from gbgbgb (for example)
> to bgbgbg, for the lines which have blue, effectively changing the
> pixelformat, right?

Correct.

> 
> In that case I think the only solution is to simply return -EBUSY when
> the vflip / hflip controls are changed while a stream is active.
> 

So this effectively forces a reprobe of the hardware?

> As for the race window with one application querying the format (or even
> setting it) and then another app changing the flip before the application
> which just set the format starts the stream, we already have that wrt 2
> applications doing this:
> app a: setformat x
> app b: setformat y
> app a: start stream (thinking format is x)
> 
> Which is something which normally (luckily) never happens.
> 

If this ever becomes a real issue, shouldn't some kind of user-space
master program aquire the device and then handle format requests for
all client programs?

> Does that sound like a plan ?
> 

Yes, I'll try this ASAP.

> Note that this is a solution at the driver level, which IMHO is the only
> way as we cannot assume libv4l is always being used.
> 

If it works this sounds like the most clean and elegant solution.
The weak point being that the application must try to renegotiate
the format upon the -EBUSY signal.

Thanks for the help!

Regards,
Erik


> Regards,
> 
> Hans
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknYqtwACgkQN7qBt+4UG0FBgACggwgmVfMKj2bQAj/UVSL/vHSH
Ss0Anj/8xoRpXiIzBg3HdtDa0SXK6WK2
=yIxz
-----END PGP SIGNATURE-----

Re: libv4l: Possibility of changing the current pixelformat on the fly

[Hans de Goede]

On 04/05/2009 02:58 PM, Erik Andrén wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Hans de Goede wrote:
>> On 04/05/2009 01:26 PM, Erik Andrén wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>>
>>>
>>> Hans de Goede wrote:
>>>> On 04/04/2009 10:22 PM, Erik Andrén wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> Hi,
>>>>>
>>>>> While trying to get hflip and vflip working for the stv06xx webcam
>>>>> bridge coupled to the vv6410 sensor I've come across the following
>>>>> problem.
>>>>>
>>>>> When flipping the image horizontally, vertically or both, the sensor
>>>>> pixel ordering changes. In the m5602 driver I was able to compensate
>>>>> for this in the bridge code. In the stv06xx I don't have this
>>>>> option. One way of solving this problem is by changing the
>>>>> pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal
>>>>> format. When a vertical flip is required, change the format to
>>>>> V4L2_SBGGR8.
>>>>>
>>>>> My current understanding of libv4l is that it probes the pixelformat
>>>>>      upon device open. In order for this to work we would need either
>>>>> poll the current pixelformat regularly or implement some kind of
>>>>> notification mechanism upon a flipping request.
>>>>>
>>>>> What do you think is this the right way to go or is there another
>>>>> alternative.
>>>>>
>>>> The changing of the pixelformat only happens when you flip the data
>>>> before conversion. If you look at the current upside down handling
>>>> code you will see it does the rotate 180 degrees after conversion.
>>>>
>>>> This is how the vflip / hflip should be handled too. We only have
>>>> 4 (2 really since we don't care about r versus b / u versus v while
>>>> flippiing) destination formats for which we then need to write flipping
>>>> code. Otherwise we need to write flipping code for *all* supported input
>>>> formats, not to mention flipping some input formats is close to
>>>> impossible
>>>> (JPEG for example).
>>>>
>>> So you mean we should do the vflip/hflip in software, just exposing
>>> one native format?
>>>
>> Erm, yes that is what I was saying, but that is because I was confusing
>> things with the sq905 driver some other people are working on.
>>
>
> Glad that you were confused as I couldn't really make out the
> meaning of your answer. :)
>
>> Now I understand what you were trying to ask. So the problem is that
>> the vv6410 sensor can do flipping in hardware, and then the order in
>> which it sends out the pixels changes from gbgbgb (for example)
>> to bgbgbg, for the lines which have blue, effectively changing the
>> pixelformat, right?
>
> Correct.
>
>> In that case I think the only solution is to simply return -EBUSY when
>> the vflip / hflip controls are changed while a stream is active.
>>
>
> So this effectively forces a reprobe of the hardware?
>

No, it just disallows changing the flipping (and thus the format) while
an app is actively streaming. so one can use something like v4l2ucp, and
change the flipping while the cam is not being used otherwise, but
if for example skype or cheese or whatever is streaming data from the cam
then the flip will be disallowed (and a device busy error will be returned).

This may not seem very user friendly but normally one does not want to
mess with the flip controls anyways unless the cam is mounted upside down
or something like that.

>> As for the race window with one application querying the format (or even
>> setting it) and then another app changing the flip before the application
>> which just set the format starts the stream, we already have that wrt 2
>> applications doing this:
>> app a: setformat x
>> app b: setformat y
>> app a: start stream (thinking format is x)
>>
>> Which is something which normally (luckily) never happens.
>>
>
> If this ever becomes a real issue, shouldn't some kind of user-space
> master program aquire the device and then handle format requests for
> all client programs?
>

Yes, one of these days we need to think (very hard) about a much better
way for sharing v4l devices.

>> Does that sound like a plan ?
>>
>
> Yes, I'll try this ASAP.
>
>> Note that this is a solution at the driver level, which IMHO is the only
>> way as we cannot assume libv4l is always being used.
>>
>
> If it works this sounds like the most clean and elegant solution.
> The weak point being that the application must try to renegotiate
> the format upon the -EBUSY signal.
>

No, the idea is that the flipping will simply not change (hence the
error, signaling the setting of the flip control failed).

Regards,

Hans

Re: libv4l: Possibility of changing the current pixelformat on the fly

[Theodore Kilgore]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4309 bytes --]



On Sun, 5 Apr 2009, Hans de Goede wrote:

> On 04/05/2009 01:26 PM, Erik Andrén wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> 
>> 
>> Hans de Goede wrote:
>>> On 04/04/2009 10:22 PM, Erik Andrén wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>> 
>>>> Hi,
>>>> 
>>>> While trying to get hflip and vflip working for the stv06xx webcam
>>>> bridge coupled to the vv6410 sensor I've come across the following
>>>> problem.
>>>> 
>>>> When flipping the image horizontally, vertically or both, the sensor
>>>> pixel ordering changes. In the m5602 driver I was able to compensate
>>>> for this in the bridge code. In the stv06xx I don't have this
>>>> option. One way of solving this problem is by changing the
>>>> pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal
>>>> format. When a vertical flip is required, change the format to
>>>> V4L2_SBGGR8.
>>>> 
>>>> My current understanding of libv4l is that it probes the pixelformat
>>>>     upon device open. In order for this to work we would need either
>>>> poll the current pixelformat regularly or implement some kind of
>>>> notification mechanism upon a flipping request.
>>>> 
>>>> What do you think is this the right way to go or is there another
>>>> alternative.
>>>> 
>>> The changing of the pixelformat only happens when you flip the data
>>> before conversion. If you look at the current upside down handling
>>> code you will see it does the rotate 180 degrees after conversion.
>>> 
>>> This is how the vflip / hflip should be handled too. We only have
>>> 4 (2 really since we don't care about r versus b / u versus v while
>>> flippiing) destination formats for which we then need to write flipping
>>> code. Otherwise we need to write flipping code for *all* supported input
>>> formats, not to mention flipping some input formats is close to impossible
>>> (JPEG for example).
>>> 
>> 
>> So you mean we should do the vflip/hflip in software, just exposing
>> one native format?
>> 
>
> Erm, yes that is what I was saying, but that is because I was confusing
> things with the sq905 driver some other people are working on.
>
> Now I understand what you were trying to ask. So the problem is that
> the vv6410 sensor can do flipping in hardware, and then the order in
> which it sends out the pixels changes from gbgbgb (for example)
> to bgbgbg, for the lines which have blue, effectively changing the
> pixelformat, right?


You mention the sq905 cameras, and the general problem of image flipping. 
You comment that the order of the data changes if any kind of flipping 
is done, with the result that the image format (Bayer tiling) changes. One 
difference I do see here is that "the vv6410 sensor can do flipping in 
hardware" which the sq905 cameras obviously can not. However, the fact 
that the Bayer tiling of the image must change in accordance with the 
flipping is equally present. And I do not see how that problem could be 
avoided, on any occasion when flipping is needed.

This brings up an interesting question of what would be the most efficient 
way actually to do the required image flipping:

If the flipping is done before the finished image is produced, then the 
Bayer tiling of the image has changed. Therefore a different treatment is 
needed.

If the flipping is done after the finished image is produced, then there 
is three times as much data, and the flipping might take longer (or might 
not if it were done exactly right?).

Therefore, how best to do this? As I said, I am thinking about the sq905 
driver. One of its peculiarities, as far as I can tell, is that the 
cameras all use the same Bayer tiling before the flipping. But after the 
flipping it is obviously a different story. The approach that was taken in 
the libgphoto2 driver for the sq905 cameras was to do the flipping first, 
and then to apply the right Bayer tiling afterward for the particular 
camera. Clearly, that could also be done here. However, is that the best 
way to go about it? Perhaps in fact it is simpler to do the flipping of an 
entire finished image, instead. Then one would of course have to move 
triples instead of single bytes, in order to leave the color mapping 
unmolested.

It is interesting that this problem comes up with some other cameras, too.

Theodore Kilgore

Re: libv4l: Possibility of changing the current pixelformat on the fly

[Hans de Goede]

On 04/05/2009 06:53 PM, Theodore Kilgore wrote:
>
>
> On Sun, 5 Apr 2009, Hans de Goede wrote:
>
>> On 04/05/2009 01:26 PM, Erik Andrén wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>>
>>>
>>> Hans de Goede wrote:
>>>> On 04/04/2009 10:22 PM, Erik Andrén wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> Hi,
>>>>>
>>>>> While trying to get hflip and vflip working for the stv06xx webcam
>>>>> bridge coupled to the vv6410 sensor I've come across the following
>>>>> problem.
>>>>>
>>>>> When flipping the image horizontally, vertically or both, the sensor
>>>>> pixel ordering changes. In the m5602 driver I was able to compensate
>>>>> for this in the bridge code. In the stv06xx I don't have this
>>>>> option. One way of solving this problem is by changing the
>>>>> pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal
>>>>> format. When a vertical flip is required, change the format to
>>>>> V4L2_SBGGR8.
>>>>>
>>>>> My current understanding of libv4l is that it probes the pixelformat
>>>>> upon device open. In order for this to work we would need either
>>>>> poll the current pixelformat regularly or implement some kind of
>>>>> notification mechanism upon a flipping request.
>>>>>
>>>>> What do you think is this the right way to go or is there another
>>>>> alternative.
>>>>>
>>>> The changing of the pixelformat only happens when you flip the data
>>>> before conversion. If you look at the current upside down handling
>>>> code you will see it does the rotate 180 degrees after conversion.
>>>>
>>>> This is how the vflip / hflip should be handled too. We only have
>>>> 4 (2 really since we don't care about r versus b / u versus v while
>>>> flippiing) destination formats for which we then need to write flipping
>>>> code. Otherwise we need to write flipping code for *all* supported
>>>> input
>>>> formats, not to mention flipping some input formats is close to
>>>> impossible
>>>> (JPEG for example).
>>>>
>>>
>>> So you mean we should do the vflip/hflip in software, just exposing
>>> one native format?
>>>
>>
>> Erm, yes that is what I was saying, but that is because I was confusing
>> things with the sq905 driver some other people are working on.
>>
>> Now I understand what you were trying to ask. So the problem is that
>> the vv6410 sensor can do flipping in hardware, and then the order in
>> which it sends out the pixels changes from gbgbgb (for example)
>> to bgbgbg, for the lines which have blue, effectively changing the
>> pixelformat, right?
>
>
> You mention the sq905 cameras, and the general problem of image
> flipping. You comment that the order of the data changes if any kind of
> flipping is done, with the result that the image format (Bayer tiling)
> changes. One difference I do see here is that "the vv6410 sensor can do
> flipping in hardware" which the sq905 cameras obviously can not.
> However, the fact that the Bayer tiling of the image must change in
> accordance with the flipping is equally present. And I do not see how
> that problem could be avoided, on any occasion when flipping is needed.
>
> This brings up an interesting question of what would be the most
> efficient way actually to do the required image flipping:
>
> If the flipping is done before the finished image is produced, then the
> Bayer tiling of the image has changed. Therefore a different treatment
> is needed.
>
> If the flipping is done after the finished image is produced, then there
> is three times as much data, and the flipping might take longer (or
> might not if it were done exactly right?).
>

True, still doing the flipping after the conversion is done, is what we are
currently doing for the rotate 180 case (so h-flip + v-flip) and is what I
think we should also do for the regular h-flip and v-flip.

Why? Simplicity! We support 4 different destination formats, which can
be simplified to 3 for the flipping case (we do not need to care about uv
order). So that means writing vflip + hflip + rotate 180 = 3 x 3 9
flipping routines. At the moment we support 23 different source formats,
so doing flipping at the level requires 3 x 23 = 69 flipping routines of which
we can shave of quite a bit by being smart here and there, but then we are
still left with quite a large number. But the most important reason for me
not to want to do this at the source format level, is that I do not want to
make it harder to add new source formats. Currently for a new
source format, conversion routines for all 4 dest formats must be written,
so that is 4 new conversion routines at worst. I do not want to make adding
new formats harder.

Regards,

Hans

Re: libv4l: Possibility of changing the current pixelformat on the fly

[Jean-Francois Moine]

On Sat, 04 Apr 2009 22:22:19 +0200
Erik Andrén <erik.andren@gmail.com> wrote:
	[snip]
> When flipping the image horizontally, vertically or both, the sensor
> pixel ordering changes. In the m5602 driver I was able to compensate
> for this in the bridge code. In the stv06xx I don't have this
> option. One way of solving this problem is by changing the
> pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal
> format. When a vertical flip is required, change the format to
> V4L2_SBGGR8.
> 
> My current understanding of libv4l is that it probes the pixelformat
>   upon device open. In order for this to work we would need either
> poll the current pixelformat regularly or implement some kind of
> notification mechanism upon a flipping request.
> 
> What do you think is this the right way to go or is there another
> alternative.

Hi Erik,

I saw such a problem in some other webcams. When doing a flip, the
sensor scans the pixels in the reverse order. So,
	R G R G
	G B G B
becomes
	B G B G
	G R G R

The solution is to start the scan one line lower or higher for VFLIP
and one pixel on the left or on the right for HFLIP.

May you do this with all the sensors of the stv06xx?

Cheers.

-- 
Ken ar c'hentan	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: libv4l: Possibility of changing the current pixelformat on the fly

[Erik Andrén]

2009/4/5 Jean-Francois Moine <moinejf@free.fr>:
> On Sat, 04 Apr 2009 22:22:19 +0200
> Erik Andrén <erik.andren@gmail.com> wrote:
>        [snip]
>> When flipping the image horizontally, vertically or both, the sensor
>> pixel ordering changes. In the m5602 driver I was able to compensate
>> for this in the bridge code. In the stv06xx I don't have this
>> option. One way of solving this problem is by changing the
>> pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal
>> format. When a vertical flip is required, change the format to
>> V4L2_SBGGR8.
>>
>> My current understanding of libv4l is that it probes the pixelformat
>>   upon device open. In order for this to work we would need either
>> poll the current pixelformat regularly or implement some kind of
>> notification mechanism upon a flipping request.
>>
>> What do you think is this the right way to go or is there another
>> alternative.
>
> Hi Erik,
>
> I saw such a problem in some other webcams. When doing a flip, the
> sensor scans the pixels in the reverse order. So,
>        R G R G
>        G B G B
> becomes
>        B G B G
>        G R G R
>
> The solution is to start the scan one line lower or higher for VFLIP
> and one pixel on the left or on the right for HFLIP.
>

As I wrote in my original email I haven't found out a way to adjust
this when using the vv6410 sensor.

> May you do this with all the sensors of the stv06xx?

This issue is vv6410 specific.

Best regards,
Erik Andrén

>
> Cheers.
>
> --
> Ken ar c'hentan |             ** Breizh ha Linux atav! **
> Jef             |               http://moinejf.free.fr/
>

Re: libv4l: Possibility of changing the current pixelformat on the fly

[Theodore Kilgore]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2665 bytes --]



On Sun, 5 Apr 2009, Jean-Francois Moine wrote:

> On Sat, 04 Apr 2009 22:22:19 +0200
> Erik Andrén <erik.andren@gmail.com> wrote:
> 	[snip]
>> When flipping the image horizontally, vertically or both, the sensor
>> pixel ordering changes. In the m5602 driver I was able to compensate
>> for this in the bridge code. In the stv06xx I don't have this
>> option. One way of solving this problem is by changing the
>> pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal
>> format. When a vertical flip is required, change the format to
>> V4L2_SBGGR8.
>>
>> My current understanding of libv4l is that it probes the pixelformat
>>   upon device open. In order for this to work we would need either
>> poll the current pixelformat regularly or implement some kind of
>> notification mechanism upon a flipping request.
>>
>> What do you think is this the right way to go or is there another
>> alternative.
>
> Hi Erik,
>
> I saw such a problem in some other webcams. When doing a flip, the
> sensor scans the pixels in the reverse order. So,
> 	R G R G
> 	G B G B
> becomes
> 	B G B G
> 	G R G R
>
> The solution is to start the scan one line lower or higher for VFLIP
> and one pixel on the left or on the right for HFLIP.
>
> May you do this with all the sensors of the stv06xx?

That is a very clever solution -- if the hardware will do such a thing. I 
can not speak for the stv06xx cameras, of course. But I am pretty sure it 
is impossible for the sq905 cameras. Therefore it is not a universal 
solution. If it can be done, great. But it seems to me that the general 
way to do this would be just to adjust the Bayer tiling to be in accord 
with the flipping after it is done (one of the possibilities already 
mentioned above).

The problem which I would address is that the need for image flipping 
ought to be handled in a standard way, if possible. The sq905 cameras 
(with which I have been directly concerned) do give rise to similar 
problems. The big difference is that there is no way with an sq905 to tell 
the camera to do any flipping in hardware, nor to shift the pixel reading 
one space over or down. Hence my obvious interest in seeing this problem 
analysed completely, and in seeing the best solution adopted. One possible 
way to do that would be to have the choice for the pixel format to reflect 
what it ought to be, after any flipping has taken place. From this point 
of view, it would not matter if the flipping is done in V4L or in 
hardware, before the data has left the camera. It would only be necessary 
to agree that any required flipping takes place first, and then the Bayer 
interpolation afterwards.

Theodore Kilgore