Perhaps we must interpret this as: all the photos currently VISIBLE in the filmstrip (horizontal scrolling of that aside). And images may not be visible because they have been filtered out of view according to their attributes or because they have been collapsed out of view according to their stacking. The Filmstrip states (e.g.) 4 of 8 photos, because those 4 are the only ones presented.   In terms of physical analogy: if you pile several pieces of paper together, you can then write only on the visible top sheet - and whatever you do there, does not also write the same thing onto the other sheets below. You'd need to spread those sheets out side by side, to make them all writeable-on. Similarly, sheets that you have temporarily concealed inside a file folder (filtered out) are thereby temporarily not part of what is visible. ... View more

OK, thanks, that helps. Your starting import needs to NOT be a "Move" type, if you want that beginning TIFF to stay where it is.   If you don't want to create an additional copy of this TIFF during import, then that needs to NOT be a "Copy" either.   What's left is an "Add", which simply leaves your TIFF alone. From this latest info I strongly doubt that Export had anything to do with your TIFF moving its own location. That was the Import almost certainly.   If you want your export of the JPG to go to your Desktop and not into a 2024 folder then you need to click Choose and direct your export to the Desktop itself, as a specific destination. I posted a screenshot recently showing yellow highlighted destination info, and a red arrow pointing to the Choose button whereby you can change that.   ... View more

Regardless of what kinds of keywords may have been possible to create, the syntax used when searching for images by keyword makes, and always has made, it unwise IMO to include spaces in keywords.   Thus, for example, "John_Waterson" can be treated as one exclusive searchable item / searched on inclusively by its parts (looking for all keywords that include the characters 'John' for example) - depending on whether you set the Filter bar to search by Keywords "contains" or "contains words". That control is not available if the keyword is in the form "John Waterson". Because then a search on "John Waterson" will either way find not only "John Waterson" but also "John Adams" and "Linda Waterson" and "Waterson Falls" and only (for example) "Ted Johnson" could be excluded, by setting the search to "contains words" instead of "contains".    I am not aware of any recent change of search behaviour or of practical implications, in these respects.   IOW: say a fragmented keyword is technically permitted by the software - is that going to be a good idea?   Incidentally, if one did decide to change (for example) keyword "John Waterson" to "John_Waterson", that can be done by simply editing each keyword that has already been assigned. Immediately the searching results will react accordingly.   As a bonus, if you use a dividing character scheme rather than just running the first and last names together, this lets you search on (say) "_Waterson" and have this report everyone with that same surname, without picking up images tagged with "Waterson Falls" and suchlike too. I might suggest reserving a particular dividing character just for people tagging; and have a different strategy with other kinds of keywording. ... View more

Any subfolder name given will only apply if the box next to that is checked. This will happen, or not happen, inside whatever is the chosen Export To: "specific folder".   To change that "specific folder" destination click the Choose button.     ... View more

To get the issue of not-as-expected EXPORT out of the way, it would be helpful to see a screenshot of the entire Export screen.   So far as IMPORT: the whole circumstance of this is a little confusing (as below), but first some explanations about the interface which may help. You will only see a "Destination" panel like this when you are doing a Move import or a Copy import. The other type of import is Add, and in that case there are no destination options since this merely takes a file that is not imported to the Catalog, and imports it without doing anything else. These are choices at the very top of the Import screen. If you are moving or copying, and you have chosen to Organize "By Date" as shown in the screenshot, that is what explains the creation of a 2024 folder and it is also what explains the imported files moving or copying away from wherever they were created.   But more basically: if you are exporting a TIFF then this TIFF would normally not then appear inside the Catalog. There is no need for it to do so since the original photo with its edits - that you made this TIFF from - is still there to continue working on. It is possible to choose for an exported image version (a JPG, say) to be made but also to immediately be imported back to the Catalog, by selecting a checkbox in the export settings. But I can see no convincing reason to do so, and lots of convincing reasons to not do so. It's different when extenally editing an image since in that case the aim is to supplement the original image with another new original (showing the results of editing done in e.g. Photoshop). This image and the LrC edits get passed directly - you would not first export a TIFF and then separately open up this TIFF into your other editor (such as Photoshop).    To understand the wider workflow context might really help make sure that any advice will suit the case usefully. IOW, often the problem turns out to be a task issue - it's not always a technique issue. ... View more

Some people get caught out by the Export dialog's ability to make multiple forms of export simultaneously for a chosen batch of images. I am not sure if this explains your issue or not, but just to make sure you are aware.   In the Export screen there are settings in the main part of the dialog, and there are panels on the left where export presets show. If you click on a preset this "recalls" the settings that were recorded into that, and shows them in the main part of the dialog. So that is what your export will then consist of. However if you click the checkbox against a preset (or against more than one preset) then the export setup (or multiple setups) then gets carried out. For example, you might export a TIFF to a certain subfolder and also export a couple of different standard formats of JPG into their own different subfolders, by checking the relevant presets, and all of that will then happen with a single click of the Export button.   In other words: to avoid unwanted additional exports happening, make sure there are no checkmarks against any export presets listed down the left side of the export screen. ... View more

This naming "problem" is inherent to LrC printing. Outputting electronically is just a physical alternative, to having a machine spray ink onto paper. Often including multiple photos on a sheet; a picture package referring to just a single photo, is something of a special case.   If you wanted to (say) be able to identify to a printer what each photo was - you could separately output a 'contact sheet' showing all these photos. On that contact sheet turn on Photo Info so as to label each photo with its starting filename. Then you could issue instructions in terms of those filenames, the printer looks each photo up visually on the contact sheet and prints the respective sheet the requisite number of times. ... View more

If a newer Lightroom Classic version tells you that a Catalog needs to be upgraded (because if was made and worked on under an older software version) - this upgrade is done and then saved to disk as a new copy with a different name. By default, this name will show the LrC version number concerned, at the end.   The Catalog that is being upgraded FROM, still remains behind on disk as well. So if that older software is still present in the computer, it can be told to open that again just as before.   The source images and folders that this older Catalog references are the exact same ones that the upgraded Catalog as used by the newer software is also referencing. They are physically shared across both, in other words, and everything starts out looking the same in relation to those within both Catalogs: library organisation, edits etc.   Further work in either Catalog will now cause them to diverge. A Catalog that is compatible with a newer version cannot be back-converted so that an older version can open it, this works in one direction only.   If you want to go forward with the latest version (as that develops over time) under a subscription plan, then Lightroom 6 becomes redundant. At some point it may come that your hardware / operating system will no longer support it, or that some cybersecurity consideration makes using this no-longer-supported software inappropriate.   If the older software is being discontinued, its respective Catalog can be removed without damage to the newer Catalog. Of course, you would need to leave all the imported images and their folders just as they are.    Otherwise you should consider any usage of these two versions as 100% independent except that you would need to be careful not to delete any images from disk when removing from one Catalog, or reorganise anything on disk, since the other Catalog may be silently relying on those same images remaining where they were. YOu would get no warning : a bad situation IMO.  So I advise: accept the subscription - which is objectively good monetary value in my judgement - cease using Lr 6 altogether, and don't look back. You can then access the latest features constantly, and a product that is under active development. So any functional issues - and these do arise - are going to receive a new corrective update, which will never happen with Lr6. ... View more

Another question: are you continuously backing up this storage to elsewhere? If so, that might interfere. ... View more

Also check you are not viewing these images in the context of a Smart Collection, or in the context of a Collection Set.   Stacking can only operate when you are viewing by Folder, or viewing a particular Collection.   Furthermore: any stacking of images as they are seen in Folder view, will not be evident when the same images are viewed within a Collection - and vice versa. The same applies for any custom sorting (where images are manually dragged around into the order you prefer). ... View more

Assuming "existing XRC files" refers to XMP files; as written previously by LrC; still in the same folder as their respective image file; the image file is proprietary camera Raw not JPG or DNG; the base filename - everything but the file-type extension - of the XMP and the Raw files continues to match up - LrC will be looking out for any such XMP files and you don't need to do anything to have them automatically used at import.   So the edits and metadata found within that XMP file will set what is initially seen for that photo, once imported - and not the current processing defaults. This will include what Processing Version the image is to use, and what calibration Profile it is to employ, and so on - matters which may need some further attention after import. ... View more

Constrain to Image is not optional for the Develop crop - you cannot adjust a crop boundary beyond the original image extents in any case. You may be thinking of this as an optional setting controlling tools in the Transform panel - since as a result of perspective or geometric transformations of the image (especially scaling) the picture information extent seen becomes decoupled from the original image extents, such that extraneous areas may be artifically brought to show not only within the original image extents, but also within the current main crop boundary.   A checkbox is presented in Transform as to whether (when this happens) such white extraneous areas should be allowed to show, or should get further trimmed away on the fly.   I would expect this setting to be sync-able between images (its checked, or unchecked state) along with the other Transform panel adjustments. Separately from the main Develop crop, IOW. ... View more

As I recall there is just one customised set of default adjustments (it might be misleading to call this a 'preset') - and this is held in common for all sorts of mask. It is not remembered differently for each different kind. So (possibly by accident), this will have been 'recorded' recently while you were making a new mask with some other selection method. Say, a brush mask or a gradient or something.   Similarly, if you check the box to say "always reset" then every kind of new mask will show that behaviour hereafter. Remembering, a mask item may come to contain multiple kinds of selection - also, changing kinds of selection over time. There is no such thing as a "subject mask" per se, only a Mask which (currently) happens to use Subject as its sole form of selection. The default adjustments apply for the parent Mask entity, not for the subcomponents within that (such as Subject or Sky or Brush). ... View more

It is long-standing Lr(Classic) behaviour that you can customise what default adjustments are initially seen, whenever you add a new local adjustment mask (involving a selection of any kind).    The sequence is important here: add the new Mask entry, then move some sliders: you are only changing the adjustments belonging to this one brand new local adjustment.  OTOH first move some sliders and then add the new Mask entry: you have changed the default processing slider settings that ALL new local adjustments will begin with hereafter, including this one.   If you want all your brand new adjustments to always start out showing zeroed adjustments, you can prevent any such customised defaults from being put in place: there is an "always Reset" checkbox option in the masking panel. I don't recall the exact wording for this checkbox, but that's the idea.  ... View more

The practical reality is that an image of certain pixel dimensions - say, 6000px  x 4000px - is saved and sent to a printer with instructions that it should be output to a certain physical size. To deliver on those instructions, any PPI setting that is saved into the digital image will almost always need to be disreagarded. The result of printing that many pixels at that physical size, will be whatever resultant PPI it happens to work out to.   Where we take account of PPI as a "proxy" for printed detail / quality, is when we combine a certain number of original pixels with a certain physical scaling. In effect, are there enough of the former to meet our expectations for the latter. But we have to be considering a real-world resultant PPI, not whatever notional PPI may be written into the digital image, to conclude anything useful.   Similarly, we take account of PPI - called DPI, sometimes in this context - when scanning a negative: because the negative is of a known physical size, this number can act as a "quality proxy" for evaluating whether we will be capturing lots of pixels TOTAL, or only a few pixels TOTAL.  ... View more

Consider how we value banknotes. I pay a certain sum of cash into my bank in the form of $10 bills. Will I later double that value  if I withdraw the same money, in the form of $20 bills instead? No: because to achieve the same total value, the bank will have given me half as many bills. In isolation, the dollars per one bill (Pixels Per Inch) tells you nothing. Also in isolation, the number of bills tells you nothing (inches wide and high). Only when these two pieces of information are combined, is any particular total cash value being expressed.   And there are two ways to express a certain quantity: with a real complex scenario / a simple count.   Say - "five $20 bills in an envelope" / "10 inches wide @ 300ppi" is complex. If we want to compare against "three $50 bills in an envelope" / 54 inches wide @ 96ppi" we have some calculations to do, and that calculation must involve converting the various denominations and counts into a simple total dollar value / converting the particular printing scenario, into a simple number stating how many pixels there are in total.   So one might as well just define, discuss and compare cash - or digital images - on that simple basis in the first place.  ... View more

If you import a file that has previously had (* Adobe compatible) edits written to it, you do not need to do anything to have those edits presented as the starting appearance that you see in the Catalog.    * meaning, that it was either Adobe Camera Raw or some kind of Lightroom which did the writing   So far as exporting Original, this is a choice listed in the normal Export settings - instead of stating JPG, or DNG, or whatever specifically. The result is a JPG if the imported file was a camera JPG, a DNG if the imported file was a DNG, a proprietary Raw if that was what was imported.   The difference between this option and explicitly selecting one of those formats, is most apparent to see with a camera JPG. If you export choosing JPG specifically you will get a newly made JPG that's been processed according to your edits. If you export to Original instead, you get a simple duplicate of the unprocessed camera JPG which has remained the same so far as its picture content, as when first imported. Then attached to this you get the latest edits as metadata instruction. If that JPG was then imported (say, into someone else's Catalog or else opened in ACR) then these instructions are followed and an edited image is seen. But if you view this same JPG in a standard image viewer (say, Finder) you can still see whatever the camera first put there, without any LrC edits destructively applied. ... View more

Export can in effect create a direct copy, without any edits baked into its picture information, when the Image Format of the export is set to "original".   The result is a duplicate of the starting imported file plus latest edits written to the file in metadata. One point is that if you exported two virtual copies of the same image using "original", two actual files will be produced: a duplicate of the imported file twice, each one with that particular version's edits as the attached metadata.   The thinking behind this as e.g. a backup tactic is not something I personally can get behind, though. ... View more

i meant, as a proposed Idea, that a means of suspending the effect of the crop temporarily might be helpful more widely, not only in terms of the Remove Tool.   Currently each panel has an "eye" button which one can hold down to temporarily see a Develop preview without the application of the adjustments within that panel.   I was thinkiing, if Crop could be given a similar button - but one that acted as an on/off toggle - one could temporarily work on an uncropped image as desired, but without losing crop settings. ... View more

A more generally useful approach may be to temporarily suspend and then later re-enable a (meanwhile remembered) crop?   There are workarounds e.g. via syncing between virtual copies but - laborious. ... View more

As another option IIRC (can't check just now) after putting the keyboard focus onto the WB Temp, you can then shift that keyboard focus vertically between the various Basic panel adjustments, using the [dot] and [comma] keys - hope I have that right!   Alternatively the Quick Develop panel in Library might be something to consider, since this can apply the same relative Tint adjustment onto multiple highlighted photos even though their starting Tint values may differ. ... View more

First, AFAIK Content Credentials does not control whether or not camera EXIF etc are included - for that, one would look to the Metadata section of the export settings.    Second, are you saying that when certain EXIF has been  set to not be included, extracting the thumbnail from the exported file is still showing that EXIF nonetheless? If so, what file format are you exporting to? ... View more

just for completeness: another way that virtual copies may get created is when Softproofing is active, and then images are adjusted in any way. An image thumbnail that is itself not already a proofing copy, will in that case spin off as a brand new, separately editable  (virtual) proofing copy - referring back to the same shared source file. There's a notification pop-up for this, but that notification may have been suppressed in which case this virtual copying happens silently.   ... View more

For me the checkbox option shows as Conrad_C's screenshot, but only once you've clicked to highlight a particular folder within the Source panel.   If you have the heading of an entire drive volume highlighted, this option does not show.   IMO logically enough: only a folder has got subfolders. If you wanted to import all of the top level folders within a given drive volume then they may need to be all explicitly highlighted. This is seldom the case though, in that very often there will be a parent folder involved: e.g. "DCIM" on a camera memory card. But in that case one might not be opening up the folders of the Source - more usually, there will not be a selective import in that case - or at least, not on the sole basis of the folders. ... View more

You don't create a droplet in Lightroom Classic. You create a droplet in Photoshop, and many tutorials on how to do that should show up in a web search on those terms. In summary and IIRC (it's been a while), you start in PS where a 'scripted' sequence of operations are recorded into a named Action, which is then made available to be called from outside of PS by being written into a named 'droplet'.   In effect this droplet acts as a separate program - which when run, calls on Photoshop to actually carry out the operations.   The only part of this which takes place inside Lightroom Classic, is when you tell an Export batch to include a call to that droplet as its postprocessing step. The exported images are then passed to PS so the relevant operations can happen there; then results are saved back out to disk (which should be the last step in the originally made PS Action, on which this droplet has been based). ... View more

One cautionary point: by default with Lightroom Classic, develop edits plus any and all organisational metadata worked on in the Catalog, are stored in the Catalog only. In that case the external file's metadata  will not include any record of this work done within the Catalog environment.   "Read metadata from file" creates a new History state wherein not only are e.g. ratings introduced that were applied externally, but also wherein the whole image is reset back to whatever that external metadata holds for its Develop appearance, keywords, etc.   So if that other stuff has not been previously written out (up to date) before reading it all back in again, you will see more change in the image than you bargained for. That change (resetting to an unedited appearance for example) is still reversible by rolling back the Catalog's History to its state just prior to the "read".  But that would need to be done for each affected image.   If you had previously written everything out up to date, or else had LrC automatically write that out continually as it went along, then this method can work. However I would agree that rating etc within the Catalog or else within Creative Cloud in a manner that syncs in a Lightroom aware manner to the Catalog, is far the more elegant and robust way.   Mingling Catalog-centric and file-centric methods together, is IMO simply doomed to frustrate because it clashes paradigms. For example: how could one use Bridge to apply ratings to virtual copies? ... View more

You might also try going back through some Catalog backups to see if there was a moment when the problem started. Backed up Catalogs will need to be un-Zipped before they can be opened. ... View more