[vlc-devel] [PATCH 3/12] esformat: fix ORIENT_LEFT_BOTTOM and ORIENT_RIGHT_TOP descriptions
Romain Vimont
rom1v at videolabs.io
Sun Sep 27 12:52:15 CEST 2020
Hi,
There are so many conventions involved in video_orientation_t, each one
reversing the global interpretation:
- orientation applied VS to be applied
- top/left mapped to XXX/YYY: from capture to stored VS from stored to
captured
- ORIENT_ROTATED_90: CCW vs CW
- orientation of the scene VS orientation of the camera capturing the
scene
- ...
Each one should be clearly documented and defined without ambiguities.
Without that, we cannot say whether "rotated 90 clockwise" is wrong or
right: what is rotated compared to what? Just reverse the interpretation
of an odd number of steps to get the opposite result.
I am not sure without further investigations in the codebase which ones
are actually used in VLC. If it's clear to you, would you like
documenting precisely these conventions in video_orientation_t, please?
Thank you,
Regards
On Sun, Sep 27, 2020 at 04:04:57AM +0100, Lyndon Brown wrote:
> On Sat, 2020-09-26 at 23:42 +0200, Romain Vimont wrote:
> > On Sat, Sep 26, 2020 at 08:17:42PM +0300, Rémi Denis-Courmont wrote:
> > > Le lauantaina 26. syyskuuta 2020, 19.48.21 EEST Romain Vimont a
> > > écrit :
> > > > What is the meaning of ORIENT_XXX_YYY?
> > >
> > > Names are the same as in EXIF.
> >
> > http://jpegclub.org/exif_orientation.html
> > https://web.archive.org/web/20080106081516/http://park2.wakwak.com/~tsuruzoh/Computer/Digicams/exif-e.html#IFD0Tags
> >
> > > +-------+------------+------------+
> > > > Value | 0th Row | 0th Column |
> > > +-------+------------+------------+
> > > > ... | | |
> > > > 6 | right side | top |
> > > > ... | | |
> > > +-------+------------+------------+
> > >
> > > Entry #6 in the table says that the 0th row in the stored image is
> > > the
> > > right side of the captured scene, and the 0th column in the stored
> > > image is the top side of the captured scene.
> >
> > So IIUC, following that logic, ORIENT_LEFT_BOTTOM means:
> >
> > captured stored displayed
> > A---B D---A A---B
> > | | ---> | | ---> | |
> > D---C C---B D---C
> >
> > The first row in the stored image (D-A) is the left side of the
> > captured
> > image, and the first column (D-C) in the stored image is the bottom
> > side
> > of the captured image.
>
> I think that's perfectly correct, and I can understand your example
> better now.
>
> Put another way, using their example of 'F', though it might be helpful
> to imagine taking a person's photo instead, if you're facing this
> object/subject:
>
> 888888
> 88
> 8888
> 88
> 88
>
> ... and take a photo with your camera held "upright", i.e. in "normal"
> landscape orientation, this would be framed as follows in the
> viewfinder, stored this pixel grid form, and similarly displayed later
> on screen the same way:
>
> ------------------
> | 888888 |
> | 88 |
> | 8888 |
> | 88 |
> | 88 |
> ------------------
>
> If instead you rotate your camera 90 degrees clockwise into (one of two
> forms of) "portrait" mode, you naturally see this in your camera's
> viewfinder (standing normally, no tilting your head):
>
> ----------
> | |
> | 888888 |
> | 88 |
> | 8888 |
> | 88 |
> | 88 |
> | |
> ----------
>
> ... which is stored by the camera as:
>
> ------------------
> | |
> | 88 |
> | 88 88 |
> | 8888888888 |
> | |
> ------------------
>
> ... since of course the image sensor data just maps to the pixel grid
> without any concern/knowledge of camera orientation I'd guess.
>
> ... with the camera optionally recording that it had been rotated 90
> degrees clockwise when the picture was captured, to assist with
> displaying it the right way up later. (The documentation is very clear
> that the EXIF orientation property represents the orientation of the
> camera, not how the picture differs from the orientation of the scene,
> which would be the opposite rotation).
>
> If we then consider the picture in terms of the pixel-grid, row-0
> (topmost) corresponds to the right edge of the captured scene and col-0
> (leftmost) the top edge, i.e. the top-edge of the camera had been moved
> to where its right edge was, and its left edge had been moved to where
> its top edge was, i.e. ORIENT_RIGHT_TOP (top->right, left->top), i.e.
> camera had 90 degrees clockwise rotation.
>
> A program just showing it like that (landscape) is obviously not
> necessarily satisfactory, and could take the camera orientation
> attribute into account, to automatically re-orient the displayed
> picture to be "upright". (E.g. showing the portrait photo of a person
> upright rather than on its side).
>
> Thus here ORIENT_RIGHT_TOP meaning the camera was 90 degrees clockwise
> rotated, means that we happen to need to apply the same adjustment, a
> 90 degrees clockwise rotation, to thus display it as:
>
> ----------
> | |
> | 888888 |
> | 88 |
> | 8888 |
> | 88 |
> | 88 |
> | |
> ----------
>
> ... on the screen.
>
> Thus in those terms, if video_orientation_t is used to express the
> orientation (rotation) status of the camera that captured the related
> picture/video, clearly ORIENT_RIGHT_TOP should be clockwise and
> ORIENT_LEFT_BOTTOM should be anti-clockwise, exactly as amended.
>
> Though of course auto-correction of orientation isn't always ideal;
> Imagine deliberately taking an upside-down picture, only for your
> picture viewing app to auto-rotate it to the right way up... The doc
> also notes that the attribute can be unreliably set.
>
> I was initially confused about why there are 8 sets of orientations
> listed rather than 4 when it's talking about cameras, since how can
> anything other than rotation on the one axis apply with a camera? But
> it does also mention adjustments being made via menus, which presumably
> would be applied to the captured image by the camera as though the
> camera had physically been put into such an orientation, with only four
> actually being physically possible.
>
> > > [video_orientation_t] represents how the the orientation of the
> > > encoded image.
> >
> > Therefore, ORIENT_LEFT_BOTTOM corresponds to "rotated 90 degrees
> > clockwise" (the stored image is the captured image rotated by 90 CW),
> > doesn't it?
>
> In other words you're describing now the movement (diff) from scene
> ("upright") to that of the stored ("on it's side") picture... no. The
> orientation, per the docs pointed to, is the diff from scene to camera
> orientation.
>
> With that said, it's been 1.5 years since I originally did this work,
> and I'm now second guessing myself as to whether I was looking at other
> portions of it (unit test and transform calc fix) from the right
> perspective. I better go take another look at that...
>
> > Regards
> > _______________________________________________
> > vlc-devel mailing list
> > To unsubscribe or modify your subscription options:
> > https://mailman.videolan.org/listinfo/vlc-devel
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
More information about the vlc-devel
mailing list