I’ve been using the Vignette app for photography on Android ever since Dawn recommended it to me. It allows me to tap to shoot (avoiding the balky Droid X camera button) and offers a bunch of shooting options.
It also offers dozens of filters for creative photo-making, any of which can be applied either at the time of taking a shot, or later, to any photo in the Droid’s gallery. In fact, there are so many filters that I have trouble keeping track of all of them, and developers neilandtheresa (who, by the way, have an utterly charming blog and web site that seems not to discuss their super application at all) continue to add more with each update to the app.
So I cheated and made myself a handy reference for the current set of built-in effects. It’s a little unwieldy to use on the droid itself, but not too bad — and it’s a big help for thinking about post-processing of photos that I’ve already shot. It includes examples of the vignette, coloring, camera and film effects styles and more. I hope it’s helpful to you. Click through for the full-size sheet at flickr.

Keep in mind that the effects can be layered on top of one another via the customizations menu, allowing the stacking of any number of treatments. This sheet doesn’t show any of those combinations.
One hint for working with Vignette: Set a favorite preset with all effects, frames and customizations to Normal/None; then you can quickly toggle from fancy-pants artistic to straight normal settings.
For the sake of completeness, here’s a list of all the effects currently in the application (note that not all simple color variations are included in the example sheet).
COMPLETE EFFECTS LIST as of Aug 21 2010
1. Normal - Generic film effect
2. Vignette
3. Portra
4. Velvia
5. Ilford
TOY
6. Toy Camera
7. Toy Camera BW
8. Leaky
9. Cross-Process
VINTAGE
10. Faded
11. SX-70
12. Summer - hazy grns and browns
13. Colourised - flat pastels
14. Oversaturated - bright washed out reds & yellows
15. Yearbook - faded B&W
16. Sepia
17. Platinotype - bright smooth tones & deep shadows
18. Retro Red - faded color variation
19. Retro Yellow
20. Retro Green
21. Retry Cyan
22. Retro Blue
23. Retro Magenta
COLOUR HIGHLIGHT
24. London - contrasty b&w and red
25. Paris - contrasty B&W and blue-green
26. New York - contrasty black & white and yellow
COLOUR SWAP
27. Red/blue
28. Red/green
29. Blue/green
30. Rotate Hue
TINTED MONOCHROME
31. Sepia - same
32. Platinotype - same
33. Bleach bypass
34. Night vision- grainy and green
35. Duotone red, yellow, green, cyan, blue, magenta
LENS EFFECTS
36. Dreamy - soft-focus
37. Tilt-shift - portrait and landscape modes
38. Tobacco filter - deep orange tint for dramatic skies
39. Grad tobacco - portrait and landscape
40. Grad ND - portrait and landscape
41. Red, yellow, green, cyan, blue and magenta simple filters
CINEMATIC
42. Action movie - vivid reds w/blue-green tint
43. Technicolor - red and cyan 1930s look
44. Scary movie - tri-tone blue and magenta
MISC
45. Posterise
46. Blackboard
47. Infrared
48. Rainbow
49. Negative
50. Invert
FRAMES
51. Bordered
52. Rounded
53. Oval
FRAMES - INSTANT
54. Instant classic
variants: Wide, mini & square
FRAMES - GRUNGY
55. Instant transfer 1
variants: 2 (smaller border) and 3 (yellow/magenta border)
56. Filed carrier
FRAMES - FILM
57. 35mm
58. 35mm full bleed
59. 6x6
60. 6x6 full bleed
- ()
- This article is dated Saturday August 21, 2010 and is posted to technology, photography
, with tags android
apps
droid
droidography
droid x
photography
tools
vignette
Now that I have a photogenic, tiny gurgling creature in the house, I’m shooting a lot of photos, both on the Droid X and the Pentax. Most of these photos end up, one way or another, in Lightroom for cataloguing, and as I’ve described earlier, I have a nice workflow for updating these rapidly-growing galleries on my iPad.
But how about the Droid X? It has a nice screen, and I want to foist photos of my beautiful boy on anyone I happen across — so I started to wonder if, continuing to use Lightroom as my core platform, I could keep a small gallery of photos on the Android phone with as little manual work as possible.
Here’s the executive summary: I again use a smart published collection in Lightroom to create the gallery; then I use a LaunchAgent in OS X to monitor the mount point of the Droid X on the filesystem; and a tiny shell script syncs the published gallery to the Droid whenever I plug it into the MacBook Pro. Read on for altogether too many details.
First, a couple of things to note about how the Droid X generates image galleries [ note that this may apply to all Android devices; I have no idea, and your mileage may vary ]:
- Android automatically displays galleries based on image type — so you don’t need to update a database or anything to build your galleries on the phone. You just need folder(s) full of images.
- When you run the Gallery app, it will display galleries with the name of the parent folder containing the images. This means you can make a folder tree on the Droid’s SD card and neatly package multiple gallery folders within it, without cluttering up your root directory.
Prepare the SD card
When I attach my Droid X via USB to the MacBook Pro, it automatically mounts it as a volume titled NO NAME, so I used the Finder to change the label to DROIDX. This, happily, seems not to have affected any of the phone’s operations; the Droid must not depend on the name of the SD card for any of its internal work.
The second preparation step is to create a master gallery directory on the SD card. This is just for housekeeping purposes; everything in the galleries will be in a subdirectory of that top-level directory. Again, I simply did this with the finder: navigate to the DROIDX drive when the phone is connected, and create a new top-level directory, Galleries.
Your SD card and Droid should now be ready to go.
Set up the Gallery/Galleries
Just like last time, I’m using smart publish collections, based on keywords, to populate the galleries that will be synced. I decided to prefix all the keywords for this usage with dx — so, dx-gallery is my main tag, and I’ve edited it in LR to not be included in export. It’s a housekeeping tag only.
I’ve tagged a bunch of images with the dx-gallery tag.
Then it’s off to build the publish service. Here’s what it looks like in the publishing manager:

And add to that service a Published Smart Set that looks like this:

You can assign multiple keywords to the Smart Set, or create as many smart sets as you want galleries, and use unique keywords to assign photos to each. Each smart set within the published collection will appear in your directory tree as a subdirectory of the top-level folder for the set — and that makes the syncing to the Droid easy.
Automate syncing via LaunchAgent
Everything I know about LaunchAgent I learned from this tutorial. This is basically a concise repeating of that description, edited for our purposes. (I’ve previously described using this process to perform system backups)
First, if it’s not already there, mkdir ~/Library/LaunchAgents. This is the folder that OS X will watch for scripts triggered by system events such as mounting an external drive, which is exactly what plugging in the Droid does.
In that directory, make a new plist file (I called mine droid-sync-watch.plist) and give paste this into it:
<?xml version=“1.0“ encoding=“UTF-8“?>
<!DOCTYPE plist PUBLIC “-//Apple Computer//DTD PLIST 1.0//EN” \
“http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<dict>
<key>Label</key>
<string>droid-sync</string>
<key>LowPriorityIO</key>
<true/>
<key>Program</key>
<string>/Users/alan/Library/Scripts/droid-sync</string>
<key>ProgramArguments</key>
<array>
<string>droid-sync</string>
</array>
<key>WatchPaths</key>
<array>
<string>/Volumes</string>
</array>
</dict>
</plist>>
In short, this plist file tells the OS to run the identified script (~Library/Scripts/droid-sync) when the specified WatchPath changes.
The sync script itself lives in ~Library/Scrips and consists of a check against the desired volume (here’s where naming the Droid SD card comes in) and an rsync of the designated published collection to the previously-generated target directory on the SD card.
echo -n "[*]-- new /Volumes... sleeping" | logger
sleep 20
if [ ! -e "/Volumes/DROIDX" ]; then
echo -n "[*]-- DROIDX NOT connected - Exiting" | logger
exit 0
else
echo -n "[*]-- DROIDX Connected - Performing gallery sync" | logger
fi
rsync --delete -r ~/Pictures/Exported\ Photos/Droid/ /Volumes/DROIDX/Galleries
echo -n "[*]-- DROIDX gallery sync complete" | logger
Finally, tell the LaunchAgent controller to watch your scripts by doing the following at a terminal:
- launchctl load ~/Library/LaunchAgents
- launchctl list | grep sync
You should see your droid-sync script appear in the list produced by the second command, above.
Now you’re ready!
Plug in and go
That really should do it. When you connect the Droid X, you can watch the messages in the sync script appear in your console log, and everything should work — after syncing, disconnect the device again and fire up the gallery application; in the “Folders” section of the gallery you should see an item for each gallery you create in Lightroom. You’re done!
As with the iPad workflow, the great part of this is that once it’s set up, it’s pretty automatic. If you edit, add, or remove photos, as long as you republish the collection, those changes will all be pushed over to the Droid. Thanks to a little nerdery and Lightroom, we’ve built a bit of functionality that the Droid software doesn’t directly offer — and it’s still done with LR as the core of the photo library.
- ()
- This article is dated Saturday August 14, 2010 and is posted to technology, photography
, with tags droid
droid x
lightroom
lightroom 3
os x
photography
sync
tools
tutorials
This little draft has been sitting unfinished becuase, well, life happened, so I thought I’d just throw it on up to get it out of the bin. These are somewhat organized thoughts about getting a Not-iPhone
So I posted this bit of a rant a couple of weeks ago about how Android just didn’t float my boat and etc. Well, not long after that I finally decided to stop waiting on a Verizon iPhone, and I ordered myself a Droid X.
Yes, the one described by David Pogue as like talking into a frozen waffle.
So how is it? Well, it is large, but it doesn’t feel like talking into a toaster pastry. I actually like the finish and feel a lot. The volume rocker is a little small, and the hard camera button is sloppy feeling. But the rubberized feel to the back of the phone is nice to hold, the ridge for the camera is a good contour, and the device overall feels quite thin.
Now that I’ve had some time to get used to the four hard buttons (menu, home, back and search), I’m pretty efficient at using the Droid X. I quite like the way the back button in some contexts returns to the prior application — for example, after visiting a link clicked in the twitter client, the back button returns you from the browser back to twitter. Search is application context-sensitive, and at the home screens it searches applications, contacts, and google. It also remembers prior searches, so it’s a handy way to launch applications or make calls, too.
However, the menu button can cause some complication, because applications don’t always use it consistently — worse, some create a soft button of their own that might or might not invoke a context menu. Here the iOS model definitely wins.
Keyboard: Text edit views often obscure UI elements, and small text boxes often are rendered as multiline text areas, taking up space rather unnecessarily. Fortunately, I have learned how to hide the keyboard after typing: since the Droid X keyboard doesn’t have a “hide” button like that on the iOS (and as I understand Android offers standard), swipe down from the top of the keyboard. That will re-hide it and give you back the rest of your UI. (That’s an undocumented Pro Tip, right there.)
Horizontal coverflow like display of bookmarks and images in gallery is awful. Really, it’s bad. Hold the phone vertically for a standard thumbnail-style view. (The same holds for the bookmarks view in the browser. In the faux coverflow style, bookmarks are entirely, entirely unusable.)
Lack of bookmarklets is regrettable. I hear there are workarounds that involve chanting and offerings to Shiva, so I’ve delayed exploring them.
Battery life: I have heard bad things about smart/app phones in general, including the Androids. It’s easy to imagine that Android’s true multitasking could be a big battery liability. This is where the fanboys go ZOMG APPLE SUXORS, but the presence or lack of multitasking hasn’t been an issue for me yet, in terms of functionality. I have observed that Android runs a lot of applications that i have not once, ever, run on my own — Amazon mp3 store and the car dock, for example — and this strikes me as a pretty inefficient thing to do.
So does it matter for battery? Who knows? After a handful of days I stopped using Advanced Task Killer every twenty minutes and just relaxed. While I reserve the right to revise and amend my statement, for now I’m very happy with my Droid X’s battery life: I routinely finish the day with 50 percent of battery life left on the meter after a day of pretty heavy use.
Apps I like (The range of Android applications seems … adequate if not impressive. The Android market badly needs some kind of curation.):
- My Tracks: nice tracker app for biking in the hills. Integrates well with google maps.
- Twitter app: Clean, works well, nothing extraneous.
- Vignette: Much better than the built-in camera app, with a bunch of creative filters. I’m taking more pictures with the Droid X than in the past several weeks with my DSLR. Really good photo application a la the Hipstamatic app for iOS.
- K-9 Email: This is a powerful email client with IMAP support. On the Droid X, there are lots of problem reports about the stock client not correctly refreshing, and while I am loath to solve a defect with an app, K-9 syncs properly and offers a bundle more features than the stock client.
It’s a good device with very nice hardware and some software feature that I really like — and some hitches.
More later?
- ()
- This article is dated Sunday August 8, 2010 and is posted to technology, with tags android
droid x
iphone
We have a little boy. I am amazed.
- ( [1])
- This article is dated Sunday August 8, 2010 and is posted to
Marco Arment sums up my bemusement with the Android platform, and, by extension, why my frustration that that AT&T’s network is so awful where I live:
The current must-have Android phone changes every few months, and they’re often radically different from each other, making it difficult for consumers, developers, the press, and the carriers to build loyalty toward any of them or entrench them in the market. The OS needs to be updated over the air with three involved parties, only one of whom is motivated to update it. Features are added when they can be, not when (or if) they should be, or if they can be done well. Nearly every usability detail appears to be an afterthought, as if “design” is relegated to a coat of paint at the end of the development cycle rather than a deep-rooted philosophy throughout it.
The driving theme of the iPhone, as evident in every “There’s an app for that” ad, is “use this to do stuff.” Meanwhile, as near as I can tell, the driving motif of the Droids — with all the menacing Terminator-style chrome and unblinking red eyes — is that they’ll kill you if you aren’t careful. The tech-heavy “Droid Does” slogan reminds me of the days when Sega, hoping that more advanced specs would win the video game wars, tried out “Sega does what Nintendon’t.” And that turns out to have worked great for them, right?
The Verizon signal where I live is great, and I get a work discount, too. I simply can’t justify ditching that right now for AT&T’s extraordinarily mediocre signal, no matter how much I prefer the user experience of the iPhone. While there is precious little that actually draws me to Android, it’s a less dead end option than any other option that’s not an iPhone.
- ()
- This article is dated Sunday July 18, 2010 and is posted to technology, with tags android
ipad
verizon
Eat me.
(Anybody notice the clever use of user profiles to insert otherwise benign-looking referrers into the referrer spam, lately?)
- ()
- This article is dated Thursday July 15, 2010 and is posted to , with tags douchebags
spam
Smitten Kitchen’s Porch Swing post got me thinking about the cucumber cocktail we made a lot last summer.

Mmmmmm.
- ()
- This article is dated Tuesday July 6, 2010 and is posted to , with tags cocktails
cucumber
drinks
gin
recipes
What’s in the bin this week?
- your.flowingdata — a personal data aggregator in the same vein as daytum and mycrocosm. Flowing Data is a great site, so this tool has lots of promise. Update activities via Twitter dms.
- Summertime in Flagstaff is just great. (The Schultz fire is now fully contained and crews are working on flood/mudslide prevention.)

- I’m still loving the iPad. My Lightroom 3 to iPad gallery workflow has proved to work pretty well for my needs. I’m eagerly awaiting the release of PlainText and have started to daydream about an app or web utility that would facilitate writing markdown, textile, and other markup-formatted text.
- Shouldn’t people writing fake term papers for sale just expect that they’re going to get ripped off by douchebags?
- ()
- This article is dated Monday July 5, 2010 and is posted to , with tags flagstaff
ipad
lightroom
links
news
- ()
- This article is dated Tuesday June 29, 2010 and is posted to technology, with tags portal 2
portalportalportal
steam
valve
Brayden asked below about my experience so far with the iPad. Can it replace a PC for most uses? Put most simply, yup. I’m using mine for about 90 percent of the everyday time that I would normally spend on the MacBook Pro. In fact, it’s probably easier to write up the things that I’m not routinely doing on the iPad, these days:
- Lightroom: I do have a nice workflow for publishing photos to the iPad from Lightroom, but for now at least, that application itself still lives on the MBP. And Lightroom 3, by the way, has a host of improvements that I recommend.
And that’s about it. Now that I’ve had some time to get used to the keyboard, i can write pretty quickly with the iPad; autocorrect doesn’t always seem to catch things I think it should (like the lowercase “I” in the prior sentence), so i think about the Bluetooth keyboard once in a while, but I haven’t really needed more than the software keyboard. If i want to write a lot, of course, I can hop onto the laptop and TextMate away. (I drafted this article using simpletext.ws on iPad.)
The iPad so portable and easy that I do a lot of sitting on the patio with it. It undersells it significantly to call it a reading device, but it’s so very good for propping in my lap with a coffee or a beer and diving into instapaper or the Kindle app. It’s just a thoroughly enjoyable experience.
Shortly after the iPad launch, some reviewer noted how it just gets out of the way and just becomes the application you’re using or the web site you’re visiting. That’s really a great way to put it, and it’s largely true. With a well done app, the iPad mostly disappears.
Here’s a short list of the good apps I’m spending time with (in addition to Safari and Mail):
- Instapaper Pro
- Kindle
- 1password Pro
- Twitterific
- Tab Toolkit
- Netflix
- Reeder
I’m still looking for a case for the thing (the DODO Case is mighty tempting), just for a bit more protection, though I’m not eager to cover it up, either. [Other recommendations, anybody?] And I don’t love the crop of text editors I’ve tried, so far, hence using simpletext.ws for this post; the upcoming PlainText app sure looks good, though. But I have no true complaints. This is a super little device and I’m really having a great time with it. Don’t let anybody tell you it’s just a big iPod Touch.
- ( [1])
- This article is dated Saturday June 19, 2010 and is posted to technology, with tags apple
ipad
review
(Or, an efficient way to use Lightroom to manage photos on your iPad)
I got myself an iPad a few weeks ago. Short review: It’s a big iPhone only in the sense that an iPhone is just a phone; that is, it’s hawt and I love it. (More ZOMG iPad articles to follow, I’m sure.)
The iPad really shows off photos, so I’ve been thinking about the best way to manage the photos that I want to put on it. With the non-beta release of Lightroom 3 this week, I think I’ve found a start at a workflow in the new publishing service that it offers.
First a note about syncing photos to the iPad. Like the iPod/iPhone, you have to select a single parent directory, and optionally subdirectories, of photos that you want to sync. The iPad stores photos in a series of albums simply named after the subdirectory where they live on your hard drive. In my case, I keep the photos that I publish out of Lightroom in one of a number of subfolders of a ~/Pictures/Exported Photos directory, but I don’t necessary want to sync all of them to the iPad. And, for the iPad, I wanted a little more control over the album naming for purposes of navigation — so I didn’t want to keep the directory names I’ve previously used for simple file management.
So: I have an “iPad” directory in my exports folder, and that’s what I sync to the iPad — along with all its subdirectories. I’ve copied a handful of existing albums into that directory, which isn’t a great solution but it does work for now. Apple has apparently decided that symbolic links cannot be synced [that would be a great capability, wouldn’t it?], so I can’t simply create links to the file locations of the existing, non-Lightroom albums that I want to sync.

But the Lightroom albums are another story. Right now, I’ve simply created a couple of Hard Drive publish services, each of which publishes to a subdirectory of that “iPad” folder I described above. For example, the current flickr one simply sets up a set of export parameters for photos that will be published to a subdir.

But the slick part comes by making a smart collection that will publish everything I post to flickr in 2010. Simply build the smart collection within the publish service:

And then set it to include all photos that match some key criteria: Since I use Jeffery Friedl’s flickr plugin, I can call directly on the metadata it creates at export:

I now have a smart collection within a publish service, so the photos that I export that match that criteria will automatically be added. I’ll have to occasionally republish to the service itself; and each time I do so, the iPad will gather up those photos the next time I sync.
You can use the same methodology to set up hard drive publish services for any album you like; each service will appear on the iPad as an album, and if you create a smart collection (or a series of them) as part of the service, then they’ll be updated automatically as you perform you regular photo workflow.
One final note on why I think the publish service is an ideal tool for this workflow, rather than a solution such as simply exporting to a folder: The publish service will apply future changes to the service settings to all photos under its control. So, were I to decide to apply a watermark, a border (via, for example, LR/Mogrify 2), or adjust photo quality in order to save space on the iPad, those changes made to the publish service would result in the option to re-process the current photos:

In a sense, then, the photos produced via the publish service are truly synced — future changes will be managed and will trigger re-processing, if I choose. I think that’s pretty Good Stuff.
Pics or it didn’t happen
It’s May again (I know, I don’t know how that happened either, except that it followed April, and don’t get me started on April). Among other things, May is home to the “IronMan in May” competition at my place of work. The goal is to complete a sum of distances equivalent to an IronMan triathlon in the span of 31 days: 26 miles running, 2.4 miles swimming, and 112 miles biking. It’s a fun challenge and makes for a nice opportunity to mix up my workout routine, especially since I’m really, really not much of a runner.
And of course it means data to keep track of! There’s a paper chart on the wall at work, but who would want to use that when there’s such a glut of data visualization tools making the rounds now? Two years ago I used Joe Gregorio’s sparklines tool to plot my progress as I went:

Well it’s 2010 now (don’t get me started on 2009; that’s when I dislocated my shoulder — again — and then got nasty tendinitis to boot, so I didn’t take on IronMay last year), and this year I’m using Processing to plot my month’s data. Like R is really a programming language oriented to data-oriented programming, Processing is a language oriented around visualization (unlike R, however, which makes it easy to access vectors and data frames, Processing requires one to go back to array manipulation, so it took me some getting used to). Now, having seen the spectacular stuff in the Processing gallery I just hope that I’m not insulting the poor software by using it to make bar graphs (that look an awful lot like the old sparklines! I figured I had to start somewhere as I learned something brand new-to-me). This quick Processing tutorial is a great place to start.

Update May 31 2010: It’s a gorgeous day in Flagstaff and I knocked out the last of my run and bike miles on the urban trail this morning. Iron June, anybody?
Update shortly after the prior update: I wasn’t content with just the bar plot, so I tinkered just enough with streamgraph.js to come up with this (click through for the full-sized version at flickr):

Pretty rad, I think.
- ()
- This article is dated Sunday May 2, 2010 and is posted to technology, with tags data
exercise
ironman
may
processing
sparklines
visualization
About, the short version
I’m a sociologist-errant. This site is powered by Textpattern, Joyent and the sociological imagination. For more about me and this site, see the long version.
Copyright and so forth: Commenters own their own posts, and linked or excerpted material is subject to whatever copyright covers the original. Everything else here is mine, rights reserved.
RSS feed