Re:RFC: Where to store camera properties (upside down, needs sw whitebalance, etc). ?

Re:RFC: Where to store camera properties (upside down, needs sw whitebalance, etc). ?

[Olivier Lorin]

> >> 2) With some cams the upside down ness may actually be stored in an eeprom, or
> >> in some cases even determined by a switch (so the cam can be rotated
> >> manually by the user and the the switch indicates the position)
> >>
> >> In these cases we need a userspace API to find this out too. Since this is a
> >> per frame thing for some cams (one frame could be upright, the next upside
> >> down). I would like to suggest to define some V4L2_BUF_FLAG_ 's for this
> >> which can be used by drivers to indicate that the picture in the buffer is
> >> vflipped or hflipped (with upside down being both together).
>
>
> Please be aware of the fact that, when the gspca-sq905 module is
> considered complete, there will need to be some kind of scheme which will
> take its needs into consideration. Here is what happens with these
> cameras:
>
> 1. All of them have the same Vendor:Product number, 0x2770:0x9120.
>
> 2. Some of them emit output which needs vertical inversion, but for some
> others a horizontal mirroring is required, instead.
>
> 3. The way that you can tell which is needed is that a four-byte model
> number is requested, and that can be parsed to decide which of (1) or
> (2) to do. The way the camera works, the first step in initializing it is
> to read this number; the streaming takes place after that.
>
> Clearly, it is possible either to perform the appropriate action on the
> frames either in the module, or in userspace, in libv4l. Equally obvious,
> if the action has to take place in userspace then there has to be some way
> to pass the appropriate information on.
>
> From my point of view, it does not matter whether the appropriate
> manipulations take place in the module or in userspace. I merely want to
> point out that the information does not come from the Vendor:Product
> number, but from a specific query which takes place after the module is in
> control and is sending commands to the camera. And, if the manipulation is
> done in userspace then the information has to be passed on, too.
>
> Theodore Kilgore

The use of the buffer flags makes the life easier as this flag 
is read for every image. So we can solve for the flip/rotation 
issues with the help of two new buffer flags: V4L2_BUF_FLAG_NEEDS_HFLIP 
and V4L2_BUF_FLAG_NEEDS_VFLIP.

A driver has to set them properly. Does the rotation or flip(s) 
apply to every image (e.g. sensor upside down) or change with frames
(e.g. Genesys webcams), that no more matters .
I can do the patch these days.
I do not remember if there is h/v flip functions in the libv4l, 
maybe they have to be added.

Regards,
Nol

 Créez votre adresse électronique prenom.nom@laposte.net 
 1 Go d'espace de stockage, anti-spam et anti-virus intégrés.
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: RFC: Where to store camera properties (upside down, needs sw whitebalance, etc). ?

[Adam Baker]

On Friday 16 January 2009, Olivier Lorin wrote:
<snip discussion of cameras needing image flipping capability in libv4l>
> The use of the buffer flags makes the life easier as this flag
> is read for every image. So we can solve for the flip/rotation
> issues with the help of two new buffer flags: V4L2_BUF_FLAG_NEEDS_HFLIP
> and V4L2_BUF_FLAG_NEEDS_VFLIP.
>
> A driver has to set them properly. Does the rotation or flip(s)
> apply to every image (e.g. sensor upside down) or change with frames
> (e.g. Genesys webcams), that no more matters .
> I can do the patch these days.
> I do not remember if there is h/v flip functions in the libv4l,
> maybe they have to be added.
>
> Regards,
> Nol

That sounds like a sensible approach. The flip code is already in libv4l  but 
is currently controlled by a static table (v4lconvert_flags) of cameras that 
need it.

It doesn't address the issue of whether libv4l should also provide gamma 
adjustment, auto white balance and auto gain for cameras that could benefit 
from it. Again that could be done with a static table but keeping the 
knowledge in libv4l in step with the list of supported cameras in the kernel 
won't be easy.

Adam

Re: RFC: Where to store camera properties (upside down, needs sw whitebalance, etc). ?

[Olivier Lorin]

[-- Attachment #1: Type: text/plain, Size: 2112 bytes --]

> <snip discussion of cameras needing image flipping capability in libv4l>
> > The use of the buffer flags makes the life easier as this flag
> > is read for every image. So we can solve for the flip/rotation
> > issues with the help of two new buffer flags: V4L2_BUF_FLAG_NEEDS_HFLIP
> > and V4L2_BUF_FLAG_NEEDS_VFLIP.
> >
> > A driver has to set them properly. Does the rotation or flip(s)
> > apply to every image (e.g. sensor upside down) or change with frames
> > (e.g. Genesys webcams), that no more matters .
> > I can do the patch these days.
> > I do not remember if there is h/v flip functions in the libv4l,
> > maybe they have to be added.
> >
> > Regards,
> > Nol
> 
> That sounds like a sensible approach. The flip code is already in libv4l  but 
> is currently controlled by a static table (v4lconvert_flags) of cameras that 
> need it.
> 
> It doesn't address the issue of whether libv4l should also provide gamma 
> adjustment, auto white balance and auto gain for cameras that could benefit 
> from it. Again that could be done with a static table but keeping the 
> knowledge in libv4l in step with the list of supported cameras in the kernel 
> won't be easy.
> 
> Adam

For sure the use of buffer flag copes only with the need of 180 deg rotation 
(and also hflip or vflip but it is not yet part of libv4l). 
And once again it handles as well constant orientation status as variable one 
as the buffer flag value is requested every image.
Moreover this does not require the maintenance of the static table and needs 
only two new V4L2_BUF_FLAGs.
Post gamma or white balance correction seemed to be more part of the webcam 
capabilities than the image state so that the new API to get these features 
is quite logical. 

I join a patch to make libv4l-0.5.8 handles 180 degrees image rotation with 
buffer flags. It could be extended to manage hflip and vflip with the addition 
of corresponding functions in flip.c.

Nol

 Créez votre adresse électronique prenom.nom@laposte.net 
 1 Go d'espace de stockage, anti-spam et anti-virus intégrés.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch_libv4l_UpsideDown-0.5.8.diff --]
[-- Type: text/x-diff; name=patch_libv4l_UpsideDown-0.5.8.diff, Size: 1341 bytes --]

diff -cr libv4l-0.5.8/libv4l2/libv4l2.c nv_libv4l-0.5.8/libv4l2/libv4l2.c
*** libv4l-0.5.8/libv4l2/libv4l2.c	2008-12-02 23:39:49.000000000 +0100
--- nv_libv4l-0.5.8/libv4l2/libv4l2.c	2009-01-16 23:14:57.000000000 +0100
***************
*** 68,73 ****
--- 68,74 ----
  #include <sys/stat.h>
  #include "libv4l2.h"
  #include "libv4l2-priv.h"
+ #include "../libv4lconvert/libv4lconvert-priv.h"
  
  /* Note these flags are stored together with the flags passed to v4l2_fd_open()
     in v4l2_dev_info's flags member, so care should be taken that the do not
***************
*** 78,83 ****
--- 79,89 ----
  #define V4L2_SUPPORTS_READ		0x0800
  #define V4L2_IS_UVC			0x1000
  
+ #ifndef V4L2_BUF_FLAG_NEEDS_HFLIP
+ 	#define V4L2_BUF_FLAG_NEEDS_HFLIP 0x400
+ 	#define V4L2_BUF_FLAG_NEEDS_VFLIP 0x800
+ #endif
+ 
  #define V4L2_MMAP_OFFSET_MAGIC      0xABCDEF00u
  
  static pthread_mutex_t v4l2_open_mutex = PTHREAD_MUTEX_INITIALIZER;
***************
*** 249,254 ****
--- 255,264 ----
      return result;
    }
  
+   // Check for upside down image
+   if ( (buf.flags & V4L2_BUF_FLAG_NEEDS_HFLIP)  &&  (buf.flags & V4L2_BUF_FLAG_NEEDS_VFLIP) ) 
+     devices[index].convert->flags |= V4LCONVERT_ROTATE_180;  else  devices[index].convert->flags &= ~V4LCONVERT_ROTATE_180;
+ 
    devices[index].frame_queued |= 1 << buffer_index;
    return 0;
  }

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: RFC: Where to store camera properties (upside down, needs sw whitebalance, etc). ?

[kilgota]

On Fri, 16 Jan 2009, Olivier Lorin wrote:

<snip>


> Post gamma or white balance correction seemed to be more part of the webcam
> capabilities than the image state so that the new API to get these features
> is quite logical.

Hmmm.

While one is in the process of planning ahead, it it good to think of 
everything. You have not yet seen any code for the sq905c cameras in 
webcam mode, yet. Well, actually, you can if you want to. The needed 
sequence of operations is used in the support for

"gphoto2 --capture-preview"

in libgphoto2/camlibs/digigr8/library.c.

What happens with this camera is, the frame data has been compressed and 
therefore it is needed to know how much data is present for a frame before 
downloading the rest of the frame. The length of the frame header is set 
at 0x50 bytes, so one downloads that first. Here is a sample of one such 
frame header:

0000  ff 00 ff 00 ff 00 ff 00-ff 00 ff 00 ff 00 ff 00  ................
0010  ff 00 ff 00 ff 00 ff 00-ff 00 ff 00 ff 00 ff 00  ................
0020  ff 00 ff 00 ff 00 ff 00-ff 00 ff 00 ff 00 ff 00  ................
0030  ff 00 ff 00 ff 00 ff 00-ff 00 ff 00 ff 00 ff 00  ................
0040  e0 5a 00 00 3b 3e 50 3b-36 00 ff 00 ff 00 ff 00  .Z..;>P;6.......

Now, most of this is just filler. The data size for the frame is to be 
found in bytes 0x40 and 0x41 and it says that 0x5ae0 bytes must be 
downloaded for this frame. I have never seen the next two bytes with 
anything in them, so my reasonable conjecture is that they are similarly 
used, as part of the data size field. It is just that in practice one 
never sees a frame with so much data in it.

Now, my comment here is directed toward bytes 0x44 through 0x48. I do not 
claim to know exactly what they mean. However, I would strongly suspect 
that they have something to do with contrast, color balance, intensity, 
and so on. Really, logic would seem to indicate that there is no other 
point to providing those entries, which certainly do vary from one frame 
to another and the readings in them do seem in some vague sense to have 
something to do with the local light conditions, and sucn.

Therefore, confronted with my experience with these cameras, I would tend 
to suspect that

"Post gamma or white balance correction seemed to be more part of the 
webcam capabilities than the image state"

may not always be the case. For, here, with this camera, it appears that 
some kind of related information is being passed with each individual 
frame. It is also more certainly the case that the camera has no other way 
to pass such information. In particular, there is no long initialization 
sequence. One just turns on the stream.

Theodore Kilgore

Re: RFC: Where to store camera properties (upside down, needs sw whitebalance, etc). ?

[Hans de Goede]

kilgota@banach.math.auburn.edu wrote:
> 
> 
> On Fri, 16 Jan 2009, Olivier Lorin wrote:
> 
> <snip>
> 
> 
>> Post gamma or white balance correction seemed to be more part of the 
>> webcam
>> capabilities than the image state so that the new API to get these 
>> features
>> is quite logical.
> 
> Hmmm.
> 
> While one is in the process of planning ahead, it it good to think of 
> everything. You have not yet seen any code for the sq905c cameras in 
> webcam mode, yet. Well, actually, you can if you want to. The needed 
> sequence of operations is used in the support for
> 
> "gphoto2 --capture-preview"
> 
> in libgphoto2/camlibs/digigr8/library.c.
> 
> What happens with this camera is, the frame data has been compressed and 
> therefore it is needed to know how much data is present for a frame 
> before downloading the rest of the frame. The length of the frame header 
> is set at 0x50 bytes, so one downloads that first. Here is a sample of 
> one such frame header:
> 
> 0000  ff 00 ff 00 ff 00 ff 00-ff 00 ff 00 ff 00 ff 00  ................
> 0010  ff 00 ff 00 ff 00 ff 00-ff 00 ff 00 ff 00 ff 00  ................
> 0020  ff 00 ff 00 ff 00 ff 00-ff 00 ff 00 ff 00 ff 00  ................
> 0030  ff 00 ff 00 ff 00 ff 00-ff 00 ff 00 ff 00 ff 00  ................
> 0040  e0 5a 00 00 3b 3e 50 3b-36 00 ff 00 ff 00 ff 00  .Z..;>P;6.......
> 
> Now, most of this is just filler. The data size for the frame is to be 
> found in bytes 0x40 and 0x41 and it says that 0x5ae0 bytes must be 
> downloaded for this frame. I have never seen the next two bytes with 
> anything in them, so my reasonable conjecture is that they are similarly 
> used, as part of the data size field. It is just that in practice one 
> never sees a frame with so much data in it.
> 
> Now, my comment here is directed toward bytes 0x44 through 0x48. I do 
> not claim to know exactly what they mean. However, I would strongly 
> suspect that they have something to do with contrast, color balance, 
> intensity, and so on. Really, logic would seem to indicate that there is 
> no other point to providing those entries, which certainly do vary from 
> one frame to another and the readings in them do seem in some vague 
> sense to have something to do with the local light conditions, and sucn.
> 
> Therefore, confronted with my experience with these cameras, I would 
> tend to suspect that
> 
> "Post gamma or white balance correction seemed to be more part of the 
> webcam capabilities than the image state"
> 
> may not always be the case. For, here, with this camera, it appears that 
> some kind of related information is being passed with each individual 
> frame.

Yes, we've seen that more often. In this case the solution is simple, since we 
need to do decompression in userspace anyways, just pass the entire frame 
including the header (with the potential interesting bytes) to userspace in the 
frame buffer, then userspace can get that info if it needs to.

A bigger problem is when this happens and the cam generates a standard format 
like jpeg (with an additional header), but we haven't encountered cams like 
this yet, so lets not worry about that for now.

Regards,

Hans
'