That would probably need some changes on their side, digiKam is not able to monitor what other applications do. And there is no common framework, that could be used by all KDE apps, either. So, the answer is (most probably) no. Besides, that's out of scope of my GSoC work (time is limited and I need to focus primarily on my project) =/ But I agree it would be cool to have such feature alongside whole KDE :)

Quite good and important questions, thanks for them :)

1: Yes. Automatically copies the current photo and saves the changes. About the save button - hm, probably. But if this feature is going to be optional, then it would have to stay. That's not decided yet.

2: This will be customizable and it will be possible to keep the original image where it is with its newer versions along, or move the original to specified folder ("Originals" for default) or keep only the latest version and move all the rest. This is not entirely clear either, I'm still focusing on the foundations. But another setting should allow you to either see all image's versions or see only the latest version in digiKam's album view.
To your points:
- The origional file name is always the most recent photo, this is what the user expects (this is how a program without history would do it).

that's true, although with non-destruct. editing this doesn't hold I guess, because the original is THE original, edited images should be distinguishable IMHO

- You only keep a duplicate of the most recent version around if the user did edit the photo. (most user do not edit most photos).

basically there will be only one duplicate (created when you apply some filter), but as soon as you apply some filter, which uses some random stuff (like raindrops), you need to create another copy of this and all other version base on this as you won't be able to reproduce it with the exact same result as you would reproduce brightness setting for example

- Since you have a duplicate of the most recent it is easy to find out that another program edited somefoto.jpg

yes, I'm counting with something like that

- The copies are stored in the Pictures folder, of which you can expect that it has enough space.

the Originals folder is supposed to be created also in the picture's folder

- The copies are close to the location of the current photo. (easy for backups)

yeah, same with Originals folder, but having a hidden folder is not too good for backup, think about copy/paste when you have hidden files hidden. This wouldn't be a problem if you copied the parent folder, but if you enter that folder, press ctrl+a and ctrl+c, then you would paste them somewhere else with ctrl+v, you won't copy the hidden folders. I was also thinking about this solution, but I figured, that folder like "Originals" will better let the user know, that he has the original files there. I have to put some more thoughts on this process.

3: Most probably it will :)

4: That's also not clear yet. But I guess the undo/redo could integrate with the image history, this will be possible. And probably also done.

Again, thanks for the questions. It also helped me to think more about those things ;)

Marty

1. The save button should be changed to "save as" button. Because many use JPEG files and they mistakenly press the "save" when the original file is overwritten and so on the quality is lost and the changes are done. But in this case, we could get somekind notification to thumbbar where the green mark tells what photo is saved in background.
check the page 3 the showFoto thumbbar under the photo: http://saukonpaa.com/documents/digikam_showfoto.pdf

2. I dont like the idea that original is moved away from the current album. I use ISO album naming when importing and the MIME type as well.
So I get albums like 2010-06-15/orf/ and 2010-06-15/jpg. Now I would get more albums to manage: 2010-06-15/orf/original and 2010-06-15/jpeg/original.
But that would still be much better than hiding albums or photos! We can not hide files because when we manage albums with file management, we easily would end up to delete album thinking it is empty, while it would not.
And that would especially be _very bad_ if the originals are hidden. I think now we need to get good versioning UI (coming later it seems).
The original and edited photos can exist in same album but renamed just different way when viewed by file manager. But in digiKam, it should notice automatically what is original and what is edited and group them.
The UI is then important part. I have somewhere few mockups of versioning editing UI's what I could send to the author if he can use anything from them for his own idea.
But I think that if we add somekind marking over photo when we hover it (or shown all the times) and then we would get somekind list of versions what could be opened, it could make things easier.

And how about having non-destructive file for the edited photo with versioning but still having a single file (original + edited)?
Like having a TIFF whats features are used for versioning. When user edits photo, add new layer and place the editings to that top layer. Then save automatically in background the file.
More editings, the TIFF would grow. And when watched with normal viewer application, we would get top newest edit in view (this would not support crops :-()
And Krita, Photoshop etc would see as well the layers and you could use them. (Crop and resize are the things what are missing or does the TIFF support such?)

Is there any open image format what would allow layers, but show only the top layer as the one, even it would be different size?
TIFF allows to have layers different size, the biggest jus is the one. So the bottom layer could be the original, cropped/resize and edited versions could be used.
But would it be bad idea to allow digiKam/showFoto to read TIFF images like they would show only the top layer?
TIFF would be non destructive, compressed image.

I think this discussion should be gone in devel mailing list.

I have as well. year-month-day/MIME -format.

And I have only few kind sub-albums after Y-M-D album. ORF for olympus RAW, CR2 for Canon RAW, JPEG for all cameras and then a PNG where I have all the edited versions.
When I select the main album, I have set to group photos by type. So I get PNG's in own box and I can see straight away what I have edited.

What I have been thinking is that when you edit photo, it should save it to automatically to mime typed sub-album. Like if I have album/orf and album/jpg albums already and I edit photo. When I save it, it creates album/png and moves the file there. But we need this non descructive way and the file renaming.

Question really is how many savings there comes among editing? Like is it per save (Ctrl+S) or edit (levels, curves)? Like I usually do about 10-15 edits for every photo. Resize, Crop, Whitebalance, Sharpening, noise reduction, Gamma, Levels/curves, Saturation, Vivid. Those are my very basic tools. And I might use them multiple times. So if the versioning is per edit, I would end up having dozens of versions of the same photo and then when storing in non-descrutive version, it could be 500Mb for one photo (PNG format, 30-60Mb each when on 10Mpix camera, more when 16Mpix camera)

As far digiKam has tried to show all the photos what is stored in albums. More like file manager shows all files (expect hidden).

Is there time when now we would need to get digiKam possibility to hide specific files/photos? Like having a tag/filename what would get hidden automatically? This way we could make edited versions, hide them and show only newest. But we would have problem to get user easily to see all the photos in that album.

Lightroom has nice idea about virtual copies. When you make edits, it stores only the edits to it database. Then when you export photo, it creates real file. Or when you create the virtual copy, it allows user to set new set of edits to that but it is only in database, not in the file itself until you export it. So you can have multiple versions with one file, while saving disk space.

That's pretty much how it will appear to the user, yeah.

To your questions:
What you seem to be talking about is keeping a catalogue of images to record the history of edits to a given original.

No (Damn I should work on my explaining skills). That's wrong from so many views. My answer continues with your next question..

The central part of non-destructive image editing is, keeping the original image and a history of edits to that image.

Yes, that's how it will be done. Except that the history will be stored in another file (and in digiKam databse too), which will be there for thumbnaling reasons, for additional editing with external apps (eg. you do some edits in digiKam and then you want to do some edits in GIMP. That would be impossible of you have only the list of changes in database, you would need to export it first). And the snapshots will be used to speed up processing, although some users would like to keep all the snapshots. There will be this possibility.

It is not necessarily best to save the current image in the original image format

Hm, that's pretty good point. I will talk about it with my mentor and we'll see what we'll come up with.

That's ok, thanks for asking :)

Marty

I don't think that's a good idea. Think about when you copy some folder (album) to some other place, other computer let's say, where there isn't digiKam installed. That way you have also all the originals with you. If you would have all the originals in one place, they wouldn't get copied with the rest of your album, plus it would be very hard to pick those you actually want (think about 5000 pictures in there and think about naming conflicts...).

What about creating the _v1 version as a hardlink of the original on import?

This would get unusable on other platforms. I guess.

use inotify to watch the collection directories for updates to the files and create new versions whenever the files were changed by external applications

You would have to have digiKam running all the time to pick up on those changes.

Marty