[digikam] [Bug 366391] New: rotating an image seems to forget to reset the orientation flag

[bugzilla_noreply]

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

            Bug ID: 366391
           Summary: rotating an image seems to forget to reset the
                    orientation flag
           Product: digikam
           Version: 5.0.0
          Platform: openSUSE RPMs
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: Import-PostProcessing
          Assignee: [hidden email]
          Reporter: [hidden email]

Whenever I (auto-)rotate images, e.g. by the menu action or during import where
it seems to be done automatically, it looks like the image contents are rotated
but the metadata is not updated (or maybe only in the sidecar file but not in
the image itself). Manually setting the exif Orientation tag to "normal" via
the menu seems to fix the view inside digikam but not for external programs,
e.g. gimp.

Reproducible: Always

Steps to Reproduce:
1. find a jpeg which is rotated by its exif flag
2. rotate in digikam (with the settings above)
3. open the image in e.g. gimp to see the messed-up result

Actual Results:  
rotated image (contents) with the original exif orientation flag inside the jpg
file

Expected Results:  
rotated image (contents) including the exif orientation flag set to "normal"
inside the jpg file

related application settings:
* Metadata -> Rotation -> Rotate by changing the content if possible
* Metadata -> Rotation -> Write flag to metadata if possible
* Metadata -> Behaviour -> Read from sidecar files
* Metadata -> Behaviour -> Write to sidecar files + Write to XMP sidecar only
(* Metadata -> Behaviour -> Use lazy synchronisation OFF)

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

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

--- Comment #1 from Maik Qualmann <[hidden email]> ---
Git commit c4368decf81052e45dcec84833e8697d748dfe7d by Maik Qualmann.
Committed on 04/08/2016 at 17:22.
Pushed by mqualmann into branch 'master'.

move temp sidecar file to image if rotate image

M  +20   -3    libs/jpegutils/jpegutils.cpp

http://commits.kde.org/digikam/c4368decf81052e45dcec84833e8697d748dfe7d

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

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

Maik Qualmann <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Version Fixed In|                            |5.1.0
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |[hidden email]
         Resolution|---                         |FIXED
      Latest Commit|                            |http://commits.kde.org/digi
                   |                            |kam/c4368decf81052e45dcec84
                   |                            |833e8697d748dfe7d

--- Comment #2 from Maik Qualmann <[hidden email]> ---
This commit fix the not updated exif orientation if using sidecar files. With
you metadata settings you write metadatas only to sidecar files. Gimp not read
sidecar files. You must write metadatas for Gimp in the image files. I close
this bug now.

Maik

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

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

Nico Kruber <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
     Ever confirmed|0                           |1
         Resolution|FIXED                       |---

--- Comment #3 from Nico Kruber <[hidden email]> ---
Thank you and yes, I usually do not want digikam to modify the file contents
(so I do not need to backup the jpg over and over again) and hence my settings.
Looks like the temporary (and left-over) jpegrotator...xml files are a thing of
the past, too, after your commit :)

However, the option "Rotate by changing the content if possible" allows the jpg
file to change and implies that the image's metadata in the jpg file is
consistent with the image content itself. Therefore, the metadata in the jpg
file should be changed as well and that was the behaviour in digikam < 5.0.
I know that these two settings somehow contradict each other but I also believe
that the previous behaviour is the most sensible one under these circumstances.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

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

--- Comment #4 from Maik Qualmann <[hidden email]> ---
I do not think that the behavior of digiKam < 5.0.0 was different. I test it
tomorrow with digiKam-4.14.

Maik

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

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

--- Comment #5 from Maik Qualmann <[hidden email]> ---
With digiKam-4.14 the same behavior. Orientation flag is not written in this
case. The bug (now is fixed) with temporary XMP files is also available.

Gilles, what do you think? Should the orientation flag be changed in the
metadata, if the option is enabled that all changes only write to sidecar
files?

Maik

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

[bugzilla_noreply]

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

[hidden email] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #6 from [hidden email] ---
>Gilles, what do you think? Should the orientation flag be changed in the metadata, if the option is enabled that all changes only write to sidecar files?

Typically, no. If only sidecar must be touched (through metadata settings),
well only sidecar must be changed. Some users want to not touch the image file
and delegate to sidecar all metadata changes.

Gilles

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

[bugzilla_noreply]

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

--- Comment #7 from Nico Kruber <[hidden email]> ---
(In reply to caulier.gilles from comment #6)
> >Gilles, what do you think? Should the orientation flag be changed in the metadata, if the option is enabled that all changes only write to sidecar files?
>
> Typically, no. If only sidecar must be touched (through metadata settings),
> well only sidecar must be changed. Some users want to not touch the image
> file and delegate to sidecar all metadata changes.

this bug is not about whether the orientation flag should be changed in the
image when metadata should only be written to sidecar files but whether the
orientation flag should be changed in the image when the user selects to
"Rotate by changing the content if possible" AND decided to write metadata to
sidecar files only (which kind of contradict)

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

[bugzilla_noreply]

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

--- Comment #8 from Nico Kruber <[hidden email]> ---
(In reply to Maik Qualmann from comment #5)
> With digiKam-4.14 the same behavior. Orientation flag is not written in this
> case.

I guess you are right - although I remembered differently, I verified the same
behaviour with digikam (and kipi) 4.14, 4.6 and 4.3 on my side. I can't test
any older version here but think that my setup was once working.
Note that with these three versions, after auto-rotating the file and
re-reading their metadata (with the "Read from sidecar files" option set), all
are rotated wrongly in the UI but I guess this is due to the left-over
"JpegRotator-XM****.digikamtempfile.jpg.xmp" file which is the only file that
has the new orientation flag set and is now (hopefully) correctly integrated
into the right xmp file :)

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

[bugzilla_noreply]

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

--- Comment #9 from [hidden email] ---
Problem still reproducible using current DK 5.4.0 bundle ?

https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM

Gilles Caulier

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

[bugzilla_noreply]

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

--- Comment #10 from [hidden email] ---
Can you reproduce the problem using digiKam Linux AppImage bundle ? The last
bundle is available at this url:

https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM

Gilles Caulier

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

[bugzilla_noreply]

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

--- Comment #11 from Nico Kruber <[hidden email]> ---
with the 5.4.0 package from 22/12/2016:
* using auto-rotate does not touch the jpg file at all but only seems to set
the orientation flag in digikam's DB and thus the file is shown in the wrong
orientation in digikam itself. (this is some other bug, I guess)
* using rotate left/right the file's content is rotated but the exif data in
the jpg is not changed (only in the sidecar file). It is shown correctly in
Digikam but is wrong in programs only using the exif data from the jpg.

Please let me sum up my desired change: the content of the file needs to be
consistent with the exif data in the file, so if the content is changed, e.g.
by allowing rotation, there is no point in not changing the metadata along with
it, despite the setting of where to save metadata.

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