15 posts tagged “flickr”

When Adobe first launched Photoshop Express (from hereon in, PX) a month and a half or so ago, it featured integration with three online sites: Facebook, Photobucket, and Picasa. Unfortunately, I don't use any of those for photos. So when I saw that there was an update to add Flickr support, I dug out my old registration - the one that required me to claim I was living in the US, sigh - and had a very quick look.

Construction (Original)

Flickr appears under the "Other Sites" heading on the left nav - or is it a palette? - of the main window. Clicking the "Flickr" item asks you to authenticate, although somewhat oddly it uses desktop-style auth, so instead of using a nice redirect, PX instead uses a pop up window, which was naturally blocked. It also means you manually have to click about three more buttons than you would with web based auth. Perhaps this is explained by the amount of client-side code, but it still jarred for me. I expect users who don't have to wrangle API auth code would probably cope, though.

Once logged in, Px starts fetching images from Flickr. This is done pretty nicely- pulling each image is slow, so it will carry on if you're not doing anything else, and present the images it's already found for you. Images are sorted by date taken, which is odd if you're used to Flickr's photostream order, which is by date uploaded. (Dates are, naturally, in American format, which annoys me no end, but let's try and ignore that for now.) However, for me it stopped after just over 550 images, which is only about a tenth of the total. I'm not sure why, or how to get it to look for the rest.

Once the images are listed in the Flickr album, they're editable just like any other image available to PX. The tools aren't as sophisticated as those in the main desktop version of Photoshop, Photoshop Elements, or even iPhoto: there's no "levels" tool, and minimal highlight and shadow controls, for example. However, the white balance editor is pretty good, and there's a "Pop Color" effect for those images where you want a red London bus in a monochrome city. Beyond desktop apps, I'd also say that it compares fairly shabbily to Picnik, which is also web-based, but manages a much richer set of tools. Handily, Picnik's integrated into Flickr, making it even more likely to be used.

Construction (Edited)

After editing my image, I wondered where the "save" dialog was, and where I'd get to choose whether the original image was replaced, or who'd get permissions on the new image. It turns out that this is all done automatically. An edited image gets uploaded as a new photo, with your default permissions. The title and description are preserved, but tags and date metadata aren't. To me, this is a killer flaw. Firstly, I want the option to replace an existing image. Secondly, throwing away image metadata is something Photoshop hasn't done since about version 7; it's appalling that PX does this today. Thirdly, I want the option to set privacy levels.

Once again, Picnik's Flickr integration gets all of these things right - in fact, it even seems to have an option to bump images up your photostream with comments intact, which is a very clever trick indeed. In contrast, PX looks like it's hardly trying.

One place that Photoshop Express does try very hard - for publicity - is with images that are copied from its library to Flickr. You can explicitly copy an image into the internal library, create an "album" on Flickr (what's more usually called a set, there), and then copy it back to Flickr in that set. Doing this creates a description that lets everyone know you're using Photoshop Express, and, hey, would you like to use it too? I know everyone is after viral exposure these days, but please let me know you're doing it first and let me set something more sensible.

On the subject of albums, PX loads your Flickr sets as a list of albums, although for some reason this didn't happen the first time I tried it. They're listed in alphabetical order, which, like the "date taken" ordering, is a little odd - Flickr preserves set ordering, and it would be nice if PX would honour that, at least as an option. Opening an album, unfortunately, shows an empty screen, even if there are images in the set. I assume the photo download process is linear. Hopefully a later release will change this, and let the UI take priority, as well as adding caching - each time you open the web app, it has to fetch the list of photos and sets from Flickr afresh.

For all this criticism, I do recognise that Adobe's product is just a beta. On the other hand, given how slick Picnik is, and how nicely it's integrated, it's hard to see how Photoshop Express has much to offer Flickr users, other than a brand name.

As hoped, after my previous post detailing my failure to rotate a video for display on Flickr, I've had a useful hint which has since led to me successfully uploading a couple of videos.

Gareth pointed me at a page detailing how to use mencoder, part of mplayer, to rotate the video (along with a bunch of other steps at the end assuming you want your video to stay landscape in the end; I don't.) At first I had no luck getting it to work, but a download of the source and compile (which was error, if not warning, free on this Intel Mac) left me with a working command-line application. Starting with Scott Hansleman's invocation, I ended up using

./mencoder -vf rotate=1 -o output.mov -oac copy -fafmttag 1 \
           -ovc lavc -lavcopts vcodec=mjpeg input.mov

to convert the file from the Ixus to one that Flickr would accept. The important bit is the "-vf" tag, which gives a list of video filters to apply; -oac and -ovc are for the output audio and video codes respectively, and I'm using mjpeg as it's the same as the input. (Using "copy" didn't work, probably because it was using the frames without rotating them).

Ideally there'd be a nice front end for this, but most of the mencoder GUI wrappers I've seen for Mac OS X were abandoned long ago. For now, using the command line is fine for me, and if you're trying to do the same, hopefully it'll work for you too.

I posted nice and early about Flickr and the API, without even posting a video of my own, and with no inkling of the protests that were about to bounce around Flickr's forums. Eventually I pulled a couple of videos from my old photo site (I'm particularly fond of this one, since you really need the movement to see what the point is), and posted them, while I looked for more videos that I'd shot with my old Ixus, generally five years ago now.

This morning, there were two more videos I wanted to post. However, both were in portrait not landscape orientation, and so far I've not found a way of posting them to Flickr the right way up, despite trying a few things. So, here's what doesn't work, before I ask the crowd what will.

Firstly, and most simply, I tried using QuickTime Pro to rotate, using the Movie Properties window as discussed at The Unofficial Apple Weblog, amongst many others. Unfortunately, while this looks as if it works, it's actually just a metadata flag, and Flickr discards it on upload. This fate also befell a "hinted movie" export.

This started me on a search for a suitable Export format. I tried AVI with Cinepak, but that looks truly awful, and I wasn't prepared to even try uploading it. AVI + DV-PAL looked as if it worked, but on upload Flickr converted it to a 4:3 aspect ratio, rather than 3:4, which is obviously no good. The same problem affected various MPEG-4 exports, including the presets for the iPhone and so on that QuickTime offers. I had a look at the 3GPP formats, but these have a maximum size of 320 pixels, while my originals are 640x480. That's no good.

Thinking that maybe I was in the wrong application, I turned instead to iMovie. However, it turns out that it won't even think about producing a movie unless it's in landscape format*. I suppose I can see why: if it's a video for TV, or that would eventually be shown on one, then it'll have to be that way around for it to work. On the other hand, this is the exciting new digital era! Who knows what sort of device your video will end up on? The best I could manage here was to mark the video as rotated, and then crop the middle out to return it to 4:3. Sigh.

After this exploration, though, I can see why post-upload rotation is still on Flickr's to do list for video support (along with replacing videos) - although if it was there, it'd be the solution to my problem right there. Anyway, that's basically the end of the road so far. I keep seeing Windows MovieMaker mentioned as a way to rotate video, but I don't (yet) have Windows installed here, and I'd really rather not for something that I'd thought was trivial. Can anyone else suggest a way of doing this with a Mac software package? In the meantime, you can't see my shiny carousel. Sorry.

Updated: Thanks to Gareth, here's a command line solution.

* iPhoto 7 has a similar problem with cropping images to a 16x9 aspect ratio. For 3x2 and 4x3, you can choose either landscape or portrait; for 16x9, you can only use landscape. My workaround is to rotate, crop, then rotate back, but that's stupid. More sigh.

Overnight Flickr launched their video support, which I'm sure you can read about everywhere else. I'd like to note (as much for myself as anything) how to handle videos in the API.

As with the main site, videos are treated just as funny photos. As kellan explained on the Flickr API group, the API does just the same thing. There's a new "extras" parameter, "media", which returns either "photo" or "video". What isn't fully explained on the thread is how to display a video as a video, rather than as a static thumbnail (the way Flickr themselves do on, for example, pool pages).

The answer is to use the embedding code shown with each video. (You'll need to be logged in to see that page.) Seasoned API users will note that the photo ID and secret are in the code that Flickr gives you, so it looks like it'll be easy to check the media attribute for a photo, and either show just the image, or use the Flash code (with the appropriate substitiutions) to show a playable version. Unfortunately, if you can't figure out the aspect ratio of the image (typically by using the o_dims extra argument to methods like flickr.photos.search - and yes, it works for videos), you'll need to do an extra call (to flickr.photos.getSizes) to get those arguments for the <object> tag. (This is a problem for images, too, but I'd be happier leaving height and width tags out of an <img> than an <object> tag.)

In summary, then, supporting videos on Flickr through the API looks as if it should be straightforward, and in fact even if you do nothing then it'll work (albeit with videos treated as images). Nicely done.

I've been thinking a lot about aggregation (and lifestreaming) recently. Actually, that's not quite right; I've been thinking about it for a while, but the launch of friendfeed and another look at jaiku¹ brought it to the forefront again. (This post also overlaps somewhat with my Feeding the Daemons post over at my other blog, but I hope it's set out a bit more clearly.)

So, what do these services do? I'll try and make a couple of definitions that might be useful, even if only within the context of this post. Firstly, there's horizontal aggregation. This is at the level of a single service, but it spans users. Most of the entries in my Safari bookmark bar - pages I can get to with a single key combo - are like this: my friend's twitters, photos from my contacts, my del.icio.us network, and friends pages here and on LiveJournal. This means that I'm usually seeing the same sort of object (very short text, photos, links, and posts respectively). Lots of sites offer this (Tumblr's dashboard is another example).

Secondly, there's vertical aggregation. This spans services, but only takes in a single individual. My home page is an example of this, although it's not exhaustive. The best example I've seen is Les Orchard's accumulator, because it lets you control how much or how little you see, and it makes it very clear what's being collected. There are plenty of other examples; one of the first I saw was Jeremy Keith's stream.

Vertical aggregation is actually quite popular, and you can turn a bunch of services over to it; for a while that's what I used tumblr for. In the end, though, I decided I wanted a bit more control, and did it myself. More often, people don't have the infrastructure to collect everything together nicely, which is where services like LoudTwitter (which collects your tweets for the day to your blog) and Twitter Updater (which posts to Twitter announcing blog posts) come in. Unfortunately, they're a bit hit and miss; it's possible to configure circular posting, and I've seen people use tools to post their twitters to more than one of their blogs, which seems a bit much².

So, what's new with Friendfeed and Jaiku? Well, they're a combination of horizontal and vertical aggregators: they pull in updates from lots of people and lots of sites. The obvious problem is that, if you're dealing with purely horizontal or purely vertical aggregation, you'll never see the same item twice. If you start mixing them, though, duplication can become a real problem.

What's the solution? Well, I'm not sure, but it seems that filtering is going to be pretty important; not just the crude level of cutting out feeds, but individual items. In fact, full-blown email-type filtering ("if subject contains 'tweets for today' then hide") might well become important.

In fact, I wonder if the failure to tackle this is part of the problem with Facebook that the alpha geek crowd seems to have. They're the people who will import their web activity into the site, and so will their friends, meaning they're bombarded with not just the usual zombie/film/quiz noise, but also every twitter, photo and blog post. It's no surprise that many run from the information overload. Will real people suffer from this? Perhaps in time, but for the moment I suspect most Facebook users are getting about the right balance between no activity (so why use it?) and overload.

In conclusion, then. If you run a web site with a social component, please offer the tools to allow users see their friends activity easily on the site, and also to include their own data in their own aggregators. (To be honest, almost everyone does this already.) If you're running a service that allows users to pull in data and share it with friends, filtering is a must.

¹ Jaiku's odd, as it combines Twitter's status updates with aggregation, and that makes it much harder to explain to people. If it had concentrated on one or the other it might have found Twitter's market first.
² Movable Type 4's activity streams show that Six Apart know it's a problem that needs addressing. Oddly, Vox has enough information to build one, but it's not used.

• Flickr's API is pretty cool. Ruby's Flickr libraries are bitrotten.
• Scripting Bridge and language support in 10.5 is pretty cool too.
• Unfortunately, it's not entirely bug free, and the bugs are baffling.
• Some applications have rubbish scripting definitions.
• Tom Insam is full of useful hints for programming.

I think that'll do for one weekend.

A year or so ago, whilst writing groupr (RIP), I came up with what I thought was a useful name for something I found myself doing a lot: the API join. I'm fairly sure this is common to a lot of Web (2.0) APIs, but it's especially common with Flickr. For example, take groupr. First, it would do a call to get the groups you're a member of. For each of these, it then fetched the photos in the group. Obviously, this has a problem: as the number of groups you're a member of goes up, so does the number of calls to the API - and each call takes about a tenth of a second. The only way to mitigate this, and the solution groupr used, was to page the groups - and even that leaves you making as many calls as you have groups on the page.

The problem reared its head again when I was looking at doing a ffffound-inspired Flickr favourites app. I wanted to display the usual Flickr size, rather than square thumbnails (as Flickr's own favourites page does). Unfortunately, the standard call to get favourites didn't list the size of the photos, and I really didn't want to spend two seconds fetching them all. Other people have raised similar questions on the Flickr API group discussions; for example, here's one about getInfo and getExif, and here's another about getting photo sizes.

Imagine my surprise, then, when I looked at the documentation for flickr.photos.search and noticed a new argument to the "extras" parameter: o_dims. It turns out this returns the original height and width, and is also available in the favorites methods, so now it's possible to avoid doing those calls, and to embed derived height and width for web-scale images from a single call, even for the 36 or so images on Flickr's version of the page.

Of course, this is simply because the API has now moved the join deeper; instead of being at the API level it's being done inside Flickr (presumably at the database level). In fact, I suspect that last weekend's database downtime may not be unrelated (perhaps it was needed for the launch of Apple TV's Flickr slideshows?). It also doesn't help with the other methods, such as getExif (there's a reason I've moved some of my EXIF data to machine tags, which are fetchable with another extras parameter to many calls).

Facebook, interestingly, allows a SQL-like query language as part of their API access, but I wonder how they deal with queries that could bring the database to its knees. I do notice the line

In order to make your query indexable, the WHERE should contain an = or IN clause for one of the columns marked with a *.

Is that an enforced criteria, or is it merely a recommendation, and do they return long-running queries without results to keep up database performance? It's the sort of thing I'd love to see Flickr add to their API, but I can imagine the problems are far from trivial, and in the meantime, I'm very happy to see one API join bite the dust.

For the last week or so, I've been using a site called ffffound a great deal. In its own words,

FFFFOUND! is a web service that not only allows the users to post and share their favorite images found on the web, but also dynamically recommends each user's tastes and interests for an inspirational image-bookmarking experience!!

There's a great writeup by Michal Migurski which, if you've not seen it, you should read. He covers the bookmarklet, the lack of tags. It's interesting that its tight invite policy - although it's gone up from one to three per user - has kept the site's quality high, despite the growth of the site. (A mention from Kottke and wide linking to an animated gif of Paris Hilton don't seem to have caused problems.)

There are a couple of things mentioned in that post I'd like to reiterate. Firstly, the automatic creation of the fan/follower network (based on who posted images first, I believe) is lovely. Compared to its two obvious reference points, Flickr and del.icio.us, this really feels like magic, and it seems to largely work. (Migurski himself noted that your network is no longer invisible, but it is still autogenerated.) Secondly, the site has a really nice string of image connections; it's very easy to surf. I still run a narrow browser, so I almost missed the three thumbnails to the right of every main image; beyond that, when you click through to an image's page, there's usually a good half dozen candidates for further exploration.

A feature that wasn't mentioned (maybe it came along later?) is the use of vi keys for paging. Usually the standard paging in a browser works fine, but for a screen of images, you'll usually end up with an image stranded half in the viewport, half out. ffffound allows you to use 'j' to bounce between anchor tags for each image, fixing it toward the top of the page and allowing you to see it in full. There are also keys to scroll upwards, and to go back and forth between pages. It's really easy to scan. Another nice touch - this one only noticable once you've joined - is the distinction between "posted" and "found" images. The former are those you've added with the bookmarklet, whereas the latter include those you saw on the site. Both have RSS feeds, too, which is nice.

There are very few issues I have with the site. I suppose an API would be nice, but to be honest for what I want to do - possibly include my found images on my site - the RSS is perfectly sufficient. However, I do worry that a single big list of found images will make it hard for me to get images I like back out of ffffound when I want them. An API would fix this, if it exposed the date and title metadata already on the image. I've also had trouble with the bookmarklet on Safari 3 on Windows, but that browser is so crashy I'm reluctant to blame ffffound for it.

Browsing, and then using, ffffound also prompted me to think about Flickr's favourites. Unsurprisingly, a lot of images are from Flickr, but there's no real integration at either end. Personally, I'm making a bit of a distinction; if it's on Flickr and obviously a photo (as opposed to artwork), I'm still adding it as a favourite there; otherwise, it'll be on ffffound. Most other ffffound users don't seem as picky, though. I wonder what the "API users are stealing my images" crowd will do when they find out?

Anyway, I'm very happy to be on ffffound, which has some great touches, and hope that some of its lessons can be taken over to Flickr.

Things you should be able to do with Flickr favourites 1, but can't:

There have been a couple of posts since Apple's press event on Tuesday, which saw the launch of the new .Mac Galleries - an online, read-only version of iPhoto, kind of - that state that "Apple doesn't get the web". Jeremy Keith says

in the fast-moving, messy world of online services I don’t think the genius-led design of Apple can compete with the truckloads of nimble young upstarts making snazzily addictive products on the Web

and Chris Heathcote writes

Whenever Apple strays towards software and the web recently, there’s a lot of flashy interfaces, and little substance.

I think there's a slight qualification to be made here. I think Apple are great at web publishing. Their site is one of the best product sites I've seen (despite the fact I dislike the new bigger-than-800-pixel width). I've been going on about the elegance of URLs - it's possible to guess that there's something at apple.com/keyboard, for example - since 2001 or something, and even when they drop in AJAX their pages still have usable permanent links.

When designing for consumers, Apple takes the same approach. They produce tools for publishing, using a one-to-many, one-direction mode of thinking. As James Duncan Davidson notes as he writes about the .Mac galleries, "It’s not Flickr, and comparing it to Flickr is probably pointless." Well, no. Flickr is the archetypal Web 2.0 application, being almost as much about community as about photographs themselves. The .Mac gallery, on the other hand, is all about putting your work online. There's no comments, no notes, no tags, but the people who it's aimed at don't want that. They're about publishing, not interaction, and while they pages are undoubtedly heavy, and probably scale badly, they're also slick enough that a lot of people will like them.

Similarly, iWeb-generated blogs have no comments, but well-designed templates (from which it's hard to stray.)* Again, it's designed for publishing. The problem for Apple is that it's not 1999 any more. People expect more from their sites now, and thankfully more and more of the sites I use are applications, not brochureware. So perhaps the statement needs to be refined, because despite the JavaScript libraries and slick visuals, Apple doesn't get Web 2.0.

* One point where iWeb fails is that it doesn't preserve Apple's nice URLs; the ones it generates are distinctly ugly. At least, they were in the first version.