[KPhotoAlbum] Suggestion: Relations between images

Paul Fleischer paul at xpg.dk
Thu Jan 31 22:06:49 CET 2008

Hi again,

I have been silent for a while, but I'm still here and still thinking
about image groups/hierarchies. Having played around with my own two
patches I somewhat got in doubt whether the approaches in them is the
most suitable. So, I'll spend some time thinking rather than coding. I
have come up with a new shiny concept: RELATIONS. Now, let me start by
saying that this might be utterly crap, and if you think so please let
me know. But I got the idea and feel that it should be shared. No
matter how bad it might be in reality.
That being said, of course currently I think it is a extremely good concept :-).

The basic idea of relations is to relate images to each other
using one-to-one relations. Such a relation has two names assigned, one
for each image in the relation.  For instance, a relation between a RAW
image and a JPEG generated from the RAW image could have the RAW image called
"Raw" and the JPEG file called "Exposure". We will call this a "Raw<->Exposure"
Another relation could be between an image composed from multiple images.
The composed image could have a "CompositeParent<->CompositePart" releation with
each of the images it was composed from (being at the CompositePart end in
all cases).

This kind of one-to-one relation is not very well suited for flat-grouping.
For instance, if one has taken 5 images by paning, these could be grouped
as being part of the same panorama. If there is no single image generated from
the 5 images the approach used with a composed image above cannot be used here.
One way to group these 5 images using the relation concept, would be to create
a "PanoramicSibling<->PanoramicSibling" relation between all of the images.
However, this results in a rather big amount of relations. A more clever way
would be to use the position between the panorama images for the relations.
So, a number of "PanoramicLeft<->PanoramicRight" relations.

Relations are to be defined much in the same way that categories are currently
defined. They must thus be defined before they can be used.

I have created a mock up of how this could be implemented in the user
interface (see attached image). We have the usual thumbnail view on
the left side, and a new "Relation View" on the right side of the
screen. When an image is selected, its relations are shown in the
Relation View, as can be seen in the mock up. The selected image is
centered in the view, and all of its direct relations are shown.
Indirect relations are shown as well, but smaller, like _igp5838.pef
in the mock up, which is related to the selected image through the

It is possible to drag and drop another image into the Relation View,
in which case a drop-menu is shown (the lowermost dialog on the mock
up). Here the "<->" button can be used to switch the relation
endpoints, while the "Select" and "Cancel" buttons do what you would

That's basically the relation concept.

I haven't given much thought to how it could be implemented. But on
the top of my head I would say that it is quite straight forward
except for the actual Relation View. As far as I know there is no
generic graph component for QT/KDE, which means that we might have to
implement all the layout stuff from scratch. But then again, I haven't
investigated it much.

Thank you for your attention.
Do please let me know what you think.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: RelationView.jpg
Type: image/jpeg
Size: 186470 bytes
Desc: not available
Url : /mailman/pipermail/kphotoalbum/attachments/20080131/27b6e3e7/attachment-0001.jpg 

More information about the KPhotoAlbum mailing list