[Digikam-devel] Managing multiple data for the same picture

Leonardo Giordani giordani.leonardo at gmail.com
Mon Aug 29 18:45:21 BST 2011


Hi all,

is there already a discussion about managing multiple derived pictures
produced for the same original image?
I cannot find it in issues or in the ML so I try to describe it.

My workflow produces several files for each source raw.

The minimal amount are 3 files: raw picture, the processed full frame
TIF not sharpened and the same sharpened and cut with my aspect ratio
of choice, in JPEG format.
But if I want to print the picture I save a new version with different
processing: I found the "good" sharpening and color balance parameters
to obtain the correct print at the shop (no color profiles for the
printer, and no monitor calibration, sadly).
Moreover, if I find something wrong in the image, or if I want to
develop some special processing, I save it and process it with The
Gimp for example, so I can also have one or more intermediate images,
produced outside digiKam.

Potentially there is a bunch of pictures for each raw (or whatever
source you have).

Problems that arise:

1. I have multiple copies of the same image in the main view.
Now we added the format label (thank you!) but I can produce 10 JPEGs
with different cropping ratios, so this does not solve this problem.
Now I rename each image I save with a complex scheme
(<name>_L<processing_level>_R<aspect_ratio>, sorry but its the only
solution I found :) ), but the overhead of saving with the correct
name is very high and error prone. (I think the save interface can be
improved, but this is not the problem now.)
My images have different names that allow me to identify the correct
one, but in the main interface it is impossible to tell two images
apart without selecting them and looking at the name on the bottom
status bar, since names are long.

This is ugly and confusing. If I interrupt the workflow it is
difficult to find the last image since not always the workflow levels
are alphabetically ordered.
When I want to export all my beautifully cropped JPEGs to prepare a
slideshow I have to do complex searches, sometime its faster to
perform a find in bash.

Name schemes, searches and workflow management is something a computer
can do better than me, so here there is room for improvements :)

2. When I use an external program to develop my picture (say, The
Gimp, but could also be PS under Wine or whatever) I cannot take
advantage of tags and stars managed by digiKam. I have to first save a
copy of the image and then open it with an external program, so that
digiKam is already aware of the picture.

Again, this is something a computer can do better than me.


I find the solution implemented by Calibre (http://calibre-ebook.com/)
very interesting. Calibre manages e-books, which come in different
formats, e.g. EPUB, PDF, DOC, LIT, etc. This is similar to our digiKam
scenario, with pictures instead of e-books.

For each imported book Calibre creates a directory where all different
files belonging to the same e-book are stored. The files are saved
with a custom name decided by Calibre and hidden to the user. When
books are exported (saved) to disk Calibre saves them with a custom
name scheme the user can configure with a printf()-like technique,
just like the powerful renaming interface implemented in digikam.

This way I see just one entry for each book in my UI and, when
clicking on the image, a window shows me the different formats,
allowing me to do what I want.

I shall mention that a similar solution opens the way to "programmable
workflows". I could say to digikam: listen, I develop a raw and save
it tagged as "unsharpened" (here I use tag in a workflow sense, not
related to digiKam picture tags). Then I develop this latter either
with an external program and save it tagged as "external processing".
Since digiKam is aware of this it could make a copy of the image for
me with the new name and open with Gimp automatically. And so on.

I do now want to go too far now, but I find this scenario very
interesting and more oriented to complex workflows, since digiKam is
already far beyond a simple album manager.

What do you think about this?

Thank you very much

Leo



More information about the Digikam-devel mailing list