[vlc-devel] [PATCH 3/12] esformat: fix ORIENT_LEFT_BOTTOM and ORIENT_RIGHT_TOP descriptions

[Lyndon Brown]

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