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

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





--- Comment #44 from DGardner <dkde gardnersworld org>  2009-06-15 19:55:30 ---
(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.

--
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