Lightroom: Cannot "Mark as up-to-date" new photos.

  • 1
  • Problem
  • Updated 6 years ago
  • (Edited)
Even though this feature is available for modified photos, it is missing from new photos.

Here is a scenario that calls for this requirement:

- A photographer uses the same publish service both on a desktop and a laptop.
- While on the go, he shoots new pictures, imports them into a catalog on his laptop and publishes his picks.
- When he returns back to his base, he exports the new pictures from the laptop as a (mini) catalog, then imports them to his working catalog on the desktop.
- The pictures that have been already published from his laptop are "new" to the desktop catalog and have to be published again (!!)

This is happening to me for both my website (hard drive publish service over Macfusion/SSH) and Facebook. When I publish from my laptop, I have no option than publishing the same "new" pictures from my desktop again after I return ...and then manually delete one copy from my web server and FB account.

I use LR for workflow and I love it. Though this bug completely breaks my publishing workflow.
Photo of auhopu

auhopu

  • 4 Posts
  • 0 Reply Likes
  • frustrated

Posted 6 years ago

  • 1
Photo of jdv

jdv, Champion

  • 728 Posts
  • 56 Reply Likes
So, you are importing image renditions exported from catalogue A into catalogue B as new image file references, and then re-creating renditions to a similar (but not identical -- it cannot be) publish service?

Unfortunately, the publish status is stored in the catalogue, so there is no way to tell B that the photo is part of one or more publish service collections on A. Furthermore, there is no way to connect a remote reference of a published rendition to a local file reference in a catalogue unless a rendition of that local reference has been created.

That is, there is no way to "connect" two or more publish service collections on multiple different instances of Lr. The key here is that they are collections, and collections are catalogue specific entities.

So, yes, it is expected that those photos are "new". Because they are. There is no easy or error-free way for another instance of Lightroom to know that they are the same. Perhaps if the service offered a "sync" option you could find a way to hook up published remote renditions with local photo references. But this is a very tricky thing to get right.

It sounds like you want something like Revel, which has the notion of state across devices. Or (maybe) use a single catalogue that you sync between running instances of Lightroom. As long as you are publishing the exact same collection to the exact same publish service (not one just with the same name, but actually the same definition in the same catalogue) those renditions will not be seen as new, but changed.
Photo of auhopu

auhopu

  • 4 Posts
  • 0 Reply Likes
Hi John,

What you are saying totally makes sense. I understand that it is hard to sync two independent catalogs between two different instances of LR in terms of publish services.

It makes sense why the photos previously published from catalog A are new and unpublished on catalog B.

What I am asking for is a workaround to overcome this situation: just give catalog B (or any catalog for that matter) the opportunity to remove photos from the "New Photos to Publish" list via a "Mark as Published" context menu, the same way that "Mark as Up-To-Date" removes modified photos from the "Modified Photos to Re-Publish" list.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 384 Reply Likes
Unmark for republish requires no special programming.
Mark as published requires publish-service specific programming.
See more of my answer below.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 384 Reply Likes
Most publish service authors have encountered this same problem.

Most 3rd party publish service plugins support marking new photos as published.

All of mine do, although unfortunately not all of mine are released yet ;-}

Some people think they're being smart using Adobe publish services instead of 3rd party versions - maybe worth re-thinking that...

Consider Jeffrey Friedl's Facebook plugin.
Standby for more advice regarding hard-disk/FTP'ing publish plugins...

This problem could also be solved using SQLiteroom, but that's a subject for another time, another place...

Cheers,
Rob
Photo of auhopu

auhopu

  • 4 Posts
  • 0 Reply Likes
I wonder if another way to overcome this is to:

- copy the whole catalog from desktop to laptop
- import new photos on the laptop
- publish new photos on the laptop
- copy the whole catalog from laptop to desktop
- copy the new photos only to the desktop
- open the catalog on the desktop and "find missing folder"

If the publish service - lightroom relationship lives inside the catalog, this should work. I will give it a try.

The idea for a different, small catalog on the laptop was to accomodate the new photos instead of having to carry potentially thousands of photos with you.

Maybe it would be okay working on the same catalog without having to drag the actual old photos on the laptop... and just ignore the "?" icons for them in the library.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 384 Reply Likes
Yes, this will work.

Having publish service info omitted from catalog export / import seems to be a "glaring omission".

Cheers,
Rob
Photo of auhopu

auhopu

  • 4 Posts
  • 0 Reply Likes
Yep, it worked.

"?"s for the old photos on the laptop (did not bother to copy them). Catalog and new photos copied to deskop, missing folder found... and the new photos that were published from the laptop are still considered published on the desktop.

Thanks, Rob and John!

It is true though. If publish info is a catalog property why can't it be imported along with it? I wonder if this happens with history/snapshots/virtual copies.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 384 Reply Likes
Snapshots and virtual copies come along for the ride for sure, and history too if I remember correctly. Publish services had some issues so Adobe punted. Dan Tull of Adobe said so (paraphrased by me).