Bug 142056

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

Yes !

For me, this is the most wanted feature missing in digiKam : saving the history of modifications for raw files, in an external XML/txt/watherver file

For completeness, see also the discussion in
  http://bugs.kde.org/show_bug.cgi?id=103350
  http://bugs.kde.org/show_bug.cgi?id=125387 

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

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

There are several dupes of this bug, and many dupes of the dupes. The basic feature that most people are asking for is versioning:
1) User has an image file
2) User modifies the image file with Digikam's Image Editor
3) User saves his modifications as a new file, which is stored alongside the original file and has the original file's metadata (Tags, XMP / IPTC data). The filename could be something like originalFilename-mod1.jpg
4) When browsing images, the user only sees the modified file. However, when selecting the modified file the user can pick which version of the file to see / save / etc.

Note that other photo management programs have this ability, notably F-Spot (http://f-spot.org/Features). I last tried this feature in F-Spot two years ago when I switched to Digikam, but it is a remarkable feature that literally adds another dimension to photo management. Instead of being frightened to modify photos, users can fire at will and interact with their photos.

Created attachment 26146 [details]
Screenshot showing F-Spot Versioning selection dropdown

I looked through the F-Spot implementation of Versioning and I find it very
intuitive. The Image Editor is part of the View GUI, encouraging the use of
photo-enhancing tools (especially Crop, Redeye, and a few other tools). The
Versioning selection dropdown is available in the sidebar. The modified file is
stored in the same folder as the original with the text " (Modified)" added
right before the filename extension. I found myself naturally improving photos
left and right and having a blast. It's so good that I don't want the wife to
see it, lest she pester me about moving back to F-Spot!

Since Dotan argues so nicely for the F-Spot approach, I'll duplicate my summary of how that works from bug 103350 here:
 
 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.

It might be better, if feasible (I don't know), to do it the Aperture / Lightroom way. As far as I remember, these programs don't store modified copies of the photo, but only change sets (mask this zone, change brightness, blur something, etc). Aperture, particularly, applies the changes using the GPU for its preview to be instantaneous (but Lightroom doesn't AFAIK, so it's doable only on the CPU). 

Caching some sort of thumbnails would also be an option to make it speedier (say, after applying the effect on the CPU, a thumbnail on that zoom level and the general thumbnail for picture browsing, or whatever). 

This way, even if the original image is heavy on disk (say, a RAW), you can have as much modified copies as you want, as each one only take some hundred of k's. 

@Jisakiel: The problem with storing the change sets is in rendering time. Each time you want to view the image, it must be rerendered. Disk space is generally considered rather cheap, while processing time is not.

Well, the problem with raw management in showfoto is that it first imports the whole image (loosing raw information indeed) and then processes it at 100%.  Each time a value is changed, the whole image is processed. Each time a change is done, or undone, the whole image is saved/restored. Each time you tweak a value, the whole image needs to be re-rendered.. you see the problem?
commercial and other opensource raw processors don't process the whole image, they process a preview of it, and only when you press okay, generate the jpeg. that's why they are faster and more effective.

But this requires long changes in the way showfoto works with raws.

@Jisakiel & Dotan Cohen:
The only way I can see of implementing this the way Jisakiel said, would be through a kipi plugin which would do basic (or even advanced in the future) processing by loading a set of images, and doing it the way raw processors do:

load each of the images, but show a smaller preview (whatever fits on screen)
a toolbar on the right hand would allow tweaking brightness, levels, contrast... in an easy manner.
the preview would change each time the settings are changed, and each of those setting changes goes to an xml file
once done, you press okay, and all images are processed to jpeg, but xmls are kept for new reprocessing.

It's what Tools->Raw Image Converter should do except it should do history and batching. And well, current version of the converter doesn't seem to work at all here, so it needs quite a bit of fixing

What do you think?

I thought it might be useful to have these cross-references:

What Jisakiel suggests in #9 is the subject of bug 125387. In that bug (as well as in the now closed bug 103350) there has already been a bit of discussion on versioning vs. simulated modifications. Also related to versioning is keeping track of images that are derived from other images, such as raw and jpeg versions of the same image, or panoramas derived from more than one image. This was suggested in bug 151232.

So, for versioning: bug 142056 (this one), simulated changes: bug 125387, image relationship graphs: bug 151232.

Of course, the three ideas have lots of interactions, so the discussion on how they go together, and on the merits on versioning vs. simulated changes, has its place in more than one of the reports.

Some people here seem to be confused between versioning and editing undo. Versioning is not the "undo" button that one has available when editing. Versioning is the concept where an edited photo is saved IN ADDITION TO the original photo, not overwriting it.

No matter what edits are done to a photo, by the mechanisms currently possible in Digikam, Digikam should provide the option to save the new photo ALONGSIDE the original photo, with a suffix added. To be compatible with F-Spot, we could use the suffix " (Modified)", so "dscf3252.jpg" would be edited, and when the user is done with his edits (redeye, crop, whatever) he saves the photo and Digikam writes the edited photo as "dscf3252 (Modified).jpg" which is a new file. The Digikam Thumbnail mode would only show the thumbnail of the modified photo, and in View mode one could choose which version to see.

F-Spot currently has this versioning feature and it is not only very useful, it is also very fun. The user can edit - interact - with his photos without fear of damaging the original file. The file names F-Spot uses go like this:
dscf3252.jpg
dscf3252 (Modified).jpg
dscf3252 (Modified(2)).jpg
dscf3252 (Modified(3)).jpg

I also do not like the use of space and the use of parenthesis, however, as Linux accepts them as valid filenames and an established photo organizing tool already uses this convention, I recommend that we adopt it in the name of interoperability.

Dotan,

Thanks for this analys from F-Spot.

Note than using capitalized char in filename is a problem under win32 filesystem. M$ manage very bad this point. So, like we will port digiKam under win32, i recommend to not use capitalized char here.

Also, i don't like very well this file name annotation.

We will working on versioning after than 0.10.0 will be released. we need to patch again database version to add these informations and make the versionning interface as well. We need to wait to stabilize the new database interface before to implement versionning. After that, all will be more simple.

Gilles Caulier

Very good, Gilles, as I don't like the way F-Spot does it either. In my original comment I suggested the annotation "-modN" so that the filenames would become:
dscf3252.jpg
dscf3252-mod1.jpg
dscf3252-mod2.jpg

Is that acceptable to you? Or is the whole idea of filename annotation unacceptable to you? If so, then the modified files would have to be kept separately, which I do not think is a good idea.

If I understand correctly, these files are saved by user interaction, 
right? Ie, it's the user that requires storing the version with 
something similar to "save" button.

The disadvantage of saving .jpg files versus an .xml with changes ( as 
suggested by the reporter) is that if you save a jpeg file you cannot go 
again to that version 1 month later and change parts of what was done. 
The jpeg doesn't contain the history of changes. So you have to redo the 
image from the very beginning.  I understand it's much more simple to 
implement though.

Dotan,

Using a suffix as versionning of file is always better, like this original filename and extension is preserved and we don't need to make a wrapper to extract it. Using standard Qt API will work like QFileInfo::fileName().

So something like that is better:

dscf3252.jpg
dscf3252.mod1.jpg
dscf3252.mod2.jpg 
...

With Qt API we are able to extract the last extension suffix as well ("jpg"), or the complete one ("mod2.jpg"). extracting the revision annotation is easy to implement.

Gilles

Unai,

I always don't to use sidecar file. It will bloat hard drive.

Also, we have a database for that. So search all revision 2 of all modified files is possible for exemple. You cannot do it easily and speedly using sidecar.

Note : it's the same for all XMP sidecar file. I work very hard to support metadata writting with Exiv2. Currently JPEG, TIFF, PNG and JPEG2000 are implemented. Still all RAW files format to host as least XMP at the right place (like exiftool do).

Gilles Caulier 

I agree Gilles, sidecars can be very annoying, but I like storing 3 
versions of 3MB jpeg files even less.

Now that I was looking at this movie from you, about the raw importer,

http://digikam3rdparty.free.fr/TourMovies/0.9.5-rawimporttoolforeditor.ogv

Maybe there's an even more simple way to store the image without 
creating .jpeg files and not altering the raw file.
That raw importer applies all settings each time the raw file is processed.
Wouldn't it be safe and simple to store the settings of the importer in 
database? Just the settings, no files, no versions.

Next time the user goes to edit the raw file, it loads the settings to 
the importer, and the user can tweak it again.
The problem is it only works for changes done in the importer, but it's 
the best I can think of :/

Unai,

This can be done only in KDE4 version. In KDE3, we will don't touch database schema.

Gilles

Unai, problem with changes stored in some special file is that each time
you will open photo they have to be applied. For photos with long
history it could take insane amount of computer power. Some solution
would be saving original image *and* last, and only last modification
version.

I know that hard disk space nowadays is cheap but with each camera
generation files are bigger and storing all that data on HD...

@Mikmach

Yes, processing the whole image is very cpu costy. That's why I was 
suggesting to use it only for the raw importer tool. Raw files are 
always processed from scratch anyway, so this isn't an issue, and 
there's no need to store the whole history of changes.

What I don't know is how other raw processing apps manage to do this in 
real time. Processing only the view on screen might help, which can be 
600-800kpx only versus the full image which is 10Mpx. Which is around 
10-15 times faster. But then each time the image is scrolled, they need 
to be reprocessed, and some tools cannot be applied unless they are done 
over the whole image.

@Gilles: I agree that the .presuffix like you mention is the best idea. As we are now over 20 comments, I will summarize:

1) Versioning is not the same as Edit Undo.
2) Versioning will be implemented as an additional stored .jpg file, where filename.jpg is turned into filename.modN.jpg for the Nth modified file.
3) Noteworthy info is found in comment #8: http://bugs.kde.org/show_bug.cgi?id=142056#c8

Dotan,

>2) Versioning will be implemented as an additional stored .jpg file, where >filename.jpg is turned into filename.modN.jpg for the Nth modified file. 

Why storing versionning file as JPG which lost quality by compression ? Why not to  use PNG instead ? Nothing will be lost like this.

Note: this remark is valide for others image format to version, as RAW and TIFF for ex. PNG support color management, 16 bits color depth, XMP, Exif, IPTC metadata. It's the perfect image container...

Gilles Caulier

@Gilles,

Yes, very clever. Saving once and again to jpeg only destroys quality. 
For raw I prefer processing always from scratch though, since extra 
information will be lost of png is used.

@ Dotan,

I don't think the guy actually refers to versioning in the report. He 
says he wants to recover the status of the picture without saving to 
jpeg. I think he's thinking raw processors there, not jpeg editors.
I think that's the source of the confusion. Versioning is one thing, and 
I think the report is another ;)

As a sidenote. What's the difference between the proposed jpeg 
versioning and "save as" option currectly available?
I fail to see the advantage

> As a sidenote. What's the difference between the proposed jpeg
> versioning and "save as" option currectly available?
> I fail to see the advantage


1. You don't have to remember to hit "save as" not "save". I lost sooo
   much data in that way :)))
2. "Save as" clutters album view (you have visible all versions, with
   versioning old versions will be hidden).

So, having all available versions of a photo somehow "related" to the original one in the GUI would definitely help with the usability. 

Regarding how other apps do the effects processing in real time, Aperture from Apple does use the OSX 10.4++ CoreImage API, which IIRC uses the LLVM backend (sort of JIT for any code parsed by the gcc frontend) to generate code targeting the GPU present in the system, or if it isn't powerful enough, the SSE extensions available. That, of course, limits the color precision to that available from the GPU (used to be so powerful only in single mode). 

I don't know how Lightroom (as of 1.0) does it, as it doesn't seem to depend so much on a powerful GPU. I'd bet on decoding the images, processing them and storing the final results hidden from the user; it wouldn't use *more* space than saving an additional un-lossly-compressed copy of the RAW, However further processing from that snapshot would not hurt quality (it's RAW -> effect set 1 -> effect 2 vs raw -> effect set 1 (mmap-saved file?) -> effect 2). Only if you wanted to selectively undo effects would the image have to be regenerated from the original raw, which could be a case uncommon-enough. 

@Gilles: Yes, png is better. Agreed. I mentioned jpg with the [bad] assumption that the original would be jpg, and that the user would prefer the same format as the original.

@Unai: I agree that the original request here does not seem to be versioning. However, my own and other versioning request bugs were duped to this bug, so I take my arguments and interest here.

> What's the difference between the proposed
> jpeg versioning and "save as" option
> currectly available?

The versioning feature lets the new image 'replace' the original in the Thumbnail and View modes. Think of the case where you took an otherwise excellent photo of your wife, but the frame is crooked and she has redeye. With versioning you can straighten the photo and remove the redeye, without ever altering the original image. During normal use the user only sees the altered image. However, in View mode the user can select a previous version of the photo (the original as it came from the camera) and view or alter it as he sees fit. As Mikolaj pointed out, with versioning the older versions do not clutter the album.

@Jisakiel: you are thinking about Edit Undo, not versioning. The current method of editing and undoing will not be changed. The only change with versioning will be that the revised image will be saved in addition to the original, not overwriting the original.

Regarding disk space:
The disk space used with versioning will grow as O(n) with usage. This is ideal, and keeps disk space used on the same order of magnitude as without versioning. If your disk has not enough space for versioning, then it has not enough space for normal growth due to the addition of new photos anyway. If this is not familiar to you, then please read a bit about space complexity: http://en.wikipedia.org/wiki/Computational_complexity_theory#Time_and_space_complexity

Thanks for the summaries, Dotan! What remains to be figured out, as far as I can tell, is whether it is possible to come up with either a fixed naming scheme for the images, or some other way to locally store the version relationships such that other programs can interoperate with Digikam.

Using the F-Spot naming convention (but perhaps using png:s instead of jpeg:s) is one idea, but IIRC it would not in itself suffice to achieve interoperability with F-Spot, since that program uses its database to actually store the version relationships. Also, the F-Spot-style file names do not tell you which version of the file is the current one.

Perhaps it is not possible to do this? But it would indeed be nice if the Digikam albums were easily browseable with file managers, viewers and other photo managers, rather than the user having to employ an "export" feature each time she wants to get her pictures out of Digikam.

The idea would be that e.g. Gwenview, dolphinpart and KPhotoAlbum would have an option to show only the current version of an image, if that is available, and perhaps even to allow the user to switch versions of an image. Just to get started, here is a suggested naming scheme, based on Gilles' comment in #18:

Suggestion 1:
img1234.jpg <- original
img1234.current.png
img1234.mod1.png
img1234.mod2.png

Here, if I create a new version from "current", that would still be named current, but the old "current" would be renamed "mod3". It becomes slightly ugly if I then decide to revert to "mod1": "mod1" would then be renamed "current", and perhaps the old "current" would become "mod3" and there would be no "mod1" any more.

Suggestion 2:
As above, but "current" is a symlink to the current version, e.g. "mod2".

Avoids the above ugliness, but I hear there are platforms with no symlinks!?

Suggestion 3:
A local (hidden) text file specifies the version relationships.

Suggestion 4:
Give up making the version state locally interpretable; just store it in the database.

That last one is simpler, but it seems to really lock you in to using only Digikam. Anyway, this was just a first go at this.

>Suggestion 3:
>A local (hidden) text file specifies the version relationships. 

You know my viewpoint about sidecar file : i hate this idea...

Using image Metadata is always better, especially XMP... We have an digiKam XMP namespace for that.

Gilles Caulier

Re: #31

Yes, I agree, and I was going to get into metadata, but felt that my comment was already too long :-) So, is there a good way to do this with metadata? Maybe you'd tag the variant files something like:

VersionOfFileName: img1234.jpg
VersionOfUID: 0xF00BA8
VersionOfImageHash: 0x123456 (likely to be overkill)
ActiveVersionAsOf: 2008-08-06 13:42

Here the VersionOf tags all refer to the original image, the idea being that even if some files are renamed or removed we still have a chance to figure out the relationships. The "current" file to show would be the one with the most recent ActiveVersionAsOf tag. (Reverting to the original while keeping the variants, as F-Spot lets you do, would be a special case though, since we may not want to touch the original file at all?)

Or would one need something else or more sophisticated? I don't know; I am just trying to raise this for discussion by more knowledgeable people...

@Martin:
> What remains to be figured out, as far as I can tell, is whether
> it is possible to come up with either a fixed naming scheme for
> the images, or some other way to locally store the version
> relationships such that other programs can interoperate with Digikam. 

The naming scheme as proposed by Gilles will be used:
dscf3252.jpg
dscf3252.mod1.jpg
dscf3252.mod2.jpg 

The 'current' photo information will be in the database, not in the filename.

>The 'current' photo information will be in the database, not in the filename. 

In database _and_ in image metadata, in using XMP digiKam namespace.

Note : in XMP digiKam area, we can write like we need. nothing is cached, all is written in clear format. I have already registere digiKam namespace in Exiv2 (http://dev.robotbattle.com/cmtinfo_svn.php?r=10&l=50&v=1545). for the moment this include only one tag with wall digiKAm tags path set to the image.

Gilles Caulier

With all that metadata some export plugin or action is more and more
necessary to clear data which shouldn't be available for strangers.

@Mikolaj:
Regarding metadata removal, please comment on Bug 169230.

As I just noticed that this issue has been earmarked (in a blog posting) for
digiKam 1.0, I have a few comments to add.

The comments above are heavy on naming conventions but light on use cases.
The only use case is the very linear: user edits an image a few times and
each version (a saved edit) is preserved in a separate file; only one
version of an image is displayed. This struck me as being not particularly
useful for my only typical use cases:

If I change a file, I don't edit, save new version, edit new version,
save newer version, edit newer version, etc. until I have a the single
image that I'm after. That really does not work well for JPEG images,
where each save is going to degrade the quality. If I know what changes
I want to make, I make them all at once (usually).

More typically, I am not aiming for a single "current" version of a
file. I often make one edit to fix colours, exposure, sharpness, etc.
and then make separate edits for cropping to ratios suitable for
printing to 6x4, 7x5, 10x8, etc. I commonly crop a single image to one
ratio in both portrait and landscape orientations. For example, a
half-body shot cropped to 7x5 in portrait orientation and cropped to a
7x5 ratio head-and-shoulders shot in landscape orientation (and the
same all over again for 6x4 or 10x8, or I might make the 7x5 crop from
the 6x4 crop, etc.). What I would like to do is select a representative
subset of these crops to be visible, not just one of them. I might also
like the original to be shown, as I may have done nothing to it except
make crops for printing. For example, I might want to show the portrait
and landscape 7x5 crops (and hide the other crops), as these crops are
very different images even if they came from the same original file.

Personally, I don't mind tracking all of these versions myself and I have
my own naming convention ("*-00.jpg" is the original, then "*-01.jpg" is
an edit with the original aspect ration, and "*-02-7x5.jpg" is another
edit that is a 7x5 crop). I could, if I wanted, track a "tree" of edits
by using "*-01.jpg" for the initial corrections and then "*-01-01-7x5"
as the "01" crop edit of the "01" edit, etc. However, I don't make things
that complicated for myself. If this feature is added, I would rather it
not get in the way of the more complicated version control that I usually
do manually. Of course, I'll have to remember not to use a convention that
accidentally coincides with the convention proposed in this "bug" or I'll
get screwed when I take on a new digiKam. (Why ".mod1", by the way, why
not just ".1" or ".v1"? My file names are long enough already.)

What gets in the way are all of the near duplicate images and the "grouping"
feature (bug #121310) would solve that problem for me, as I can decide how
many different groups with a "current" image I want based on whether or not
I think a new version constitutes a near duplicate image or not. How would
grouping and version tracking work together if they were both implemented?

Linear version tracking is a nice feature for those who are just fixing an
image and emailing it on (assuming they are not concerned about JPEG losses
as each version is created). Aside from that, it is not very useful unless
it can track a "tree" of image versions and allow several nodes in the tree
to be visible "current" images.

On the issue of saving edit lists for an image and playing them back, I had
a few thoughts about this some years ago. GEGL (http://gegl.org/) is designed
to support this kind of operation, but it was not mentioned in any of the
comments above. Also, if I can save the edits for one file as a kind of
edit decision list (EDL), then it would be nice to apply that EDL to some
other file. This overlaps with the functionality of the batch queue manager
in some ways. Using GEGL (or similar) for the EDL, different nodes in the
EDL could represent different images in the version tree, each adding more
edit operations to the ones that came before it. This EDL could be modified
afterwards to, say, decrease the sharpening made in the first version of the
image before all the crops were applied. That way, for example, all the
over-sharpened crops could be fixed with one change via a nice GUI that
shows me my EDL tree and lets me change the parameters to the operation
nodes. (There is no reason why I couldn't write the edits to files to
improve performance, but these files would be updated if I were to change
the EDL.)

Finally, there are lots of tools that perform version control. Why not base
digiKam version control on RCS, CVS, SVN, etc.? RCS would probably work
well, as it is simple, controls one file at a time (all you need), comes
with its naming convention ("x.y" in "*,v" files, etc.), can be integrated
with scripts, is a standard that other tools could interoperate with, works
on just about every platform you can imagine, suits the case of having one
"current" version of an image at a time, reduces the number of other files
that are floating about, and it supports branching, so that could be a
feature that could be added more easily in the future.

> The comments above are heavy on naming conventions but light
> on use cases.

Probably because the devs need to decide on a nameing convention to code!


>The only use case is the very linear:

I have other use cases, but let's examine this one.


> user edits an image a few times and each version (a saved edit) is
> preserved in a separate file; only one version of an image is
> displayed. This struck me as being not particularly useful for my only
> typical use cases

It is useful for our family use case. We are now organizing partially with F-Spot, for the photos that we edit. This is quite what we do. It's fun to see which family member can improve a particular photo in the best way! And who forgets to remove the obvious redeye!


> If I change a file, I don't edit, save new version, edit new version,
> save newer version, edit newer version, etc. until I have a the single
> image that I'm after.

But some families do. Our does, although each edit usually starts off original from the original image.


> That really does not work well for JPEG images, where each save is going
> to degrade the quality.

That is why Gilles declared that png is better, and png seems to be the most likely candidate, not jpg.


> More typically, I am not aiming for a single "current" version of
> a file.

It's hard to say how typical your use case is. Shall I pester the F-Spot list for users who actually use this feature? I think that they'd gladly help.


> If this feature is added, I would rather it not get in the way of the
> more complicated version control that I usually do manually. Of course,
> I'll have to remember not to use a convention that accidentally coincides
> with the convention proposed in this "bug" or I'll get screwed when I take
> on a new digiKam.

This is a very good, important point. Gilles, can the mod filename be configurable in the options? That should make everybody happy, even those who want F-Spot compatibility (assuming that the database issues can be worked out).


>Linear version tracking is a nice feature for those who are just fixing
>  an image and emailing it on (assuming they are not concerned about JPEG
> losses as each version is created). Aside from that, it is not very useful
> unless it can track a "tree" of image versions and allow several nodes in
> the tree to be visible "current" images.

Although our usage method is in fact a tree (several different mods all starting from the original image), there are few enough nodes that storing them in a linear fashion is acceptable.

(In reply to comment #38)
> > If I change a file, I don't edit, save new version, edit new version,
> > save newer version, edit newer version, etc. until I have a the single
> > image that I'm after.
> 
> But some families do. Our does, although each edit usually starts off original
> from the original image.

Sorry. I am not arguing against the existing use case--it is as valid
as any other. I am arguing that there are other use cases that will not
be met by the proposed solution for that use case, so the feature will
not be particularly useful to *me*.

Whether or not my use cases are typical, I cannot say, but I doubt they
are particularly unusual. Their acceptance also depends on what the
target audience for digiKam is, both now and in the future. Does it
intend to compete for attention from those who might use Picasa or
Lightroom or both, or something else entirely?

While solutions can be kept simple in the short term, it might not be
possible to enhance those solutions in the future if the developers
have backed themselves into a corner by not considering where the
feature might ultimately be going. I've done it often enough myself in
the past to be very wary of it nowadays and I think that this feature
has the potential to cause trouble later if not thought through very
carefully now. Where will it be in five years' time?


> > That really does not work well for JPEG images, where each save is going
> > to degrade the quality.
> 
> That is why Gilles declared that png is better, and png seems to be the most
> likely candidate, not jpg.

Can the Exif/IPTC/XMP metadata be maintained in the PNG?


> > More typically, I am not aiming for a single "current" version of
> > a file.
> 
> It's hard to say how typical your use case is. Shall I pester the F-Spot list
> for users who actually use this feature? I think that they'd gladly help.

I, for one, would welcome any extra information on use cases.


> >[...] it is not very useful
> > unless it can track a "tree" of image versions and allow several nodes in
> > the tree to be visible "current" images.
> 
> Although our usage method is in fact a tree (several different mods all
> starting from the original image), there are few enough nodes that storing them
> in a linear fashion is acceptable.

I don't really understand what you mean by "storing in a linear fashion"
in this context or trees of edits. (Oh, and I mean "not very useful to me".)

>> That is why Gilles declared that png is better, and png seems to be the most
>> likely candidate, not jpg.

>Can the Exif/IPTC/XMP metadata be maintained in the PNG?

Yes definitively.

To convince you try this way :

#convert foo.jpg foo.png     (where foo.jpg has Exif/iptc/xmp)
#convert foo.png foo2.jpg

and look with Exiftool or Exiv2 in foo2.jpg. All still there

You can do the same to check foo.png.

in digiKam and Exiv2 i have implemented full support of PNG metadata. It's better than tiff because all metadata are stored in a dedicated place. Iunlike tiff, we don't mix Exif image informations with all Exif photo informations.

In PNG whole Exif byte arry is stored in a dedicated chunk. Same for IPTC, and XMP. There is not confusion possible as with TIFF. TIFF is really a mess... This is why it not fully supported properly in all photo software.

Gilles Caulier

> I, for one, would welcome any extra information
> on use cases.

I asked on the F-Spot list, but nobody has answered:
http://mail.gnome.org/archives/f-spot-list/2009-June/msg00007.html

> I don't really understand what you mean by "storing
> in a linear fashion" in this context or trees of edits.

I mean that the available versions are shown as a flat list, not as a tree depicting versions' hierarchies (most versions started off from the original image).

F-spot stuff don't care about digiKam. Sound like a competition (:=))))

Gilles Caulier

At the risk of taking the bug OT, I must stand in defence of the F-spot community, they have been very helpful in the past. The name Stephane stands out.

(In reply to comment #41)
> > I don't really understand what you mean by "storing
> > in a linear fashion" in this context or trees of edits.
> 
> I mean that the available versions are shown as a flat list, not as a tree
> depicting versions' hierarchies (most versions started off from the original
> image).

I still don't see how that is in any way equivalent. If the list is
flat and "most versions" started off from the original image, then
what about the other versions, how can I tell where they came from?
With more than one "leaf" image, which leaf or leaves should be
displayed?

For example: I start with an image shot on a DSLR at a 3:2 ratio and
I create a version where I've fixed some red-eye. I then take this
new version from it I make two new versions that are crops: one in a
5:4 ratio (for a 10"x8" print) and one in a 7:5 ratio. What about the
following?

 1. How can a flat list indicate that the two cropped versions were
    both derived from the second version of the image unless there
    is some naming convention that makes it possible to derive this?
    Wouldn't a tree make it easier to visualise (even if the tree is
    just built by parsing the more complicated file names)?

 2. The only difference between the three new versions is the aspect
    ratio; all have the red-eye fix. Which one should be the displayed
    version of the image? If it is a landscape image, the 3:2 image
    would fit best on my wide-screen monitor. For portrait, the 5:4
    image would fit best. However, the 7:5 image was the last version
    I created, so is that one shown? Maybe I'd like the 5:4 ratio
    image in landscape because the cropping improved the composition.

 3. Do I have to create a copy of the image if I want to show more
    than one image? How would I trace the edit history of that if I
    wanted to see what changes I had made to get the new image. Is
    any link with the original file lost?

 4. [And so on.]

Maybe I'm over-thinking the whole thing, because I'm used to tracing
the history of source-code changes in trees in my day job and in my
free time I tend to make lots of different versions of key photos with
different orientations, crop areas and aspect ratios, so revision control
(like with RCS) with branching would be second nature to me.

I still think it is worth looking at something like RCS to control file
versions, as it would be easy to insulate the user from the details and
it could operate linearly by default. Branching functionality could be
implemented in a later release, but at least it would be a logical
extension of the chosen approach and would not rely on potentially
confusing and conflicting file names or lock users in to the digiKam
database or naming scheme.

RCS (or a similar approach) could meet your use cases today and meet my
use cases tomorrow. I think it would be the best way to keep our options
open, as it would be an open and solid foundation for a variety of
different version control schemes; from the simplest scheme to start
with to a more advanced, branching scheme with annotated revisions and
visualisations in the future.

If processing power was not a limitation, RCS could control many versions
of a script containing the edit decision list and any version or versions
could be applied to a single copy of the original image to render the
image on-the-fly. Potentially, such a rendered image could be saved to a
cache and named using the RCS revision number. If such an image was marked
to be displayed all of the time (such as when I want two edits of the same
original image to be displayed), then it could remain in the cache, but
all non-displayed revisions would be discarded on exiting digiKam.

I've come across to many situations where revision control had to be added
to an application (in a completely different field from image management)
to know that rolling your own revision control is a real waste of resources
when there are so many good tools that can do it for you. RCS (which
underpins CVS for controlling individual files) is just one such tool that
could be used off-the-shelf. Maybe someone can suggest something equally
simple and robust. Whatever it is, I would dearly like to see a solution
that at least has the potential to grow into the best revision control
system in an image management application even if it starts out simple
with a single, linear HEAD branch. You could skip all of the debates about
the perfect file naming convention or the most realistic use cases, because
the former is no longer relevant and the choice of the latter is not going
to limit future progress.

All of this should also be looked at in the context of grouping photos
together, a very popular wish list item (bug #121310). Which solution to
revision control would work best with a solution to grouping? If we group
based on file naming conventions (for some groups, such as joint JPG+RAW
shooting), then would a version naming conventions make things hopelessly
complicated? Maybe it wouldn't, but I'd bet that something like a single
RCS file would be easier to accommodate.

> I still don't see how that is in any way equivalent. If the list is
> flat and "most versions" started off from the original image, then
> what about the other versions, how can I tell where they came from?
> With more than one "leaf" image, which leaf or leaves should be
> displayed?

The last revision would be the version shown, unless the user selects a different revision.


> Maybe I'm over-thinking the whole thing, because I'm used to tracing
> the history of source-code changes in trees in my day job and in my
> free time I tend to make lots of different versions of key photos with
> different orientations, crop areas and aspect ratios, so revision control
> (like with RCS) with branching would be second nature to me.

Yes, I suspect that you are overthinking it! Existing photo managers that support versioning just have a list of versions in the order that they were finished, without regard to how they started off. In reality, if the user is making so many versions of a photo that he needs revision control, then managing them in Digikam as versions of a single photo is not the proper workflow. The intention of versioning in Digikam is to let the user make some small touchups (correct redeye, straighten photos) and save them without erasing the original image. It does not need to be overcomplicatd to revision control.

I just want to add my vote to the F-spot approach (multiple files). We have to remember that digikam is not the only application used for photos. Naming the files sensibly (e.g. by appending "Modified (1)" etc.) makes it pretty easy to understand in other applications.

Relationships should be stored in metadata tags as discussed above.

- One more feature, I would like integrated in this:
My camera stores 2 pictures every time I click the shutter: one JPEG and one RAW. This is very useful in that I don't have to do any raw work on pictures that don't need it. The files have identical names except for the extension (.JPG or .CR2). I would like digikam to recognize that those 2 files are two versions of the same picture and only one of them should show in the album browser. Tags and ratings that I apply should be applied to both.

I am really looking forward to the versioning feature. I need it greatly right now!

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

you might want to look at exiflow http://exiflow.org/wiki/Description_of_exiflow I am using f-spot with the exiflow extensions, and works pretty nicely.

I would love to give digikam a try, but I would hate to give up this nice version management.

@sbahling:
The site that you linked to has been unavailable since the day you posted. Please describe the features that you like here. Thanks.

The exiflow wiki link seems to be working again. The main features that I use are:

1) Filenaming - exirename creates converts my default camera file names to something more usable with date, camera ID, user initials etc... The naming scheme is user configurable. I currently do this as a batch command line operation, and I can use it with digikam as is. The workflow is like:

- gphoto2 (get photos from camera)
- exirename
- f-spot (or digikam) import

2) Recognition of photo versions. The exiflow file naming scheme appends a 3 digit version to the end of the file name. The exiflow f-spot plugins recognize and manage version based on this file naming and represent the separate files as different versions of the same photo within f-spot.

Already exiflow recognizes the .nef/.jpg pairs that come from my Nikon as "versions" of the same photo, names them appropriately, and I manage them in f-spot nicely.

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

Versioning is implemented with 2.0. All if you interested are invited to test the betas.