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

[Dotan Cohen]

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


Dotan Cohen <kde-3 at dotancohen.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kde-3 at dotancohen.com




--- Comment #38 from Dotan Cohen <kde-3 dotancohen com>  2009-06-07 20:07:49 ---
> 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.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.