[Digikam-devel] image versioning development

Gilles Caulier caulier.gilles at gmail.com
Mon Dec 1 19:01:20 GMT 2008


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

2008/12/1 Marcel Wiesweg <marcel.wiesweg at gmx.de>

> > 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
(:=)))
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20081201/6634d28a/attachment.html>


More information about the Digikam-devel mailing list