browsing web albums directly - and versioning

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

browsing web albums directly - and versioning

Per Bothner
This is a high-priority wishlist item.  I'll copy it into
BugZilla, but first I thought I'd ask if anyone else has a
similar issues/workflow, and might have different ideas.
(I can think of using symlinks or sub-directories for
scaled images, but neither are appealing.)

I organize my photos into web albums, which I publish directly.
I.e. Each directory contains full-size images, scaled images,
and generated html files , along iwth an index.xml descriptor file.
See:  http://www.gnu.org/software/qexo/qalbum/
An example album:
http://pics.bothner.com/2006/NCAprStuck/index.html

Using a photo organizer like digikam (or gthumb or gqview,
which I've used in the past) is useful for getting an overview
and classifying the images.  But as soon as I've generated
scaled images or done any transformation I have duplicate
images based on the same photo, and it's a mess.

This ties in with the previously-requested "versioning" feature,
as done in f-spot.  But in my case the versions are thumbnails
and other scaled versions.  If digikam supports multiple
versions, it would be solve my problem, and make it more
useful in general.

The first issue is a naming convention.  When f-spot
edits a file "PATH/NAME.jpg" it renames it to
"PATH/NAME (Modified).jpg".  A problem is that space is
not valid without escaping in a URL, and it seems in general
a bad idea to insert spaces without user request.  So I
suggest just dropping the space: "PATH/NAME(Modified).jpg".
Or more-generally:
   "PATH/NAME(VERSION-NAME).jpg"

I suggest allow arbitrary VERSION-NAME, but standardizing
at least the following names:
   "Original"
   "Rotated" (usually rotation of the original)
   "Modified"
   "Modified-NUMBER"
   "ScaledNNN" (scaled to fit in a NNN*NNN box)

When editing an image, there can be a user preference for
the default new name, but the default might be:
(1) If there is a Modified-N version save the file as Modifier-M
where M=N+1.
(2) If there is a Modified version, and an Original version,
save the name version with the Modified version.
(3) If there is a Modified version, and no Original version,
rename the old file to Original, and save it as Modified.
(4) Otherwise, depending on user preference
   (a) save the old version as Original, and save the
   new version under the old name.
   (b) keep the old version with the original name, and save
   the modified version as Modified.

Or something like that - I haven't really figured out the
Right Thing in all cases.

In an album view if there are multiple (VERSION) modifiers
for files with otherwise the same filename, the priority
order should be:
   Modified-N (for the highest number N)
   Modified
   no VERSION specified
   Original

When viewing an image, there would be a selector (like in f-spot)
to select between versions.  If there is a file without an
explicit VERSION, it can be listed as Original if there is
no file explicitly named (Original); otherwise Modified if
there is no file name Modified; otherwise "(unnamed version)".

The album view could have a widget to select versions:
Original, Modified (newest), or All.  If images are selected, the
selector widget could show all the versions for the selected
images.  If a selected image has no version matching the
selected version, the display could be something like
"no VERSION for xxx".
--
        --Per Bothner
[hidden email]   http://per.bothner.com/
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users