I fork this mail to digikam-devel mailing list. please continue at this place (all people are registered here)<br><br><div class="gmail_quote">2008/12/1 Marcel Wiesweg <span dir="ltr"><<a href="mailto:marcel.wiesweg@gmx.de">marcel.wiesweg@gmx.de</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">> Hi Marcel,<br>
> I'm interested in implementing image versioning in Digikam (which is<br>
> discussed in bug reports such as<br>
> <a href="http://bugs.kde.org/show_bug.cgi?id=142056" target="_blank">http://bugs.kde.org/show_bug.cgi?id=142056</a> and<br>
> <a href="http://bugs.kde.org/show_bug.cgi?id=125387" target="_blank">http://bugs.kde.org/show_bug.cgi?id=125387</a>).<br>
><br>
> After talking to Gilles Caulier (see the IRC log below) I decided to<br>
> start with implementing a simple versioning method. I envision this<br>
> working as follows:<br>
</div><div class="Ih2E3d">> the digikam image editor) (by default) the original file is not<br>
> touched (the user should still have an option to overwrite the<br>
> original). Instead, the modified image is saved as a new file (with<br>
> some version info encoded in the filename). Additionally, some sort of<br>
> relationship (probably parent->child) is recorded in the database to<br>
> let digikam know which image is the original and which one(s) is(are)<br>
> the derivative(s). The digikam preview can use this relationship<br>
> information to always display the latest version of the image (or<br>
> whatever version is selected by the user).<br>
><br>
> As Gilles suggested, I examined the project/DBSCHEMA.ODS file. I did<br>
> not quite understand the contents of that file, but I found a<br>
> 'relation' property under the "Dublin Core property". After doing a<br>
> quick search for "dublin core" I found this:<br>
> <a href="http://www.loc.gov/standards/mods/v3/mods-userguide-elements.html#relatedit" target="_blank">http://www.loc.gov/standards/mods/v3/mods-userguide-elements.html#relatedit</a><br>
</div>>em . Given this information, I suspect that this is the right kind of<br>
<div class="Ih2E3d">> property (relatedItem and relationType) that we need to record in the<br>
> digikam database to implement the above simple versioning. In any<br>
> case, please let me know whether the current DB schema includes<br>
> support for recording "version" information about images. If there is<br>
> nothing like this, then please provide me with some pointers as to how<br>
> I can make that happen.<br>
<br>
</div><div class="Ih2E3d"><a href="http://wiki.kde.org/tiki-index.php?page=Digikam+development+discussion" target="_blank">http://wiki.kde.org/tiki-index.php?page=Digikam+development+discussion</a><br>
<br>
</div>If you read this page in the version of yesterday you may note that it<br>
describes initial drafts of the changes we introduced for 0.10, with the<br>
exception of versioning and storing actions.<br>
The reason is simple, it was too much work for us to do everything at one<br>
time.<br>
Instead, versioning/storing of actions we postponed to a later version. The<br>
current database schema does _not_ include any of the proposed tables, but we<br>
have now (we did not before) the possibility to upgrade the DB schema, both<br>
backward compatible or incompatible.<br>
Such a change is possible, but should not be done for every minor version. The<br>
team need to decide on that, but I would suggest not to change the schema<br>
before 0.11, so that all 0.10.x versions are compatible in all directions.<br>
<br>
I have updated the above mentioned wiki page to a current status. There are<br>
suggestions for database tables, my experience with 0.10 shows that initial<br>
drafts are pretty good but actually implementing the functionality usually<br>
requires changes in some details.<br>
<br>
A first thing to do (which requires no DB work) is devising a naming scheme to<br>
store edited images with a different file name and implement the<br>
corresponding behavior in IE as you describe here:<br>
<div class="Ih2E3d">> every time the user edits and saves an image (in<br>
> the digikam image editor) (by default) the original file is not<br>
> touched (the user should still have an option to overwrite the<br>
> original). Instead, the modified image is saved as a new file (with<br>
> some version info encoded in the filename)<br>
<br>
</div>Your second step:<br>
<div class="Ih2E3d">> Additionally, some sort of<br>
> relationship (probably parent->child) is recorded in the database to<br>
> let digikam know which image is the original and which one(s) is(are)<br>
> the derivative(s).<br>
<br>
</div>I would opt to do this right the first time instead of implementing some sort<br>
of workaround with the current schema.<br>
<br>
If you really want result in short term, you can do a workaround using the<br>
ImageProperties table which allows to store any information in key/value<br>
pairs for an image.<br>
<div class="Ih2E3d"><br>
>The digikam preview can use this relationship<br>
> information to always display the latest version of the image (or<br>
> whatever version is selected by the user).<br>
</div>This depends on DB integration obviously.<br>
<br>
There is more work, the most tedious part, not in terms of innovation but of<br>
mostly copy and paste, would be adapting the image plugins (because of their<br>
number)<br>
<div><div></div><div class="Wj3C7c"><br>
><br>
> Additionally, it's not necessary at this time, but I would appreciate<br>
> if you could answer the other questions that Gilles mentioned in the<br>
> IRC log below.<br>
><br>
> IRC Log:<br>
> < abaecker> Plouj, maattd: the "action list" is discussed bug 125387<br>
> < Plouj> thanks abaecker<br>
> < high_lap> I suppose you all know the picasa way :) creating a<br>
> "original" folder with the original. and small changes (color<br>
> lightning) are stored in a text file with info how to undo it<br>
> < abaecker> Plouj: but it seems that the most detailed plan is<br>
> discussed/outlined in the link you found above<br>
> (<a href="http://wiki.kde.org/tiki-index.php?page=Digikam+development+discussion" target="_blank">http://wiki.kde.org/tiki-index.php?page=Digikam+development+discussion</a>)<br>
> < abaecker> Plouj: but that's of course a non-trivial piece of work ....<br>
> < cauliergilles> abaecker, Plouj, maattd: i'm back now<br>
> < cauliergilles> Plouj: to respond to your question "what advantages<br>
> do the users get from the second approach, and are those advantages<br>
> worth the development effort?"<br>
> < cauliergilles> Plouj: to remember second way is Action List<br>
> < cauliergilles> Plouj: the advantage to implement Action List is not<br>
> only to perform versionning<br>
> < cauliergilles> Plouj: with action list, i can implement easily a<br>
> Batch Queue Manager<br>
> < cauliergilles> Plouj: for ex : i assign to one image more editor<br>
> action on the same time. Put the image to process in a queue, start<br>
> it, take a coffee, and when i'm back , all is done<br>
> < Plouj> so, even from a developer point of view, this is a more desirable<br>
> way < cauliergilles> Plouj: you can also copy and paste action List from<br>
> one item to another one (dixit BibblePro)<br>
> < cauliergilles> Plouj: so, versionning stuff is a right way for you,<br>
> to implement something in digiKam<br>
> < cauliergilles> Plouj: so, now, if i compare PNG versionning and<br>
> Action List, the first is more easy to implement, more fast but need<br>
> more free space on HDD<br>
<br>
</div></div>What is PNG versioning? Simply storing a new file for every edited version?<br>
<div></div></blockquote><div><br>yes, it is. PNG is already used to manage undo/redo operation in editor.<br><br>PNG is lossless, and support all metadata for backup purpose.<br><br>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 <br>
<br>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...<br>
<br>Gilles<br><br>Note :please use Mailing list. it's better for visibility and it's archived (:=)))<br></div></div><br>