I want to export images from Lightroom to my hard drive using the publishing service. Therefore, I want Lightroom to continuously number the images even if I add images by publishing new pictures from the same smart folder.
At the moment I have the following problem: I have for example 4 images in my smart folder and exporting them using the publishing service. The images appear as: IMG_01.jpg, IMG_02.jpg, IMG_03.jpg and IMG_04.jpg on my hard drive. But if I add some pictures after a while and export the new pictures using the publishing service again they appear as: IMG_01-(01).jpg, IMG_02-(02).jpg,.... BUT I want them to continue the row and be named as IMG_05.jpg and IMG_06.jpg.
What kind of settings do I have to you use for this? At the moment I am using "rename" to "Text"_Sequence(00001) in the settings. I am working with Lightroom classic 10.1 on a Mac.
Thx for helpful advises 🙂
Copy link to clipboard
I'm typing this on my iPad so I can't verify this, but I do not think this is possible with Lightroom's renaming options. Sequences only work for a single series of images, the counter is reset when you publish a second series. There is also another way of adding numbers, but in that case the counter does not increment between series, so you'll get the same problem.
Copy link to clipboard
Part of the problem might be that when new images are added to the publish service, Lightroom Classic is probably thinking of them as their own export job that doesn’t change images already exported. It’s only sequence-renaming the new ones. For all of them to be renamed, all of the images would have to be in the same export job.
For example (I haven’t tried this): What happens if you select all existing images in the Publish Service, right-click any of them, and choose Mark to Republish to reset their status and add them to the unpublished ones, then click Publish? Does that replace everything in the folder with one correctly numbered sequence, or does it leave incorrectly renumbered files?
I believe that if you select "Image#" rather than "Sequence#" in the file renaming template editor, that will continuously increment the number it uses rather than beginning again for each batch.
However I can't really see any benefit to applying numbering at this stage. One of the benefits of Publish, is that it can detect when a given image has been further edited since the last time published. and replace the first external file with a suitably updated version, intelligently. A numbering sequence within the Publish setup will sabotage that since the newly made filename and the previously made one, are pretty much guaranteed not to match.
In any case the sequencing of images within a Publish set will not be meaningful or consistent once repeated Publish of the changing source set has happened. There will be gaps for removed images, and either conflicts of different images getting the same numbering / the same image getting different numbering on different occasions - depending on which numbering method you choose.
IMO it is better to use some other naming method for the Publish, which naturally associates back to its source image within the Catalog. If someone says they liked your published image number 17 but want some changes, how are you going to later work out whihc image they mean? Given your LrC Publish Collection may now have different membership than it did before.
Best IMO to use a method which will repeatably assign the same filename to the same image, if that is output more than once. If you truly need to include an ever-increasing index number, maybe Import is the place to do that. Then whenever the same image gets re-output, its naming will naturally repeat the same, and the external version will overwrite properly.
My own recommendation is simple: I don't rename anything at import. I can't see any benefit in sequence numbering: the images' metadata and camera filenames are enough for all purposes I can envisage. For export or for Publish purposes, I prefix the original camera file name with the capture date in standard ISO format - YYYY-MM-DD. Those two combine as a unique reference (even if the in-camera counter were to circle back to zero again) that is positively informative. And this method chronologically sorts the image files by default - regardless of the, accidental, order in which they were imported to LR - or, in which they have been later output / re-output.
"I believe that if you select "Image#" rather than "Sequence#" in the file renaming template editor, that will continuously increment the number it uses rather than beginning again for each batch."
That was the second option I mentioned, but unfortunately that won't work either. When you setup this renaming method, you will have to fill in the starting number of 'Image#'. During a batch export Lightroom will then start with this number and increment it. But when you publish a second batch, Lightroom will start again with this number rather than keep incrementing from where the previous batch ended.
When used at import, I believe "Image#" continues on from the last number used within a previous batch, does it not?
If some unique "image serial number" is desired for each photo, IMO that best happens by renaming at import. One could e.g. achieve repeatable uniqueness for virtual copies, by including their Copy Name after the source-file name, when exporting. Given that derived copies such as PS edits will also possess a unique file-name with (by default) a "-edit" suffix - though this suffix can be changed by the user, and/or overridden during the first Save.
My other comments questioned if sequence numbering even made practical sense as part of Publish - though it may well do for the Export of a one-off set.
No, that's the point. Each batch 'Image#' starts again at the number you initially filled in.
Thanks a lot for the answers. It seems like my ideal way of exporting pictures continuously using the publishing service of lightroom is not possible. That´s a great pity but in this case, I do not see the advantage of the publishing service. I thought it would be to export images and add only new images or updated images after a while to the export. But if lightroom do not have the possibility to keep order of the exported images in the end this whole service does not make sense for me. What is the benefit of this service? I don´t get it. 😞
It makes a lot of sense (and stays organised) if you do not rename the images...
Export can be repeated, but at heart this is more about a one-off set made for a particular purpose at a certain moment. In that context, it may make a lot of sense to number the images - even to making them "1 of 8", "2 of 8" etc - since there are (say) 8 images known to constitute this batch, of which this image is the first, and that one is the second.
Publish is more about maintaining a live external, fluctuating set of image versions, to correspond with a live internal, fluctuating set of images within the Catalog. This internal set will vary when you delete an image; when you add or remove image's membership in a Publish Collection; or when the inclusion rules of a Smart Publish Collection automatically throw up a different set of complying images today, than was the case yesterday, becasue the images present within the Catalog AND their attributes are constantly in flux..
So if you number them during their output, your Published external set might eventually include "1 of 8", "1 of 8 (2)", "1 of 9", "2 of 12", "2 of 8", "3 of 12", "3 of 12 (2)", "3 of 9" etc... complete chaos IOW. With no easy way to tell what's repeated vs what's unique; what has been maybe re-published under different naming than before; what has failed to get removed when it should have been, etc.
This does not happen if repeatable naming is used, which operates consistently whenever you update the Publish. LR can then match up what copies now need to be added new, what copies now need to be overwritten with an update, and what copies now need to be deleted from the Publish target location.
Furthermore, the fact that an image appeared as "number 3" within a given output batch last week (whether Export or Publish) , does not trace back to - and is not remembered by - the corresponding thumbnail in the Catalog, this week.
Okay that would work if I only work with images from one camera, but how would you proceed if you have images from several different cameras (all named differently) and you want the exported pictures to be sorted by the capture time? If I do not rename the images they will be sorted by the different images names from the different cameras. E.g. first all DSC...images second all IMG_....images and so on.
The easiest option would be to rename by capture time on import. That is what I do. Another option would be to rename on publish, but use the capture time all the way up to the second, so YYYYMMDDHHMMSS. If you shoot bursts, then add a sequence number as well. That will just affect the order of images shot in the same second.
I also like the option of prefixing capture date and time, but one argument for only including this at export, only applied to the output, is that sometimes we may want to edit capture date in LrC. Not only if the camera clock was set wrong or to address timezone issues, but also in the case of scanned / re-photographed prints or film, we may want to alter the capture date after import, perhaps to show original exposure date, rather than the date of scanning / re-photographing. It would be extra work to then also rename affected files to exactly correspond. But if images are only being renamed at export to include their date, that issue does not arise. While inside LrC each image knows its own (currently set) capture date from metadata, also a date-related folder filing system can help. Capture date (once corrected as necessary) is thereafter a permanent constant for a photo, regardless of what else may happen with it organisationally. So that meets the 'repeatability' requirement and thus should work fine, on the fly, with either Publish or Export.
When I need to change the capture date, I simply rename the images in Lightroom using the same template after I have done so.