Personal Photography 2.0

I have been considering solutions to the data overload problem that I mentioned in my last post. For now, I will hold off on dealing with paper documents and the issue of multiple online content repositories. Concerning digital images, however, here is an example of what I would consider a highly optimized system which could be created using current technology.

The image capture device itself need not be any different than current digital cameras except in a single essential and several optional aspects. The essential aspect is wireless data transfer capability. As soon as a picture is taken (and perhaps pending a 5-20 second waiting period to allow for deletion of images locally that are not wanted), it should be transferred wirelessly and automatically through the internet to either a personal computer or, perhaps preferably, to a hosted server or service. The latter would likely be better since a hosted service would have a higher percentage of uptime (unless the individual has a very stable machine running with a UPS and their ISP never goes down). Now even at this point, before any of the "magical", i.e. extremely helpful and cool, elements come into play, a great benefit has been realized. Viz.:

• If anything happens to the camera or memory stick while out, the data is preserved. From dropping a camera to the memory becoming corrupted, things can happen.

The camera and the memory stick are no longer single points of failure. The data captured will be preserved almost immediately after capture such that it cannot easily be lost.

In addition to this, however, one can imagine many other potential features that could be added to the system. The camera could be fitted with additional sensors, or additional data could be associated with the images captured. Normally, digital cameras simply associate the time of the shot with the file created. But the temperature, say, or weather conditions, or altitude, could also be added as metadata. This would allow for a more coherent whole of the events captured to be constructed later. Of greatest assistance, I think, would be GPS-based location data for each image. This could be incorporated into the wireless data transfer system added to the camera. In this way, a real "trip" could be reconstructed from the images, via a mashup with Google Maps, for instance.

The final elements of this system would be performed by the user's computer or the hosted service, for performance reasons. The simplest step at this point would be to display the images captured in a web portal, associated and organized by their metadata, time, location, etc. In this fashion, one could make images from a vacation or outing available while still out on the trip! And that without having to download them to a laptop and have internet access on it at the time. Or if one wished the images to be kept private, one would minimally already have a photo album waiting upon returning from the trip.

The more complicated, but also more interesting, step now would be to analyze the images for content and provide them with appropriate names. This could utilize preferences set by the user concerning the naming, length, title versus tags, etc. Automated image recognition technology has not been deployed for individual use in many capacities as of yet, but this feature would provide for great strides in personal organization. Instead of sorting through hundreds of images and coming up with names for them such that they can be searched, imagine an automated process which would scan the images, find and assign likely tags or titles, and organize the images into albums divided by topic or by location!

I currently lack the skill to implement the steps of this process, but this entire system could be realized based on presently-existing commercial technology.

A consideration of a personal business interaction

I wished for something today that at first surprised me, but made more sense in afterthought. At a grocery store, when it was my turn to checkout, I knew exactly what the cashier would be likely to say, the exact procedure she would follow. After the perfunctory greeting, she would ask whether I had a discount card for the particular store, then scan some or all of the items (depending on their number), then ask which bag type I would like. After all items were scanned and the price totalled, I would brandish my check card, which would prompt the query "Credit or debit?". Of course, I would select debit because I would not want to take the time to get the receipt and sign it when I could simply put in my PIN. In any case, since I selected debit, she would ask whether I could like any cash back, to which I would respond in the negative. After the transaction was completed, she would provide me with a receipt and I would be on my way. Nothing too extraordinary.

But this is what I will do every time, aside from the extremely rare cases of asking for an alternative bag type or for cash back, as a result of special circumstances. In today's case, as I walked out, I found myself thinking, "I sure wish I could set my grocery store config file to those responses as default, and pass special options when necessary." I most likely thought this as a result of being in a programming environment commonly, where seeking such improvements would be a matter of course. I smiled at my thought, but then asked "Wait, why not?" Why need I take my thought away from other considerations to respond whether I would like paper or plastic? Why would that be necessary more than once? Why not have my preferences for such things stored in my debit card, which I would slide through a reader after unpacking my items from the cart?

I think pondering such possibilties is fruitful, in that there is no reason that even small elements of everyday life such as this should not be improved when possible.

Adumbrations

I used to spend several hours a day combing through feeds, newsletters, and portals concerning topics I found interesting. At first, I merely noted them in memory. Then, as I became interested in being able to refer back to particular developments, I started a simple text file, divided into basic topics, such as "Security", "Programming Languages", etc. After a short time, this became unwieldy and ineffectual.

My next approach was to create an extensible folder structure, finely-grained by topic, containing document files which included the links to stories, tutorials, and other sources of information pertinent to the topic of their directory. I also found it easier to add personal notes and commentary on the information in this way. This method was much more effective, but still very limited.

As time progressed and my collection of information grew, I realized that the structure I had created was limited in two critical respects: 1) adding or editing information was overly time-consuming, as I had to find the appropriate document in the appropriate folder structure, then open, edit, and save it, 2) searching the structure was limited to the search functionality built into Windows, and later to Google Desktop search. It became clear at that stage that the design of my record system needed to be centered around 3 basic principles:

1. Ease of entering new information
2. Ease of searching for information
3. Ease of altering topical structure
   

Around the time when I began to grow dissatisfied with the folder/document system, I discovered Treepad. This is a wonderful program, with many potential uses. It allows one to form a structure of "trees" and "leaves" within a single file. Each of the leaves allow for insertion of text and images, and the entire structure can be altered, linked, and seached with ease.

Using Treepad was much more effective, and I would have been satisfied with it, had I not found Freemind. This allowed for all the features of Treepad, except that I was not limited to an Explorer-style visual interface, but rather a topic map which could be unfolded as desired. I found it much easier to find information, track developments, and understand topics through this display method than any structure I had used previously.

I ran into one final difficulty: as my topics of interest and my databank grew, I found that the time required to search through various feeds and portals, pick out interesting information, and record them in my topic structure was simply too great. Thus emerged the need for a system which I now set out to create. This system (for which I lack an effective name currently) will perform the following basic functions:

• Record an initial list of syndicated feeds and URLs of portals of interest, and allow for new feeds and sites to be imported
• Read each of the feeds or portals as appropriate and parse the information they contain
• Tag each piece of content based on an extensible topical structure
• Record content and applicable metadata in a database
• Provide an interface for the content to be searched based on a variety of criteria
  

The system may also be extended to include the following much more advanced features:

• Web spiders to find new feeds and sites which should be of interest based on the current topical structure and areas for which information is lacking and determined to be desired
• Visual interface for graphical display of topical structure and content relations

I hope to write this system mainly in Python, as it seems suit the task well in its simplicity and ability. This blog will serve as a record of the steps in its development, from things I learn about Python, to semantics, and probably much more.