possibly support multiple versions of photos
Submitted by Adam Dingle
Link to original bug (#716521)
Description
---- Reported by adam@yorba.org 2010-08-23 09:43:00 -0700 ----
Original Redmine bug id: 2474
Original URL: http://redmine.yorba.org/issues/2474
Searchable id: yorba-bug-2474
Original author: Adam Dingle
Original description:
A suggestion from Bruno Girin:
So while on the plane back, I came up with a high-level design for the support of multiple versions of photos, with some versions being stored physically on disk, others being a set of changes stored in the database. You'll find attached a wireframe of what it could look like.
My first principle is that it should be fully transparent and not change current Shotwell behaviour for users who are happy with a single original and a single modified version. The core is two differentiate between two types of library photos:
- Physical photos: photos that are only and fully described by the file on disk, such as the original file or any file created by modifying the photo in an external tool;
- Virtual photos: photos that are described by a previous version and a set of transformations stored in the Shotwell database (with potentially a back-up on disk).
The idea is then if you start applying modifications to a physical photo, Shotwell automatically creates a new version so that every physical photo is considered like a negative that shouldn't be modified. When applying modifications to a virtual photo, no new version is created and transformations are added to the database. This basic behaviour would support the current way that Shotwell operates.
Then add the following features:
Through the version pane, allow the user to go back to a previous version and update that version, so you could do something like the following:
- Import a photo: v0
- Apply a black & white filter to it => v1
- Revert to v0
- Apply a sepia filter to it => v2
Also allow the user to “freeze†a version a virtual photo: that version is now considered the same way as a physical photo and any modification to it creates a new version, allowing you to do the following:
- Import photo: v0
- Enhance contrast, sort out red-eyes, etc. => v1
- Lock v1
- Apply b&w filter => v2
- Revert to v1
- Apply sepia filter => v3
- Lock v3
- Crop v3 => v4
- etc.
The last piece in the puzzle if how to store several versions of the same photo on disk. I'd suggest to keep it simple:
- Original (v0): image.ext, e.g. IMG1234.%(=caps)JPG%
- Others: image_version.ext, e.g. IMG1234_001.%(=caps)JPG%
Related issues:
- related to shotwell - Feature #2090 (closed): Photo stacks (Open)
- related to shotwell - Feature #4184 (closed): Journal transformations and edits (Open)
- related to shotwell - Feature #3382 (closed): Also show unmodified master of photo (Invalid)
- duplicated by shotwell - Feature #6033: support multiple edited versions (Duplicate)
---- Additional Comments From shotwell-maint@gnome.bugs 2012-03-27 19:31:00 -0700 ----
History
Comment 1
Updated by Adam Dingle over 3 years ago
- Subject changed from support multiple version of photos to possibly support multiple versions of photos
Comment 2
Updated by andreas - over 2 years ago
- Keywords set to versioning
Cross linking #3382 (closed) (Also show unmodified master of photo) which is a much simpler scenario of this.
Comment 3
Updated by Piergiorgio Traversin over 1 year ago
- Description updated (diff)
I'd like to add to the versioning scheme: there is already a piece of software with a scheme I find interesting, called exiflow (http://exiflow.org). They provided a plugin for f-spot that was using their version scheme instead of the IMHO quite annoying original one (that was adding spaces and several levels of "(" to the file name, à la Windows).
In the exiflow versioning scheme 000 is the original file, 100 a first version, 110 a version of the 100 version, 200 a second version of the original and so on. http://exiflow.org/wiki/Description_of_exiflow#Are_filenames_important.3F
In the Bruno scheme, the 'freeze' would be equivalent to a 'save', a point in the editing history where we give the new version number to the edited photo, e.g. IMG_1234-100.JPG. Then we can decide to go on editing the newly created version (obtaining an IMG_1234-110.JPG) or make different changes to the original one, ending up with an IMG_1234-200.JPG.
Ideally, one should see only the last version, with the others being available via (for instance) a right-click menu.
--- Bug imported by chaz@yorba.org 2013-11-25 21:46 UTC ---
This bug was previously known as bug 2474 at http://redmine.yorba.org/show_bug.cgi?id=2474 Imported an attachment (id=261724)
Unknown Component Using default product and component set in Parameters Unknown version " in product shotwell. Setting version to "!unspecified". Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. Resolution set on an open status. Dropping resolution