Digikam/GSoC2010/NonDestructiveEditing

"Never touch the original"

Parts needed in the foundation:

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

Basically XML file in image metadata (using XMP)
Use OpenRaster specification as a basepoint for changes description - http://create.freedesktop.org/wiki/OpenRaster
A changeset (editing operation) will classify into one of these categories:
- Reproducible/Repeatable: when given the set of stored parameters and the original data, an identical result will be produced. (majority of digikam's image plugins)
- Complex: The operation is documented and a number of parameters may be known, but the identical result cannot be reproduced. (strictly, any operation involving random data, like raindrop, distortion, blurfx and filmgrain. Possibly also any operation involving a very complex algorithm, like inpainting or local contrast, where new versions are likely to alter results)
- Documented History: The source images are known, a textual description may be added, but there is no way to automatically replay (typically, editing with external tools like Gimp or panorama stitching. Relation may need to be added manually by the user)
see below for some thoughts on how to refer to existing files in this format

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

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

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
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.
- See below for detailed suggestions
- note the requirement of a "two-dimensional" naming - lines of development (alternative edited versions), and revisions (steps, versions) in this line of development

the original is stored, untouched. (if metadata access is allowed, write unique ids of type 1+2, see below)
A format is selected as "workspace format". By recommendation a lossless format: PGF, PNG, TIFF; if really wanted, also JPEG.
From any original, multiple lines of development/alternative edited versions can be started. Each of these lines has a current version and optionally intermediate versions stored on disk.
- Language usability problem: what is a version - a full line of development, or a single revision in this line? Need native speaker input.
Each file on disk records in its metadata all changes leading from the original to itself. The original contains no versioning metadata, the current version all applied operations.
The current version is always stored on disk in workspace format.
intermediate revisions are generally not stored, unless necessary; that is, results of "Reproducible" editing operations are not stored, results of "Complex" and "Documented History" operations are optionally stored (setup option, need to decide on default value: Off?)
special case Raw import: The result is the current version. When downloading RAW+JPEG from a camera, the relation must be recorded. Raw import is a "Complex" operation. When editing this current version, the rules for intermediate revisions apply.
Original and intermediate files on disk are hidden in digikam's UI

In a format describing changes from an original file over intermediate results to a current version, the previous files need to be uniquely referred to
for intermediate versions we can expect to be able to write to the metadata. For original images, we cannot guarantee this.
full-file hashes as used by git are very elegant for version management, but fail in our case: We modify the metadata all the time, changing the hash. For the same reason, the smaller uniqueHash currently in use by digiKam is not suited for this purpose. A hash on only the image pixel data is currently technically not available (and would require support for each image format separately)
there can be metadata fields with unique ids (Exif.Photo.ImageUniqueId). These can have two different meanings:
- 1) showing that a group of different pictures result from the same original (simplest case, groups a RAW with the corresponding JPEG)
- 2) uniquely identifying a single picture version
Suggesting a combined approach:
- Use a unique id (type 2), added to the metadata on modification, or, if allowed, on import of original. Caveat: Will not be changed when editing externally.
- Use filename, creationDate or unique id (type 1) for identifying original pictures