public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Adam Baker <linux@baker-net.org.uk>
To: Hans de Goede <hdegoede@redhat.com>
Cc: kilgota@banach.math.auburn.edu, Hans Verkuil <hverkuil@xs4all.nl>,
	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 21:46:32 +0000	[thread overview]
Message-ID: <200902222146.33136.linux@baker-net.org.uk> (raw)
In-Reply-To: <49A1A03A.8080303@redhat.com>

On Sunday 22 February 2009, Hans de Goede wrote:
> 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.


If we take Olivier Lorin's gl-860 case though, how do we define what is the 
normal orientation and what is pivoted, it is likely we'd just decide the 
direction where the sensor output is the right way up is normal and the other 
is pivoted and then what info have you got from having multiple flags.

In order to explain what I mean it is probably best to refer to rotations in 
terms of pitch, yaw and roll (as per the definitions at 
http://en.wikipedia.org/wiki/Flight_dynamics) where the forward direction is 
the shooting direction.

When still cameras are fitted with gravity sensors they are normally set up 
with the intention of measuring roll and will often get confused by 90 
degrees of pitch. If a laptop is fitted with a camera that can either record 
the user or the view looking away from the user then the camera needs to be 
able to either pitch or yaw but not roll. If the camera yaws then no 
correction is needed but if it pitches then the resulting image needs 
rotating to be the correct way up (and in that scenario it is improbable that 
the user doesn't want the correction applied). Other than the fact that one 
needs correcting and the other doesn't these options appear identical to the 
user and so manufacturers provide one or the other but not both.

If a video camera had a roll sensor (or even, as a believe some specialist 
tripods can manage, a full set of roll, pitch and yaw measurements) then a 
substantially different mechanism is needed to provide access to that data 
but in the absence of anyone having access to such equipment I don't think we 
can design the interface now.

Adam

  parent reply	other threads:[~2009-02-22 21:46 UTC|newest]

Thread overview: 37+ 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
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 [this message]
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

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=200902222146.33136.linux@baker-net.org.uk \
    --to=linux@baker-net.org.uk \
    --cc=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=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