Tech stuff, API and programming

I've got a beta-quality publish service for 23 and Adobe Lightroom working and almost ready to go. I can post the URL with the details here if anyone is interested.

I've been using it for a few weeks now, and it seems a solid, though wider testing of the account setup and authentication stuff is probably needed.

It supports the notion of public and private photos. It has almost complete Album support through the service instances, and fully supports comments, replacing images (without losing metadata) and will preserve tags (but not apply them to your catalogued images) added via 23.

Basically, if there is actual interest in this right now, this might goad me into actually finishing up the packaging (and maybe fixing the admittedly rough debugging interface that is still needed.)

I would love to have such a feature for Lightroom!!!
Pity is I dont have any knowledge of programming, so i can`t be of any help :(

Thank you for your work, please let me know when and where we can download the plugin.

BUG: well, if you have to republish a large number of photos, you will get a nasty uncaught exception from the Lightroom SDK. You can keep hitting publish after it complains it couldn't publish some number of photos until they are all published.

I think an internal struct is blowing out. I need to dig into this more.

[Later]

Yup, I had a race condition on an async call.

New version:

http://clevermonkey.org/Lightroom/23-Photo-Sharing-Plugin/

That is great, I was thinking how to organise my stuff as I would not be able to reupload all my images because I am no PLUS-Member.

Thanks for your great work!

Should we include an MD5 hash in the API lists? Would be pretty simple to do for us -- and would save you quite a bit of work?

@fj-07, unfortunately, being able to show previously uploaded images in the publish collection is beyond the current plugin, and is not /really/ supported by the Lightroom SDK.

I am thinking about how to solve this at my end.

Actually, the remote ID /is/ provided by the remote service, but the real problem here is not getting a remote ID, but associating it with a local photo ID in the catalogue.

There just isn't an easy way to indicate to Lr that "this image on 23 with URL xyz and remote ID 0xDEADBEEF is actually a published rendition of that Lightroom Photo over there." And what do we do about photos no longer in the catalogue? Or that were actually never touched by Lightroom in the first place (i.e., some of the photos were from other sources, which is pretty common)?

I'm going to back-burner this rather advanced feature and reconsider how it could be done, but I'm leaning toward waiting for Adobe to make the SDK more mature.

For example, all we would need is a right-click context to let us hook into a "associate this rendition with this photo" gesture. And right now, we don't have that.

[EDIT]

Well, I'm hoping that if Friedl figured this out for SmugMug, I can figure it out for 23. There is still the risk that we might end up associating the wrong Lightroom photo with a published rendition on 23. This could end up "replacing" a photo on 23 with the wrong rendition because it thinks it is the same photo.

For reference, I'm hoping to steal much of the functionality from http://regex.info/blog/lightroom-goodies/smugmug/publish for this plugin.

It will likely be a plugin extras menu that will use the filename or the capture time to pair images up.

This will be a huge feature to add, though. Realistically, I'm hoping Lr 4 adds some SDK sauce that makes this, and other stuff, much easier.

@Steffen, what would the MD5 hash stored with images be generated from? I'm trying to think of a way to generate it such that it would be really easy to match up photos in the catalogue to those published on 23.

Right now all I can think of is to use the filename (assuming the name wasn't changed on export/publish, which means we can't use it) or the capture time (which, given how fast burst shots can be, might not have enough granularity to be certain.

But if we can come up with a MD5 hash based on some of the other EXIF/XMP data (camera serial number?) then we can really be sure of finding a good match. Unless that EXIF data is missing, in which case I'd like to fall back to one or more other techniques. (Which implies that if the hash can't be created properly we shouldn't trust it; maybe I could just do a metadata lookup on select metadata myself, until I'm satisfied we have a match.)

Ideally, we want something that is extremely fast to retrieve as well. Crawling an entire account to collect this information will be slow, and I assume would really hammer 23 servers, too. I'd want to batch up these calls since the POST requests would be expensive. I'm not sure at this point what the exact API calls I'd be making in order to do this.

Perhaps once I'm ready to add this huge feature I can just email you directly and we can sort this out.

Hmmm. This implies I've have to calculate the MD5 on the rendition on my end, and save that as private metadata.

It is relatively easy to construct and MD5 hash from a string via the Lr SDK, but calling out to access the binary rendition data (or last X kb) might be tricky. I'd probably have to hang onto the rendition after it has been uploaded and then delete the local copy myself. Not ideal.

It would be nice to have a dependable signature, though. Let me think about this.

BTW, if there is a need to localize this plugin to your specific language, please let me know.