[Bug 142056] Save changes of image modifications with Versioning.

https://bugs.kde.org/show_bug.cgi?id=142056


DGardner <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]




--- Comment #37 from DGardner <dkde gardnersworld org>  2009-06-03 17:05:24 ---
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.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel