[Digikam-devel] Re: Versioning, but not editing in digiKam

Mikkel Bækhøj Christensen mikkel at baekhoej.dk
Mon Nov 8 10:12:24 GMT 2010


On Fri, 2010-11-05 at 22:53 +0100, Martin Klapetek wrote:
> On Fri, Nov 5, 2010 at 16:56, Marcel Wiesweg <marcel.wiesweg at gmx.de>
> wrote:
>         
>         > 1. Most cameras are now able to create both RAW and JPEG
>         files at the
>         > same time. I think digikam should be able to recognize that
>         each
>         > RAW/JPEG pair is really just two versions of the same
>         picture. Maybe it
>         > could happen while importing from camera, but there should
>         also be an
>         > option to do automatic "version pairing" on existing
>         folders. I have
>         > thousands of these images.
>         
>         
>         It is not implement, but considered ;-)
>         Yes, this is one of the most obvious features we need.
> 
> 
> True. I still haven't looked into this one yet, though. Marcel, how
> can we detect if the RAW + JPEG are actually a pair? By filename is
> not enough, so I suppose by some metadata, right (because the camera
> itself also display the pair as one image)?
>  

I think that filename matching is good enough for now. The matching
doesn't have to happen automatically for the entire database. For me it
would be okay to have to apply a "Pair RAW/JPEG" operation manually for
each album. It is easy for me to ensure that the filenames match within
an album. A more automated system would be great, but the semi-automatic
version solves 99% of any cases I can imagine for myself. After we
finish applying versioning to our existing images, it could be an option
to do it automatically during import from camera. During import I think
that file name matching would be guaranteed to work.
 
>         
>         >
>         > 3. Someone mentioned somewhere that all the different
>         versions of an
>         > image are stored in the same folder. I hope that is not a
>         strict rule. I
>         > like to keep a repository with original images and then keep
>         my edited
>         > versions in a separate folder tree. That makes backups a lot
>         easier to
>         > manage. At the moment, that sort of workflow makes it
>         difficult to find
>         > the edited versions of the pictures, but the new versioning
>         feature will
>         > make it really easy! Whoo hoo! Assuming that I can save a
>         new version
>         > somewhere else.
>         
>         
>         I am planning to make this configurable, but I think Martin
>         may correct me
>         there is not much configurability atm. At least for automatic
>         saving. Maybe we
>         need a way to specify the file location of the saved file
>         manually.
> 
> 
> Yes, there was an idea for that, but I dropped it later, because of
> switching the images. If you move any image from the relation anywhere
> else, you still have it in the sidebar among the available versions,
> but you can't switch to it, because it would need to switch the album
> as well. Also it would break the concept of "current-version" that we
> had back then. Now when you can have more than one "current" image, it
> could be done I suppose. Actually, this could also be achieved kinda
> easily. But - What do you think, is switching albums ok? I mean you
> select a version from the sidebar which is not in current album, so
> the album will change and you will have selected the desired version.
> I'm just afraid that this could seem a little chaotic to some users
> (suddenly all the pictures are gone and they see some bunch of other
> images etc).
> 

As I see it, switching albums is not a problem. When I get versioning, I
probably won't even be looking at my pictures in album view. Most of the
time I would probably be using the Tag view instead. In that case, no
switching would be visible, because all versions would probably have the
tag that I use to select them.

> Martin

Thank you very much for your work on this!

Mikkel




More information about the Digikam-devel mailing list