Underexposed

Eugene Berman's plug-in lets Lightroom users export photos directly to iStockphoto.

(Credit: Eugene Berman)

Photographer and programmer Eugene Berman has released version 1.0 of a Lightroom plug-in that enables photographers to export pictures directly to iStockphoto, a "microstock" Web site that sells images for relatively low cost.

Adobe Systems' Lightroom is gaining in popularity as a way to edit and catalog the unprocessed "raw" images from higher-end digital cameras, and Adobe in 2007 released a beta version of a software developer kit (SDK) that lets anyone write plug-ins for exporting photos.

Other Lightroom plug-ins also exist that permit uploads to Flickr, Picasa, Zenfolio, and SmugMug.

Exporting to iStockphoto is a different matter, though. Photographers might be more inclined to take their shots on a trip through Photoshop for more careful noise reduction, edge sharpening, or selective editing not possible in Lightroom.

The plug-in provides the ability to enter keywords, upload multiple photos, and include model releases, Berman said.

However, Lightroom expert Sean McCormack rightly gripes that it would be improved if it exported the photo's title from the metadata title field rather than the filename, which is more likely to be something obscure such as DSC7893.jpg.

(Via Lightroom News.)

• Picasa Web Albums Uploader for BlackBerry--Upload to Picasa Web Albums from a BlackBerry smartphone. Bonus: automatic geotagging if your BlackBerry supports it.
• Jeffrey Friedl offers "Piglets": Plug-ins for Lightroom Plug-ins--This time, Friedl has built Tim Armes' LR/Mogrify export plug-in so it can be used as a subcomponent of Friedl's Flickr/Zenfolio/SmugMug/Picasa export plug-in. First time I've seen the word "fourth-party" used in a while. World's longest dialog box too.
• ImageReporter: Extract data from Lightroom database--Analysis tool for extracting information from the metadata stored in Lightroom's catalog. It's a free download.
• 5,000 Flickr photos lost to a phishing scam--This fellow lost his Flickr identity to a phishing scam that meant all his photos, comments, and online conversations were deleted. "How does one download all the metadata? Flickr should have an export feature that creates a .flk file on your PC." I don't think it's as clear as that.
• BreezeBrowser Pro supports 1Ds Mark III, D3, D300, E-3, A700--Raw files from the latest SLRs are now supported. That includes Canon's 1Ds Mark III, Nikon's D3 and D300, Olympus' E-3, and Sony's Alpha A700.
• CoastalOpt 60mm UV-VIS-IR 1:4 Apo Macro lens--Transmits ultraviolet and near-infrared light with no chromatic aberration. "The 60mm UV-VIS-IR 1:4 Apo Macro lens achieves unprecedented correction...by combining fluorite and quartz with elements made from carefully selected high-transmission glasses."
• State of the Art: Marilyn Wars:The Empire Strikes Back--Who's allowed to sell images of Marilyn Monroe? Copyright vs. rights of publicity.
• Thomas Hawk: Copyright Schmopyright--Provocative words from a compulsive (and good, in my opinion) photographer. "Fair use? Who the hell cares. The images need to be captured. And they need to be presented to the world in new and exciting and fun ways."
• Paleo-Future: Bearded Men of the 21st Century (1939)--Dang, and here I just shaved my beard off. I guess I just am too cowed by authority and missed the revolt.
• Rusty Russell gripes about git--A Linux kernel programmer ascends the learning curve of Git, the source code management system Linus Torvalds wrote to manage the kernel programming project.
• Call for community testers for Intel driver--Intel wants outside help testing its open-source graphics drivers. The "Intel team is not able to cover all hardware configurations, hence not able to reproduce or verify some bugs." Sign up at Intellinuxgraphics.org
• Havoc Pennington leaving Red Hat--A longtime coder is departing, but he's not saying yet what his new gig is.
• Intel 965 chipset blacklisted in Ubuntu 8.4 Hardy Heron--Programmers couldn't get good 3D support out of the new Intel graphics chipset.
• Ohloh Goes Open Source--An open-source command line tool to identify the language a program is written in and count how many lines it's made of. It's under the General Public License version 2 (GPLv2).

Adobe Photoshop Lightroom is taking its first look at the world beyond its own photo-editing boundaries, and stock-art photographers are among those who stand to benefit.

A view of the Flickr export tool in the Lightroom developer kit.

(Credit: Adobe)

Adobe's software development kit for its Lightroom software, released Thursday evening along with the Lightroom 1.3 update, is only a preview edition with limited abilities, but already one potential use for the software is evident: easier photo uploads to "microstock" photo-sale sites.

The SDK preview involves only image export from Lightroom, but it includes several features for interacting with Web or FTP sites on the Internet.

Uploading photos can be a big hassle for photographers who sell their work via the gaggle of microstock sites such as Dreamstime, iStockphoto, and Fotolia that have cropped up on the Internet. Some microstock photographers shoot exclusively for one site or another, lured by higher payments, while others sell photos at multiple sites. Either way, exporting directly from Lightroom could ease export difficulties.

Of course, it might not be the thing for everyone, including those who want to do further processing for noise reduction and sharpening in Photoshop, for example. But it's a step in the right direction.

Likely to be of nearer-term use is a sample plug-in distributed with the kit that permits uploading photos to Yahoo's Flickr photo-sharing site. It lets users set a variety of options, including privacy and tags, but doesn't let users deal with Flickr sets used for grouping photos together.

"I'd love to say that we support full-on synchronizing with Flickr sets...but that's not really possible in (Lightroom) 1.3," Lightroom engineer Eric Scouten said on Adobe's Lightroom forum. "I'm a Flickr user myself. I understand the desire and hope to see it happen in a future release."

Those who want to get started writing plug-ins should bone up on the Lua programming language that Adobe selected for plug-ins. And they should refrain from ambitions to reproduce the rich world of Photoshop plug-ins: Adobe expects at least for now to confine plug-ins to "workflow" tasks such as exporting rather than image-editing tasks.

Update: I found a couple extra tidbits on the Lightroom 1.3 update beyond the SDK from Tom Hogarty, the Adobe executive in charge of the software. For one thing, he still recommends against using the Time Machine feature in Apple's Mac OS X 10.5 Leopard operating system with Lightroom. For another, he said there are other reasons to upgrade besides the SDK, new camera support, and some Leopard compatibility fixes. "In addition to fixing the auto-write XMP performance issue there are several other architectural changes under the hood that should make your experience with Lightroom smoother," Hogarty said on his blog.

Google's Android software gives Sun Microsystems' Java technology a starring role--but not the version of Java the rest of the mobile phone industry has been developing since the 1990s.

Instead, Google struck off on its own in an attempt to improve performance and openness for the software used in the Open Handset Alliance phones. That means programmers will have a new variety of Java to reckon with--offset somewhat by Google's $10 million code contest to draw developers in.

One difference is Google's development of its own core Java virtual machine (JVM) technology called Dalvik, the software that actually executes Java programs on an Android phone, which Google says means Java programs run fast even on the constrained hardware of mobile phones. But a more significant departure than just using an in-house JVM is the fact that Android isn't part of the Java Community Process that Sun established in 1999 to oversee the development of new Java features.

The JCP governs Java by codifying new features as application programming interfaces (APIs), so programmers can have a standard way of calling upon new technology such as Bluetooth support or 3D graphics. But that existing Java realm wouldn't accommodate the developer freedoms Google thought were important in Android.

"We wanted the platform to be open in a lot of different ways," said Mike Cleron, a Google senior staff engineer working on Android. "The idea is that anybody can come along and replace the pieces of the Android experience on a very fine-grained level. The existing APIs didn't really allow the level of openness we were hoping to achieve in Android."

It should be noted that Google isn't working in a Java vacuum. For example, one of the OHA partners, Motorola, has helped lead development of Java for mobile devices, and Google wants to keep the Java programming experience familiar to developers. And Google is an executive committee member of the JCP, though only for the Standard and Enterprise editions that run on PCs and servers, not the mobile edition for phones and other devices.

"We have people on the team who are active in the Java community. They've been helpful in informing us and guiding us, making sure what we were doing is familiar to folks in the Java community," said Steve Horowitz, Android's engineering director.

Further fragmented?
But the bigger issue is whether Google's effort will worsen the already fractured world of Java. Not all phones support all the same Java standards, so programmers can't be sure that their software will run on a multiplicity of devices, as the "write once, run anywhere" Java tagline promises.

"They are using Java, but they aren't implementing any well-known Java framework, and really that just creates another standard to support. The risk they take here is that they might fragment the market further," Benoit Schillings, Trolltech chief technology officer, told my comrade Maggie Reardon. Trolltech, which sells tools and components for programmers whose software runs either on PCs or on mobile phones.

Mauro Lollo, CEO of mobile phone video-streaming company Movidity, saw Google's work similarly. "In essence, they've created another standard. Standards are great, but the challenge is that there are so many of them," he said.

Google also faces a common risk of open-source software, that the openness will mean programmers can "fork" projects in different, incompatible directions. (Indeed, this was one of the earlier reasons Sun resisted its eventual decision to make Java open-source software.) "In the end, you could have 20 different versions of the Android technology that are incompatible, because anyone can take the license, modify it, and create another variation," Schillings said.

For its part, Sun supports Java and open-source software on mobile devices, but expessed some caution about joining Google's alliance. "We were interested in being part of the Google ecosystem, but we were interested in getting more clarity on what this program entails," said Rich Green, executive vice president of Sun's software effort.

Asked if there's any possibility of unifying the Android work with the Java Community Process, Horowitz said, "It's an open alliance. We can welcome anybody who wants to join."

Android uptake
Techno-politics aside, Google clearly has grand aspirations for Android. And it wants outsiders to be part of the development.

In stark contrast to Apple, which plans to release a software developer for its iPhone in February, half a year after the product began shipping, Google is releasing its SDK about a year before any Android phones ship.

"We're making it available pretty early--early enough that we can get feedback at a point where we can still impact the direction of the software," Horowitz said. "People tend not to ship SDKs until the products are done. In this case we thought the platform was such an important part that we wanted to get that out early."

Of course, there's another advantage to releasing an SDK early: the open-source community can help build interesting applications that give Android phones more than just the basic set of programs.

So far, so good, said Horowitz, pointing to "unprecedented" interest in Android compared to other projects hosted at Google's open-source projects site, code.google.com. "It is above and beyond anything Google has seen to date," Horowitz said.

A diagram of the inner workings of Google's Android software for mobile phones.

(Credit: Google)

Among details in the SDK:

• It makes mention of support for GSM mobile phone networks, the leading technology for mobile phone networks, but is silent on support for the top rival, Qualcomm's CDMA. That will come, though, Horowitz said, pointing to CDMA allies such as Qualcomm that are members of OHA. "It's clearly something on the roadmap, but we're not talking about specific support for it at this time," he said.

• OHA supports touch-screen technology, but Horowitz declined to comment on support for multitouch, a notable iPhone ability that opens up user-interface possibilities, beyond saying multitouch support isn't in the first version of the Android SDK.

• Google will release a new version of the Android SDK once feedback from programmers starts coming in. "We're committed to a regular release cycle," Horowitz said.

• Software should run quickly on mid-range phone hardware such as those with a 200MHz ARM 9 processor. "One of the key goals of the project was to ensure we can run on a broad range of phones that don't require a high-end processor at all," Horowitz said. "When we bring it to higher-performance devices, it's just going to scream."

• The SDK so far permits development only of software that runs on the Java foundation, not natively on the hardware itself. "We are aware of the interest in native application development, but we having nothing to comment on right now," Horowitz said. But performance shouldn't be an issue: "Our system is designed to take full advantage of native code in performance-critical areas and expose this functionality through our framework APIs."

Marguerite Reardon and Dawn Kawamoto contributed to this report.

Correction: An earlier version of this blog misstated Google's connection to the JCP. Google is a member of the Java Community Process, though not for the Java Mobile Edition version to which the Android software is most closely related.