Digikam/GSoC2010/NonDestructiveEditing: Difference between revisions

Revision as of 14:58, 10 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
mck182 - I would store changes like cropping immediately into new file as recropping image everytime it's displayed could be quite expensive

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
the user can choose a default image format to store his edits. By recommendation lossless (PNG, TIFF, PGF), if the user really wants, lossy (JPEG)
mck182 - When exactly will be the new files created? With every new modification to the original image (new modification of the original=new version)? I would let the first modification stay just in metadata, another new modification of the original would create _v1 file for the first modifications and the new modifications would go into original image's metadata. With another modification to the original image, dump the current modifications in metadata to _v2 file and write the new ones in metadata of the original etc etc. But that way we would also need something like _curr (current) version of the file for thumbnailing and working with other apps.
- My suggestion: For every version (independent line of development starting from an original image) there is a current version. In this file's metadata all editing steps from the original to the resulting file are described. Intermediate versions need not be stored, unless an editing step cannot be replayed automatically. Forking a new version can be done from any point in this line of development.
- this requires a two-dimensional numbering - lines of development, and step in this line of development

TODO

specify details of the format for storing changes
think more about the UI changes (would be great to involve usability team)
email Krita mailing-list for their opinion?

@@ Line 48: / Line 48: @@
 *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
+*the user can choose a default image format to store his edits. By recommendation lossless (PNG, TIFF, PGF), if the user really wants, lossy (JPEG)
 *mck182 - When exactly will be the new files created? With every new modification to the original image (new modification of the original=new version)? I would let the first modification stay just in metadata, another new modification of the original would create _v1 file for the first modifications and the new modifications would go into original image's metadata. With another modification to the original image, dump the current modifications in metadata to _v2 file and write the new ones in metadata of the original etc etc. But that way we would also need something like _curr (current) version of the file for thumbnailing and working with other apps.
+**My suggestion: For every version (independent line of development starting from an original image) there is a current version. In this file's metadata all editing steps from the original to the resulting file are described. Intermediate versions need not be stored, unless an editing step cannot be replayed automatically. Forking a new version can be done from any point in this line of development.
+**this requires a two-dimensional numbering - lines of development, and step in this line of development
 == TODO ==