Bug 276708 - Allow to explicitly overwrite the original with versioning
Summary: Allow to explicitly overwrite the original with versioning
Status: RESOLVED DUPLICATE of bug 271672
Alias: None
Product: digikam
Classification: Applications
Component: Setup-ImageEditor (show other bugs)
Version: 2.0.0
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-28 18:38 UTC by Frederic Grelot
Modified: 2023-05-27 07:50 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frederic Grelot 2011-06-28 18:38:27 UTC
Version:           2.0.0 (using KDE 4.6.4) 
OS:                Linux

I just installed version 2.0.0-rc of digikam, I am surprised to se that if, in the editor view, I edit an image and chose "Save change" in the save dialog, the changes are saved as *_v1.jpg instead of overwriting the original file

Reproducible: Always

Steps to Reproduce:
-Open an image in editor view
-activate the "Thumbbar"
-Use Transform/rotate Right
-Select another image in the Thumbbar
-In the dialog that shows up, click "Save changes"

Actual Results:  
A new image with "_v1" appears in the same directory as original image

Expected Results:  
The original image should get overwritten

OS: Linux (x86_64) release 2.6.38.8-32.fc15.x86_64
Compiler: gcc

Version : digikam 2.0.0-rc from git (checked out from tag)
Comment 1 caulier.gilles 2011-06-29 06:57:59 UTC
Disable Image Versionning (or tune it) in setup dialog and all must be fine.

Gilles Caulier
Comment 2 Frederic Grelot 2011-06-29 07:11:06 UTC
I'll do that.
But still, I think that it is not incompatible. In my case, the modification was just about rotating the image (which was not automatically rotated, strange by the way...), and thus I didn't want to keep the original image.
If i use the "Save changes" instead of "Save change as new version" (I had both choices, so that was deliberate), even with versionning enabled, I think that the label is pretty clear and that the old name should be used...

I think that versionning is a very good new feature, but sometimes (like in my case), one may want to overwrite the old picture regardless of the default preference...
Comment 3 Marcel Wiesweg 2011-07-11 18:19:30 UTC
if you have a JPG image, and rotate it in the Image Editor, you have a lossy operation and an indication to preserve the original.
Rotate it with jpeglossless, and it's not recorded in the history (which may be regarded as a lack of support in the plugin, but it's at least a lossless operation)
Comment 4 Marcel Wiesweg 2011-07-11 18:21:21 UTC
See #271672 for a wish to, among other, keep the current version always with the original file name and store away the original and intermediates at a different filename
Comment 5 Frederic Grelot 2011-07-11 21:07:42 UTC
>if you have a JPG image, and rotate it in the Image Editor, you have a lossy
>operation and an indication to preserve the original.
>Rotate it with jpeglossless, and it's not recorded in the history (which may be
>regarded as a lack of support in the plugin, but it's at least a lossless
>operation)

Well, what I found is that : if I use "Image/rotate/Left or right"  in album view, it's ok, the file gets overwritten. But if I use the editor, I have no choice but to use the "Save change" button, and this actually creates a new file while I didn't want to, and I don't want to disable versionning : is there no easy way to actually force overwriting of the image?? File/Export, then select the original seems to be the only solution... I really think it's an-natural...
Comment 6 RSB 2011-11-04 16:28:31 UTC
Same here. Sometimes I want to have one or more copies (e.g. when doing many different and large modifications). But often I want to do only a litle correction and don't need it saved as a new version. It's annoying to delete all the original images and to rename the new versions.
Comment 7 caulier.gilles 2011-12-18 17:33:36 UTC
Frederic,

This file still valid using digiKam 2.4 ?

Gilles Caulier
Comment 8 caulier.gilles 2012-09-11 19:54:43 UTC
Frederic,

This file still valid with 2.9.0 ?

Gilles Caulier
Comment 9 RSB 2012-09-11 22:44:28 UTC
this bug is valid for 2.9.0
Comment 10 caulier.gilles 2015-07-01 06:04:23 UTC
New digiKam 4.11.0 is available :

https://www.digikam.org/node/740

Can you reproduce the problem with this release ?
Comment 11 caulier.gilles 2015-08-22 06:37:00 UTC
digiKam 4.12.0 is out :

https://www.digikam.org/node/741

We need a fresh feedback using this release please...
Thanks in advance.
Comment 12 caulier.gilles 2016-07-15 21:25:41 UTC
Frederic, 

This file still valid  using last digiKam 5.0.0 ?

Gilles Caulier
Comment 13 caulier.gilles 2016-11-26 10:34:27 UTC
This problem still reproducible using digiKam AppImage bundle 5.4.0 pre release
?

It available at this url :

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

Gilles Caulier
Comment 14 caulier.gilles 2017-04-16 20:12:09 UTC
digiKam 5.5.0 is released officially

https://download.kde.org/stable/digikam/

...and new 5.6.0 pre-release as bundle is available here :

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

Please check if this problem still reproducible with these versions.

Thanks in advance

Gilles Caulier
Comment 15 caulier.gilles 2017-06-22 21:39:37 UTC
digiKam 5.6.0 is now release and available as bundle for Linux, MacOS and Windows.

Can you check if problem still exists with this version ?

Thanks in advance

Gilles Caulier
Comment 16 caulier.gilles 2017-11-30 09:31:09 UTC
Please update this entry from bugzilla with current 5.8.0 pre-release bundle to see if problem remain.

https://files.kde.org/digikam/

Thanks in advance

Gilles Caulier
Comment 17 caulier.gilles 2018-12-31 11:40:46 UTC
Can you reproduce the dysfunction using the last digiKam 6.0.0-beta3 just released ?

https://www.digikam.org/news/2018-12-30-6.0.0-beta3_release_announcement/

Gilles Caulier
Comment 18 caulier.gilles 2023-05-27 07:50:58 UTC

*** This bug has been marked as a duplicate of bug 271672 ***