alternatively, you can use this control - 'Never' option is the same thing as being hidden with the H shortcut. 'Always' means they all show whenever you are in masking mode. Or you can opt to have these pins only show for the currently active radial or grad.  ... Ver mais

Two of the file naming 'tokens' that can be used when exporting: Filename, and Original Filename.   Depending on the specifics of what metadata has been preserved through a particular image's editing "career", which is what it is looking for, Original Filename may report the starting camera filename. Or will report later naming info, if that is what it now finds in the relevant metadata field.    But AFAIK, in my experience, Filename (without the "original") refers directly to the current file info for the image being exported. ... Ver mais

As to why externally writing XMP can sometimes fail: various reasons, including a cloud-sync or similar process operating within that part of the file system (OneDrive, iCloud, whatever) and conflicting with standard file operations - also, this can relate to user-specific or application-specific file and folder access permissions.   But IMO it is important to say: writing metadata to the external files (as XMP data, loosely speaking) is not a necessary component of editing in Lightroom Classic. The Catalog always holds your successive editing steps in any case.   A "metadata warning" does not say anything about the validity of that image's editing within the Catalog. It only speaks to the current relationship between that editing, and any duplicated editing info which may be also present externally.   In fact the Catalog holds some information against each image which can never be externally written. Examples: prior editing History steps; Collection membership; Stacking; the entire existence of Virtual Copies.   Making Catalog backups reasonably often is your best protection (into distinct storage hardware ideally, not sharing hardware with your working setup ideally). This should be accompanied by a good separate backup regime for the image files themselves, which are not included when you backup the Catalog.    As I see it ALSO externally writing XMP metadata is only even useful, in two circumstances:   The first is: if for some reason you want to access these same image files by another method that does not involve a LrC Catalog, using software that will nonetheless properly implement Adobe-specific metadata describing the latest editing state that was achieved inside the Catalog.   The other way it may help is: say you last backed up your Catalog on Monday evening. And now it's Wednesday, and you need to revert to that Monday backup for whatever reason. If while you worked during Tuesday, external XMP was being continually written out - then your latest work (done meanwhile, since that Monday backup happened) can be at least partially retrieved from there. Two scenarios: an image was already imported before the Monday backup, in which case you can now Read external metadata to update with your latest Tuesday editing on that. Or, the image only got imported during Tuesday, in which case if you now repeat the import, it arrives reflecting the latest (Tuesday) editing state that has been written to that. ... Ver mais

As I understand it MacOS "goes by" the volume name, but Windows "goes by" the drive letter, and the volume name is just an optional description.   When the volume name is consistent, MacOS will recognise that this is the same drive as before - and, that the image paths relate to. When the drive letter is consistent, Windows will recognise that this is the same drive as before - and, that the image paths relate to.   IMO it is unwise to employ a drive letter such as D: for an external drive: because sometimes, accidentally, that particular drive letter will have already been assigned to some different device. This will depend on the order in which devices are connected (or if left connected, the order in which they are found when the computer next starts up). In which case, this external drive will be assigned E:, F: etc instead - whatever is the next currently free letter.    And if images were formerly found in a D: drive which now appears to the computer as F: these images are thereby 'not found at same location' so far as the Catalog is concerned.    I strongly recommend: leave the volume naming in place for MacOs purposes, but for Windows change each external drive so that it will request a particular (unique) drive letter much further on through the alphabet. That way, there will be no accidental drive letter conflicts that will affect the Catalog. You will just once need to re-address the Catalog to tell it that this whole set of photos can be now found on (say) P: drive instead of D: drive as before.   Re-addressing a bunch of image folders is easiest when there is a single point of management exposed.   Say that within a given drive you have a top level folder "photos" and inside that year folders "2019", "2020" etc, and inside each of those a further subtree of image folders relating to that year.  And say that within the Catalog you only see those "2019", "2020" etc. As things then stand you would need to re-address "2019", and then separately "2020", etc. So it would be more efficient to go to (say) "2019" and right-click and choose Show Parent Folder to expose "photos" to your Catalog. Now you can just readdress that to update the locations of all the year folders in one go. This is done by right-clicking the folder and choosing the relevant option "Update Folder Location / Find Missing Folder" (which differs by circumstance but amounts to the same result).  ... Ver mais

Go to one of the folders that are held within your 2025 parent folder, right-click and choose "Show Parent Folder".   To flesh that out a bit, the folder directly containing any imported image always reports itself somewhere within Folders. Other folders can be made to show too. Whatever direct parent-child related folders occur within the Folder panel, have that parentage reflected by suitable nesting. But those folders which do not have any direct parent showing can only be shown as a flat list. ... Ver mais

You can check the box to tell LrC to reset everything for each newly made mask.   If that's not checked, then sequence matters: if you begin making a new mask (start brushing, place the position of the gradient filter, whatever) and then move adjustment sliders around, those changed adjustment sliders are specific to this new mask only.    But if you select to make a new mask and then move sliders around before you have yet started any brushing (say), then these changed sliders become the new default adjustments not only for this current mask, but also for future ones, until you say different. So this can be used to your advantage, maybe, if you want to brush some sort of consistent adjustment onto a succession of different pictures.   Unless usage of any non-zero default is being prevented, by a checkmark in 'Reset Sliders Automatically'. ... Ver mais

If you export to JPG, or you print, I am sure those areas will be sent as white.   It is just that they are now being distinguished from any solid white areas that may be present as part of the image.  ... Ver mais

It is not generally necessary to delete and re-create masks for this; just to update them.   If they were automatically generated then you can click Update and they will be re-generated to suit the changed appearance of the photo content.   If a brushed mask was manually painted to take account of an object in the scene, and then you later 'substitute' the place where this object showed, then similarly that part of the mask can be re-brushed / erased suitably. In that case of course there is no "update" button to click, also there is no red dot to warn you that what you brushed before, may now not be appropriate to this 'substituted' photo content. ... Ver mais