Re: image versioning development

[Gilles Caulier-4]

I fork this mail to digikam-devel mailing list. please continue at this place (all people are registered here)

2008/12/1 Marcel Wiesweg <[hidden email]>

> Hi Marcel,
> I'm interested in implementing image versioning in Digikam (which is
> discussed in bug reports such as
> http://bugs.kde.org/show_bug.cgi?id=142056 and
> http://bugs.kde.org/show_bug.cgi?id=125387).
>
> After talking to Gilles Caulier (see the IRC log below) I decided to
> start with implementing a simple versioning method. I envision this
> working as follows:

> the digikam image editor) (by default) the original file is not
> touched (the user should still have an option to overwrite the
> original). Instead, the modified image is saved as a new file (with
> some version info encoded in the filename). Additionally, some sort of
> relationship (probably parent->child) is recorded in the database to
> let digikam know which image is the original and which one(s) is(are)
> the derivative(s). The digikam preview can use this relationship
> information to always display the latest version of the image (or
> whatever version is selected by the user).
>
> As Gilles suggested, I examined the project/DBSCHEMA.ODS file. I did
> not quite understand the contents of that file, but I found a
> 'relation' property under the "Dublin Core property". After doing a
> quick search for "dublin core" I found this:
> http://www.loc.gov/standards/mods/v3/mods-userguide-elements.html#relatedit

>em . Given this information, I suspect that this is the right kind of

> property (relatedItem and relationType) that we need to record in the
> digikam database to implement the above simple versioning. In any
> case, please let me know whether the current DB schema includes
> support for recording "version" information about images. If there is
> nothing like this, then please provide me with some pointers as to how
> I can make that happen.

http://wiki.kde.org/tiki-index.php?page=Digikam+development+discussion

If you read this page in the version of yesterday you may note that it
describes initial drafts of the changes we introduced for 0.10, with the
exception of versioning and storing actions.
The reason is simple, it was too much work for us to do everything at one
time.
Instead, versioning/storing of actions we postponed to a later version. The
current database schema does _not_ include any of the proposed tables, but we
have now (we did not before) the possibility to upgrade the DB schema, both
backward compatible or incompatible.
Such a change is possible, but should not be done for every minor version. The
team need to decide on that, but I would suggest not to change the schema
before 0.11, so that all 0.10.x versions are compatible in all directions.

I have updated the above mentioned wiki page to a current status. There are
suggestions for database tables, my experience with 0.10 shows that initial
drafts are pretty good but actually implementing the functionality usually
requires changes in some details.

A first thing to do (which requires no DB work) is devising a naming scheme to
store edited images with a different file name and implement the
corresponding behavior in IE as you describe here:

> every time the user edits and saves an image (in
> the digikam image editor) (by default) the original file is not
> touched (the user should still have an option to overwrite the
> original). Instead, the modified image is saved as a new file (with
> some version info encoded in the filename)

Your second step:

> Additionally, some sort of
> relationship (probably parent->child) is recorded in the database to
> let digikam know which image is the original and which one(s) is(are)
> the derivative(s).

I would opt to do this right the first time instead of implementing some sort
of workaround with the current schema.

If you really want result in short term, you can do a workaround using the
ImageProperties table which allows to store any information in key/value
pairs for an image.

>The digikam preview can use this relationship
> information to always display the latest version of the image (or
> whatever version is selected by the user).

This depends on DB integration obviously.

There is more work, the most tedious part, not in terms of innovation but of
mostly copy and paste, would be adapting the image plugins (because of their
number)

>
> Additionally, it's not necessary at this time, but I would appreciate
> if you could answer the other questions that Gilles mentioned in the
> IRC log below.
>
> IRC Log:
> < abaecker> Plouj, maattd: the "action list" is discussed bug 125387
> < Plouj> thanks abaecker
> < high_lap> I suppose you all know the picasa way :) creating a
> "original" folder with the original. and small changes (color
> lightning) are stored in a text file with info how to undo it
> < abaecker> Plouj: but it seems that the most detailed plan is
> discussed/outlined in the link you found above
> (http://wiki.kde.org/tiki-index.php?page=Digikam+development+discussion)
> < abaecker> Plouj: but that's of course a non-trivial piece of work ....
> < cauliergilles> abaecker, Plouj, maattd: i'm back now
> < cauliergilles> Plouj: to respond to your question "what advantages
> do the users get from the second approach, and are those advantages
> worth the development effort?"
> < cauliergilles> Plouj: to remember second way is Action List
> < cauliergilles> Plouj: the advantage to implement Action List is not
> only to perform versionning
> < cauliergilles> Plouj: with action list, i can implement easily a
> Batch Queue Manager
> < cauliergilles> Plouj: for ex : i assign to one image more editor
> action on the same time. Put the image to process in a queue, start
> it, take a coffee, and when i'm back , all is done
> < Plouj> so, even from a developer point of view, this is a more desirable
> way < cauliergilles> Plouj: you can also copy and paste action List from
> one item to another one (dixit BibblePro)
> < cauliergilles> Plouj: so, versionning stuff is a right way for you,
> to implement something in digiKam
> < cauliergilles> Plouj: so, now, if i compare PNG versionning and
> Action List, the first is more easy to implement, more fast but need
> more free space on HDD

What is PNG versioning? Simply storing a new file for every edited version?

yes, it is. PNG is already used to manage undo/redo operation in editor.

PNG is lossless, and support all metadata for backup purpose.

Perhaps later, we can use another file format based on wavelet compression as OpenEXR (better ratio compression than PNG).. But i need to write an image loader for digiKam core. it's planed

The question is where to store PNG file for versioning ? in local albums (where original images are), or in a dedicated place to optimize space of collections... The question still open. We need to look wanr is right and what is wrong in both case...

Gilles

Note :please use Mailing list. it's better for visibility and it's archived (:=)))

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel