* Re: RFC: Where to store camera properties (upside down, needs sw whitebalance, etc). ?
2009-01-16 11:43 Olivier Lorin
@ 2009-01-16 20:58 ` Adam Baker
0 siblings, 0 replies; 4+ messages in thread
From: Adam Baker @ 2009-01-16 20:58 UTC (permalink / raw
To: video4linux-list, Olivier Lorin, linux-media, Hans de Goede,
kilgota
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: RFC: Where to store camera properties (upside down, needs sw whitebalance, etc). ?
@ 2009-01-16 22:56 Olivier Lorin
2009-01-17 19:02 ` kilgota
0 siblings, 1 reply; 4+ messages in thread
From: Olivier Lorin @ 2009-01-16 22:56 UTC (permalink / raw
To: Adam Baker, video4linux-list, linux-media, Hans de Goede, kilgota
[-- 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: RFC: Where to store camera properties (upside down, needs sw whitebalance, etc). ?
2009-01-16 22:56 RFC: Where to store camera properties (upside down, needs sw whitebalance, etc). ? Olivier Lorin
@ 2009-01-17 19:02 ` kilgota
2009-01-20 10:10 ` Hans de Goede
0 siblings, 1 reply; 4+ messages in thread
From: kilgota @ 2009-01-17 19:02 UTC (permalink / raw
To: Olivier Lorin; +Cc: Adam Baker, video4linux-list, linux-media, Hans de Goede
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: RFC: Where to store camera properties (upside down, needs sw whitebalance, etc). ?
2009-01-17 19:02 ` kilgota
@ 2009-01-20 10:10 ` Hans de Goede
0 siblings, 0 replies; 4+ messages in thread
From: Hans de Goede @ 2009-01-20 10:10 UTC (permalink / raw
To: kilgota
Cc: Olivier Lorin, Adam Baker, video4linux-list, linux-media,
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
'
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-01-20 10:08 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-01-16 22:56 RFC: Where to store camera properties (upside down, needs sw whitebalance, etc). ? Olivier Lorin
2009-01-17 19:02 ` kilgota
2009-01-20 10:10 ` Hans de Goede
-- strict thread matches above, loose matches on Subject: below --
2009-01-16 11:43 Olivier Lorin
2009-01-16 20:58 ` RFC: " Adam Baker
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.