[Digikam-devel] [digikam] [Bug 344155] Rotating raw image sometimes results in the preview showing the photo rotated in the opposite direction [patch]

[Marcel Wiesweg]

https://bugs.kde.org/show_bug.cgi?id=344155

--- Comment #7 from Marcel Wiesweg <marcel.wiesweg at gmx.de> ---
My comment is about the original problem and the patch from comment 1:

The complexity has already been explained by Gilles. Another component of the
problem is that libraw/dcraw does some intransparent magic of its own and gives
us the data readily rotated. Which means that we never know in how far the
rotation flags that we can read were actually put in use (maybe the information
was taken from some makernotes, or other special knowledge).

Which means that we read a rotation flag via exiv2, and libraw may use another
value.

Second part of the problem is that we support "virtual rotation" for RAWs,
which means that when rotating in digikam, the flag in digikam's db is changed,
but we cannot change the flag in the raw file (because metadata writing to RAWs
is not universally supported, and the complexity of the file formats would make
it difficult to find the right flag for all formats.
That's the intention of the patched code: Normally, digikam's database contains
the exiv2-read rotation value. If we detect that the current code in the
database is different, the user must have applied an operation, and this
operation B is computed from A and C.

One possible solution was if we would read the rotation flag via libraw instead
of exiv2, or see that the two information source gave the same results.
The second problem is that the thumbnail may have a different rotation than the
main data. I dont know, we must with several formats and see for each single
format where the problem lies.

(In addition I put forward - I'm not a mathematician, so please correct my
equations if necessary - that mathematically, the proposal is not correct. 
We have A*B = C. 
By multiplication from the left with A_inv, we get
<=> A_inv*A*B = A_inv *C
<=> I * B = A_inv * C
<=> B = A_inv * C

Assume the proposed "B=C_inv*A" was correct:
B = C_inv*A
<=> C*B = C*C_inv*A
<=> C*B = A
<=> C*B*B_inv = A*B_inv
<=> C = A*B_inv
which is true only if B=B_inv, or B*B_inv = I, which is not true for rotate90
for example.
)

-- 
You are receiving this mail because:
You are the assignee for the bug.