<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi David, thanks for initiative to bring us all on the same page.</p>
<p>From what I understand, this series aims to do two things:</p>
<p><br>
</p>
<p>1.: Make the public API follow the EXIF specification<br>
</p>
<ol>
</ol>
<p></p>
<p>I personally, having implemented the existing API in Pipewire
and, still pending, the Gstreamer element, am rather neutral on
this, as the new and old values have a bijective relationship. All
I care about that it's easy for apps to transition and support
both APIs for at least a short while.</p>
<p><br>
</p>
<p>2.: Clarifying the expected behavior and fixing existing
inconsistencies.</p>
<p>The main issue with the existing implementation I personally have
been running into, that is fixed by this series, was the returned
Transform value from `validate()`.</p>
<p>To give an example, consider the following two cases:</p>
<ul>
<li>A camera mounted 90 deg rotated, a config requesting
`Transform::Identity`</li>
<li>No camera rotation, a config requesting `Transform::rot90`</li>
</ul>
<p>In the first case (typical for Linux phones like the Pinephone
(Pro) and Librem5) the returned value will be `Transform::rot270`
(IIRC) and the user can use that to adapt the output downstream.</p>
<p>In the second case, the returned value will be
`Transform::Identity` and the user has to remember that it asked
for something different.<br>
</p>
<p>Combining a non-identity mounting rotation and a non-identity
requested transform thus essentially leads to random results and
makes a clean implementation almost impossible.</p>
<p>I personally like the proposed behavior - either you get the
requested result or you have to apply the combined transform
yourself - a lot.</p>
<p>From what I understand there are only two open questions here:</p>
<ol>
<li>Should the sensor do partial transforms?<br>
</li>
<li>Do we really want/need the new `Orientation` enum or
could/should we instead with `Transform` and just update/clarify
the expected results?</li>
</ol>
<p><br>
</p>
<p>Hope you agree that these are the issues to agree on.</p>
<p>Thanks everyone and cheers,</p>
<p>Robert<br>
</p>
<div class="moz-cite-prefix">On 23.06.23 10:26, David Plowman via
libcamera-devel wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAHW6GYJjGDFpdd=DQ34cDhdphMmtPqqedVg7Hn9h7LWdSSvzfA@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">Hi everyone
Thanks for that message. I think it's very helpful to quote the source
documentation:
* The transform is a user-specified 2D plane transform that will be applied
* to the camera images by the processing pipeline before being handed to
* the application. This is subsequent to any transform that is already
* required to fix up any platform-defined rotation.
What this is trying to say, badly, is that the transform you request
is applied after ("subsequent to") fixing up the platform rotation. So
you do indeed get auto-correction. This is also the actual behaviour
of the code on the Pi, has been for, I don't know, nearly 2 years? At
this point, the earth does indeed get my official permission to
swallow me up for not writing something that was less prone to
misinterpretation,
But I think this does leave us in a position where large amounts of
this thread are a mixture of not very helpful or even plain confusing,
and with people's permission, I'd honestly like to start again, with
everyone on the same page.
You might have noticed that "orientations" were really bugging me as
to what they were, and how one could use them. I've managed to resolve
these problems in my own mind and think that there's a very simple
connection between "orientations" and "transforms" that I would be OK
to implement and use. I think our next attempt at this discussion
should start by being clear on our requirements, and then we can look
at how "orientations" and "transforms" can get us there.
(Rest of thread purposefully deleted... hope that's ok!)
Thanks!
David
</pre>
</blockquote>
</body>
</html>