metaverse

A new project: Pixelpipe (Projects)

Thu, 24 Jul 2008 06:52:00 GMT

You may have been wondering why it's been a while since I've done anything on the PictureSync or MediaSock front, or if you're a client why my availability has been next to non-existent (sorry!). Although this was not the intention, I can now reveal that in December I was invited to join a [then] stealth startup Pixelpipe. Technically I joined part-time so that I could continue with other projects, but it hasn't quite worked out like that! It's a cool project, in fact one that I'd already considered (but rejected) doing myself, however with the incentive of someone else funding it and the idea of a regular paycheque, it seemed unreasonable to pass up!

Thus I've been busy designing the core logic and managing its development of what could be described as a PictureSync as a web-service. I'd floated this as an idea myself after developing the MediaSock Client Framework (our .NET photosharing service abstraction library), having seen that so efficiently deployed by Scrapblog. However at the end of the day I'm still a believer in the power of the desktop—but I'll do a follow-up post about this, and the impact on PictureSync/MSCF at a later date.

It's early days and I'm not going to (heck, can't really) go into any detail about what to expect as Pixelpipe grows, other than that we've got a lot of connecting to do between apps and providers. As part of this we will be working towards providing SDKs and APIs that enable developers to employ our platform as simply as possible. Now we're a closed platform with our own business-case, but these will be built as much as possible around standards, and with interoperability in mind so that developers are not reliant on a system that could one day disappear. Whether for an hour, or forever—replacability (or the ability to have an alternative) is of course one of the issues of network-based computing/services.

I'll add that scalability is also a critical issue for such a platform and this is partly what put me off doing something similar myself. Whilst we've been busy with Java here in Delhi, the guys in SF have been imaging, starting, stopping and re-imaging EC2 instances with frightening frequency, and that has ultimately given us what we expect to round out into an elegantly scalable computing layer. This would have been quite a hurdle to both development and adoption without EC2 it has to be said!

I'll post more soon, but also see this post on the PictureSync blog, ping me, or just signup on the Pixelpipe site if you'd like an invite.

Photo metadata conclusions (Photography)

Fri, 29 Jun 2007 17:57:00 GMT

Some industry bodies recently held the first international Photo Metatdata Conference and the IPTC have released a Photo Metadata White Paper (PDF). These are their conclusions to which I'm interjecting my own thoughts. I'm starting with their last point first, as to me this is the most important.

A key feature of metadata for digital assets – photographs included – are globally unique identifiers: Standardisation bodies and system vendors should start a joint effort to define and encourage a technical and administrative system for generating such identifiers and a system that resolves these identifiers to a set of at least basic information about this digital asset.

This means giving every photo ever taken a unique ID that enables it to be identified from all others. Arguably a filename is an ID, and on a camera filesystem this is both unique and persistent. Once transferred to a computer however that name may be shared with other files (often the case) and may also be renamed (not persistent). After import from a camera professional photographers often use a utility to rename all their images uniquely to avoid this issue. DAM and photo-organisation applications use different techniques for identifying and avoiding duplicates, the most basic is a simple file hash however this doesn't accommodate editing, others check the date and time captured but even this might not be unique, whilst more advanced solutions are to analyse the image data for similarities. None are brilliant. An ID would benefit consumers, professionals and application developers alike.

Privacy advocates are likely to throw their arms at the implications of photo IDs. Take for example MAC addresses, which are unique IDs used in network communications (below IP), it's possible to ascertain the manufacturer and thus potentially trace the part all the way back through the supply chain to a customer. In my opinion it would be wrong for a photo ID to contain any traceable element. Some cameras actually already embed their serial numbers, indeed this can then become exposed by photosharing sites online, however I consider this potentially useful data, and believe that applications at the point where this data could be compromised should strip it out. Law enforcement agencies would no doubt love to have all this information embedded, but I shall say no more about the traceability issue beyond having raised it.

The benefit of an ID (untraceable or otherwise) in the workflow and is two-fold. Firstly it will make managing a user's assets infinitely easier in that duplicates and derivative versions can be linked and grouped across different applications. Indeed I would like to see such a Media-GUID spec support a hierarchical derivation tree that records the ID of an original item and creates a new one when the user saves a new copy of the file, revealing what IDs and versions have been used to create it. (This would obviously require support in desktop editing software.)

Secondly, and probably most interestingly, workflows that involve transfer to other systems, such as with photosharing, will greatly benefit through the ability to uniquely identify photos. For a desktop application such as PictureSync that transfers items to service providers, in order to offer the ability to update that photo with the provider at a later date (an essential part of any dynamic workflow), it must store an ID for that item. Currently a provider will generate it's own ID and then return it to the client application to store, and send back anytime further actions need to be applied (e.g. updating changed metadata, or replacing the entire file). With a Media-GUID the provider would not need to return such an ID nor the client store it, as an ID would already have been created for the photo file at its point of origin (e.g. a camera, or scanner…).

Write-Once metadata values: Some metadata values can actually only be written once without abusing a stakeholder, such as the creator or the original copyright owner of a photograph. To implement this requirement, the values of specific properties should be protected by a digital signature mechanism: it would not prevent changes to these fields but a check against the signature would reveal any changes.

Versioning of metadata values: Currently only the latest edit of a property's value is stored. At least as an option it should be possible to save the previous version of a value after editing it. Another option is that standards should define which properties should or must have versioned values.

Both of these raise the issue that metadata is not always preserved by applications when editing, and brings into question what should be. For example editing the image data (e.g. by adjusting levels) in iView MediaPro/Microsoft Expression Media destroys some of the camera-specific EXIF data. Arguably the camera is no longer responsible for the current state of the image, however that data is still relevant In combination with a Media-GUID, we could record changes attributed to a specific version of an image having its own derived ID. Metadata values not specific attributed to the primary ID of an image would merely be representative of prior versions, and in combination with the IDs of those versions applications could group these version for easy reference.

Cameras should allow easy-to-preset metadata values: As the camera is the first stage of most photo workflows, it is highly desirable to upload presets of administrative and descriptive metadata such as the photographer, a job identification for a series of photos, or a common basic caption for a series of photos.

Cameras should deliver more than Exif metadata (this point is related to the one above): The current Exif specification provides only a limited set of descriptive and administrative properties. To meet the request for uploading metadata presets it is desirable that cameras manage metadata beyond the Exif schema.

Metadata standards such as IPTC have historically existed for and been adopted by professional and organisations for their specific workflows, it is not uncommon for such standards and functionality to then filter down into consumer applications as there is some commonality and this should be considered so that common ways of capturing metadata on the camera can be implemented for all usage scenarios. Current attempts to allow labelling of shots on consumer cameras provide little utility that can't be better implemented at transfer time, and neither professionals nor consumers are likely to want to spend time after taking a shot to annotate, so clearly this needs work. It appears to me the solution to this would lie in tighter integration with the desktop, and an evolution in camera interfaces to allow richer input…

UI. This is the most readily implementable and comes down to the workflow. Almost inevitably for consumers and professionals alike, photos are shot in batches, so having a simple mode to start a batch and enter common metadata would solve the issue of doing this repeatedly. A lesson could be learned from phones and PDAs here. A camera with a scroll wheel or even a multi-touch display, enabling text input would enable the shift from annotating metadata at the desktop (or online) to the camera to be more effective.
Discoverability. GPS provides an absolute way to acquire a position, but other means can allow a device to discover relevant locative metadata and give an image a position or approximate address also. Wi-Fi and cell-tower IDs also offer opportunities to discover location (a simple one-way cell radio that can receive local cell IDs would be effective, possibly more so than GPS in an urban context, especially with triangulation). Such data could be refined by the user either in-camera or in an application further down the workflow--having a suitable UI and connections to databases/webservices that allow the resolution of the available data (e.g. latitude/longitude, cell IDs, etc. to place names). With an increase in nearfield discoverable devices the camera could even suggest who is in a photo based on the owners of nearby devices. This could even be used to automatically identify people using facial recognition by acquiring a recognition profile from such devices. (Thomas Hawk and Dave Winer are conjecturing in this general direction.)
Sync. Devices should be able to sync lists of frequently used keywords, places, people and other metadata with desktop applications. This will avoid the need for inputting data constantly on the device and instead to simply select from lists defined specifically for the user on their desktop.

Improved support for controlled vocabularies (CV) as the source of metadata values on the user interface level: Currently, the vast majority of photo management software provides only limited support for this feature. CVs that map between a single term identifier and term names in different languages are a tremendous benefit to the international photo business – but their easy application by users must be supported by the software. Another requirement is to agree upon a common format for exchanging CV files.

Having done some work on solutions involving this I can agree this is essential, especially for workflows involving professional service providers (such as stock agencies) and photographers with specific metadata requirements.

Well defined mapping between metadata properties of different schemas: Exif, IPTC IIM, IPTC Core, PLUS and other standards exist in the photo industry. In fact metadata properties for precisely the same semantics exist in parallel. A mutually agreed and well-defined mapping between the properties is the basic requirement for any synchronisation of values by software.

Consistent implementation and use of photo metadata standards must be improved: Standardisation bodies should not only provide technical specifications but also easy-to- understand names and descriptions for properties in different languages. Software vendors should commit themselves to adopting the names as field labels and to provide on-the-spot help with the full definition of a field to deliver the specified semantics to the end user. Furthermore, standardisation bodies should also provide user guides on how to fill in the metadata fields. The IPTC has created a user guide for the IPTC Core and provides it at no cost to all software vendors and interested parties.

This is well identified, and does need to extend beyond identifying the equivalencies across different/related schema, to also providing standardisation and usage guidelines within a single schema. Currently even a title property can be found in either of the IPTC-IIM fields Headline or Product Name/Object (the latter being used by Adobe Lightroom, the most others).

Imaging devices are not restricted to cameras anymore: To align pictures from non-camera sources to existing photo workflows, the makers of such devices should implement photo metadata at the same level as professional still camera makers.

Just as one can't presume that the material is a photographic image, or that the subject matter of the image is to be attributed to the date of capture (such as with a scan of an old family photo).

Contrary to professionals, consumers at the end of the day don't care what data is being stored and where, so the benefits for them in these movements are mainly non-tangential. But in both cases the goal is to acquire more data to refine the management and presentation of the media, and equally, enable data portability and preservation. The conclusions from this first conference certainly seem to be on the right track.

Stateside Update (Projects)

Sun, 27 May 2007 23:42:00 GMT

I am now in Manhattan, since 10 days. Although I've not yet settled into longer-term digs, I am more or less acclimatised to the change of environment, even appreciating it, if not pace. I'm pretty clear on what I'll be doing for the next 2+ months, still being on track with the plans I laid out in Blore, before ascertaining the next stage.

I am still looking for co-founders/developers to put in time on PictureSync, but will be following up some further neglected leads shortly (sorry to those of you awaiting a response). I could actually see myself setting up shop here and taking on more clients and becoming quite successful as such, but this is not my intention and PictureSync remains the focus, and MediaSock has been moved up the agenda.

I definitely made the right decision coming to the US, so far it does seem much more entrepreneur-friendly than the UK or India, not least because I suddenly feel in control of the outcome (!) and amongst people who appreciate the freedom of innovation. But either NYC is bloody expensive, or inflation has been on a rampage since I was last living in a big city (some three years or so), then again Bangalore isn't exactly good preparation. The Dollar exchange rate is doing its bit though.

Unfortunately I haven't yet really been able to focus properly on work, barely caught up on email, and only just managed to finish wading through my feeds (too much relevant news!). Still I should be able to hole-up and get down to doing something more than talking soon.

Footnote: apologies to anyone who's posted comments previously, I had a rather unpleasant surge of spam and accidentally deleted all comments whilst clearing them out.

Presence Aggregation (Web)

Sun, 27 May 2007 20:59:00 GMT

Svetlana at Profy has posted about profile aggregators, and I was going to comment but got sufficiently carried away that I opted for a blog post…

Profile aggregation is a bit of a misnomer, really they're presence/activity aggregators that are exposing your actions from across many services, from which profiles and identity are built. These sites are useful for pushing your actions out for those who follow you to consume in a conveniently combined view. Conversely some of these sites are intended for consuming the activity of your own network in an aggregated fashion (rather than publishing your own), but really lack the deep integration that would make this any better than a feed reader.

I think many people don't however want to aggregate their networks and identities in one place, I like to keep my personal and professional networks separate, and indeed to have distinct profiles in some cases.

That said there are actions I would like aggregated from across different sites, and I'm really liking Jaiku's lifestream view at the moment, it provides a simple time-based overview of your (grouped) actions. Whether Jaiku's slim timeline view or Ziki's more interactive categorised view is better is debatable, and probably comes down to intention. If you're actively following someone, Jaiku is better, but Ziki is if you're discovering/exploring someone (if not ideal in that role). Mugshot also has a similar if less developed lifestream view.

Using one of these services as a URL (on email, cards, other sites, etc.) is definitely going to make it easier for your contacts to stay abreast of your actions. But at the end of the day not everybody wants to see all your identities and actions, so a quick way to drive a user to the most appropriate profile is useful. Jaiku lacks the ability to add links to profiles though, whilst Ziki and Profilactic allow you to add arbitrary links to expose your actual diverse profiles and identities.

43 People has long provided an aggregated view too, similar to SuprGlu (which has the nicest layout of this type) and Profilactic, but these views are much harder to keep tabs on as they generally include a full content rather than a summary like Jaiku (and Ziki). I really don't see that services like these with full views provide a useful function, unless the user produces a low volume of activity. This could be improved if they were to use grouping/nesting (of time and type related content) like Jaiku does. Indeed visualisation and analysis of actions needs to develop a whole lot more to keep pace with the increase in user output and service generated data, so as to avoid overloading the users that wish to consume this information that is being produced by their network.

What really sets these services apart is deeper integration to acquire data about your activities and identities, from the other services that they're integrating. Such as by exposing and grouping your contacts or Jaiku's ability to access your location and availability from a mobile client. I can't wait for this to be integrated with IM for presence data too (as opposed for twattle).

For an average user, the choice, functionality and indeed purpose of all these services is bewildering. What is clear, is that with the growth of activity data and disparate identities, aggregation is essential for this information to be consumed. Yet perhaps not so for the producer as using separate specialised sites (e.g. for photos/videos, blogging, music, networking) allows them greater freedom, and binding these data streams together themselves may not be in their interests (or within their scope of knowledge at present). The onus therefore may be on the consumer to find the solution for gathering a person's distributed identity and not vice-versa.

Anyhoo, convergence isn't happening anytime soon, for now everyone is still working out out to connect so many diverse things together (mashups). I'll add that Facebook's new developer offering may yield some interesting results here with its open and modular application add-ons platform.

Preferential photo-sharing (Photosharing)

Mon, 30 Apr 2007 11:39:00 GMT

I'll admit it, although I'll happily take what I'm given and probably appreciate it, I'm a desperate cynic and hard to please when choice is available—especially for something I'm passionate about (basically design, and aesthetics—both in look and feel, which includes interaction and usability).

A PictureSync user just asked me (thanks John!) what are your favorite [sic] photo/video hosting sites? (off the record) (I'm going to presume sharing in lieu of hosting here as the functionality is quite distinct even if hosting companies like Photobucket are increasingly blurring the line.)

On the record (as this is a blog post now ;) my favourite sites are presently Flickr and Vimeo for their communities, aesthetics and to a certain extent, innovation too. Indeed these have been my favourites since the beginning except for a dalliance with Buzznet who managed to create a nice integrated offering (but subsequently for me the design and community missed the mark).

However for an all in one package it looks like the new incarnation of ipernity could be a winner, it appeals to me as an integrated solution for blogging, photos and video, more than its most obvious rival VOX. In part because of its Flickr UI cloning, although being compared to Flickr doesn't do anyone any good.

Twango is also pretty progessive, and I wouldn't rule out SmugMug as a recommendation if perhaps only for their passion, longevity and reciprocated loyalty to their customers. I'm afraid to admit I haven't yet properly checked out the new version of Zoto, but they did impress me and their apparent mimicry of SmugMug's business model (not free) could herald good things.

Although I don't personally use any of the following services, they stand out and are worth investigating too. Fotki are frequently overlooked but have a solid and popular service that includes basic journals (and some limited video functionality). Likewise 23 has a nice simple stories function allowing you to mix words with photos, whilst with Zooomr you can flag people in your shots and create links from an area of one photo to another. Also worth mentioning is Tabblo which lets you create nice layouts of your photos, and Scrapblog which takes custom layout even further.

This is a thoroughly incomplete glance at what the photo-sharing space has to offer based on my foremost observations. Indeed working in this space does my head in sometimes with the proliferation of services. It's tough trying to stay on top of developments and indeed making choices about which providers to support (hopefully in future when we've got more resources online this won't be such an issue). Ultimately though liking a product that holds and presents your intimate memories and thoughts can only be a very personal thing, and can thus only be evaluated yourself.

Whilst I'm on the subject of sites I like, I want to mention Tumblr, a multi-media meta-blogging platform of sorts, and Jaiku, an aggregation, and presence service with a mobile client (akin to Twitter with Plazes, or Twittervision).

As I haven't posted here for a while, remember that I'm increasingly using del.icio.us as a picoblog and am including links their to interesting sites, blog posts and comments threads. My del.icio.us page is linked in the sidebar, along with the latest links, and if you're on the feed, you'll be getting the links combined daily.

In other news, as per my schedule over here, I'll be hitting NYC for three months in a couple of weeks (after a brief break in France) to really focus on trying to get uVerse's projects (PictureSync and MediaSock) to the next level. But more on that later.

Reflection

Sat, 06 Jan 2007 07:05:00 GMT

Now is typically a good time to reflect on what's happened in the past year, however my year currently ends in the spring when I leave Blore, and will start again after a bit of a break in France. I have two posts written about this time last year that clearly show how much my plan at that time changed, leading to my coming out here. Suggestively I never posted these entries.

Firstly I'd just completed my first private software development since leaving Enigma…

(Jan '06) A little bit of liquidity can certainly be useful (especially as my last reserves were long since squandered on a particular trio of rather scrummy cocktails in Cannes), and although I'm not looking for work occasional requests find their way to me, and so I just undertook the development of an upload application for a Canadian service…and may be doing two more. After some inevitable misunderstandings (the complexities of French tense don't translate too easily) my first effort at doing private software development independently is apparently faster than Fetch. However I must try not to get distracted from the tasks before me (which will it be, restructuring my business plan, hacking code, or cultivating ideas?) thus it is that I probably won't take any more on, although this all depends how long raising finance for my project is going to take.

Secondly, and given extra interest in what I was doing, I had then planned on moseying off to the Valley and raising some decent capital…

(Feb '06) I have to say I like planning cash flow forecasts. For those not in the loop, my business plan 2.0 ups the ante from circa 100k angel investment to significantly more from VCs. This is of course partly the reason why I'm enjoying this revamped plan. It means I don't have to scrimp and save quite so much, and can even afford to have a Cocoa Guru on the staff roster… now if that's not super what is? No I don't have a Docklands suite on the business plan, but I'd be paying myself a decent salary during the development phase at least.

Both of these outlooks were clearly discarded and I ended up doing more client work, and adapting to India, whilst PictureSync has sat on the backburner for most of the time. I have only an inkling of what is in store for 2007, but I am going to have to be more selective about taking on external projects, and also kicking back a bit more! Indeed I'm thinking I may not return to Blighty (at least for long), but head off somewhere else new, given how portable my work is.

It is clearer with every passing moment that my plans have fantastic potential, and that I'm on the right track, with forecasts (and examples) of tighter desktop-web application integration and innovative UIs coming from all quarters, and photo/media sharing having achieved critical mass (take a ganders at this Kodak Winds of change video put together for promoting their vision within the company). Some interesting thing were learnt and achieved last year, but still there's much to be realised, and I'm certain 2007 will be bringing some good surprises as uVerse is starting to become a cohesive operation. (I'm actually also partly involved in a social-web nightlife platform for India as a side-pursuit but I'll blog about that when it is launched).

For PictureSync, having now passed the 2 years, 2m uploads, and 1k sales marks, without really having tried, it's time to grow out from its niche and embrace the larger market and make it both profitable for us, and essential to our users. The first stage of this will finally be getting some steam behind it with a UI overhaul in the coming months to make up for the stalls. This isn't going to be radical, but it's the first positive step in the right direction. (Mentioned over here.)

My watchwards for 2007 will be, stay keen, be focused and realise value. Growth will follow.

Aperture Export (Projects, Design, Development)

Wed, 27 Dec 2006 05:52:00 GMT

I've previously mentioned how Apple have sagely gone about developing an API, not least by hiring an external developer to supplement their team, and by getting a bunch of service providers on board for its launch.

We were recently approached to develop an Aperture plug-in and as ever being up for a new challenge, and to test out what the Aperture API is up to, I was keen to take the project on. This plug-in we've developed is just about ready to be released, so as I haven't blogged here for a while what better than to recap some of my design decisions and observations on Aperture's API.

We've already worked on another solution for this service so were familiar with its methodologies and were simply tasked with making it fit with Aperture. I should add that I did not do the Aperture code myself, indeed increasingly I'm doing much less coding which I have to say suits me fine…

Aperture has an export plug-in API that allows developers to add image export functionality (or upload—notice the menu naming inconsistencies). It takes a fairly managed approach which took me by surprise somewhat, as the main plug-in UI is a view within a window managed by Aperture itself, and to which Aperture will add options (such as naming or conversion controls) as desired.

This means you only have design control over one part of the dialog, on the plus side it saves you a great deal of trouble reinventing the controls it does offer, and ensures a degree of interface consistency for the user. But on this latter point I would argue that although a user may (will, what with the proliferation of services) have several plug-ins, it is not going to be enough that, allowing for the variation amongst service requirements, that any UI consistency might actually be worthwhile. Of course as a developer in the field I fully understand where they're coming from, but as a plug-in developer I wanted more control as I was out to design a UI with a bit of chutzpah.

The key issue for me whilst considering usability and design impacts, was that Aperture provides an exceptionally limited feedback mechanism during uploads. Furthermore it's modal which means the entire Aperture UI is blocked during the upload, so you can't make optimal use of your time. Not that many other applications address this issue, but Aperture is supposedly progressive.

My solution to both the issues (UI and uploads) was my usual. Use a standalone application. Unfortunately having access to the Export function within the Aperture was a requisite and as Aperture foists its Export dialog upon you, you can't simply launch an external app from your plug-in and not show the Aperture Export dialog as Aperture shows the dialog itself (resulting in a brief flash of it before you close it from the plug-in code). Not a great user experience, so in the end I designed a slightly compromised layout for the export view which includes the key service functionality. The standalone upload application is launched after you click Export, and is effectively only used to perform and display the uploads in a more user-friendly manner. The app also has a minimised mode which places a (moveable) progress indicator in your menubar, that can also be seen in Aperture's full screen mode.

I think this works pretty well, and for the client gives them the opportunity to hook plug-ins for other applications into the same standalone upload engine providing a consistent interface to their service. Arguably a consistent UI in the origin application is more important, but sometimes it is appropriate to sacrifice some of this, in this case gaining better usability with a UI that is more aligned with the service.

Our next project is a similar standalone engine but whose workflow is the reverse, it's intended to take media from one specific application (without a plug-in API) and transfer it to disparate services. This is in fact PictureSync's workflow, but without some of the application and destination specific functionality that this solution requires. Furthermore PictureSync's goal is far greater than its current implementation, with the intention being far more bidirectional than these one-way solutions. After this we're back onto PictureSync and implementing some of these goals.

Untitled

Wed, 27 Dec 2006 05:39:00 GMT

This blog has been down for a short while due to an unusually intense attack by HTTP referrer spammers that resulted in many hundreds of thousands of hits. Normally this wouldn't be a problem for a server, but I actually have code to track referrers incorporated into my blog CMS, and it has some experimental routines to try and filter out referrer spam which basically took the whole server down due to the load.