| Summary: | Many Problem with Editor "Save As..." | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | DGardner <damien> |
| Component: | ImageEditor-Save | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | caulier.gilles, languitar, marcel.wiesweg |
| Priority: | NOR | ||
| Version First Reported In: | 1.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | 2.0.0 | |
| Sentry Crash Report: | |||
Issue 1 is fixed in current trunk. The last used extension is used now. 2: in the editor's thumbbar or in the thumbnail view window? 3: Cannot reproduce here. 4: Do you have an example file opening in the wrong orientation? 2. The file names are duplicated in the "New Image File Name - digiKam"
dialog box (opened from the "Save As" tool-bar button in the Editor).
3 & 4. I think these are related. While I was typing this comment I
did the following....
a) Started digiKam.
b) Imported some new photos (by copying into an album folder from
the command-line).
c) Checked that a portrait photo (a tree) was displayed correctly.
in the preview window. It was OK.
d) Opened that photo in the Editor. The orientation was OK.
e) Set the rating on the photo.
f) Opened it in the preview window. The orientation was OK.
g) Opened it in the editor. The orientation was WRONG.
h) When I switched back to the preview window, the photo was
oriented in landscape but was clipped within the same portrait
bounding box that was used before I opened the editor. Note
that I did nothing in this window other than switch back to it
from the editor.
j) I switched to the editor, applied "Auto Levels", and selected
"Save As". The dialog had duplicated file name and the extension
was "jpeg" instead of "jpg". I gave the file a new name.
k) I switched back to the preview window (again, I did nothing to
it) and the image was back in the correct orientation. The
thumbnail bar showed the thumbnail for the original image and
the thumbnail for the new image. There was no difference (and
the "Auto Levels" should have been obvious).
l) I closed the editor.
m) In the preview window, I (portrait) selected the thumbnail for
the newly created file and the preview image was shown with
landscape orientation.
n) I selected the thumbnail for the original image and I was back
to step g): wrong in the editor, clipped in the preview.
o) In the preview window, I selected another image and then went
back to the original tree image. The clipping was fixed.
p) I exited digiKam and started it again. The thumbnails for both
tree images were no correct, inasmuch as they showed the original
and edited images. However, the orientation of the new image was
wrong (as it was in the editor).
q) I selected the original image for preview and then opened it in
the editor. I was back to g) again.
I used "exiftool -G" to examine the images. The original image
reports these settings (the camera is a Canon EOS 50D):
[EXIF] Orientation : Rotate 270 CW
[MakerNotes] Camera Orientation : Rotate 270 CW
Those setting were the same before and after rating the image.
The edited image reports:
[EXIF] Orientation : Horizontal (normal)
[MakerNotes] Camera Orientation : Rotate 270 CW
In the SQLite database, the orientation of both images is
recorded as "8" in the "ImageInformation" table.
Sorry, in "p)", it should read "now correct", not "no correct". Can you provide a sample picture with which this problem happens? If it's too large to attach here, you can send it by private mail. In the settings, do you have switched on to write ratings to the metadata? In which window and in which way to you assign the rating in step e)? In step e), I was in the preview window (the nearly full screen view of the image with the thumbnail bar on the left). I cannot remember now if I set the rating by clicking on the stars on the thumbnail within the thumbnail bar to the left of the preview window or by hitting "Ctrl+[1-5]" while previewing the image. It would have been one of those two, as I don't know any other way to set it from the preview window. I have the setting to write metadata to the image files turned on. Is there a separate setting to write the rating? (I haven't got digiKam in front of me at present.) I'll see if I can get an image that can be used to reproduce this and get back to you. Ok, the image editor saving code has structurally changed for 2.0, so this very old bug is no longer applicable. Feel free to report any new defects you encounter, preferably with 2.0 and KDE 4.5 |
Version: 1.0.0-rc1 (using KDE 4.3.4) OS: Linux Installed from: Ubuntu Packages I'm having a lot of problems with the "Save As..." option in the Editor in RC1: 1. If I edit "x.jpg", the "Save As" dialog defaults to the name "x.jpeg", which is not the same file extension as the original file. It did give the correct ".jpg" extension for the first file I edited, but for every file after that, the extension offered was ".jpeg", which to my mind is wrong. Every time I use "Save As..." I have to rename the file and fix the extension, too. 2. In the list of existing files in the current folder, the file names appear twice. If I select the parent folder and then select the original child folder again, the file names are no longer duplicated. 3. When I save "x.jpg" to "x2.jpg", back in the thumbnail view the thumbnail for "x.jpg" is the same as that for "x2.jpg". I have to do something to modify the file such as set a tag (I have metadata modification time stamp updates turned on) to make the thumbnail get refreshed. (I'm viewing the results of a search, if that makes a difference.) 4. Some portrait images (and they are displayed as such in the thumbnail view) are opening in landscape in the Editor. When I save them as new files, the thumbnail shows the original portrait image, but viewing the image shows it to be still in landscape orientation after editing it. This happened a few times and then stopped happening, even when editing the same (original) image again that first opened in landscape. The reversion to the correct behaviour seemed to coincide with the change from ".jpg" to ".jpeg" extensions in the "Save As" dialog.