Bug 146337 - Tag regions of an image
Summary: Tag regions of an image
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Tags-Engine (show other bugs)
Version: 1.3.0
Platform: Gentoo Packages Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-06-04 08:16 UTC by Christian Weiske
Modified: 2012-06-27 10:23 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In: 2.0.0


Attachments
Suggestion for UI made during coding sprint (451.91 KB, image/png)
2010-04-28 20:14 UTC, Michael G. Hansen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Weiske 2007-06-04 08:16:31 UTC
Version:            (using KDE KDE 3.5.5)
Installed from:    Gentoo Packages

It would be good to be able to tag regions of an image, not just the whole picture.
This functionality is known from flickr and facebook. Having support for this would lay the base to implement bug #146288 (face detection and recognition).


Examples:
http://flickr.com/tour/keepintouch/ (Notes and Comments)
http://idea.zanestate.edu/archives/2007/04/face-recognition-coming-to-f-spot/
Comment 1 Colin Guthrie 2007-06-04 12:46:01 UTC
Carrying over my comments from bug #146288:

From my point of view this would help for my Sync plugin (yeah I know I've made 0 progress lately!) when integrating with e.g. Facebook - Tags of regions to represent your friends etc. 

I'd imagine an extension of the current tags concept to store always a region (defaults to the whole image) of an item. e.g. rather than just storing a boolean "has_tag" for the tag, digikam must store a region. Smaller regions can be defined that represent e.g. faces or other special notes of interest.

I can see how Face Detection could automate the assignment of these people tags.

For my purposes I would require that the tag region is queryable via the KIPI API.
Comment 2 Arnd Baecker 2007-06-04 15:39:58 UTC
For the Notes and Comments example linked to in #0
we might need even a bit more than just an association with a tag, 
because also an individual comment text 
is used, right?

On the technical side, this would presumably mean to introduce 
geometric objects (rectangle, circle, ellipse, polygon, ...)
into the database.
Such an object could then be connected with a tag.
Or/and it could be connected with an additional comment
(This comment would be different from the one attached with the full image).

Maybe there is a simpler way?

Technically one could think of using (a subset of) SVG to describe
the geometric objects; there are routines in Qt to deal with SVG,
though I don't if they can be used to draw on top of an image.

Another issue is then to think about a good way how
to create/add/edit geometric objects and the attached information.


Comment 3 Christian Weiske 2007-06-04 16:06:55 UTC
The notes and comments was just an example that such systems have been implemented already and are useful.
I would be happy with just tags for a region.

And at first I would only allow rectangles to be selected. That requires storing two (x,y) coordinate pairs, not more. Allowing circles, rectangles and boolean operations on them would be overkill in my opinion.
Comment 4 Stefan Endrullis 2007-11-10 15:52:16 UTC
*** This bug has been confirmed by popular vote. ***
Comment 5 Braiam Yesid 2007-12-14 14:02:37 UTC
I agree with Christian: rectangles are sufficient.

Systems with region tagging (i.e. Facebook) have always the same image size. Since digikam organizes local collections, where there are lots of images with disparate aspect ratios (this is more true to pro photographers, they cut the image just as a step of making the pic), what should be the size of the region? 

One approach would be use a default fixed size, I think 20% of the image size (20% of the shorter side of the image). The other approach would be a user defined size.

(next paragraph is IMHO. I have not seen a single line of digikam. and have never written a single line of QT)
But note that both approaches have in practice, custom square size. So I think it could be implemented using a class with following attribs:  x, y, length, comment, tags. Explaining it a little more:
- x, y: could be the center of the area. alternatively, it could be the up-left corner.
- length: is the length of the side of the square
- comment: is a string with a custom comment for the region
- tags: is the collection of tags associated to this region
- and possibly, an ID field. I dont know what could be the next step in organizing photos, but a public region id could be useful in the future.

It could also be useful a list of regions in the side bar (QListView?). Some systems like Flickr let tag, but one should search with the pointer for regions. Some other systems, like Facebook, have the list of tagged items, and it's very handy. The mentioned list should not be a mere list, but some kind of a regions administrator. I think that below the list there would be a box to write/view the comment, and the tag selector.

For the user, I think the flow would go like this
- select the "create region" ("tag region", or any other name) button.
the pointer changes to crosshair, the sidebar gives the "click or drag to make a region" instruction. Possibly a more flashy behavior to reflect this "creating region" state could be a thick colored border for the image (ideally, a beautiful and sober highlighting frame).
- create the region by clicking or dragging
- if clicked or dragged a little, create the region with the default region size, and centered in the clicked point.
- if dragged more than (let's say) 4 or 5 px, begin making an area.
- When finished creating the region popup or focus to the frame containing the comment box and tags selector.
- if the popup was used, click ok and go to the normal state. If focus was used, just go to the normal state.

With this digikam would be ready to export to flickr with regions, to facebook with tags, and obviously, helping a little with bug #146288
Comment 6 Braiam Yesid 2007-12-14 14:25:39 UTC
Sorry for the double post, but im thinking a lot on this.

Again, I agree with Christian. To allow rectangles and not only squares, its better to store two pairs of xy coordinates (not the x, y, and lenght combination that I proposed in the previous post).

And, I've noticed a problem... what should happen to regions if images are changed externally?. Cropped images could leave us with "out of range" regions!. Or shifted/rotated images could tag to incorrect objects in the image.

I think a workaround to solve this could be a feature that allow move and resize  all the regions as a group. Invalid (out of range) should be marked as invalid in the proposed administrator (red font or red background). I know it is a lot of work in the UI side, but thats the way I see it (again, IMHO).
Comment 7 caulier.gilles 2008-12-06 15:26:13 UTC
Another file for KDE4

Gilles Caulier
Comment 8 Marcel Wiesweg 2008-12-30 00:13:34 UTC
*** Bug 170458 has been marked as a duplicate of this bug. ***
Comment 9 Michael G. Hansen 2009-11-12 19:14:37 UTC
SVN commit 1048077 by mghansen:

Document for discussing ideas for image annotation and face recognition.

CCBUG: 146288
CCBUG: 146337



 AM            ImageAnnotation.odt  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1048077
Comment 10 Aditya Bhatt 2010-04-28 10:29:35 UTC
Hi Everyone,

To all who are following this bug - I'm working on it as part of the GSoC Face Recognition project.

I like Braiam's suggestion. Although I think it would be nice if others too could give more suggestions about how the tagging interface should look/work like.
So that we can incorporate all the good ideas :)
Comment 11 Fri13 2010-04-28 12:33:05 UTC
The tagging should be very easy. You just select a region (just like the default crop in showFoto) and you tag it by dragging a tag over it or then applying a tags. 

If user has not a region selected, the tag is placed for whole photo. 
If there is region selected, tags are for that only.

At least the face tagging should be with Ctrl+Drag way. Same way as user selects area from the Marble. This is one problematic because the area selection is needed to be similar on all digiKam views, it is a usability question. This was one point for having a Ctrl+Drag for panning view in preview. Because we needed just the dragging for tagging. But now it is needed to be a Ctrl+Drag.

In showFoto the dragging already creates the selection for effects/cropping, without a Ctrl (etc). It already forces to be different way in showFoto and digiKam preview (+lighttable). So it is needed that showFoto, digiKam and Lighttable all use Ctrl+Drag as selection for region, what then will be used for tagging, cropping and effects.

That selection function could be possible to linked after summer (or same time with someone else) with task to create a brushes function. For allowing a clone/heal stamp, layer masks or other local non-destructive editing (but those would be a circular selections while we now need a retancle.

I would vote to the 1:1 format because it is easy to be used then anywhere else when there is no need to take care of possible different format. It could be used as tag screenshot, album screenshot, screenshot in other places using nepomuk etc. And it would stand better ways in use the cropping and other functions. Easy to drag a area and show all different area-tags in next each others when they are same format.

The sidepanel where the face tagging should be placed is littlebit harder. Now we have a tag search on left and tagging on right. Some people does not like it and would like to mix them. But it would remove powerfull functionality from digiKam. Right now because of left/right separation, we can search by tags and then remove/apply tags from search results. That is something what is not any other photo management application offering so easily.

So would the face/area tagging need a two different tabs more? I believe we could link the area tagging for the tags itself. But add only a new tab for face tagging.
We just dont change tags in faces as much as we can do with subjects in photos otherwise. Like if we edit photo, we do not change character face tag to "John Doe" > "John Doe Edited". But we might add new tag "Edited" or "Print version" to it. 

So is there a need for two sidepanels for face tagging? (Search / Tag)
Comment 12 Aditya Bhatt 2010-04-28 13:09:43 UTC
Thanks for your ideas Fri13.

Ctrl+Drag seems a good idea for drawing tags.
As for the assigning  of tags, I have another idea. How about
Kdevelop-style tooltips - that pop up near the mouse when you hover
over a tagged region - with fields like rating, name, description and
stuff?

More ideas welcome!

On 4/28/10, Fri13 <friiduh@gmail.com> wrote:
> https://bugs.kde.org/show_bug.cgi?id=146337
>
>
> Fri13 <friiduh@gmail.com> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |friiduh@gmail.com
>
>
>
>
> --- Comment #11 from Fri13 <friiduh gmail com>  2010-04-28 12:33:05 ---
> The tagging should be very easy. You just select a region (just like the
> default crop in showFoto) and you tag it by dragging a tag over it or then
> applying a tags.
>
> If user has not a region selected, the tag is placed for whole photo.
> If there is region selected, tags are for that only.
>
> At least the face tagging should be with Ctrl+Drag way. Same way as user
> selects area from the Marble. This is one problematic because the area
> selection is needed to be similar on all digiKam views, it is a usability
> question. This was one point for having a Ctrl+Drag for panning view in
> preview. Because we needed just the dragging for tagging. But now it is
> needed
> to be a Ctrl+Drag.
>
> In showFoto the dragging already creates the selection for effects/cropping,
> without a Ctrl (etc). It already forces to be different way in showFoto and
> digiKam preview (+lighttable). So it is needed that showFoto, digiKam and
> Lighttable all use Ctrl+Drag as selection for region, what then will be used
> for tagging, cropping and effects.
>
> That selection function could be possible to linked after summer (or same
> time
> with someone else) with task to create a brushes function. For allowing a
> clone/heal stamp, layer masks or other local non-destructive editing (but
> those
> would be a circular selections while we now need a retancle.
>
> I would vote to the 1:1 format because it is easy to be used then anywhere
> else
> when there is no need to take care of possible different format. It could be
> used as tag screenshot, album screenshot, screenshot in other places using
> nepomuk etc. And it would stand better ways in use the cropping and other
> functions. Easy to drag a area and show all different area-tags in next each
> others when they are same format.
>
> The sidepanel where the face tagging should be placed is littlebit harder.
> Now
> we have a tag search on left and tagging on right. Some people does not like
> it
> and would like to mix them. But it would remove powerfull functionality from
> digiKam. Right now because of left/right separation, we can search by tags
> and
> then remove/apply tags from search results. That is something what is not
> any
> other photo management application offering so easily.
>
> So would the face/area tagging need a two different tabs more? I believe we
> could link the area tagging for the tags itself. But add only a new tab for
> face tagging.
> We just dont change tags in faces as much as we can do with subjects in
> photos
> otherwise. Like if we edit photo, we do not change character face tag to
> "John
> Doe" > "John Doe Edited". But we might add new tag "Edited" or "Print
> version"
> to it.
>
> So is there a need for two sidepanels for face tagging? (Search / Tag)
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug.
> _______________________________________________
> Digikam-devel mailing list
> Digikam-devel@kde.org
> https://mail.kde.org/mailman/listinfo/digikam-devel
>
Comment 13 Michael G. Hansen 2010-04-28 20:14:46 UTC
Created attachment 43086 [details]
Suggestion for UI made during coding sprint

I did some thinking about a possible UI last year at the coding sprint, it is attached here (the whole document is here: http://websvn.kde.org/trunk/extragear/graphics/digikam/project/documents/ImageAnnotation.odt?view=log ). I think the list of area titles would be useful if a user wants to quickly find a certain area, without hovering over them all to find out their titles.

I would definitely vote for at least rectangular regions, because they are very useful if you describe something other than faces (just my opinion of course!).

For detecting that an image has been edited in an external application, and thus that all areas are now wrong, one could store the dimensions of the image with the region tagging information, this would allow detection of many modifications already.

For the ctrl+drag vs. drag: How about a "New area" button? At least with the Map Search, we had some users asking how to make the selection, and thus now display a hint if there is no selection.

Michael
Comment 14 Fri13 2010-04-28 22:14:32 UTC
"For the ctrl+drag vs. drag: How about a "New area" button? At least with the
Map Search, we had some users asking how to make the selection, and thus now
display a hint if there is no selection."

That has a valid point for bringing up the feature. But it is would make difficult to add multiple region tags for photo because between regions user would be needed to click a button and then drag a region.

If the button would like a "On/Off" button, it would be harder again to drag photo for panning. And what should happend when user selects other photo or other tag etc?

There is needed somekind indicator for that. Thats why I think it would still be best that panning would happed from middle mouse button and region selection would happend from left drag. This way we have mouse scroll always for view options (zoom in/out, pan, 1:1/fit). But that is the other topic for getting a same kind functions to all around digiKam features.

We need to think how users want to tag photos. Example for me, I go trough all photos with one tag. So that results to multiple "circles" to go trough them. Same time I can re-rate the photo if it starts feel someway different. As far the tagging persons has be one of the biggest jobs. So when we get it automatic (or mostly automatic) it will cause less "circles" (at least for me).

One way what I was thinking, was if user selects/creates region tag and then user is asked to drag a area. Like if you drag a region tag over photo, you are informed to drag then a region.

And I came just up that it should be easy to move the region tag. So we could just add region tags to photos and then go later just to reposition them correctly.
Should that need a "edit" function what would lock/unlock region tag from mistakenly happening moving?
Comment 15 Michael G. Hansen 2010-04-29 07:43:13 UTC
(In reply to comment #14)
> "For the ctrl+drag vs. drag: How about a "New area" button? At least with the
> Map Search, we had some users asking how to make the selection, and thus now
> display a hint if there is no selection."
> 
> That has a valid point for bringing up the feature. But it is would make
> difficult to add multiple region tags for photo because between regions user
> would be needed to click a button and then drag a region.

We could do it like in the map search: The power user can use the ctrl/shift modifiers, the novice can use the buttons until he learns the shortcuts.

> One way what I was thinking, was if user selects/creates region tag and then
> user is asked to drag a area. Like if you drag a region tag over photo, you are
> informed to drag then a region.

Sounds good.

Michael
Comment 16 Arnd Baecker 2010-05-01 15:16:08 UTC
Hi Aditya, 

great that you are working on this wish - I think it has
a lot of applications, way beyond its need for face detection/recognition
(eg, I often have in mind to mark the position of mountains in a photo .. ;-)

The mockup in c#13 looks very good to me (and ImageAnnotation.odt
also addresses many important points).
For a start it might be good, to just implement something
using CTRL+drag (or CTRL+SHIFT+drag, or ...)
and associate tags, as suggested by Fri13, just to the selected region.
Then there should be a possibility to select regions ("active selection")
and unselect (eg. by another mouse-click) and provide a visual feedback
for this (dashed/non-dashed/highlighted etc.).
All the visual details (and mouse/keyboard short-cuts) can be adapted
later, if necessary at all. Usually, after something like this is implemented,
one will see how it works, and whether it feels "good"/"right".

An important issue will be how this information is stored in the database.
One possibility would be to leave the tags part as before, i.e
any tag associated with a region is also a tag of the whole image.
Then only an additional block of data corresponding to each region
will be needed. This might carry
- bounding box   (llx, lly, urx, ury)
  or, more generally, a sequence of (x0, y0, x1, y1, ...) to form a polygon
- image size
- tag name
- region comment
- ... anything more? ...

Then all the other things (display variants, eg. including the tag,
resizing the region by moving the sides/corners,
behaviour on resizing images, ...) could be added later,
once the basic stuff looks right.
For the very beginning, even no additional side bar with the regions
would be necessary (maybe adding a region comment
is not possible then).

Unfortunately, I don't have much time for coding at the moment,
but I look forward to testing anything which comes up ...;-).

Best, Arnd
Comment 17 Michael Skiba 2011-07-03 09:09:57 UTC
From what I've seen from Adityas work this wish can be closed.