From: Hans de Goede <hdegoede@redhat.com>
To: kilgota@banach.math.auburn.edu
Cc: Hans Verkuil <hverkuil@xs4all.nl>,
Adam Baker <linux@baker-net.org.uk>,
linux-media@vger.kernel.org,
Jean-Francois Moine <moinejf@free.fr>,
Olivier Lorin <o.lorin@laposte.net>,
Mauro Carvalho Chehab <mchehab@infradead.org>,
Trent Piepho <xyzzy@speakeasy.org>,
linux-omap@vger.kernel.org
Subject: Re: [RFC] How to pass camera Orientation to userspace
Date: Sun, 22 Feb 2009 19:58:02 +0100 [thread overview]
Message-ID: <49A1A03A.8080303@redhat.com> (raw)
In-Reply-To: <alpine.LNX.2.00.0902221225310.10870@banach.math.auburn.edu>
kilgota@banach.math.auburn.edu wrote:
>
<snip>
> Hans and Adam,
>
> I am not sure how it fits into the above discussion, but perhaps it is
> relevant to point out that flags can be toggled. Here is what I mean:
>
> Suppose that we have two flags 01 and 10 (i.e. 2), and 01 signifies
> VFLIP and 10 signifies HFLIP.
>
> Then for an "ordinary" camera in ordinary position these are initialized
> as 00. If the "ordinary" camera is turned in some funny way (and it is
> possible to know that) then one or both of these flags gets turned off.
>
> But if it is a "funny" camera like some of the SQ905s the initial values
> are 1 and 1, because the sensor is in fact mounted upside down. Now,
> suppose that there is some camera in the future which, just like this,
> has the sensor upside down, and suppose that said hypothetical camera
> also has the ability to "know" that it has been turned over so what was
> upside down is now right side up. Well, all that one has to do is to
> flip the two bits from whatever they were to have instead the opposite
> values!
>
> Observe that this would take care of the orientation problem both for
> cameras which had the sensor mounted right in the first place, and for
> cameras which had the sensor mounted wrong in the first place. Just use
> the same two bits to describe the sensor orientation, and if there is
> any reason (based upon some ability to know that the camera orientation
> is now different) that the orientation should change, then just flip the
> bits as appropriate.
>
> Then it would be the job of the support module to provide proper initial
> values only for these bits, and everything else could be done later on,
> in userspace.
>
> Theodore Kilgore
Theodore,
We want to be able to differentiate between a cam which has its sensor mounted
upside down, and a cam which can be pivotted and happens to be upside down at
the moment, in case of any upside down mounted sensor, we will always want to
compentsate, in case of a pivotting camera wether we compensate or not could be
a user preference.
So in you example of an upside down mounted sensor in a pivotting encasing and
the encasing is pivotted 180 degrees we would have the hflip and vflip bits set
for sensor orientation and we would have the pivotted 180 degrees bit set. If
the user has choosen to compensate for pivotting the default, we would do
nothing. But it is important to be able to differentiate between the 2.
Regards,
Hans
next prev parent reply other threads:[~2009-02-22 19:00 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-18 0:30 [RFC] How to pass camera Orientation to userspace Adam Baker
2009-02-18 2:10 ` DongSoo(Nathaniel) Kim
2009-02-18 14:36 ` Hans de Goede
2009-02-18 20:45 ` Dongsoo Kim
2009-02-21 11:53 ` Hans Verkuil
2009-02-22 11:17 ` Hans de Goede
2009-02-22 11:53 ` Hans Verkuil
2009-02-22 12:21 ` Hans de Goede
2009-02-22 18:42 ` kilgota
2009-02-22 18:58 ` Hans de Goede [this message]
2009-02-22 20:01 ` kilgota
2009-02-22 21:57 ` Hans de Goede
2009-02-22 22:47 ` kilgota
2009-02-22 22:51 ` Trent Piepho
2009-02-22 22:54 ` Hans de Goede
2009-02-22 23:12 ` Trent Piepho
2009-02-22 23:27 ` Hans de Goede
2009-02-23 0:19 ` Trent Piepho
2009-02-23 8:23 ` Hans de Goede
2009-02-22 23:24 ` Hans Verkuil
2009-02-22 23:56 ` Trent Piepho
2009-02-23 7:34 ` Hans Verkuil
2009-02-23 11:30 ` Mauro Carvalho Chehab
2009-02-22 21:46 ` Adam Baker
2009-02-23 11:07 ` Mauro Carvalho Chehab
2009-02-23 22:37 ` Adam Baker
2009-02-24 0:51 ` kilgota
2009-02-24 20:23 ` Mauro Carvalho Chehab
2009-02-25 0:38 ` kilgota
2009-02-25 0:53 ` Mauro Carvalho Chehab
2009-02-25 2:12 ` kilgota
2009-02-25 3:16 ` Mauro Carvalho Chehab
2009-02-25 6:27 ` kilgota
2009-02-25 3:03 ` Thomas Kaiser
2009-02-25 6:19 ` kilgota
2009-02-25 13:11 ` Thomas Kaiser
2009-02-25 7:40 ` Hans de Goede
2009-03-01 23:45 ` [PATCH] libv4lconvert support for SQ905C decompression kilgota
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=49A1A03A.8080303@redhat.com \
--to=hdegoede@redhat.com \
--cc=hverkuil@xs4all.nl \
--cc=kilgota@banach.math.auburn.edu \
--cc=linux-media@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@baker-net.org.uk \
--cc=mchehab@infradead.org \
--cc=moinejf@free.fr \
--cc=o.lorin@laposte.net \
--cc=xyzzy@speakeasy.org \
/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