This issue bit me too :(

The image editor does warn you when you exit without saving, but it does not warn you when you overwrite your original photograph...

Instead of additional (and most often annoying) dialogs, wouldn't it be better if digikam would never touch the original image and instead create a new version? For example, pic.jpg would be the original (and should never be touched) and the modified version would be called pic-modified.jpg. Then there would always be the possibility to revert the image to its original state.

The more I want to actually fix my images, the more frustrated I become by the current digikam behavior. There's no way I'm going to overwrite my original pics. Unfortunately digikam doesn't handle backup copies at all. Right now it's a complete nightmare to have a backup copy (which obviously should have the same comments and tags as the modified image). Currently, I always make a copy of my originial pic. (This copies metadata too.) Then I modify the copy. But there's still the problem of keeping the metadata in sync.

The only way digikam's image editor can become useful is proper version handling by digikam. Here's what I'd like to see:
- digikam never ever touches the original image.
- modifications are done on a (single) copy.
- both images are kept in sync. (metadata)
- they are also moved or copied together as one logical picture.
- by default digikam only shows the retouched copies
- optionally it also shows the original
- the modified image is given a special name (like "origname_modified.jpeg")
  and stored in the same folder as the original.

This is somewhat similar to Apple's iphoto. IIRC iphoto never asks to save the modifications (which is bad), but always keeps a backup copy and allows to revert to the original state. IMO completely hiding the original is a bad idea. Hence my proposal above.

*** This bug has been confirmed by popular vote. ***

Hm, I'm not sure wether I would like to hide the original picture and (optionally) shows only the rethouched one.

Here, I'm using digiam as my picture manager (cataloque) which show all picture I have (not just picture taken by camera, but also pictures made via some graphical tool) just like Picasa. In my case showing only the retouched one would be non sense, I would never want it. Picture is a picture, and they cannot represented by  each other even though they came from the same source or just differ in the filenaming (IMHO). Okay, let's say I can turn this feature on or off, let'so to case number #2

Case #2. What would typical digikam users assume when he/she use digikam? Will they know that digikam will hide their original picture and shows them only the retouched one? This lead me into a question of what digikam purposes are and how we define digikam.

Tackle those issues above in a sensical manner (think about usability) and I will agree with the bug. Otherwise, vote-- :D

I agree with the comments by Gilles Schintgen, it would be very usefull if digikam always keep a copy of the original image (expect for lossless rotation).

Then we would get a "Undo all modifications" button.

It would be even better if digikam could save the sequence of modifications which have be made to the original picture. Digikam would keep the original picture, the fully modified picture and the sequence of modifications.

This way it is possible to have some undo feature without using too much disk space. To perfom some undo action Digikam would just replay some part of the sequence of modificatoins on the original image.

For instance if I

- import a picture img_001.raw
- crop to 800*600
- add border
- perform red eye correction
- translate to jpeg

Digikam would keep img_001.raw, and img_001_modifed.jpg and [crop(800,600);add_border(black_border 80);red_eye(some coordinates ...);translate_to_jpeg(quality 80)]

Now I could undo the last two modifications, to do that Digikam would replay the first two modifications on the original image.

We could also imagine that we can get a window displaying all the modifications which have been done, and we can reorder the modifications, delete some steps, etc ...

Digikam rocks !

 

at #6: this far to complicated imho, only <10% of the users would use something like that. Even Photoshop can not reorder the history afaict. I can understand the  #0 request, but this goes to far, imho. 

Ok having the ability to reorder modifications is a bit complicated :-).
But if you forgot about reordering  what I propose is not very complicated from the user point of view (it's just an undo, redo feature !).
I agree it is hard to implement of course.

An other solution could be to just warn the user that the image has changed and propose to overwrite or to save under a new name which is automatically incremented from the image name. This is easier to implement.

Another very important consideration is compatibility with external image editors like Gimp. There should be a possibility to tell digikam that some new picture is actually a modified version of another picture. I think it's important to leave the user in control as fas as possible.

I think it will complicate matters in a way that it is inpossible to satisfy everyone. So someone edits it in gimp, then edits it in digikam. What should we do then, protect the original image (before gimp) or the modified one (after gimp). I can tell you there will be a bug where a user screams: "hey, my modification in gimp cost me ages, now i reverted to the original image and now my gimp work is lost. I'll keep #0 in mind, butthe rest not, maybe another developer wants to work on this, you never know.

Hey,

I submitted a similar bug a while ago. (or was it just on IRC? Can't find the bug ...)

I think this feature is really needed, but it can be kept as simple as possible. No need to save a complete editing history. The only thing that matters is to keep the original.

Suggestion:

- Let Digikam assume that pictures are not edited outside Digikam. There is no way for Digikam to know, and no user would expect Digikam to handle this.

- Upon calling an external editor from within Digikam, Digikam saves a backup copy of the file in .kde/share/apps/digikam/originals/originalfilename_md5(originalfile).extension. (To keep the name simple and outside the album tree, and to avoid collisions.) Or, if you want to keep you originals with the album, use albumpath/.digikam_originals where this path can be appended with some random chars (eg. ".digikam_originals_5ab3") if it already exists.

- When the external editor finishes, Digikam compares the backup with the original and if both are still identical, deletes the backup. If not, keep the backup.

- If an internal editor is called, we can just put the save_backup procedure I described in the internal editor's "Save" function.

- If a backup for a file exists (this can be cached in the database), provide a "Revert to Original" context menu item, and - perhaps - mark the image with a small image of a pen in one corner, so that it shows that it's been edited. The context menu item will just copy the original file over the current one.


Does this sound feasible?


Thanks!

Jens

> Or, if you want to keep you originals with the album, use
> albumpath/.digikam_originals

IMHO this would be *much* better. Otherwise you'll run the risk of losing your 
originals. I'd even say that digikam could store a file 
"albumpath/originals/.digikamoriginals" and _not_ hide the originals folder. 
(This file would then indicate to digikam that these pictures are the 
originals.)  This would make it easier to access the originals from within 
konqueror. I hate having important personal data stored as hidden files or 
directories.

All in all, I like your proposal. But I'm not one of the developers...

Gilles Schintgen

We have two alternatives:
1) Do not touch an original image
2) Do not overwrite a file that exists without checks

to 1)
This is noble but hard to implement. You need versioning, you have to define whats an original. Only a e.g. RAW-file or also other images in the process chain? One way to work this way is that there is maximum only one working copy of every image in digiKams file tree. This way you can use the "revert"-command not only during one IE session but also in albumview on every "open"-type command. And you need a new explicit "drop original" command making the workimage the new original. Of course the albumview shows only the working copy and may a different frame color or RMB->"open original" indicates that there is still an original image behind. This concept could work but needs modification on how images are managed for sure to the database level!

to 2) This is my concept. I want to change an image with the IE and external programs. I know digikam can not take care of changes I did in external programs but it should take care on anything I do in the IE.
Today you can open an image in the IE resize and click on "save". And now there has to come a warning, a reminder or a notice. And this does not happen - you loose your original data. Or my old mistake: open a jpeg makeing very small changes and press save, but having a digikam JPEG quality of 65% case last time I save for web :-/ I reconfigure IE that I disable every "save" action and use "save as" as default. BTW I also droped the "revert"-Action from my toolbar cause undo/redo works very well.

So as I suggest in #0 I'm fine when digiKam takes care and protects the
- metadata,
- imagesize and
- imagequality (== filesize)
of photos.
Protection does not means annoying pop up warning. There could be an informative save dialog showing
- filename and type
- old and new filesize,
- old and new image geometry,
- an option to save metadata also indicating if metadata are there,
- an option to save embedded preview,
- configured but also changeable compression setting for supported filetype
every time I press on "save".

Bye

  Thorsten       

On Sunday 04 September 2005 12:41, Thorsten Schnebeck wrote:
> We have two alternatives:
> 1) Do not touch an original image
> 2) Do not overwrite a file that exists without checks

Perhaps 2) could be implemented as a quick and easy solution, and a more 
complete solution like 1) at a later time.
IMHO, digikam 0.8 should at least show a warning before saving.

Gilles

Am Sonntag, 4. September 2005 12:41 schrieb Thorsten Schnebeck:

> to 1)
> This is noble but hard to implement. You need versioning, you have to
> define whats an original. Only a e.g. RAW-file or also other images in
> the process chain?


Again: JUST the FIRST image. No others. Everything else is too complicated.

What is an "original"? Simple: An original is an image that has no 
equivalent in ".digikamoriginals". Where "equivalent" can e.g. be 
md5sum(filepath_relative_to_album_root) to ensure uniqueness.

> One way to work this way is that there is maximum 
> only one working copy of every image in digiKams file tree. This way you
> can use the "revert"-command not only during one IE session but also in


What's an "IE" session?

> albumview on every "open"-type command. And you need a new explicit
> "drop original" command making the workimage the new original. Of course
> the albumview shows only the working copy and may a different frame
> color or RMB->"open original" indicates that there is still an original
> image behind. This concept could work but needs modification on how
> images are managed for sure to the database level!


I'm not sure this is the case.  The original images do not need to be 
included in the Digikam database and I would not want them to be shown (by 
default, anyway).

What would be needed is:

- check for original on modifications (see above)
- if none exists, save one before saving modifications
- if one exists, provide three context menus like
	Original -> Revert / Delete / Open

My additional wish would be, to be able to combine several pics to be the 
original of one. So I can save panoramas that I glued together and mark 
all seperat images as "original" and they vanish in the originals folder. 
But this can wait and would really need a DB change. ;)

> to 2) This is my concept. I want to change an image with the IE and
> external programs. I know digikam can not take care of changes I did in
> external programs but it should take care on anything I do in the IE.


Yes! Well, actually it should be able to watch the album tree via FAM and 
when a file gets opened for read-write, it could automatically open it for 
read-only, so that it keeps the current version. When the file gets 
changed, Digikam could automagically save the old copy. But I guess that's 
quite a bit of work.

> Today you can open an image in the IE resize and click on "save". And
> now there has to come a warning, a reminder or a notice. And this does


Yes, absolutely!

> What's an "IE" session?

Sorry!
IE -> ImageEditor :-)

Bye
 
  Thorsten
 

For reference, here is how the F-Spot (http://www.gnome.org/projects/f-spot/) version management works:

1) You can never edit the original image -- any initial edit creates a new "Image1234 (Modified).jpg" file.

2) The "Modified" version gets overwritten by subsequent edits, but the user can also manually choose to create new named versions.

3) Only one of the versions of an image is active -- meaning it is the one that is affected by edits and also the only one that is shown in the album view. This allows you to edit images and to preserve the originals, all while not cluttering your album. The user may select which version is to be the active one.

4) To revert to the original, just select that version to be active. (File->Version->Original). The modified version is kept. If you now edit the image again, a new version "Modified (2)" is automatically created so that the previous version ("Modified") is not overwritten.

5) The user can delete or rename a version of a file, but not the original. (Of course images can be completely deleted, but not from the version-related menu.)

In my opinion this is a very nice functionality; the user may never be aware that there is any version management going on until the day when she realizes that she just accidentally destroyed an important picture, desperately searches through the menus for a cure and to her delight finds that the original picture is sitting right there, under File->Version->Original.

An additional functionality, which should be easy to implement would be to keep track of the parent of each image version, so that revisions can be presented in a tree-like fashion.

Here is an radical, possibly stupid, suggestion. What about implementing transparent version management using ioslaves? The advantage would be that any KDE program could use it -- and need not even be aware of it.

Implementation 1: (If digiKam only allowed it, this would work today I think)

Have your Pictures directory be a "webdav:" URL that points to an  Apache/mod_dav_svn server with Autoversioning turned on. Now it should appear to digiKam that there is no version control going on, but in fact each "save" generates a new version in the server repository. Add some awareness to digiKam about how to access an old version of an image and there you have it -- full-blown version management support.

Implementation 2:

Create an ioslave that works the same way as above, except for a local subversion repository. File operations would be translated into "svn" calls. Now the Pictures directory would be "local-svn:/home/user/repository", where /home/user/repository is a subversion repository.

Implementation 3:

Create an ioslave that adds version control to any directory; saving a file through the ioslave would also copy the old version to a hidden directory. The Pictures directory would be "vc-wrapper:~Pictures". Alternatively, this could be implemented by using a separate repository and having the local directory as a working copy; however that would duplicate all the data.

--

All of the above might lead to huge storage demands for the different image versions. However, subversion stores diffs efficiently (even though JPEG compression might screw that up) and most users probably don't edit their pictures that much compared to how many new pictures they add. Nevertheless, some mechanism to delete old versions would be needed.

transparent version management using ioslaves sounds promising but at least for me it's not what I would need in digikam. 
For digikam I think it would be sufficient to keep one original file i.e. only the first modification would create a copy.

Am Dienstag, 6. September 2005 18:27 schrieb Martin Rehn:

> For reference, here is how the F-Spot
> (http://www.gnome.org/projects/f-spot/) version management works:


(...)

Yes!

I like this. I don't need full blown version management either. I want to 
retain the original, and the idea of being able to set pictures as 
"active" and "inactive". This way, when I create a panorama (single image) 
out of 8 or 10 seperate images I can set all those as "inactive" and need 
not worry about them appearing in dynamic folders, search results, 
slideshows, etc.

Of course, one can probably use tags for this and always exclude a tag 
"inactive" from everything, but wasn't digiKam supposed to be easy to use, 
right? ;-p

> An additional functionality, which should be easy to implement would be
> to keep track of the parent of each image version, so that revisions can
> be presented in a tree-like fashion.


This should be pretty easy with a DB backend.

My comment #6 has just been implemented by apple in their new professional photo managment software : aperture. (See http://www.apple.com/aperture/quicktours/)

They keep the original image and the history of modifications. The different versions of an image are displayed as a stack of pictures.

I think they assume that the picture can be edited in other software only if it is called from aperture.

@ #21 
I think this is the way picasa2 works too. It's very fast in Picasa actually... 

Dunno if this would be really desired or neccessary though. I use Picasa in windows (oeps), but still cant get used to this way of working. I uploaded several fotos to a website, thinking i uploaded the corrected version, but finding out they didnt have the corrections, because they are Picasa internal only, until explicitly exported by the user... 

@#17, this sounds like the way that would really work for me. F-spot is nice but still quite immature...and gnome ofcourse, no flame intended ;)

*** Bug 114540 has been marked as a duplicate of this bug. ***

Hi all,

I think that version management will be welcomed at some point. I vote for version management. More often than not, I create more than one branch of a picture: an aggressive crop and a large view for example. The two pictures will become two "originals" from my point of view. Another example: sometimes noise reduction is required for on-line viewing but not for prints. Sometimes I want a color version of a picture and a black and white one, each pf this two pictures will suffer subsequent modifications (i.e. versions). Sharpening is different for on-line viewing than for prints and so forth.

It is nor possible, neither desired (at least by me) to avoid using external programs for picture processing. This is why I believe that Picasso style is not the answer (or not the definitive answer). Copies of the images with slightly different names are acceptable for me (this is what I am doing now actually) but it will be nice to be able to put more info in digikam's database and to have it displayed if required (a version number, a comment, created date, etc.). 

A "full blown" versioning is not necessary difficult to use - the functionality is not related to the interface. We should not avoid functionality only for "ease of use".

It would also be nice to get a warning about image editor recompressing images upon save after rotating them.  I got a cheap camera that doesn't put rotate info into exif and need to do this by hand.  Up until now I've been doing this while browsing through my images with image editor.  Well today, I discovered that image editor saves them with 75% quality setting, so in last years worth of images of my kids every rotated image is of much lower quality than the untouched ones.  Still slapping my forehead...

Regards,
r.

*** Bug 120714 has been marked as a duplicate of this bug. ***

I was just about to create a new bug but this one kinda fits the bill (if implemented) in solving the problem I just encountered.

In DK 0.8.1 I edited an Image with the intension of saving it outwith DK to email to someone. I use the ImageEditor to do a quick crop and then did a "Save As..." and picked a file on my Desktop. I then realised that I'd forgotten to resize the image and promptly resized it and hit Save expecting (like every single other program I can think of) it to save over the file I'd just "Save[ed] As..."... It didn't. It overwrote the version in my Album.... 

IMO, This menu option should be changed ASAP to e.g. "Save A Copy..." in order to save confusion.

I also very much welcome Version Managment of Photos. Great idea... I too often have several different versions of the same photo. It would be nice to be able to merge multiple "originals" into one final version for end user display. e.g. I'd like to keep my originals for panoramas but I don't necessarily want to "see" these originals when viewing my Albums. This may have to wait for panorama stiching support tho'. ;)

The simplistic concept of always keeping a master is also nice, but I prefer the more advanced options personally.

My 2cents. :) Digikam does indeed rock!

I have used f-spot a time or two, and I _really_ like it, mostly because of its versioning system. It is completely unusable because of stability issues, but the versioning system is so compelling that I keep on trying f-spot again and again. I think this versioning system is perfect. (as described in #17)

It is also possible, even feasible, to do edits in external editors within this versioning system. Let external editors be opened from within digikam on a separate copy, and the include this copy in the versioning system as usual.

I vote for f-spot-like versioning. It would really improve digikam! (Otherwise, digikam is my favourite photo management application out there)

I've just played with a program called SVK. It is nothing to do with image editing, it is like a local SVN repository (it's actually built on SVN).

I think the concept of having a local svn repository is actually quite sensible and with binary diffing algorithm used in SVN/SVK hopefully not too much space would be wasted with edits.

In theory, if you make your whole "Pictures" folder in Digikam an SVK checkout, and provided hooks to override the methods for copy, move and rename operations (perhaps copy is not needed?) as used internally in Digikam, you could easily do the following workflow:

SVK update
Start Digkam
Do edits, rearrangments etc. etc.
Close Digikam
SVK commit

And you'd get half way to a decent versioning system.

This is obviously not as nice as doing it internally in digiKam and having a nice architecture for rolling back changes etc. but perhaps the model is one that could lead to a nice solution (e.g. use the same approach as SVK and use subversion internally if the user wants revision control features).

SVK Homepage: http://svk.elixus.org/

Just a thought - may not be a solution or even a sensible direction ;)

@#29
I agree with your last sentence :-)
> Just a thought - may not be a solution or even a sensible direction ;)

Using SVN in that way looks over-engineered. digiKam already uses a database so its seems to be better to re-use path tables to hide and access file (= image) collections as a KISS solution.

Bye

  Thorsten

 

I suggest implement the easy solution first i.e. Give a warning when user is going to overwrite the original file. Define 'original file' as the when the digikam session is opened. Other more elaborate solutions can come later if needed. 
I don't agree with keeping an always untouched 'original' and doing all changes on copies; this could use a lot of up disk space which would make digikam a poor choice for small systems. Any user who wants to keep an untouched original should do so by making a backup copy, not by relying on an application to maintain one.

Well, I couldn't disagree more, the *only* thing that I dislike or even hate with digikam is that it just destroys my precious originals. After a session of photographing with my camera, I usually get at least a hundred pictures. I can't see why I should be forced to *manually* save a backup copy of each one, entering a dedicated name and spending hours with that every time I import my pictures. The often proposed solution, retaining the original (there is only one original, the one imported from the camera, may it be raw, may it be JPEG, may it be any other file) is one simple to implement and effectful. Even if you have to redo all of your edits, that's still a lot better than just having nothing to start from again. Also, I usually use Image Editor for the basic shots, so I can edit them quickly and to be able to present them to my audience. Later on I'd like to go back to the shots worth a second look and spend some more time with serious editing. I just can't believe, that something as precious and important as the unchanged file, the root and source of all further work just gets deleted forever as soon as I start editing it. Retaining the first imported file neither enforces much complexity applicationwise nor confusion userside, it should be possible to be disabled, but it should be present. 
Version management would be cool but not so widely used IMHO. Still, this would at least be lots better than losing the shots it took you hours to align...

Yes, saving originals is important. I would vote for Digikam to save a backup whenever doing modifications (even when only inserting EXIF/IPTC tags or rotating the image). The code could be very simple:

 does "filename.jpg.orig" exist?
   -> give the thumbnail an icon that hints at the existence of a backup
   -> show "Revert to original" in context menu
   -> do not save a backup when editing

No fancy versioning, history or whatever. No fancy pathname mangling or anything - just append ".orig" to the file name and hide it from within digikam. Files named "*.orig" are not displayed in Digikam anyway, so this would not pose a problem with pre-existing filenames. And anyway, if a file named *.orig exists already, it is probably a backup copy anyway, so Digikam would do "the right thing" here.

Don't be "too flexible" at the cost of being too complicated, or never implemented. You can't make it right for every niche case.

Jens

As I've stated before, I would strongly recommend a subversion basis for this feature to be officially supported, if for no reason other than storage requirements.

E.g. Assume your "Pictures" dir is a subvresion checkout. You SVN add everything, but *don't* commit it. These are you current originals.

As you make a change to any given image, you commit the image and then make your change. You *do not* commit your editied copy. At the present moment the storage requirements are approximately equal to the two copies of your image (orig+edited+some small SVN overhead).

If you want to make a further change, you commit your edited image to subversion. Using it's binary diffing algorithm, subversion will only store the *changes* in your image. This can have *significant* storage benefits if you only change part of the image - e.g. the EXIF tag.

The interface and SVN Repo location can be totally hidden from the user. This would be a very very nice way to implement this feature.

Worst case in this setup, would be the occasional double storage of images when you are about to perform an edit and then bail out, deciding to keep the original. In this case a commited copy of the original and a checkout of the original would exist which wastes a bit of space.

In order to implement this, all that would be needed is a few "hooks" in digikam for "pre-edit" operations and a set of nice managment scripts. I can't see it being that hard (although libkipi may need some modification such that it makes the host application aware of when it is about to edit an image.

Just my two cents.

Some enthusiastic people may want to read this:
http://www.kitenet.net/~joey/svnhome.html

Using subversion is a nice add-on (I can imagine it as a plug in) but I would not recomment it for the base package.

1. It opens up a whole new pandora's box of dependencies. Digikam already depends on a dozen libraries, why add a dozen more?
2. The "keep originals" idea should be transparent and the technicalities totally hidden from the user. There should be no need to set up a Subversion repository, additional pathnames, seperate directories or running services.
3. The idea of "check out" and "check back in" is an additional step that would make it unnecessarily hard for users.
4. AFAIunderstand, you can even now check your Digikam directory into subversion while Digikam is running, and no development effort is needed from Digikam's side. The most that is needed are a few links in menus and context menus. Right?

If you can make Subversion integration as transparent as (or more so) e.g. SQlite integration in Amarok (nobody knows, and nobody CARES, that Amarok uses a SQL backend for storing and managing its data), then I'm all for it.
But if users then get confronted with new terms ("checkin", "repository", "svn" files, whatever), then Digikam will become too geeky for the normal user.

Sorry, but I've been spoiled by iPhoto for too long. It does have drawbacks, but its interface and usability is one thing that Apple got RIGHT. ;)

Jens

I agree 100% about Apples UI stuff. It's very nice - especially their use of nice OpenGL to good effect. Just makes the whole experience smoother.

I perhaps didn't explain my thoughts too well, but I would never see the user even knowing there was subversion there at all. It would all be 100% transparent. What I tried to describe above was the actions taken automatically by Digikam.

I also agree that depending on SVN libs etc is not nice, so I would advocate the it's use via KProcess and running the ncessary command.

I suspect the support could be very modular. Like I say with the addtion of "hook" in digikam which is run prior to any edit on a given image, and a modification to the libkipi API to ensure expternal plugins inform the host application prior to an edit taking place such that the host application can then run it's hook would be sufficient. The rest could be done with a simple shell script (the hook) that does all the neccessary SVN commands.

All you need after that is a KIPI plugin that reads the SVN log for a given file and allows you to restore previous versions. It wouldn't be that hard. Just a couple of small design niggles to get sorted out, but other than that there would be relatively small impact on Digikam itself.

Embedding Subversion (a hugely complex system) transparently into an application is a huge effort.

Calling external processes opens up a lot of security problems (escaping file names with special characters? How about UTF-8? what if the external process crashes and/or leaves temp files laying around? what if the user has defined aliases? what if he has subversion installed in a different path? etc). If anything, the library functions must be used. Plus, you don't solve dependancies by not calling the libraries - they are also needed by the external binaries you call.

SQLite solves this problem elegantly by consisting only of two files - the SQLite library, and the database file (or files) you create, one per database. This is peanuts to embed. I'm guessing SVN is a whole new beast.

Plus, if we do that we must really forbid the user to muck about in the Images directory himself, because otherwise Subversion will choke if there were external changes, or diffs are missing, or whatever.


I agree that Subversion is a great system, but IMHO it's total overkill for Digikam.

OTOH, we can just require Reiser4 file system with the versioning plugin, and all problems would be solved. ;-)

Hey guy,

I just following this thread since a long time without post message.

Jens, your remark about Reiserfs bring me (:=))). i remeber than M$ would to implement a new FS with Win Vista to perform advanced search into files... I'm not sure but i think this project have been avorted...

If i remember, reiserfs 4 is dedicaced to have this fonctionality. It's a reallity ?

Since reiserfs 4 sounds like to be a non-future FS (Reiser human problems ? look google), is ext4 can do it ?

Gilles

Reiser4 can do it (and lots more) and is stable, but not field tested enough to be the default file system everywhere. I don't know what will happen with Hans Reiser, but I hope (really) that if he doesn't continue his FS, then it will be taken on by some group that can talk better with the kernel team, and it will be integrated into the kernel and maintained properly.

The only reason why it is not the default FS today on Linux, and actually the reason why ext3 and now ext4 exist at all, are politics. Argh.

Jens, i'm totally agree with you (:=))) Reiser fs is very powerfull. here all my computer running under reiserfs 3 without problem.

Gilles

To the last few comments, in particular the ones made by Jens, I would like to add that whatever system is decided upon it should

not break down when a) images or b) directories are moved by external tools
c) works well with other image management tools

For the purpose of b) storing local backups (as proposed in comment #33) would be a reasonable solution. For the purposes of a) and c) this solution would not be ideal, but the user would still have a good chance to avoid shooting himself in the foot.

What would be even better though is if the naming scheme was agreed upon by more than one application. Something like the Thumbnail Managing Standard http://jens.triq.net/thumbnail-spec/index.html
except that unlike what the standard prescribes for thumbnails, I would argue for storing the backups together with the originals.

This brings me back to comment #17: the F-Spot versioning scheme. It seems to satisfy the requirements of most people that have commented recently. But why not adopt the *exact same* scheme as F-Spot? The two programs would then interoperate perfectly and this could be the beginning of a new standard. Other programs could recognise the scheme as well so that file browsers could display only the current version of an image, with an indication that there are other versions available.

I'll follow up on this comment by asking on the f-spot list what they think.

Comment #25 in bug 125387 would be a possible solution to this wish.

I _never_ want to lose or modify my original images.  Period.

I really like the way that Digikam looks and works, but right now it is just too easy to make a crop, save, and then be upset because the original is gone.

F-Spot has a good system for doing this.  A previous commenter laid out its file-naming scheme, and it is not a bad one.

iPhoto also has a great system for this.  In fact, it has a prominent menu item called "Restore Original Photo" which is enabled because of it.  (And that, too, would be a nice addition to Digikam.  Here is how iPhoto's system works:  On image import, images are copied to ~/Pictures/iPhoto Library/YYYY/MM/DD/imagefilename.jpg  If ANY edits are made, iPhoto automatically creates ~/Pictures/iPhoto Library/YYYY/MM/DD/Originals/ (if it did not already exist) and copies imagefilename.jpg into that Originals directory.  It then makes the edits and performs an automatic save to the original location.  

iPhoto is designed so that a user need not be aware of how the file system is structured but, if a user wants to, it is possible to dive in and manually pull out the original file.

Picasa and Aperature (also mentioned above) do their "versioning" in a VERY different way.  These two programs never actually save _any_ modifications to the original image file, except when the user explicitly chooses to Export... an image out of the program's database.  Instead of saving modified images, these two programs keep a database of editing instructions and apply them on the fly to the orignal image to show the user the modified version.  This has a good advantage in protecting the orignal and in not consuming disk space, but it has the disadvantage that any edited version cannot be manipulated by an external program without an explicit Export... step and then a re-Import into the program (which results in a new image file that the application does not associate in any way with the original file).

The upside of iPhoto's system is simplicitly.  The downside is that becuase the same filename is used for both the original image and the modified image (albeit in different folders), it is limited to a single edited version.  F-Spot has the advantage that multiple edited versions can be maintained within the program, bu t (since it uses different filenames) it is more complex to manually handle the resulting image files.  

I think that very, very few images will result the user wanting multiple edited versions, so I think that iPhoto's system is better.  (For the case that the user _really_ wants multiple edited versions, it is possible to duplicate the original file and then perform edits on that "original".)

+1 (and then some) for anyone who can implement the "Restore Original Photo" feature.  Only then will Digikam be suitable for my Mom (etc).

Thanks

I've just found a new userspace filesystem driver called "copyfs". It may be worth looking into for people that would like it.

It basically works just like any other filesystem but keeps a copy of everyfile on the filesystem.

Probably not the best place to keep the digikam.db file but may be worth looking into a bit (e.g. perhaps it could be packaged up within digikam and used?).

Not really looked into it in any depth, but when I saw it, I thought of this bug/wish.

Apologies if this has been mentioned before and I've been too lazy to notice it :)

http://invaders.mars-attacks.org/~boklm/copyfs/

Col.

It really doesn't make sense to solve this at the filesystem level. Being a happy bibble user and having tested Apple's Aperture, I'm convinced that if digikam wants to play in the same league as both of these programs, it will have to go the same way for image editing, that is to keep the original file untouched and to store the edition commands seperately.

After reading all these comments and thinking about the versioning feature, now it's my turn to make a proposal :)

This is my suggestion about file versioning

1) requirements

Files created by digikam should be readable by any other software, it should just be valid JPEG, PNG or whatever files.

Versioning should not modify albums hierarchy by creating new visible directories (like Originals or something like that inside each album) or files.

Keep it simple :)

2) my proposed solution

Create .versions directory to store files in each album dir (if needed)
Use Versioning setting to be able to adjust the number of backups, so people can choose what they want :
- 0 => no backup, like now
- 1 => only the original is stored
- 2 => the original + latest modified image file is stored
- 3 => the original + the 2 latests modified image files are stored
- ...
- infinity => the original + all modified image files are stored


For a standard image file named img0001.jpg, name of backup file could be :
- img0001_orig.jpg to keep the original picture
- img0001_2006-11-23T16:40:45+0100.jpg
- img0001_2006-11-23T16:30:12+0100.jpg
...


with date : #date --iso=seconds
Eg :
2006-11-23T16:40:45+0100

-----

But, before doing some versioning work, I wonder if it won't be a good thing to just add a warning when saving the file :
"Are you sure you want to overwrite file xxx ?"
Maybe before 0.9.0 final ?

@Fabien:
Your proposal sounds quite interesting and sound, with one notable exception: The name of the original file should never ever change unless the user renames it on purpose!

Just to be more precise, it would be something like that :

.
|-- .versions
|   |-- img_3420_2006-11-24T11:19:31+0100.jpg
|   |-- img_3420_2006-11-24T11:32:17+0100.jpg
|   |-- img_3420_2006-11-24T11:42:32+0100.jpg
|   `-- img_3420_orig.jpg
|-- img_3420.jpg
|-- img_3421.jpg
|-- img_3422.jpg
|-- img_3423.jpg
`-- img_3425.jpg

But, I don't mind if img_3420_orig.jpg has just this name:
img_3420.jpg

Adding _orig just help people to know what this file is.
Then, there could be a gui to restore a specific version from the list of files in .versions/

Am Freitag, 24. November 2006 11:48 schrieb Fabien:
[bugs.kde.org quoted mail]

What happens, if I move a photo to another album?

Although I agree that every version of a photo has to be accessible to other 
applications, i.e. not just the differences saved to svn or similar, I would 
like to point out that the basic backup would double the amount of data need 
for the photos. Laptop users might not be able to just put in a second 
harddrive.

Since digikam cannot handle several directories, those users would have to put 
all their photos on a separate USB-drive which leaves them with no pictures 
on the laptop.

From that perspective I think that digikam has to be able to manage the 
collection of photos as amarok does with music, i.e. have several dirs they 
can be stored in. If that was the case the backup-folder could be held 
seperate, if needed, e.g. on a USB-drive. That way the laptop user can have 
old pictures as well as backups on the USB-drive but still have the more 
recent photos on the laptop itself.

The filenaming convension is all well and good, but the problem comes when someone renames the file outside of Digigam and doesn't update all the .version versions.

I guess Digikam would have to track the MD5 sum or something of the photographic content (e.g. ignore the metadata as this could have been altered externally too) and cross reference it's "missing file" in the database to the "new file" it's found. It could then take care of the necessary renames.

This would also prevent the loss of image properties in digikam that are only stored  in the database, not in the files themselves.

Such a feature would be similar to Amarok's AFT (Amarok File Tracking) - it's changed acronyms a few times so I may not have the most recent - it takes an MD5 of the first x bytes of real data (ignores metadata) to uniquely identify a file.

About Comment #50 :
In my requirements, I put "keep it simple". It always looks great to have more and more features, but maybe it's not always useful, at least for most people. I'm in favor of iteration in the software process, ie I think it's better to start simple and safe (bug free) rather than trying to do everything at the same time...


About Comment #49 :
I was about to add a new comment about database management that could solve some of the problems you mentioned. 
But, you can still use symlinks in your Picture directory to point to other directories (yes, it would not be very convenient if your device is not permanently attached).

Hey guy,

There is both B.K.o file open about versionning. Look here :

http://bugs.kde.org/show_bug.cgi?id=125387

... and especially my investiguations with 'Nikon Capture NX beta' software and "actions list" stuff.

Gilles

please please please don't try to do any image versioning to solve this, as a user I'd much prefer to have the edit actions stored seperately like aperture or bibble do, and export at will to whatever format (jpg, tiff...) is needed.

I'd very much like to have my originals kept when I change them in the image editor, too.

After I accidentally overwrote an original image yesterday, I looked at
this thread again.Apart from the more complicated to implement approaches 
of version management, it has been suggested in a couple of posts to have
a warning when an existing image is overwritten.
Wouldn't it be possible for the moment just to 
implement a warning box that the user is about 
to overwrite an existing image?

All the rest about versioning, grouping of images etc. 
could be left for later ...

(P.S.: Fortunately, I do have a separate backup of my images, but
"Save" and "Save as" are just too close, to easily destroy the original ;-)

Yes, I agree with Arnd (#55). After the discussion on digikam-devel mailing list about qt4 port, I think it would be important to add that in 0.9.2

I suggest we add a dialog box "Are you sure you want to overwrite your original image ?" the *first* time a user click on save for the loaded image.

The user could choose between :
- Yes, Overwrite
- No, Save as new name
- Cancel

As usual, there could be a checkbox "don't ask again" in the bottom of the window that would keep choice 1 (Yes) or choice 2 (No).


More complex solutions could wait the qt4 port and maybe the new database schema...

Is it not a lot easier to work around then a warning?

Currently the problem is that "Save as..." apparently suggests that one saves to another file and keeps on working on that new file.

However what happens is that one continues to work on the original. So what about simply renaming "Save as..." to "Save copy". The latter indicates better that one does not continue to work on the original, but just saved the current state to another file.

Since this is a data-loss issue string-freeze should be ignored.

I wonder why this simple renaming was not don for 0.9?

On Friday 02 March 2007 20:24, S.Burmeister wrote:
> However what happens is that one continues to work on the original. So what
> about simply renaming "Save as..." to "Save copy". The latter indicates
> better that one does not continue to work on the original, but just saved
> the current state to another file.

I don't think this would be a good idea. After all, "Save as..." is used in 
pretty much all GUIs to signify save under another name. Your proposal would 
make digikam incoherent with the vast majority of desktop software.

Even worse, The Gimp already has a "Save a Copy..." menu entry and it does 
exactly that: save a copy and do _not_ change the name of the current 
picture. In this respect "Save as..." indicates more clearly that the name of 
the file is being changed and that one continues to work on a copy instead of 
the original.

Created attachment 19900 [details]
don't overwrite files without warning

This patch is an attempt to provide a solution to the problem
of accidentally overwriting an original image:
- Save as: if a file with the given name already exists, 
  a box is shown, asking whether the file should be overwritten.
  (By a small re-ordering in the code, this
   is also done, when the filename given in the SaveAs dialog
   equals the original filename)
- Save: always leads to a box, asking whether
  the file should be overwritten, or the save should be canceled.

  Note, that no "Don't ask this question again"
  is implemented in this patch. 
  (Fiddling around  with adding new configuration variables
   is beyond my present understanding
   of the digikam code ;-)

Also, more involved solutions of versioning are not dealt with this
patch. It just ensures that one should never accidentally
overwrite an original image.

Created attachment 19927 [details]
Quick and dirty hack to add basic versioning to the editor

This is a quick hack to prevent the image editor from overwriting my precious
originals. 

It copies the original image to filename,N where N is an integer from 0 to 99.
The weird extension prevents digiKam from importing the file.

There's no option to restore a previous version, you'll have to do this
manually. Nor will this work for external editors.

Please note that I'm not a C++ coder so this patch is rubbish, I wish I could
have posted it anonymously. ;-)

I'm looking forward to the proper solution of this problem (I like the F-Spot
one).

Did any of the developers maybe have time to look at the patch in #59?
Wouldn't it (apart from the versioning, which is in my opinion a separate 
issue) provide a solution to the problem,
or should the patch be improved in some way?

You have right Arnd, we have completly forget this thread (:==) 

I will try to take a look at soon.

Gilles

Have people seen this: http://www.ext3cow.com/

Posted on /. today. Seems like it could be interesting here ;)

Col

I really like the idea of having my originals untouched.

i use iphoto and i also like editing my pictures and coming back to the original when i need to
i have a 20000+ picture library, so i don't like the idea of having a copy of every image i ever changed.
i would appreciate a solution where i have my orginal in a folder and a recipe of my changes to it.

why not develop a xml schema to track the last change of a file and what has been done.
so we might easily check whether the picture has been changed from outside (so my recipe needs to be destroyed) and if not i just get a view of my orginal with the used effects from my recipe

for using thumbnails we just take original+recipe not the original and recreate it when a recipe was flushed

I like and would prefer the .orig file extension idea in comment #33. It's simple and does't influence the folder view, and the original is still there when copying the album folder.

While this solution sounds appealing, I think there is one important
problem: once the first time a change was made to an image
and a .orig file created, what do you do on the next change?
Silently overwrite the original .orig, or silently overwrite
the visible image?

Therefore I think that a simple solution right now is to
warn if any overwriting would occur.
("Explicit is better than implicit.", see "The Zen of Python" by
Tim Peters; just do `import this` at a python prompt ;-)

Because presently files can be silently overwritten,
it is important to fix this really soon (for example #59 ;-).
Actually I am surprised that this entry is characterized as wish,
and not bug, because images could be lost forever!
(Sure, everyone should have a separate backup anyway...;-)

Best, Arnd

Just coming across this one again, at least I bump up the
priority to VHI because original images can be lost.
(For 0.9.3: what about #59 above ;-)

Bumped severity; this is a severe usability bug leading to possible data loss. Also changed summary to more descriptive.

Although versioning would be nice, it really is a wishlist item and belongs to another bugreport; to resolve this one there just needs to be any sort of confirmation or warning. Perhaps patch as per comment #59 would be enough.

Gilles,  I just checked my patch in #59, it still applies and compiles
with current svn. 
However, it does not work anymore!
The reason seems to be that it is now first saving to 
a temporary file (why?) and then renamed!
At least that's how I interpret the output on the console:

digikam: Saving to :/home/ab/Pictures/AB/ijjakc.digikamtempfile.tmp (JPEG)
digikam: Dirty: /AB
digikam: Using LibJPEG quality compression value: 81
digikam: renaming to /home/ab/Pictures/AB/IMG_4658_.JPG
digikam: Dirty: /AB

Looking at the code, it seems to happen in 
  bool EditorWindow::moveFile()
So clearly something has changed (to address some other bug?) 

Of course, one could add a check in the moveFile operation,
but maybe this is too late already?

As the security of this bug is now bumped to grave (with which I fully agree!),
it should be really fixed as quickly as possible.

SVN commit 704404 by cgilles:

digiKam from KDE3 branch : ask confirmation from user to overwrite picture with File/Save action from Image Editor and Showfoto
CCBUGS: 103350

 M  +12 -1     editorwindow.cpp  


--- branches/extragear/kde3/graphics/digikam/utilities/imageeditor/editor/editorwindow.cpp #704403:704404
@@ -1305,9 +1305,20 @@
 void EditorWindow::slotSave()
 {
     if (m_canvas->isReadOnly())
+    {
         saveAs();
+    }
     else
-        save();
+    {
+        QFileInfo fi(m_canvas->currentImageFilePath());
+        QString warnMsg(i18n("About to overwrite file \"%1\"\nAre you sure?")
+                        .arg(fi.fileName()));
+        if (KMessageBox::warningContinueCancel(this, warnMsg, i18n("Warning"), i18n("Overwrite")) 
+            ==  KMessageBox::Continue)
+        {
+            save();
+        }
+    }
 }
 void EditorWindow::slotSavingStarted(const QString& /*filename*/)
 {

SVN commit 704411 by cgilles:

digiKam from trunk (KDE4 : ask confirmation from user to overwrite picture with File/Save action from Image Editor and Showfoto
CCBUGS: 103350


 M  +12 -2     editorwindow.cpp  


--- trunk/extragear/graphics/digikam/utilities/imageeditor/editor/editorwindow.cpp #704410:704411
@@ -1218,10 +1218,20 @@
 void EditorWindow::slotSave()
 {
     if (m_canvas->isReadOnly())
+    {
         saveAs();
+    }
     else
-        save();
-}
+    {
+        QFileInfo fi(m_canvas->currentImageFilePath());
+        QString warnMsg(i18n("About to overwrite file \"%1\"\nAre you sure?", fi.fileName()));
+        if (KMessageBox::warningContinueCancel(this, warnMsg, i18n("Warning"), KGuiItem(i18n("Overwrite")))
+            ==  KMessageBox::Continue)
+        {
+            save();
+        }
+    }
+ }
 void EditorWindow::slotSavingStarted(const QString& /*filename*/)
 {
     setCursor( Qt::WaitCursor );

The original subject of this report is now fixed.

About versionning, there is another file where the subject exist. To not lost information from this thread, i tag this file like duplicate.

Gilles Caulier

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

How come, we really implement this ?
Sorry, but in application I know, Save, will just save without asking for confirmation. OO doesn't ask for confirmation, and many other application. If really you want to activate this feature, make it be configurable at least.
All theses popup begin to seriously annoy me. I'm sufficiently smarted to know what I'm doing. The right fix is IMHO versionning, however as this seems hard to implement, user should have the choice. It's like the trash/delete option in konqueror. Sometimes wants to directly delete the file and know what he's doing, so the user have the possible to activate direct delete and thus without warning

Another possibility, if adding a config entry in settings is too overkill, could be to have a checkbox in the confirmation dialog : Do not ask again

Fabrice, 

you are very welcome to provide a patch.

Many thanks in advance,

Arnd

SVN commit 712844 by cgilles:

digiKam from KDE3 branch : add "Do not ask me again" option about to overwrite current image when user when to save it from editor (File/Save)
CCBUGS: 103350


 M  +5 -1      editorwindow.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=712844

Angelo,

See my new little patch to add a "Don't ask me again" checkbox...

You can backport it on MAndriva bugzilla : 

http://qa.mandriva.com/show_bug.cgi?id=33605

Gilles

SVN commit 712850 by cgilles:

backport commits #712844
CCBUGS: 103350


 M  +6 -1      editorwindow.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=712850

Saving an image is not the same as saving another document. If I open a text-document alter a letter and save it, it is not the as if I open an image use red-eye reduction and save it because not only my change is saved, but the due to the compression the image-quality is decreased.

So in that regard comment 73 completely misses the point.

S. Burmeister> don't mind. Now this can be disabled, I'm fine.

thanks for all.

Angelo, Gilles. I've backported this to mdv digikam. I'll close the cooker bug.

To comment #77: Thanks Gilles that was what i had in mind to suggest :)

To comment #79: That's right but to have the behavior you desire just leave the dialiog box as it is (e.g. don't check "Don't ask me again"). Since it's not a big issue if people don't want to manage it as you like, now they can. 

To comment #80: if you're fine don't mean it is for all the people, so please don't be rude ;)

To comment #81: Col, thank you very much, i was out and your help is *more* than welcome :)

SVN commit 769218 by abaecker:

When leaving the image editor without saving, but pressing save in the
following dialogue, ensure that the original image is not silently overwritten.

CCBUGS: 103350
TODO:KDE4PORT



 M  +20 -20    editorwindow.cpp  
 M  +1 -0      editorwindow.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=769218