The Everlasting Picture Categorizing Project

[zourtney]

Since somewhere near the beginning of time, I have been kneading this idea of an image-tagging system in my head. It was my college senior project and has gone through several failed PHP startups.

Overview:
Create a system capable of storing searchable meta-data for images.

It's becoming a tired idea, after all of these years. And perhaps there is some sort of usable system in place already, but most fall short of my expectations. But the truth is, I need a good image search because I have too many pictures. My proposed system would consist of the following elements.

Tags:
True, tags are the fad of this waning decade. But they're useful as well. For example, let's say I have a good image of my niece I took at Easter dinner this year. A dozen searchable options pop into my head immediately:

• Easter
• Emma (niece)
• Kyle (Emma's father, my brother)
• Alexis (Emma's mother, my sister-in-law)
• Mom's House (location)
• Mom (location's home owner)
• Outside (vague locality generalization)
• Smile (facial expression)
• Canon S1 IS (camera picture was taken with)
• ...and a slew of EXIF data (ISO, exposure, flash, etc) which should be searchable...

What remains to be hammered here is whether I should opt for dumb tags (everything bold above), or conjure up some more sophisticated tagging links. In the past, I always went for something more complicated.

For example, the camera would be stored in two linked tags of Canon > S1 IS, which Canon being the "parent" tag.

• This is advantageous in that "Canon" is implied.
• This is disadvantageous in that a strict parent-child hierarchy is often insufficient. Notable, what is Easter? A holiday? An outing? A gathering? Yes..!

Ever since I wrote the code for this project as my senior project, I have toyed with the idea of changing platforms. That release was a Windows-only executable. This is provides the greatest power for me, the programmer, but the least amount of portability. So, I could make it:

• 1) Totally web-based. Probably use a combination of HTML, PHP, and JavaScript
• 2) Web-based with fancy front-end. Probably use Flash/Flex for UI and PHP for the grunt-work.
• 3) Compiled executable, local only. Use C++ or C# to create a self-contained, locally managed gallery and tagging system.
• 4) Compiled executable, with some level of internets. Similar to the previous option, but allow for remote hosting, searching, and viewing of images.

Each has its advantages and disadvantages. I'm stuck here, right now.

[zourtney]

Here are some primative, high-level requirements I slapped together:

The system must:

Allow users to add images to a library
Allow users to remove images from library
Allow users to export library (or part of library)
Allow users to import library (or part of library)

Allow users to "browse' the image library
Allow users to search the image library by tags
Allow users to view a tag-cloud or similar view
Allow users to save common searches

Allow users to add a tag (to single/multiple)
Allow users to remove a tag (to single/multiple)
Allow users to make images private (via "private" tag)

Allow users to log in
Allow users to log out
Allow users to add users
Allow users to delete users
Allow users to add groups
Allow users to delete groups
Allow users to assign users to groups

[Nick]

I say lets do it. Or at least do it, and I am willing to help. I think a web-based platform is the best bet. Easy to make it OS independent and we are both quite familiar with those languages (being flash, php and the Jax 'eh.) I have looked at the various galleries and they are all ok, but all seem a little lacking. It would be nice if we could tie in the users to whatever system in running randomland at the time (SMF or drupal or something.)

Should it be a highly searchable  album based system, or a system of picture groups (a group per user) that is then tied together with tags (so you create an album by saving a search) o the possibilities. Another idea, we could take an existing gallery system and create a better search feature for it. Improving its indexing and categories without having to write all the overhead of users and display structure.

[zourtney]

In my distracted quandary, I happened upon this idea:

• A strict hierarchy is insufficient for tags
• Storing related tags would be better
• Stored how related related tags are is even better. This would be done via some sort of integer 'weight' value.
• Less important: Tags should be suggested via smarts.

This is not a very original concept. "Tag clouds" have been around for a long time. This is the same idea, just approached from a slightly different angle.

Example:
Tag: Camping
Related: dirt, fire, hiking, lake, outing, sleeping bag, tree, woods
Weighted (visually):
dirt, fire, hiking, lake, outing, sleeping bag, tree, woods

Essentially, you would assign higher values to tags you feel are more related to the tag in question. In the example above:
sleeping bag is very related to camping
outing is only somewhat likely to be related to camping.

[zourtney]

Holy moley, that response is ancient. I feel like a randomboard slacker.
(there was of course the little up-n-down dance that it did for a while)

I say "let's do it" too. I keep coming back to this project. It would have a good home on Randomland, if done properly. I get a little queasy when it comes to large web-based projects. Therefore, we need a good set of cleanly-written base classes which can be ported later.

Now I'm just making stuff up:
Stage 1: Randomland Web Gallery
Stage 2: Port to desktop app which talks to Randomland servers
Stage 3: Port to standalone desktop app using a local database
(Stages 2 and 3 might switch spots)

[zourtney]

Ok. This project needs a name. Temporary name? Permanent name? Secret codename? -- doesn't matter; it just needs a name.

Suggestion 1: RallyTag
(and I don't know why)

[Nick]

Codename: Sasquatch

[zourtney]

I've been hammering out some (UML) diagrams to try and describe a basic class layout for this thing. I need to revisit the "Requirements Document," showing what this thing is meant to do. I'll post 'em up tonight or tomorrow.

[zourtney]

Name: Common Place
because seriously, how many galleries are there out there??

Or maybe something more along the lines of "The Photo Commons," as to indicate that this is a gathering place of imagery whilst implying an air of self-detriment.

[zourtney]

Updated "use case" overview, 08-14-2009:
The following is an overview of the actions (“use cases”) the system must be able to perform. These are high-level requirements meant to give a feel for how the interface will act.

Image Library
The Image Library keeps track of all images available to the system. It is essentially the global collection of pictures. More precisely, it is the interface for getting and saving picture metadata.

• Import to library
  
  • Single image
  • Multiple images (batch file selection/upload)
  • From an exported library file
  • Upon import: option to associate tag(s)
• Remove image(s) from library
  
  • Single image
  • Multiple images (selected from search)
  • Export from library
  • Full library
  • Full user library
  • Selected items from search
• Search library items
  
  • By unique ID (database ID or similar)
  • By tags (manually entered)
  • Browse a tag-cloud or similar view
  • By saved search
• Save search
  
  • Save a search
  • Export saved search(es)
  • Import saved search(es) file

Image Viewer
The Image Viewer component visually shows the results of searches. It can show a single image of a list of images.

• View single image (may need updating if using a browser-based platform)
  
  • Windowed, image only
  • Windowed with basic with tags (EXIF and “very relevant” tags)
  • Windowed with all tags and tag corresponding weights
  • Full Screen, image only
• View list of images
  
  • Shown as thumbnailed images
  • Shown as a list of images (labeled as...?)
  • Show “related” images (ones with similar tags)
• Edit image tags (options apply to both single image and lists of images)
  
  • Add tag(s) (value associated tags and plain old tags)
  • Remove tag(s)
  • Edit tag weight(s)
  • Add to album(s)
  • Remove from album(s)
  • Set value-associated-tag data, including:
    
    • Rating
    • Public/Private flag
    • Viewable by (list of users/groups)
    • Nickname
    • RefName (ie “francine-part1-img001”)
    • Description
    • ALT text
    • Upload date
    • Figure Number (ie “1.2”)
    • ArticleURL (ie “http://randomland.net/francine/part1”)
    • Callout regions and corresponding text (ie box around someone's face)
    • Get/show thumbnail path
    • Get/show permalink
    • Email to friend, post to Twitter/Facebook/gimmickland
       

Tag Editor
The Tag Editor will be used as a management interface – not to tag images themselves. Such functionality should be built into the Image Viewer component. The Tag Editor will handle the mundane tasks of life-with-tags.

• Add tag
• Remove tag (removing reference from all linked images)
• Cull unused tags
• Manage user defaults
  
  • Add default tag (ie “Court's”)
  • Remove default tag
  • Set default tag data (for value-associated tags)
• Manage value-associated tags
  
  • Convert simple tag to value-associated tag
  • Convert value-associated tag to simple tag
  • Change value-associated tag's type
  • Change value-associated tag's default value
• Edit tag relations
  
  • Add related tag(s)
  • Remove related tag(s)
  • Edit related tag weight

User/Group Management
The User/Group Management components simply describes the actions which system users will be able to perform. Note that many of the listed actions should be restricted to administrative users.

• Log in
• Log out
• Register
• Retrieve lost password (email them a new one)
• Edit profile
  
  • Edit name
  • Change password
  • Change cookie login option
• Add user
• Remove user
• Add group
• Remove group
• Assign user to group
• Remove user from group

[zourtney]

I be thinks that the user login would be a good place to start upon them codes. It is straightforwardly easy and quite full of boredom. I shall hammer out the interface requirements and maybe we can start there.

Uploaded image to http://randomland.net/images/court/uc_user.jpg but that link will be broken until I fix Nick's server (or he does)...

[zourtney]

Codename: "mountainhose"?

[Nick]

Where did you put that file that it cannot be found? I know the server is in a state of advanced disarray at the moment so it might be hard to determine where to put hings. I am sorry for this and will be reprimanding the disorderly machine very soon. I will administer a bit of a brain wipe on it and start anew. More to fix the weird fedora upgrade (from 10 to 11) issues then to clean things up. Though it will help with both problems.

[zourtney]

Oh, nevermind that. I was just trying to make a folder to hold pictures that would circumvent the existing gallery, but I'll just use it.

In fact, here you go -- here are some "use case" diagrams I've put together. These are just to get a fairly specific idea of everything the system is supposed to do. If you look at the requirements list above, you'll notice that I have only diagramed about 1/2 of them. I'm sure I'm missing a lot of functionality/requirements, so just post them as you think of them.

BTW: softcopy if you want 'em -- but you'll have to install NetBeans.  

User Use-Cases

User Actions - this is an overview of all profile-related actions in the system. Both basic and administrative users are shown. A basic user can: Register Log in Log out Request a new password Edit his/her own profile information An administrative user can do all of the aforementioned, plus: Create a new user Disable an existing user Create a new group Disable an existing group Edit any user profile Add users to groups Remove users from groups

Edit User Profile - this is an overview of the editable profile options a user would have. In the case of an admin user, it also shows how to edit others' profiles. These are listed out separately because they are elements of a profile (as opposed to actions utilizing a profile)...and because seemed while still inside my head. Whether it be the admin or the user him/herself, these are the available profile editing options: Change email address Change display name Change password Create/clear logon cookie1

Tagging Use-Cases

Tag Image - this is an overview of the tagging options available to a user. These are options which would be seen from an image-viewing screen (ought to implement both batch-edit and single-edit modes). Here are the options that I have come up with (I'm probably missing something obvious): Associate a tag with image(s) Remove tag associate from image(s) Change tag-weight2 Change value-associated tag's data3

Tag Control Panel - this is an overview of all actions which could be taken from a "tag control panel" type screen. I'm still trying to work out how permissions should work on this stuff, but that's why I'm drawing diagrams -- so I can hit these design issues early. A basic user would be able to: Create a new tag (simple or value-associated) Create a tag-to-tag relation Change tag-to-tag relationship weight Create a user-specific standard tag (one that is automatically added to every new image) Remove a user-specific standard tag Edit a user-specific standard tag (see diagram below) Admin users have all of those abilities, plus: Remove an existing tag Remove an existing tag-to-tag relation Cull unused tags Edit tag (see diagram below) Create group-specific standard tag Remove group-specific standard tag

Edit Tag - this is an overview of what options are available when editing a single tag from the "tag control panel." All users would have access to these options, if they own the tag. How exactly tag ownership will be handled, however, I am not sure. Change tag's display name Change ownership (somehow...) Change privacy -- can be public or private (user-based or group-based setting?) Convert a value-associated tag to a simple tag Convert a simple tag to a value associated tag Change datatype -- value-associated tags only) Change default value -- value-associated tags only (again, user-based or group-based setting?)

[TODO: half-done database diagram remaining to be inserted]

Footnotes

1 cookie note	Obviously cookie options are machine-specific, so an admin can't force this behavior
2 tag-weight theory:	Simply applying tags to an image will make for irrelevant search results. To make them more relevant, each image's list of tags will have corresponding weight values. Take this visual example: I would tag it with something like the following, with larger text indictating "heavier" (more relevant): image -> Brad, rocks, woods, trees, camping, geocache, ammo box, notebook, underexposed TODO: create a UI mockup In addition to storing how relevant a tag is to an image, we will also be employing the use of tag-to-tag relations -- in other words, "how similar is one tag to another." I suspect that this can be stored at a global level (until proven otherwise.) Take the tag "water", for example. Similar (and weighted tags) might be something like: water -> stream, lake, river, ocean, cup, pipes These would be bi-directional. The idea here is that a search may branch out into these "related tags," using the weight as an approximate relevance guess. This concept is an alteration of my previously used strict relevance hierarchy, which was too limiting. Yes, a river IS water, but is also most likely a channel. (Not the best example, I know.)
3 simple vs value-associated tags	In addition to describing relevance with simple identifiers (such as "dog"), we often need to associate a value with that tag. A perfect example is an entry out of an image's EXIF field, such an "ISO=200". True, we could make tags "ISO100", "ISO200", "ISO400", etc, but this would generate an unnecessarily large amount of nearly identical information. The solution is to just store that value and link to the tag. This should be apparently in the database diagram, when posted.

[zourtney]

A three second conversation with Brad has again given me flipflopseria -- that is, I am tempted to change my target platform for this project. The first iteration, the "one point oh," if you will (and I encourage you not to) was targeted as a desktop application. In fact, the project grew out of a desire to have a fully standalone, portable picture catalog with tags embedded in he image files themselves, whenever possible (jpegs/pngs). The database backend was only a necessity because of speed and search considerations.

Anyway, what I am saying is that targeting this a web app, while good for Randomland, misses the original intent.

What say ye?