[KPhotoAlbum] Suggestion: Relations between images
Jesper K. Pedersen
blackie at blackie.dk
Fri Feb 1 08:50:36 CET 2008
Hi Paul, great work.
I was slightly puzzled about your use of "one-to-one", couldn't it easily be
one-to-many? Like Original<->"list of manipulated images"?
A problem I personally have that might or might not be solved with this (I
just bring it to your attention thats all), is that sometimes I have like 20
images more or less the same, I really just want one, but I can't make my
mind up, which. So here I'd like a way to say these 20 are all my dog chasing
its tale, and if I one day need a chasing tale image for something specific,
then I would find that one image in the thumbnail view, and would be able to
expand it into all 20.
Before you continue coding, may I bring to your attention that the days of the
Qt3 branch are counted, so you may wish to code against the Qt 4 one.
On Thursday 31 January 2008, Paul Fleischer wrote:
| 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" relation.
| 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.
Having trouble finding a given image in your collection containing
thousands of images?
http://www.kphotoalbum.org might be the answer.
More information about the KPhotoAlbum