Digikam/GSoC2010/NonDestructiveEditing: Difference between revisions

Newer edit →

Revision as of 17:41, 6 March 2010

"Never touch the original"

Parts needed in the foundation:

The format to store changes
Adapting digiKam's plugins and filters
Storing change information in image metadata and internal database
Naming scheme for versions of new (modified) images

Parts needed in the UI:

No more Save/Save As in the image editor, automatically save as new version
Some sort of menu to choose the image version - original, modified, modified_2 etc.
Menu/button for exporting the modified image
Stacks of images (original/current version) in the album icon view --needs some thinking
Widget to display version history - a tree view with buttons to show information would be nice

Details of foundation parts

1. The format to store changes

Basically XML file in image metadata (using XMP)
Use OpenRaster specification as a basepoint for changes description - http://create.freedesktop.org/wiki/OpenRaster

2. Adapting digiKam's plugins and filters

We need to have an interface in EditorTool to get the serialized operation that has been applied
From an image plugin, we need a list of filter names that are supported, and a way to execute a described operation on a given image
Plugins will have to have unique name composed of filter name and some unique part (as there can be two plugins with same name) and also plugin version will be stored (as newer versions can have different parameters)
Naming like < ... name="digikam:charcoal-hbr9Gh" version="2" > with version stored as another parameter for better parsing

3. Storing change information in image metadata and internal database

Use XMP - defining a custom namespace and writing our changes
Use OpenRaster specification as a basepoint for changes description - http://create.freedesktop.org/wiki/OpenRaster
Always store the latest version (the current) in a normal file - good for thumbnailing and editing with external apps like Gimp
If user edits some exotic format or unsupported RAW, or if he edits a read-only file on a read-only device, ask him, where to store the changed file
Create some small wrapper classes to read/write that format

4. Naming scheme for versions of new (modified) images

New files will be put next to the original with just modified name
Names will be without spaces and not a translatable string if possible (because of possible non-ascii chars, which may cause problem on some other systems)
For example image01.jpg (original), image01_v1.jpg (first version), image01_v2.jpg (second version) and so on

@@ Line 1: / Line 1: @@
-&nbsp;Expected results:
+''"Never touch the original"''
-<div><br></div><div>Define a format to store editing operations - research existing standards or similar free software approaches, or come up with a home-made XML format.</div><div></div><div>Adapt the existing image plugins to read and write their settings from this XML format and to re-apply a described operation to a given image (this is a laborious but relatively easy task)</div><div></div><div>work together with your mentor on storing version history in digikam's database and the image's metadata. (this is needed to finish the project, but it's not the core of the student's work). Set up a simple file naming scheme to store the original and derived files.</div><div></div><div>Implement the user interface changes: No more Save/Save As in the image editor. Instead, saving as current version, forking a new version, or exporting. Stacks of images (original/current version) in the album icon view.</div><div></div><div>Build a widget to display version history. Optionally this is a really nice widget, a tree view with buttons to show information. Optionally there is also support to take a set of applied changes, store it and apply it to a different image.</div>
+== Parts needed in the foundation:  ==
+#The format to store changes
+#Adapting digiKam's plugins and filters<br>
+#Storing change information in image metadata and internal database
+#Naming scheme for versions of new (modified) images
+<br>
+== Parts needed in the UI:  ==
+#No more Save/Save As in the image editor, automatically save as new version
+#Some sort of menu to choose the image version - original, modified, modified_2 etc.
+#Menu/button for exporting the modified image
+#Stacks of images&nbsp;(original/current version) in the album icon view --needs some thinking
+#Widget to display version history -&nbsp;a tree view with buttons to show information would be nice
+<br>
+== Details of foundation parts  ==
+=== 1.&nbsp;The format to store changes  ===
+*Basically XML file in image metadata (using XMP)
+*Use OpenRaster specification as a basepoint for changes description - http://create.freedesktop.org/wiki/OpenRaster
+=== 2. Adapting digiKam's plugins and filters  ===
+*We need to have an interface in EditorTool to get the serialized operation that has been applied
+*From an image plugin, we need a list of filter names that are supported, and a way to execute a described operation on a given image
+*Plugins will have to have unique name composed of filter name and some unique part (as there can be two plugins with same name) and also plugin version will be stored (as newer versions can have different parameters)
+*Naming like&nbsp;&lt; ... name="digikam:charcoal-hbr9Gh" version="2" &gt; with version stored as another parameter for better parsing
+=== 3.&nbsp;Storing change information in image metadata and internal database  ===
+*Use XMP - defining a custom namespace and writing our changes
+*Use OpenRaster specification as a basepoint for changes description -&nbsp;[http://create.freedesktop.org/wiki/OpenRaster http://create.freedesktop.org/wiki/OpenRaster]
+*Always store the latest version (the current) in a normal file - good for thumbnailing and editing with external apps like Gimp
+*If user edits some exotic format or unsupported RAW, or if he edits a read-only file on a read-only device, ask him, where to store the changed file
+*Create some small wrapper classes to read/write that format
+=== 4.&nbsp;Naming scheme for versions of new (modified) images  ===
+*New files will be put next to the original with just modified name
+*Names will be without spaces and not a translatable string if possible (because of possible non-ascii chars, which may cause problem on some other systems)
+*For example image01.jpg (original), image01'''_v1'''.jpg (first version), image01'''_v2'''.jpg (second version) and so on<u><br></u>