[KPhotoAlbum] Very experimental image-grouping patch

[Jan Kundrát]

Tero Tilus wrote:
> Do we really need "hiding"?  Wouldn't tagging do the job?  If one
> wants to show only "final" versions, just narrow down to "production
> quality" tag.  ;)

Let me try to start with this one. Strictly speaking, given that we have
tags and can assign virtually unlimited amount of properties to an
image, there's no need to add "fancy stuff" like image grouping, image
relations, labels, dates nor EXIF data. We don't even have to support
searching based on directory information either, because all we have now
can be achieved by using tags.

That said, it would be PITA to handle from the user's point of view.
Let's try to focus on how to make things easy for users, from whom a
significant part would be photographers with zero background in Computer
Sciences :).

> Concept 1, "this image is derived from that one"

"Not worth the effort" is my opinion on this.

> Concept 2, "series of exposures"
> 
> But there is also another relation concept, "these photos are all
> exposures from the same arrangement".  This comes imho pretty close to
> what Paul has implemented.  If this really is what we are going to
> pursue, I'd suggest (and that's the most I can do, as I have no time
> to invest in implementing this) that the grouping would not be done
> using parent, but with assigning images a (KPA internal) group id and
> "hidden" flag.  That way one could group pics and select none, one or
> several "completed" versios, which would be shown by default.  Also
> I'd suggest we call them "groups" or "sets" of photos.

This is the way I like because I think it's quite intuitive for users.
It might make sense to finally introduce that "rating" category and use
it for initial selection of "mostly wanted" image.

But I do think that this use case is valid even for panoramas -- you
just add both source and stitched images to one group and select a
panorama to be the "default to be viewed".

> How to tag?
> 
> How (if at all) these relations should affect tagging?  Should we
> maybe have "Annotate Derivatives/Group" bound to Ctrl-3?  It would
> take the selected items and all their derivatives (or selected items
> and all items belonging to same groups with them respectively) and do
> "Annotate Multiple Items at a Time".

That's a very good question indeed and even this solution looks very
reasonable.

> What to show?
> 
> I think the question of how KPA should select what to show is mostly
> separated from the image relation concepts.

I wave the "don't over-engineer it" flag. We don't want to create and
support a brilliant solution that isn't used by anyone due to its
unintuitive nature.

Again, image grouping with choosing one (more?) of "to be shown" images
is the way to go here, IMHO.

> How (if at all) should
> the relationships affect image visibility?  And why should I be bound
> to select one and only one image to show from a group or a tree of
> derivatives?

Because that's probably the idea that started this whole discussion. You
want to filter out "uninteresting" images while having easy access to
them whenever the "final" image is shown.

Let's look at this example -- now we can tag photos with names of people
that are on them. When you launch a viewer and see an image of Anna,
InfoBox provides a link that will present a list of all images with
Anna. This is quite a similar situation, isn't it? Images of Anna have
something common among them, so they form a kind of group...

> And then, just to piss you off...  ;)

You can't :-P.

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kphotoalbum/attachments/20071129/5ae6b01a/attachment.sig>