Randomland - The Forum

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.

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

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.

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.

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)

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)

Codename: Sasquatch

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.

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.

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

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 (http://randomland.net/images/court/uc_user.jpg) but that link will be broken until I fix Nick's server (or he does)...
(http://randomland.net/images/court/uc_user.jpg)

Codename: "mountainhose"?

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.

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

(http://randomland.net/sites/all/modules/gallery2/main.php?g2_view=core.DownloadItem&g2_itemId=49&g2_serialNumber=2) (http://randomland.net/index.php/gallery/pages/tagallery/uc_useractions.jpg.html?q=gallery)

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

(http://randomland.net/sites/all/modules/gallery2/main.php?g2_view=core.DownloadItem&g2_itemId=53&g2_serialNumber=2) (http://randomland.net/index.php/gallery/pages/tagallery/uc_edituserprofile.jpg.html?q=gallery)

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

(http://randomland.net/sites/all/modules/gallery2/main.php?g2_view=core.DownloadItem&g2_itemId=56&g2_serialNumber=2) (http://randomland.net/index.php/gallery/pages/tagallery/uc_tagimage.jpg.html?q=gallery)

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

(http://randomland.net/sites/all/modules/gallery2/main.php?g2_view=core.DownloadItem&g2_itemId=59&g2_serialNumber=2) (http://randomland.net/index.php/gallery/pages/tagallery/uc_tageditor.jpg.html?q=gallery)

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

(http://randomland.net/sites/all/modules/gallery2/main.php?g2_view=core.DownloadItem&g2_itemId=62&g2_serialNumber=2) (http://randomland.net/index.php/gallery/pages/tagallery/uc_edittag.jpg.html?q=gallery)

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: (http://randomland.net/sites/all/modules/gallery2/main.php?g2_view=core.DownloadItem&g2_itemId=65&g2_serialNumber=2) (http://randomland.net/index.php/gallery/pages/tagallery/Camping+193.jpg.html?q=gallery) 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.

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? 

So Brad was saying it should be web based? I think it should have both components. Just require internet access to sync pictures with the online repo and database while still storing everything locally for portability.

Actually, what he said kiYnd of made me want to NOT do it web based. Having to connect to a remote server to tag YOUR own pictures seems rude, at best. However, a searchable, permanent Randomland gallery that I know the inner workings of would be very, very nice.

So, in perpetual contemplation of things which pretty much don't matter to anyone, I have a couple of options:

• 1. Just write it browser based with a PHP back end -- forget the offline desktop app dream (2.0, baby)
• 2. Just write it as a desktop app in C++/C# -- forgetting the Randomland gallery dream or any online search abilities (0.0, baby?)
• 3. Write the whole darn thing twice (#1 and #2)
• 4. Write a remote server back end (PHP probably) and finagle a desktop AND web browser to talk to it. This kills the offline portability dream...
  

Oh, and if I was kind of demented, I could try to make the program a Flash application to avoid writing the frontend twice -- but THAT limits browser compatibility to needing Flash Player plugin (no biggie). Something in me doesn't like running a flash app in a browser when I shouldn't need to (ie a photo gallery); something in me doesn't like running Flash Player as a standalone app in Windows (feels like a non-native compromise).

And the same thing could be said about a Java app. But that's not even a consideration (ugk!)

Oh yeah, I'd really prefer to code this in something I can work on from my lin[ux lap]top. But if I go the C# route, I can mess with the Mono (http://mono-project.com/) libraries, which I'd like to do anyway. I'm leaning towards that because I haven't done .NET stuff in years. It has changed a lot and I got left behind.

I have never done .net stuff so any c# would be a learning experience for me. Perhaps I can right the web one and you can right the desktop one? I don't know, all the improvements to native OS support for image galleries (thinking the photo library in windows 7) makes me discourages as I would never make something that cool. But something that is OURS and does everything we want it to would be nice.

After playing with Mono for a few minutes last night, I'm interested in the idea of creating a server application in it. In theory, it could run using Gtk under Linux or (natively?) under Windows. I'll have to do some portability tests, but I like this idea. The only catch is that it'll have to be running on a Linux server running X (or Windows). So no hosting it remotely on GoDaddy, or anything like that.

My server or yours will work for that. Perhaps even build a master/backup relationship into it.

Yeah, running a server app on a machine from one of ours houses seems just fine to me. If we ever get to a point where we're running ol' Randomland remotely again, we might need to make sure that the gallery server component is separate from the tagging server component.

But as it is now, if your computer goes down, Randomland goes down. And nobody even notices  :'(

It is sad the no one notices (except us that is) The little machine has been pleasantly reliable so far. Only problem was the DSL connection dropping out all the time, but that seems fixed. Its inevitable that hardware will fail though. There is a script running that is supposed to back up the www directories and something that was set up with MySQLadmin that backs up the database every day. So all in all the machine might only be gone for a day.   

Yeah, I was thinkin the other day about the need for a backup. I'll take a copy now and then, if you don't mind. (we could even set up virtual systems and run randomland off of that -- backup and restoration would be as simple as copying a file)

anyway, what I was meaning to mention on here is that I lost my JavaScript steam. I was working on a demo page a few weeks ago. It was meant to be a drag-and-drop list holding tag info. Then the order they're arranged in would correspond to a tag weight.

If you Nick, or anyone else, wants to hack up a demo for this, go for it. I can post what I've done, if you're interested. It was mostly just a combination of interwebs examplage.

I kind of lost vision on this project (though not for the first time). I/we need to decide what I/we want:
a) an online image gallery
or b) a powerful desktop-based image archiving app

Doing both is too broad and l get bored thinking up the details. Opinions? G2 (or whatever our current gallery is called) is nice; all the stuff I don't want to think about is already written. But making a module would have an incredibly steep learning curve -- I might give up. However, Randomland needs a gallery; be it the current one or something different entirely.

Blah blah. Same ol' design conundrum.

There are other galleries... and if one gets a couple of drupal modules (like picture node) you can start putting together a gallery that is native to drupal and has tagged+searchable images. There are fairly complete instructions on how to do it. So the ability to have a gallery online is no big issue, but I for one would not want to have to tag and categorize my pictures twice if I wanted to stick a large chunk of then online after messing with a desktop app. So a desktop add is a good idea (faster and less bandwidth used editing) but I would like to see you/us make a way to upload the images with their tag info. If this means making drupal pull the info out of the images properties then cool (or gallery2 or coppermine or ....) or making a module that sets all that stuff on upload. Gallery2 is missing the super powerful taxonomy engine that drupal has going for it. If you think its a viable idea I will set up (at leasst a test) drupal-based gallery. I have enough VMs floating around now so I should use one.

Yeah, I'm interested in seeing the built in drupal image capabilities. I haven't looked at it at all.

Maybe next week I'll start working on program specs again. So, should I start gearing stuff toward (the dying) desktop app? I'm still considering doing a gtk based client/server pair.

Brad and I briefly talked about this everlasting picture project. It seems to me that the biggest stumbling block is that I don't really want to create an entire taxonomy system. It's a tedious job.

I like the image stuff we recently installed in Drupal. It benefits from Drupal giant, crazy, and powerful taxonomy system. This seems like a good, permanent solution for Randomland (unless someone objects?). If I ever do make a desktop app to categorize pictures, I could make some sort of Drupal bridge/module. This would probably make the most sense. And I can limit my project scope to desktop app only, for for now.

But, I still need to design a whole taxonomy system.  :-\  Any input?

You should make me something exactly like Flickr but for my desktop. Oh and do all of it for free. In your free time. By yourself.

Let me know when you're done, thanks!

OooOOoo I want too! Mkay, thanx bye.

Ye@h!!!!1 tbis pr0jects da rulz0rz!!1

Uh yeah. I guess I'm back to figuring it out all on my own. Which gives me a nearly infinite timeline and no one to disappoint.

I can givz help?

Sí señor. I need scope.

WIllz liststerseeen werk? I nogotz scope.

ok I guess I wont make a picture of  Listerzine as photoshop keeps crashing trying to load some font.

On a more serious note. Organizing ones picture library. Where do you even start?
In this modern age we live in, of file indexing and database driven file search. Of "image libraries" generated directly from the OS giving you rather advanced search options (even if they can be frustrating to get it to do) how does one organize their pictures? How important even is it to fret over folder naming and date ranges when I can search for everything from oct 17 1942 and have anything matching that in under a minuet (faster even if you dont have 50,000 pictures.) Naming the folders gives you a simple, easy and human readable first level or organization and from there it gets hard to add much to them. You cant assign pictures categories, you cant tag them with family members who appear in an album (folder) or image. All you can do is give them generic names and perhaps a date range. What is missing from windows is a decent tagging system. Same for linux. Though I am sure there are programs that would help I would bet they would annoy me to use. So a priority for your (our? can I join in fo realz?) project would be a powerful yet easy tagging system for managing pictures and making search possible on their subject matter, not just their date. After that one can easily see a built in search arising, or plugins for windows (that sound fun, not) and linux (probably just as not-fun.) Second, it would be a nice feature to upload things to drupal. It would be a new frontier for me, bridging the desktop app and web app as well as creating a unified version of some gallery (or just working with the modules we have, they all seem to like prerequisites and dependencies)  and working with the drupal API to crate node and have them added correctly.
But folder naming? How do you do it? Years and dateranges.. but with multiple cameras and a phone you get some over lap (i.e. (2009-9-1 to 10-3) comes before (2009-9-8 to 9-20) even though some images come after it. Not that its a huge issue) My system seem to keep things easy to find, providing I can remember about when an picture was taken.

So, to recap my ramblings.

• 1. Tagging/Taxonomy/Categories for contentment based searching
• 2. Drupal Bridge for sharing things with the largely indifferent world.
• 3. Naming folders for actual file storage in a way that makes the images human-searchable

Thats all I got for now. I'll let you know when something else annoys me about how things are now in the land of photo-logging my life.

Yes, fo reelz!

You know, if we get our drupal based image gallery set up, it might help me ger a better grasp on how to design this project's db structure. It can't hurt, at least.

I think pictures need to be organized on three criteria: date, content tags and quality.

I need to be able to do things like find all pictures taken in October 2007, find pictures tagged with the word "ocean" or all pictures I think are good enough quality to hang on my wall or upload to flickr.

It's impossible to do more than just one of those things using folder names. So you can store the tags and quality in the jpeg's meta data. Ok, but how do you find things quickly? You could use a database to keep track of what pictures are on a computer, what tags those pictures have and what quality value they've been given. This however causes it's own set of problems. Namely how do we deal with the moving, copying, deletion and addition of pictures? How do we keep the database matched up with reality?

One possiblity I can think of would be to use right click menu options similar to TortoiseSVN's for moving, deleting, adding, etc. That'd make it simple enough to do all the normal file operations and keep the database up-to-date.

The database structure itself wouldn't need to be very complex. I'll post my schema ideas later.

I like the rightclick options. I wonder if there is someway to piggyback onto the windows delete operation to call something that checks and updates a database when I supported file is deleted. The its even easier for the common user. But I think the convenience of having a (RC = rightclick, not radio-controlled) RC->RLImage->Delete/RemoveFromLibrary and RC->RLImage->AddToLibrary would be not only be more then enough, but rather cool.

But to be a real purist we should disable deleting of and images included into the program. Forever. Saving people from the temptation of deletion and the evils that there lie!

I'm pretty sure there is not anyway to hijack the deletion of a file without installing something like a rootkit. You're pretty much stuck with the right click menu options.

Here is my schema idea:

Images
Stores all image data, one row per image.

ID            int
Path         varchar(255)
Date         DateTime (the taken date, not the date it was added to the database)
Quality      int (could be out of 5 or something?)
Tags         mediumtext (comma delimited)

Tags
Stores what tags have been used and the number of images which use that tag. Very useful to have a list of which tags are in the database. This table is updated every time a tag is added or removed and is not directly tied to a specific image in anyway.

ID            int
Name         varchar(128)
Uses         int

That’s pretty much all you’d need for a basic image tagging system. Now, if you want to do something more complicated like having “sets” of images you’d need at least two more tables.

Sets

ID            int
Name         varchar(128)
Date         DateTime (date of creation of this set)

SetImages
This table maps images to sets.

ID            int
SetID         int
ImageID      int
Date         DateTime (date added to set)

Anyway that’s just my take on it. What do you guys think?

PS. Tabbing in this forum REALLY FREAKING SUCKS . That is all.

What do you want tabbing to do? It goes to each element on the page. I don't think you get the option of setting a tab order. Anyway.


What should be change about the drupal image gallery (other them making it so brad can upload images) to make it more like the picture project?

I think we should all work on creating and maintaining a image (it could be used for more thing then images. In reality we should combine all our vocabularies into one. I didn't really know what I was doing then (not that I know now) that would make things less redundant and take up less space on posts. But there is probably a reason for not doing that.)

Any input on classification? (not to hijack the thread. Feel free to reply in the comments/suggestions area)

So, Nick and I were yackin' the other day about this project.

The way I see it, we should break down development into 3 distinct stages. This way we can see progress and not become overwhelmed (or underwhelmed, as the case may be).

• 1) Develop standalone desktop application. From here you can tag, view, and search all items in your picture library.
  
  
• 2) Implement Windows Explorer hooks (right click menus and such). This is dirty, nasty code and requires that DLL registration, intentional crashing of Explorer while testing etc. The result is nice, but it's not that much fun to code and I'm not sure how to do it in a managed language (C# hopefully?). So, I say this mess should be out of the scope of the initial project phase.
  
  
• 3) Implement internet syncing. Probably will sync with Randomland's Drupal Image stuff unless I want to dig in to Flickr APIs are something even scarier. That'll be a huge project, and therefore last.

What do you think? Agree? Disagree? Did I miss something?

Let us hope that in Microsoft's hyping of c# they made OS integration a little easier. I probably hope for too much though.

So for the stand-alone portion you're pretty much going to need to write an image gallery program in C# and then add image tagging and whatnot?

I'd recommend taking a look at the interface on something like Picasa, that should give you some idea of the kinds of features you'll want (and not want). Please make the image tagging easier and better though. More like Flickr's.

So yeah, picasa gallery display + flickr tagging style. I could probably provide more concrete examples of what I'm talking about.

Yeah, some more concrete examples would help. I have not used Flickr very much (maybe 3 or 4 times) and have never used the desktop version of Picasa. I will probably try them more extensively in the near future so I can get an idea of what kind of UI I want to build.

Specifically, what features do you like? What do you dislike?

What kind of tagging interface are you looking for?

• "free tagging" text box where you enter a comma/space delimited list?
• A tag-cloud with a drag-and-drop interface?
• Something else?

YES on the free tagging. I HATE HATE HATE in Picasa how you have to click a stupid button everytime you want to add a tag. Who wants to click the button 30 times to set the tags on a single image????

Ok here is a concrete example of tag goodness that both flickr and picasa have: the ability to apply tags to a group of images at once. I want to be able to select a whole folders worth of images then apply the tag "beach" to them. Also, I want to be able to select a bunch of those same images (but not all of them) and apply the tag "Melissa" or something (I'm assuming Melissa is in those pictures.

I'll post some screenshots of picasa and flickr with me writing notes and drawing all over them sometime after I get home.

Ok, I certainly agree with all of that.

I want to start making a list of expected functionality (use cases, if you will). I have done this before, but let's do it a 16th time. Maybe I will get feedback if I feed in smaller doses. I will start shifting over the concrete stuff into a more formal Drupal page.

Knock 'em or affirm:

• Display image thumbnails in a grid (like Explorer does)
• Grid is multiselect
• Free tagging text box...somewhere
• Apply tag(s) to a single item via free tagging text box
• Apply tag(s) to multiple selected items via free tagging text box

Yea? Nay?

Oh, and what should we call this thing?? It needs a name. My old one is lame and I probably made it up in the shower, or something.

That's more or less what I was thinking. It just makes sense to be able to do it that way. To really carve out our niche I think we should focus on tagging and searchability with this. Having the tags compatible with other services (flickr for example) would be a nice bonus to it all. We might have to make out own flicker uploader for that though. Not sure.

And another thing...

Another idea for picture project: Load waypoints (or have a way to input them) so as to associate them with a given tag. So if I tag a picture with  Elk Lake or pichole, the software will automatically tag the image with the geotagging information for that location. Enabling non gps-enabled camera owners to benefit from their GPS and geotagging (or the use of waypoints/coordinates from some other source if they have no GPS.)

[DELETED BECAUSE I DIDN'T READ PROPERLY]

If you wanted to get really cool (at some later date) you could use the google api to actual show thumbnails of pictures along with the location they were taken on a map.

EDIT: I just realized I read your post completely wrong. Having them map to a specific waypoint which you could save in the program is cool idea. The only drawback is that you lose the detail level of actually specifying the exact position you took the picture from. Of course that assumes that you actually know that information... Since most cameras don't save GPS information when they take the picture I'd say that waypoints would probably be useful.

Flickr shows you a map and lets you click on the spot you took the picture. That lets you get pretty close to the exact spot the picture came from. Unless we plan on doing that (sounds like more work than usefulness) the waypoint system would be a good compromise.

I was thinking that google and flickr would use the geotagging information stored in the image automatically. Is there a standard for tagging images? Like the EXIF standards?

No tagging standard that I've ever found.

And Flickr may use the GPS data stored in the Exif by your camera, I wouldn't know as I don't have any cameras with GPSrs in them.

I've taken a screen shot of Picasa's interface and wrote my ideas and thoughts all over it. I think the program has a lot of good ideas we could steal and a lot of things we could make simpler/better.

I'll give the link (http://randomland.net/node/853) rather than embedding it as the image is fairly large.

Let me know what you guys think. We should probably make a definite list of exactly what functionality should be in the initial version of this project. That way we can avoid feature creep and have some kind of an idea exactly what we are trying to accomplish.

Sweet, that definitely helps. I too want to get this project well defined so I can avoid the feature creep* we are accustomed to. Also, if we have a well defined project, we will have no excuse to not make it.

I like the overall look of Picasa, I think. From the screenshot, it seems that most of the application's functionality happens on that screen. I want to go for something simple like that -- the simpler the better.

I'm going to try and slide all of the concrete ideas over to this (http://randomland.net/tech/picture-project/outline) page.

* man, we need a mascot of a "feature creep"

Yeah I think Picasa's interface for the most part is probably as simple as you can get (it was designed by Google after all).

It does have one other screen to handle other functionality. When you double click on an image it takes up that whole main scrolling pane and gives you a bunch of basic image editing options. Which is something we REALLY don't need in the program. Why compete with Photoshop and Gimp? No, I think we ought to just show the image resized to fill the whole pane. We probably wouldn't even need to change the control bar or anything. In fact could probably just make the larger sized image pop up in another window sorta like the randomland galleries do. That way we wouldn't have to change the thumbnail pane at all.

I didn't explicitly mention it, but feel free to edit the outline page, here (http://randomland.net/tech/picture-project/outline). It's only a start. I was in a hurry otherwise I would have stubbed out some more section headings.

So is the outline page were you want us to start suggesting features? Or should we suggest features here and then put them in the outline when they are semi-approved/agreed upon?

Let's suggest features here. I'd like the outline page (and any sub-pages we think up) to be the solid, agreed-upon stuff. It should be what this project is built off of. That was my thinking.

If we need an additional thread in the forum, we can do that too.

You should make a list of all the currently suggested features at the top of this thread or something (or start a new thread) so that we can keep track of what has been suggested.

Here is some suggested functionality:

• Image folders can be "added" to the program
• "Added" image folders are displayed in a directory tree structure (including all sub-folders).
• When an image folder is added all images in that folder and all of it's sub-folders are added to the program
• Image folders can be "updated" meaning the folder and sub-folders are searched for new images. Any new images found are added into the program
• Image folders can be removed from the program. This does not modify the actual folder on the drive.
• "Albums" can be created. An "Album" is a group of images (not necessarily from the same folder(s)).
• Albums are displayed in a list. No sub-albums.
• Images can be added into albums.
• Images can be removed from albums.
• Albums can be deleted. This does not delete the images inside the album.
• Selecting a folder in the folder tree makes the program display a thumbnail grid of all the images in that folder.
• Selecting an album in the album list makes the program display a thumbnail grid of all the images in that album.
• An image in the thumbnail grid can be selected.
• Multiple images in the thumbnail grid can be selected by using shift or control click.
• When an image is selected it's file name, size, file size, tags, date taken on, camera type and geo-location are displayed.
• When multiple images are selected the total number selected and their total size are displayed.
• Tags can be added to a selected image or group of images.
• Image tags are stored in the EXIF data of the image.
• When an image is added to the program any tags stored in it's EXIF data are loaded into the program.

That's just a (really) partial list. I'll try to suggest some more later.

I personally despise ctrl+click for making selections. I much prefer a click-on/click-off style (so you don't lose your selection if you click away from the program and then click back on it without holding ctrl) or check boxes, but they are a little 1999.

Also, how should galleries (a.k.a collections) be handled? Images with the same 'collection/gallery' tag or should it be a separate object that keeps a list of what images belong in it? 

I don't think we should use tags to specify galleries. Neither Flickr nor Picasa do. They use both keep the Album/Set/Gallery seperate and unrelated to tags. I mean you would probaly end up storing special "Gallery/Album/Set" tags inside the EXIF or something but to the user they aren't really the same thing. It lets you do things like make a "Christmas 2009" set without actually having to tag every image with "christmas2009". I mean you'll probably have already tagged it "christmas" and the image already stores the date it was taken so why should you have to make a christmas2009 tag? It kinda clutters up your tag list. It also lets you select from the much smaller set list rather than having to find the tag/set you are looking for in a list of all the tags (which is probably massive). Anyway that's just my opinion, I'm open for discussion on the subject.

What Flickr calls collections are actually sets of sets. We should probably figure out our terminology so we don't confuse each other.

I was more thinking of singling out specific tags to use as galleries. The drupal gallery we have now does not store lists of images in a gallery, but images store what gallery they are in. I am talking more structure and you seem to be talking more data locations. A

Also, as long as we are talking about where things get stored,I don't think we should go mucking around with the EXIF tags in non-standard ways. There seems to be no standard for storing tags in EXIF format so it would do no good to keep them there. No one else would know to look there (no flickr or any other comparability added) A local database would be faster (by like an order of magnitude or so) then searching tags attached to images.  The only tags we could really add to images and expect other services to recognize are author, copyright and some geotagging stuff. If I am wrong them let me know. We seem to have different ideas about this, you (brad) having used flickr and picasa allot and me having used neither to any extent. I am just going off my ideas of what an ideal image thing would be like. 

@nick:
The original design (Sr. Project) took a copy of the EXIF (relevant) data and created corresponding tags in the database. That way, date, camera, etc were fully searchable through a database query. The actual image file was only accessed to display the image on the screen.

@brad:
I don't particularly like the idea of a directory tree sidebar, if it can be avoided. I'm looking to abstract away from directory layout as much as possible. Why should you care about the "physical" layout of where the images are stored once they've been imported? It detracts from the search-oriented purpose and design.

Maybe I'm missing something and need to play with Picasa a bit to see how necessary it is. Maybe it is unavoidable.

No! Stay pure! Looking at that will only warp your thinking so you can't see things being any other way! Or it might give you some good ideas from people who have been how this road before.

So your thinking more of an image cloud that you pull things out of based on search terms/associations (i.e. a gallery?) I like that, and it stops us from recreating the work done by every other image organizer program ever. 

I haven't been talking about implementation at all, just functionality. I think it's a bad idea to design something around the implementation. We should be concentrating on what we want this program to DO. Then after we figure that out we can figure out the best way to implement all the functionality.

And if you aren't going to use a directory structure (which would only include image folders added into the program) how are you going to allow people to view images which haven't been added to a set/gallery/album yet? Or are you going to make it so that every image folder added is turned into a gallery/set/album?

The reason for storing the tags in the EXIF is so that if I give a picture I've taken and tagged on my computer, it'll retain the same tags if I give it to you and you use it on a different computer. We would of course also need to keep tag information in a database. Solely keeping it in the EXIF would be slow/stupid.

That requires that I have the same application to see those tags. I wish there was a standard for tagging images with metadata that all the major imaging places understood. Then you could create your own personal archive and any images that you sent the way of the internet would be fully tagged. Though we could probably make interfaces to work with flickr and the likes so the tags will persist when uploading.

I guess my idea was to at least have the tags transferable between users of this program on seperate computers. Using the Flickr api it would be really easy to transfer images (tags and all) to Flickr. The user would just have to input his Flickr username/password.

Ahh! Too much talkings! This is what I was going to say a while ago, in regards to Brad's comment before the last one:

Interesting question. The way I see it, an image does not need to be in a set. Really, that is fine grain information. An image can certainly exist in the system without being part of some arbitrary set. Remember, when you add a folder to your library, they will be automatically tagged with all standard EXIF info -- most importantly: date taken.

I was thinking maybe we could stick to a single pane with multiple views, which are really just queries. Maybe something like:

• All images
• All album/set/collection/gallery/whatever-we-call-'ems
• Stray Images (the ones in no sets that Brad mentioned)

I don't know. Just spewin' ideas.

Bam, I got it out!

I can see that. What if you had some sort of UI control to all you to easily show pictures taken in a specific year/month/day? I could actually see myself use that.

I'm just thinking it's gonna be hugely difficult for somebody to look through their pictures without some sort of order or way to view less at a time. Even with all the emphasis on tagging/searching, you've still got to go through and actually add all the tags to your images.

All of us have several thousand images. To be able to tag them accurately we are going to need some way to only display images taken on a certain date. That's pretty how I organize my image folders right now. If the program can show you only images taken on a specific date then that makes my folder system redundant.

Thoughts?

I want your folder system to be redundant and useless. Directory structure should be transparent to the user. That's my thought -- once it's in the program, forget your directory structure.

Is that not the entire purpose of the program? Everyone arranges their picture dumps a little differently, but it's all arbitrary. The point of tagging and album creation is to remove the idea of the limited singular hierarchy enforced by the filesystem. No?

Oh, but definitely YES to arrange by date taken. That is a must-have.

I agree. I think we can safely leave out directories all together.

You'll need some way to display the list of image directories though. That way users can see which directories have been added to the program and remove a directory if necessary. You'll also need the list so that you can "update" -> search the directories for new images.

Multi axis searching! Show me pictures of ducks + in December 06! I'm sure that was a given though.

So should be hash out what information every file will have prior to being tagged via human intervention?
Here is what I can think of real quick (With extra useless comments!)

Date taken (for picture, not for photoshop creations)
Date Modified
Date created (provided you are using linux or something, as windows changes that every time you move a file (SO DUMB) )
EXIF data (provided its an image from a camera not software or the interwebs where it got separated from that info by paint or something. But thats not what this is for)
Size
Predominate colors (computers can see that the image is mostly green or whatever. Though we might not care)
Date added to program
file format

Anything else that might be useful for searching on prior to tagging/categorizing/grouping?

I agree to Brad's assessment of needing to show what folders are being cataloged. Perhaps a small popup window can handle this? Or another pane of the main screen. Somethin'

Ok, specifically, what EXIF data are you looking for? I know we've gone over this before, but for the record...

Here's a few I can think of:

• Date Taken
• Camera Make
• Camera Model
• Shutter Speed
• ISO
• Aperture
• Flash (yes/no)
• Mode (auto, AV/TV, manual, etc)
• Elevation

There are dozens more, but many seem camera-specific.

Heres a few more we may want

• Focal Length
• Exposure Bias
• File Type (JPEG or RAW)
• Orientation

It'd also be nice to be able to see ALL the EXIF data. You wouldn't need to store them all in the database you could just read them off the file when asked as it's fairly likely nobody would ever want to search on them. Just keep the common/important ones in the database.

Agreed, you should be able to see everything if you so desire.

I have update the outline page (http://randomland.net/tech/picture-project/outline) a little bit. It's getting a little sloppy because I'm trying to record everything agreed upon in this thread. Feel free to add to it or edit it.

So...what should we call groups of images?

• Albums
• Collections
• Galleries
• Sets
• something else

I am impartial.

I vote sets only because that is what I'm used to.

Ok.
...Nick? What opineth thee?

Ummm. I don't have a huge preference as to what we call them. I guess sets is good because (at least for me) it sounds like an informal grouping. Very much the opposite of a folder. Sets work for me.

Ok. Works for me. Plus, it's short (unlike "collections"). I'll put it on the blah (http://randomland.net/tech/picture-project/outline).

Because naming the program something like "Image Organizer" or "Picture Categorizer" is really boring we should name this program after some variety of awesome animal.

I suggest "Pterodactyl".

How about Tamias (http://en.wikipedia.org/wiki/Chipmunk#Etymology_and_taxonomy)? You get your animal reference, Greek reference to a word that makes sense in the context of the program, and a little geek for flair.  :)

(It's ok if you don't like it. That was about 16 seconds of Google/Wikipedia research)

I'm going to try and make a UI mock-up based on what we've talked about. It'll be very rough and is meant for nothing more than brainstorming.

Cue the thunder and lightning!

So I know this is all way above my head with the programming and all that...especially since I didn't bother to read 6 pages worth of posts to see what exactly was going on. But I thought at the very least I should make a post giving my total support to this super awesome picture program thingy that I have heard so much about! Or something lame like that...yep. If I ever figure out exactly what you are trying to do I might actually pretend to help or something too.

Cool, it'll be good to have a UI mock up to argue about.

Yay to arguing..? :)

I have underestimated my ignorance of XAML. I've got half of a shell of a very poor UI mock up. You guys should make your own too. I'm making mine in VS2008 Express; it's a WPF app.

The most recent version of VS I have is .net... maybe. I know I have 6 someplace. Anyway, I am downloading the express edition of 2008 now. Is that what you have or do you have the full?

No, I do not have the full version, just the freebie. I think it's fully functional for our purposes. I think the version differences and mainly licensing and extra tools. Most notably, you can't sell anything you make with the Express version. (I'm pretty sure...)

But whatever. The newer stuff is pretty cool, we should all play with it. I think I prefer the simplicity of Flex's XML control layout over Microsoft's "XAML." But we'll see. It's something new to learn, at least...not that I'm running out of projects in life, or anything.

I got tired of drowning in WPF confusion, so I kind of gave up on my UI mockup. But here (http://randomland.net/node/995) is a picture of what I started. It's less than half done and not very well though out. I need input and motivation. So: let's continue the earlier conversation about what elements need to be on our screen...

I think it might be cooler then Tuesday to be able to sort on two vectors. One being day/month, grouping all the images from a time span together with breaks between time spans (kinda like windows picture library does for days) and then pick another item to sort by. Though this would be pointless if the other sort term was always date taken as that would be the default.  But ordering them by size or quality as well might be nice. ...Now that I have said it I'm not sure how useful it would be without getting strangely complicated (sort by elevation, sort by distance taken from my house) :)   

I agree. Multiple search terms and multiple sort terms would be awesome. Nearly necessary. However, it should probably not be the default action. For 80% of searches, a single sort/order term will suffice.

For example, you would usually only need this level of detail:
All images; tagged with "swimming pool" and "barn door"; order by date asc

I vote that any more complicated controls can be spun off into its own window or change the look of the sort/search toolbars (which I hate in my example, by the way...it needs to be totally different and better). Call it Advanced Search, or something similarly lame.

I think there needs to be some UI method for determing on which dates you actually have pictures for. If I want to go lookup pictures from our camping trip last year, I don't want to have to search through a whole bunch of dates to figure out which one we actually went on. I also don't want to have to search through the a whole years worth of pictures just because I don't remember the exact date.

So, what I am proposing is some sort of date UI which shows you the dates you have pictures for and allows you to select said date there by showing you all images taken on said date. (Ok that was dumb language). This UI might just be a calendar where you highlight the dates/months which have pictures for them, I dunno. I just think we need something like that.

It doesn't have to be crammed onto a sidebar/toolbar or anything it could be in a pop-up window (non-modular) you bring up by pressing a button or something.

Ok, draw one up. VB, C#, MS Paint, napkin and a sharpie, whatever...Just throw up your concepts. It'll help, I'm sure.

I like that calendar idea.  Have a normal looking calendar with an icon or a few thumbnails to show that a day or month has pictures that were taken on it. Makes it quick and easy to see when you have pictures and when you don't. There might be something like that for the drupal gallery soon.

Just looking at your UI mockup.... What is the Tag Managment toolbar?

I mean, you pretty much just either add or remove tags right? Unless this button brings up the awesome list of tags where the size of the text is related to the number of images with that tag.

I really really really don't want to have to press a button to add a tag. All you need is a text box where I can type in a bunch of words, hit enter and have them added as tags. I should also be able to see what tags an image has. Both of these things could go in your PLAH PLAH PLAH section.

I don't really care if I have to open a pop-up dialog in order to delete tags, but you could probably get away without doing that either depending on how you display the tags in the PLAH PLAH PLAH section.

EDIT:

Also, I really think the program screen should be wider. I don't think there is any reason at all for a two level taskbar at the top. You should be able to fit the search bar, sort by, display mode and sort order buttons all on one line.

I'm not sure about the other buttons, but they seem kinda large and annoying. I do like the overall layout though. I'll try to get around to doing a stupid mock-up sometime.

Most of that ugly thing I gave up on was me trying to figure out how to lay out controls using .NET's newer old stuff. Anyway, the Tag Management junk: I was thinking we need a screen (or something) that can display all of the tags in the system. No matter how smart the program is, you'll want to be able to browse through them, delete useless ones, merge typo'ed ones together. That sort of thing. At the very least, you'll want to be able to see a list of what you've got.

It was, by no means, meant for adding tags to the system. That action should be totally transparent to the user. (So should deleting unused tags)

Agreed

Oh, in regards to the giant toolbar buttons:
The images I found were not good ones, but I picked gigantic icons on purpose. They're easier to hit and, if we find good images, they're easier to decipher quickly...basically, make all of the functionality as big as possible, without getting in the way.

But alas, I don't know what buttons we need.
So....

Required toolbar-sounding-ish functionality:

• import folder into library
• simple search
• link to more advanced search
• change sort order (asc/desc)
• change group by (date, rating, ?)
• change search parameters (given by list of tags?)
• get properties of selected items (range of date taken, tags in common, average rating?)
• link to a way to view all tags in the system
• link to a way to view all managed folder in your "library"

That's just simple stuff that I can think of being useful along to top of the app. What do you think?

Can I have a button to show my calendar popup which shows the dates you've taken pictures?

Otherwise I think that about covers it. Next to figure out is the bottom info/control bar.

Duly noted on the blah (http://randomland.net/tech/picture-project/outline).

As for the bottom bar, I think I'd be into a "tag cloud" type thing. I demand to know what tags have been applied to an image or set of images by simply clicking on them in the main pane. It should be unobtrusive but immediately distinguishable (ie -- not super tiny and hidden 4 clicks away!)

If I click on a bunch of camping pictures, I should see something like this (We should probably arrange them alphabetically, but all that markup is in the way now, so whatever):
camping woods water stream lake tree cheese sasquatch dirt hunchback green toyota honda blazer pichole

Since the tags in search results would differ in quantity and weight, we may want to tweak the cloud idea a little. A slightly different spin that comes to mind is: make "heavier" items more bold (kerning?) and have more frequent items larger (bigger font). Or swap those...or! tricks with color/alpha values.

Just an idea, but I think the tag cloud idea is essentially a good one...plus, it's entrenched in society and I can't think of anything innovative.

We'll have to think of a way to handle the enivatable image with too many tags to fit into the space. Will you cap the number of tags (no)? Will you have some sort of scrolling box allowing you to view all the tags easily (maybe)? Or do you have some other genius idea which allows you to have near-infinite tags space (I dunno)?

Scrolling text box, scrolling tree hierarchy, dynamically shrinking text to punish people who cant seem to categorize a picture in the space allotted :), ummm a 'more' button that add more space when needed (though that should be easy to do automatically when the box is full) and are we talking a space/comma separated list of terms or a multi-select tree or individual boxes to enter terms into? I personally really like hierarchical trees but they are a little much for the average user. Though we could make a default one that they could later add to if we failed to provide a default tag for something. Like say they are adding a person/place/thing then the program could add it under the correct branch of the tree (less specific then the premade ones but it would work, But then they could list all the tags that are places or people or animals or whatever depending on the granularity we use)

Ok, obviously we need to clarify the basics of out tag system. This is what I was thinking.

• tags are simply a name and an ID, which is hidden to the user
• tags applied to images are weighted. Heavier = more relevant; lighter = less relevant
• the backend should be written so that, at some point, we can implement tag-to-tag relations. For example: dog, cat, lion, and bear associate with animal
• all of that complicated tag relation stuff will be a pain to administer, from a user's standpoint. I think this would be fairly useful, implementing a flat tagging system would be a better place to start...otherwise I'll drown in taxonomy theory and become apathetic. But again, I want to build the backend with this idea in mind.
• weighted or named tag-to-tag relationships would be more flexible. It could also be more fun for browsing your collection, if we have a related-tag browsing mode. For example, I might tag angle grinder as 4% dog related..!

This tagging system seems like it's gonna be really complicated. Is anybody actually going to tag all their images this exhaustively?

Most likely: no. No one would spend the time to tag their images like that. I just want to make sure that the system doesn't get too inflexible. I think the first implementation of our project should hide this idea entirely.

Sounds fine to me.

I don't think people are going to tag many pictures individually, but groups of pictures probably. I like the idea of weights, but they are so arbitrary and difficult to determine for an image. Like a forest picture  What weight should tree be? Road? Gravel? Stream? Green? I guess its up to the judgment of the user. Also, how wil the weights effect other aspects of the program? Will images be sorted based on the tag weights?

For a good idea of how people actually tag images check out Flickr. Just visit any random persons photostream.

Tag weight is an interesting idea, but I'm not sure how practical it is.

Yeah, I know. It's one of those things that would make searching awesome but make the UI tedious. I can't think of a quick and simple UI for applying tag weights, can you? Anything I can think of starts to get pretty clumsy after about 4 simultaneous tags.

If I am the only one who sees benefit in this, it can go on the back burner also. We all know that good things take longer to cook up (chili, soup, spaghetti sauce, etc). Tag weight and relations would make a mighty fine stew if let simmer for long enough. I'm willing to throw those into the "improvement" pot.

One way to do tag weight is to have them be dragable in a pane. Tags at the same horizontal/verticle level would be the same, other lower/right (as is direction) would be heavier and sink lower.

| Dinosaurs, Rock, Cheetarah  |
| cats                                 |
| old-time rock-and-roll          |
| grass, trees, volcano           |

So dinosaurs, rock and Cheetarah are all the same weight as they are on top and so on.

Quote from: Nick on Nov 10, 2009, 05:51 PM
| Dinosaurs, Rock, Cheetarah  |
| cats                                 |
| old-time rock-and-roll          |
| grass, trees, volcano           |

Oh my goodness...what are we tagging?! If we have to tag whatever comes off the top of your head, it'll be totally unmanageable :)

Anyway, we could do something like that, but it's still a little fugly. Vertically stacked textboxes in which you "free tag" things at different levels could work but that is probably not enough detail -- you can't accurately calculate the weight of each row automatically. In the example above, what weight does each row get set to? It doesn't seem right to assume the next level down is "half as relevant" (or whatever)...so I don't know.

Maybe we should put it off until we have a workable system. But this, along with tag-relations shouldn't be ignored when we think DB design.

As far as DB design goes you basically just need an integer field in the tags table so it's not difficult to put that in. Sub-tags and whatnot would be more complex.

Until somebody comes up with a UI design which wouldn't make tag management unusably complex and irritating I think we out to hold of on actually implementing weighted tags in the program.

Tag-to-tag db structure wouldn't be that bad...basically just an intermediate table holding two tag ids and a weight and/or relationship type (child-of being the most useful). But queries would be a pain, to say the least. But that should be put off, for a while. And I'm ok with putting off tag-weights for a while...it'll make every query more complex and convoluted. But....(see below)

So then, back to the user's perspective: what tools would you expect to see along the bottom of the app? I'm still stuck on exactly how to display a large number of tags in a small bar (say, under 100px tall, to throw out an arbitrary number). If we had applied weight, I don't think there is harm in dropping less significant tags from a cloud-type control (and maybe more show up as the control sizes up)...But if we assume everything is equally relevant (no tag weight), there is simply to way to do that properly.

There is no way to display all tags in such a small place. Not unless you cap the number of tags an image can have. I've seen Flickr images with 30-40 tags easy. Sometimes 100+.

I don't think we can assume the user is going to bother to add weight values to the tags which stops you from being able to drop less relevant tags.

No, you're going to need some kind of scrolling container or make it show you have to press a button to view all of the tags in a pop-up window (you'd still show however many would fit in the box). Even if you did drop less relevant tags you'd still want a button like this.

If the tag cloud takes up too much space just use a list of tags. Without weighted tags the tag cloud doesn't make any sense for a single image.

Quote from: Brad on Nov 12, 2009, 08:00 AM
Without weighted tags the tag cloud doesn't make any sense for a single image.

Hmmm...yep. Definitely true. I guess I was trying to make the tag cloud work for single images and groups of images, but not consciously thinking of it in those terms.

But yes, I was definitely thinking there should be a button which allows you too see a full-screen version of the tag cloud (or something similar to let you see all tags)

We definitely need a button to show a tag cloud when a group of images is selected, or to show the tag cloud for every image in the current query.

I think the easiest method for showing tags in the bottom control bar would be to just show all list and if there are too many tags just have a "Show All" button which brings up a pop-up (non-modal?) which shows all the tags for the selected image or group of images. This doesn't have to be in a tag cloud.

In fact I think tag clouds are not the optimal format for adding/removing tags. They make it hard to see what tags have already been added and to find the tag you want to remove. They are good for showing you what tags are used most often in a group though.

Tag clouds are a good example of being cool rather then usable.  I like them, because they often provide me with 20 seconds of entertainment but I have never used one for its intended purpose. That might just be me though. I am all old and moldery and probably too accustomed to just searching for things or using a 'most viewed' just for finding interesting images. That is not to say that we should forgo having a tag cloud, they are kinda cool after all. Just make sure it knows its place as a supplemental search tool.

The only information they give you easily is to visually see how much tags have been used in relevance to each other. You could get this same information from listing all the tags by "Most Used" but the comparison of use wouldn't be as visually obvious.

My thought: We should include it because it's cool, but it shouldn't be the primary method of viewing/adding/deleting tags.

I thought it was more of a search tool when viewing images/groups of images. You see common tags, the bolder and larger text denoting the density of that tags use. I don't think Courtney was trying to suggest its use as a tag management tool beyond a visual reference of what tags are currently in use. I think the tag clouds place would be on the side lines to give someone a way to navigate/discover related material based on the tags. If you (the program user) added add the tags to begin with this might not be as useful. You already know what there you just want to be able to find it when you want it. The tag cloud is more a social feature for looking though other peoples collections. Or so I think.

I dunno I used it for my own photostream to see what I was uploading and what my most common (and uncommon) tags were. It is nice for other people's photostreams as well as you get a good idea about what kind of pictures they most commonly take.

I still think it'd be a worthwhile (and not very difficult) addition to the program. Plus if we ever implement web interface phase of this project it's likely you may get other people's pictures that they have tagged and whatnot.

On any semi-related note: Somebody should draw up some plans for what the top and bottom toolbars should look like. Courtney did the top one, but nobody has even suggested what the bottom one might look like.

I hate my top one. It looks nothing like I planned. (Partially because I don't know how to use the framework I was using...) But yes, someone should make a mock-up. It doesn't have to be anything more than a MSPaint scribble, even.

My suggestion -- go big, go simple.

I think it should be...

• resizable
• have a big tag cloud (sizing the the height of the toolbar)
• big buttons, including one to show a larger tag cloud window and one to show a larger window displaying all properties (might be able to combine those two ideas)
• maybe some sort of label component stack where you specify a few fields you always want to see when you click on an image. Default would be date taken, camera model, and owner info or something. But perhaps you really are interested in knowing what ISO it was taken at, so you just add a field to that component.

Do I have to try and make a screenshot mockup? What do you peeps think should be on the bottom of the screen? Or do we care anymore?

I care..... I am just not sure. Yet(i).

Just a simple version of what we could do. I forgot to add +/- buttons on the right-hand side info. Opine if you've the time.
(http://randomland.net/sites/default/files/imagecache/600px_wide/zourtney/images/infobar.jpg) (http://randomland.net/node/1085)

That makes sense for multiple images selected, but no sense at all for a single image selected.

We are going to need two completely different designs.

Ok...what exactly do you mean by "no sense?" If the left side just listed tags instead of having different sized words ("tag cloud"), what is invalid or nonsensical? Better yet, what would make sense?

OK,maybe not "no sense" but maybe "not necessarily useful"?

If you are going to pluralize (is that a word?) all of your data fields then I guess it works. How many of those pluralized data fields are of any use though? The date range one is, as is the list of people who've taken the photo. The ISO one... maybe? You could do the same thing with focal range length, aperture, etc... I'm probably being a bit presumptuous assuming most of them won't be very useful to anybody.

The only data field I need to see exclusively with multiple photos is "how many photos have I selected?" Otherwise pluralize away!

Can I have my box for adding tags though? And what does the giant blue circle with the i in it do?

I figured it'd be about 1:17 seconds worth of design and coding to make it pluralize when you had multiple items selected. Obviously, if you had only one image selected it would only day "Date Taken" or the equivalent singular form. The center stupidity was me tossing around and idea for a button that shows more info. Basically, a screen with the left and right side information, but...uh, more of it. Or in a bigger space, at least.

In my crap-crap WPF mockup I posted a few weeks ago, there was a statusbar with a pane showing how many items were selected. Very Windows Exploreresque. We could throw it in that (right hand) box too. I would want to make those fully customizable -- add, delete, and rearrange. But maybe that's not even a good UI approach anyway. Can you think of something better?...I'm no UI expert or graphic artist, for sure.

As for the tag-it box, I'm not sure where to put that thing. I'm a fan of the "just start typing and a textbox appears" (think Firefox's "find as you type" or Gnome's window manager) or an unobtrusive textbox tucked in a lower corner (think SketchIt's dimension input box). I know, I forgot about it when I was playing in paint...I was distracted with, uh, work.

Here's a live(r) version of what I was talking about. It sucks, but yeah, it's in flash so you can run it in your browser. I left out the top bar we were talking about earlier. The image grid is multiselect via Ctrl+Click. Try it and watch the exif labels and statusbar change.

I don't want to do this project in Flex, it's just a convenient example medium. (Plus I've been using every day for years, so it comes pretty easy) This is just an ugly layout concept.

http://randomland.net/sites/default/files/zourtney/files/mockui.swf
[Source] (http://randomland.net/node/1089)

We could make a flex one for randomland. But its hardly needed.

But nice. We should try for smaller font with less padding in between lines to avoid the scroller though. But that's of minor concern.  A few more tool bars for navigating/searching and adding/removing/editing(aka adding information) and you have an alpha.

Yeah, I was just trying to show a slightly more interactive view of my bitmap junk I posted yesterday. That's not polished at all. That was 6am code on a full night's rest (that is to say: not my best work). I'm trying to figure out what sucks and what doesn't :)

I don't actually like how the right-side info box is coming out, though. Even if that UI is very, very rough. Having a list of info seems to be a bad format...but what would be better? Don't we need some way to show common fields? I intend them to be customizable, too, but didn't have the time this morning.

Does anyone have any suggestions or differing ideas?

I don't feel qualified to make negative comments about the interface as I would have nothing to add (and if you cant say something nice....)

I like where things are headed, we just need to start fleshing things out so some discussion gets started. Just sitting around waiting for ideas is what got suri where she is today. So as long as the backend is solid we are good, the UI can be changed easily.

True. It's easy to change the UI, usually. If we know what the interface is going to look like (essentially), it is much easier to design the back end. If we don't, we'll overbuild certain parts and neglect others...just a fact. I'm sure you think of a certain, large-scale project whose back end was designed with no regard for use interface, but I won't name any names.

I think calling the back-end of that certain project "designed" is giving it too much credit.

Oo Ooo! Is it linux?

That wasn't what I was thinking of but maybe I'm not thinking of the same thing as Courtney...

Oh, I bet you are.

Maybe I'll try to do a more comprehensive ui demo in Flex next week in my "free time." Make requests suggestions if you think of something we haven't mentioned.

Alright, I've got a few hours of boredom coming my way this evening. I'm going to try and make the flex demo a little more comprehensive. Maybe I'll make a little tag-cloud component for demo purposes. Do we have any opinion on the customizable fields I was trying to throw on the right side of the bottom bar [which needs a name!]?

Ok, fine.

No input = No input != Gnome input.

Now that I have been sufficiently distracted by my guitar and stuff, I will distract myself with Flex and stuff.

Ok!

[offtopic]
Speaking of guitars I am thinking of taking a class to learn how the beginning of next year if your interested in joining me. Its $160 I think starts at 6pm once a week.
[/offtopic]

Sorry I haven't been much input. I am looking forward to seeing what you produce though.

I got a little bit done on this last night, but couldn't get Flex to properly compile it from Linux. I want to work on it more, so I guess it'll have to wait a day or two.

Eve went to sleep hours ago (has to be at work at 5am) so I was working on that little Flex demo program. I'm not anywhere near done with it. Play with what's there, it'll take you about 20 seconds to see everything, if that.

Check it out here:
http://randomland.net/sites/default/files/zourtney/files/mockui_0.swf
http://randomland.net/node/1095 (http://randomland.net/node/1095)

Try Ctrl+Clicking to select multiple images. On the left, you'll see the tag cloud displays duplicate tags in increasingly gigantic font sizes. On the right is the hard coded EXIF data. Right now it's not combining fields when you select multiple images -- I'll do that tomorrow. I want to make that control about 1,000,000 times better by letting the user select which fields they wish to see...someone tell me this is a dumb idea, or else I'll end up doing it.

The sorting does not work yet. I'll work on that tomorrow.

Double-clicking or hitting the "more info" button brings up a new window with the same boring information in it, but in a larger screen. I'd like this to feel more like a good version of the File Properties dialog in Windows Explorer. But, all in good time. This whole thing is still pretty rough; I'm just trying to hash out some use-cases in a slightly more interesting way than sitting in front of a word processor for 10 hours.

The search bar does work, but probably not in the way you'd expect because I'm too lazy and it's unimportant right now. It's just matching any whole word to a tag name. If you type "nick" and "thermometer" you'll return one picture of Nick and one picture of a thermometer. In the final thing, we're going to have to clarify some conjunctive operations better. But certainly it should be running an "AND" search and not an "OR" search by default.

Bed time.

Cool
I like.

Updated a little more: SWF (http://randomland.net/sites/default/files/zourtney/files/mockui_1.swf)

I added a dialog which lets you view all tags. It should probably ignore or separate the EXIF tags, but it does not currently. There are non-functional buttons for deleting, splitting, and merging existing tags.

The sort-by feature works now. Only date-sorting is implemented.

I added a set of toggle buttons which select which view mode you are using -- I just made them up, including

• View all
• View sets
• View images
• View favorites

There is a bug in there where it'll throw an error if you try sorting on any view-mode except the "images only" view.

I still haven't gotten around to making the part where you add/remove tags from images. For adding tags, I was thinking maybe you just click on some whitespace and start typing. It could have a little textbox which pops up along the bottom of component. If it doesn't already exist in the system, it'll be added automatically. If it does, it'll tie it to the existing one.

As for deleting, I was thinking that when you hover over a tag, it could put a box around it with a little "x" in the corner for deleting. Something like this, only better looking:

(http://randomland.net/sites/default/files/imagecache/600px_wide/zourtney/images/tag-cloud-delete-idea.jpg)

This is the best idea I can think of for disassociating tags. Making you edit it through another popup window would only slow things down.

Adding and removing stuff from sets is a whole 'nother issue. But I'll wait to see if I get any input on this...

Perhaps a text box below the tag box that lets you add tags one at a time or comma/space separated.  With, of course, an add tag button next to it. Just as a clear place for adding tags without mungling up whats already been input.

that sounds good. I'll work try to make a usable demo model in Flex soonish.

I need some motivation on this project (again). Anyone know where to score a cattle-prod?

Who usually scores things like that? I have access to a shock collar.. but that's not quite the same. Just take some pictures and get frustrated by the lack of categorization. Saturday sound like a good picture taking day.

Truth be told, I'm not actually interested in electrocution. The picture taking idea seems far superior in every aspect imaginable.

Why are the randomnets so slow?

Brent is streaming music on his computer. That's all I can think of. But that's download and shouldn't affect the upload speed. Beyond that I don't know.

If I ever get rolling on this little project, would anyone be interested in testing for me?

Of course. I can help give you a little push if you like (get you rolling and all that....hmmmm rolling... go karts :) )

The Wheels of Moderate Interest have started to turn again and the hulking Chariot of Motivation has begun to crawl. The Axles of....nevermind, my vehicular metaphor fell apart.

Anyway, I'm starting to design this is my head again. It comes in cycles and has become more frequent, as of late. Some day I might actually do something even! Maybe I can hash out my requirements for the 23rd time during lunch today.

Let us see them! I want to help out, but it is your project. You lead us! And we, your humble code monkey conspirators, shall follow. 

As I somewhat had expected, there is a decent way to tag photos in Windows. What I did not expect is that it is built in to Windows itself (Vista and 7, anyway). You can edit tags from the properties dialog on images, doc files, and a few others (but not all files, for unknown reasons). It's easy and the search bar in the upper-right corner actually does a pretty good job and will recurse into subfolders. It'll even pick up the camera model; I did a search for "rebel xsi" and it tossed me back everything taken with my new camera.

By default, it'll search on filenames as well, but you for prefix it with tag: and just search the tags. For example, I tagged a few things and then did tag:christmas and got what I was looking for. The only obvious feature I see missing is that you can't right-click on a folder and add tags -- you have to select a group of images first. And, of course, there is no tag merging or splitting, but that is minor and would probably never be used anyway.

I think I will play with this for a while and see if it is a usable solution to my never-ending image tagging project. If it does work decently, there may still be a need to write a program that'll do a nicer-looking search, import/export.

Edit: It's kind of obvious, but I forgot to mention it -- that there is no sort of tagcloud or anything. So, while the tagging might work great for searching, you aren't going to be able to visually see what you take pictures of the most or do any kind of "data mining" on tag frequency or tag relevance. Anyway, I'm gonna play with the hard part -- tagging 100,000 pictures!

Perhaps making a companion program to the native tagging in windows would work. Something that makes tagging large numbers of pictures easier and keeps track of what tags have been aplied to things (that way you don't have to remember what tags you used when trying to search for something. In example, you named a beach trip "sandysomething" and then forgot you did it.)

So, I have tagged several thousand pictures with simple tags like "taken by courtney" or "klamath falls". The integration into the Explorer windows is pretty nice -- there is even a little bar across the bottom which lets you view and edit tags. The only problem is that it's a little to compact for my liking. Tags are only given an area about 100px width and 30px tall. As such, you can only see about 2 or 3 at a time unless you click on tagging box.

So, here are my conclusions, as of today:

• Unsurprisingly, Windows seems to have jumped on the file-tagging bandwagon a bit late. Internet has it that Mac OS now has full file-tagging support built in to the file system itself (I think). In Windows, you can tag stuff, but only select file types (those with dynamically sizable headers, I suppose? I found that PDFs can NOT be tagged... >:(). The Explorer window and Properties dialog editing is a fairly quick and easy solution and is similar to what I had in mind. However, it is rather slow to apply tags in batches over 200 or so files. Patience required.
  
• You can't recursively apply tags to subfolders. This is annoying. You have to manually select all JPG files and then edit the set. The tag property does not show up if you have non-JPG files selected. So, if you have any movie files (which I almost always do), you'll have to deselect them first. Ordering by file type helps a lot, but is still an annoyance. Enjoyment of tedious tasks required. By the way, searching for *.jpg and then trying to tag that simply refuses to work. It times out, or something, but never actually tells you what [didn't] happen.
  
• When tagging stuff, windows will pop up suggested tags. This helps reduce the "bard briles" typo type mistakes. No complaints about that.
  
• The search works quite well and will recursively search subdirectories. It is decently quick and will search both filenames and image tags.
  
• There is no real way to know what tags the system is keeping. Surely they must be stored somewhere. But I do not know where. Consequently, I have no way of doing "count" type querying. Acceptance of tag statistic ignorance required.
  
• I need an interface with a little more real-estate. Viewing the tags in the little 1.5 lines that is shown in the bottom of the window isn't enough. You can't glance at it and get any useful information. I'm looking for a tagcloud type thing when multiple items are selected.
  
• As good as the search is, it lends itself to filename/folder searches. I'd prefer to search by tags and disregard filenames entirely. This could be fixed by giving my JPGs lame filenames, but...that's a lot of changing of stuff that doesn't need changed. An example of when this is annoying is searching for "christmas tree." I have hundreds of files named "Christmas xxx.jpg" and they show up. I want stuff tagged with "christmas" and/or "tree". Minor, but annoying. Other improvements I can see would be EXIF data filters for camera type, date range, exposure bias, etc. An "advanced search" seems necessary in theory, but maybe not in practice...after all, search results do not need to be 100% slim and trim accurate, they just need to return what you're looking for.

It seems there is some definite room for improvement over the windows getup. People are not patient, do not enjoy tedious and repetitive tasks, like more real-estate but probably are ignorant of tag statistics.

So you don't have to implement search because its already done for you.

Is there any way to make a "tool bar" to go into explorer in order to make more real estate available to the tags, as well as perhaps adding some buttons for tagging and doing some statistical culling of information. (then you could make a tag cloud!) You would just have to scan all the files to get what they are all tagged with, then store it all in a tags.db next to the thumbs.db. It'd be nice though if you could get windows to do it all for you.

I'm wondering if I can find information about how windows stores these tags. It is obvious that they are stored in some system-wide database. When I start typing, it pulls email contacts, word-document authors, and a whole slew of tags I never entered. If I can seamlessly tie in to this, I think that's the way to go...even if it does tie the tag system down to a Windows platform at this point.

And, while it seems that the tag names are stored in some sort of database (or some other persistent, quick access data structure), I am not convinced that the tags are. They are quite likely just stored as text entries in the files themselves. The searches are quick, but there is a noticeable pause when searching through 80,000 pictures -- the kind of pause you wouldn't expect to see from a relatively simple database query.

But that is all just conjecture. I haven't started digging yet.

The database is probably built when the file system gets indexed. The pause might be from searching newer non-indexed files?

I don't know. I only speculate.