That's helpful info. It appears this is purely a display glitch and having nothing to do with the history itself, except that re-selecting the latest history step incidentally wakes up LrC that it needs to render the file again properly.   Re-opening the Catalog with an integrity check would do no harm.    I don't know enough (or to be more candid, anything) to advise on MacOS graphic drivers and GPU support, but that could be worth a check for any incompatibility.   I suppose one might try invoking a rendering update in bulk by applying some dummy new edit, for example highlighting a bunch of images then turning some unusual adjustment first on, and then off again with AutoSync selected.   Other ways to "wake up" the Catalog about these wrongly rendered images may be to go into Survey mode then back to Loupe - but I am straying further and further into realms of speculation here.    Among the possible even more arcane fixes might be clearing the ACR cache (which is used for intermediate postprocessing storage). ... View more

If you right-click on the icon for the Secondary Window you'll see options for its Loupe mode.   Maybe try changing the selection in this menu - IIRC there are Normal, Live, Locked modes.  ... View more

In cases where the photo is showing its initial state, but the subsequent history is listed: does the initial editing state in the history panel show as highlighted?   Or, if a photo is in the same condition (showing its intial state, showing subsequent , not displaying the effect of that subsequent history) and you make a new edit - does this new edit action clear and replace all of that later  history, or does it keep the history and then work cumularively onto that? ... View more

Are you open to a new subscription plan for your ongoing use, or are you seeking to continue using that perpetual license within a 'frozen' setup? Connected to that, is there any likelihood of soon wanting to move to a different computer? If so, there may be some practical restrictions with this older software and advice may need to be different.    Image previews being 'missing' is one thing, but images inside the Catalog complaining that they cannot locate their source files is quite another. So it would be good to get some more specifics on what you meant there.   One situation where multiple Catalogs exist (and if you are not sure which one to open) is if at some earlier stage, your working catalog was copied and upgraded under a fresh name as part of moving onto a newer software version of Lightroom (Classic). When this happens, the image previews get transferred for the use of the newer Catalog copy. Opening the older Catalog copy they will be seen to have been removed. This is normal.   Previews can always be re-created assuming the Catalog is still successfully referring to the originally imported files, but I would take this as an indication that you may not have opened the most up-to-date Catalog.  ... View more

I have never seen an option in cameras I've used (non-mainstream ones by and large) to separate Raw and JPG into separate folders. My own radical solution to the Raw+JPG 'problem' is to simply set the camera to shoot Raw only.   Any time I feel I might have liked a JPG also - but before I will have the ability to use LrC to make one (this is only exceptionally, and only with a few images) I will use the camera menu to process a separate JPG version, from the Raw, 'after the fact'.   If this was going to be a more common thing and for many images, even having shot Raw only: one could use one or another utility to extract, and save to JPG, the embedded previews out of those Raw-only files. ... View more

Not quite IMO. A screwdriver physically could be used to whack nails into a piece of wood. We can have a conversation about whether this is a good idea or not, and may end up not agreeing - such things being a matter of opinion and of circumstances.   But to use LrC to directly modify the imported files is neither a good idea nor a bad idea, since that cannot be done at all. Given that is not circumstantially the case but deliberately so, on the part of Adobe, it is very unlikely to become circumventable by users. So there is no such matter-of-opinion conversation to be had (assuming everyone accepts the practical situation). We could still have if-only-things-were-different conversations of course, but where would that get us!? ... View more

Nondestructive editing methods are deliberately made so that they cannot be used destructively. There is no "how" for something that is logically impossible.   Analogy: if someone asked "how can I use Move (not Copy) to duplicate a file using Finder / Explorer". That question would be unanswerable since 'Move' is defined as the method which does not duplicate, and 'Copy' as the method which does duplicate. ... View more

I quickly reached the conclusion that it should be LR or LrC, not LR and LrC.    I do appreciate there are many commonalities between the two of course.   But to use LrC and LR together in the hope that these will work like two sides of the same coin, only leads to frustration IMO. Keyword nesting etc does not work the same. The principles of storage and metadata location are not the same. Features are not quite the same and what features are even technically feasible: not the same.   I see these as two different coins, that share an identical reverse face: the CC system.   LrC connects to CC in its own way, and LR connects to CC in its own different way, fundamentally and inherently. These two different ways of connecting bring varying practical consequences. Settling on one work method or the other work method, is thus a choice we are IMHO wiser to make and then stick to, rather than to cavil and fudge that. ... View more

I would agree that resetting to a blank "apply during import" set of keywords is better and safer than for (perhaps without realising) bulk keywording to persist from one import, to the following one.   I handle this through an import preset  that I faithfully re-select by name every single time.   This re-initialises everything to a known, tried and tested state,   Bulk keywording is the only thing I generally change in the Import screen, so if there could be a checkbox option on that to auto-clear its contents, I would not say no! Then I would not need to re-select that import preset. Of course if other import settings might get individualised besides, that method remains useful. ... View more

As a broader comment really, whatever were found to be the best workflow opportunities for how the software used to work, will always be denied us once the software changes how it works.    So we need to find the workflow opportunities that deliver the most efficiency how the software works now.   It's just a matter of identifying what those new opportunities are. They are bound to involve different workflow steps, and/or in a different working order, possibly differently conceived. Such is change.    As an example, say this brushing that would have been done on each image in turn, was so as to apply [some adjustment] to the background areas of the portrait. Perhaps one can now as a bulk task tell LrC go and find the background areas within each portrait all by itself, and apply [some adjustment] to all of those in a smart manner. Perhaps a number of standard masks (pre-loaded with their respecitive adjustments and named for ease of reference), may be bulk-applied together so that then only tweaks would be needed within each image, which would then make use of standardised named masks which were all already in place. ... View more

To be clear, cropping is dimensionless so IMO selecting particular absolute pixel zoom factors such as 1:1, might be a bad usability fit in principle. Because when we sync a given crop across two photos of different resolutions, the sync is purely of pictorial composition and has nothing to do with individual pixels.    But one might nonetheless, without doing any violence to the underlying 'dimensionless' concept, want to magnify / reduce by a certain relative amount compared with Fit view. Say, go to 50% of Fit or to 200% of Fit. As noted already, that is a matter of achieving compositional accuracy not of achieving pixel accuracy.  ... View more

AFAIK the Destination if presented - it will not be with an Add import - would never be altogether ignored.   Just, any Subfolder asked for is first created directly inside the chosen Destination, and only then will the Organise By options kick in. So those will either be applying inside a new Subfolder that is inside the Destination, or else directly inside the Destination, depending on the 'Into Subfolder' checkbox.   The auto naming of an auto-created folder (by date) is to some extent controllable, but only by drawing date information from the photos themselves.    If you are going to be intervening anyway (to supply a meaningful folder name from your own separate knowledge) - one approach could be to tell LrC to go ahead and distribute the incoming images into different dated folders all by itself, accepting that initially these will just show the 'bare' date. Then, working from within the Catalog, rename those folders appending your descriptive text.   If your next import happens to include some photos from the same day, you might either delay renaming (so that the second batch can merge with the first) or else rename in between these two imports (so that the second batch will arrive separated from the first) depending what result you want.    To me this approach is a) more evident, and b) no more work overall, than individualising things within the Import screen.  ... View more

If there is something systematic that you want to do afresh to these images across the board, you can make a preset which not only includes an imposition of latest Process Version, but also prepares a starting point for the new adjustments which using this new PV is going to permit.    For example, a pre-made set of (suitably named) Masks. Any masks with AI behaviour will just need an AI Update to tell them to adapt themselves to the particular content of whatever image they now find themselves within. ... View more

Have you taken a look at the 'Lens Blur' feature yet? It is an entirely separate adjustments panel of its own. You can quite easily blur out chosen areas completely. ... View more

It would be more accurate to call this an addressing problem than that any images are actually LOST - they just temporarily need to be looked for at a different drive letter and file path. And that apparent moving-around can be prevented.    I think to set a fixed drive letter you need to be (temporarily) signed in as an administrator user rather than a standard user. If you just set up a user on the computer originally and are still using that, it's an administrator login. I find it more secure to use a standard user login that is created separately, so for me I would need to switch users to do the task.   Right-click on the Windows icon on startbar and choose Disk Management. With the external drive connected, you can from there assign it a new drive letter of your choice (provided that letter is not already in use). Hereafter whenever the drive is connected / the computer is turned on, instead of receiving whatever is (accidentally) the first available drive letter, it will instead actively ask for this particular drive letter you have chosen.   If you chose (say) E:, it would quite often be the case that something else would have already been auto-assigned E: (another USB storage device or a connected phone or whatever) in which case the drive would have to get (say) F: on the fly instead. This variation is what you are trying to avoid.    But if you tell it to always ask for (say) drive letter M: (you can go all the way up to Z) - the auto-assigned letters D, E etc are never going to come into conflict with this. So this drive is pretty much guaranteed to succeed in getting M: every time. If you had another drive, you might assign N: (say) for the same reason.   Once a drive letter is fixed and persisting, and you have re-browsed within the Catalog so it knows this is where the pictures now are - the Catalog can treat that as a constant. Thus this apparent "losing" of image and image folders no longer happens. ... View more

There are more adjustment possibilities available in the mask panel than may be first obvious, but that will require looking beyond the exact same name or nature of adjustment that is presented globally. In any case masked adjustments can bring different selectivity than global ones will, and that is selectivity not only of which part of the photo, but also of tone and hue range(s).   Thus, for global editing a special HSL tool is needed to target a darkening and dulling of the orange hues (say). But masking can go and seek out those same orange hues, in which case all that is needed as an adjustment onto those, will be some darkening and some dulling to achieve a similar end result - except, this can be further restricted to chosen parts of the image rather than globally.   Thus, a bit of lateral thinking sometimes needed - or naive exploration! I think of this as a mindset of: what can we do with it; not, what can it do for us! ... View more

In my opinion, you have bought LrC so that its Catalog can serve as the front-end to an image library. So it is the Catalog that you would already be using to find / organise and thus to view the image that you are considering editing in PS. So it makes sense to invoke the external edit from that same place, and by doing it this way you then get the results of your editing reimported back to the Catalog and presented alongside the starting image. You can then do further stuff inside the Catalog using that new image version, including applying further Lightroom edits nondestructively over the top.   There's more: in Lightroom there is not necessarily an exact 1 to 1 correspondence of files, and images. A particular file (for example a camera original file - JPG or Raw - but could equally well be a PS edited version saved to TIFF or PSD) can show as multiple thumbnails, each one independently adjustable and croppable and organisable using Lightroom's own tools. These additional versions referring to the same file in common, are called Virtual Copies. And any of those can be sent out to PS for further work if you want, if you do that from inside the Catalog. These additional virtual copies have no existence outside of the Catalog though, therefore there is nothing there that it would even be possible to open into Photoshop directly. Lightroom must be involved. I   t may sound perhaps counter-intuitive, but in practice this sort of thing is IMO what's great about the Catalog system. Tasks can be (at least to some degree) un-tethered from usual physical limitations, when they are carried out in a more virtual way. And that allows you to just work visually based on what you see, rather then getting involved in lots of technical steps.    So, see an image inside LrC, send a copy of it out to PS, Save and close PS when you are finished and you see the edited image. You did not tell PS where to find the image it opened, you did not set where the new file should be saved or what it should be called, you did not tell LrC to import the result and where to find that. And if one image is Raw based and the other is PSD based you can just operate on them and do stuff with them just the same, including making virtual variants for one or another purpose (maybe cropped differently, or adjusted differently., or grouped together in a virtual Collection).  ... View more

Store with Catalog is specific per Catalog, whereas storing centrally in the user's files (the 'roaming' area of that computer account's profile) is specific per computer user. account   So I guess it depends on which one there might ever be more than one of - where you still wanted to automatically see the same set of presets. Also, might this be happening within a second computer as well.   Either way, including the presets location into backups would be a good idea. Personally, I think it makes sense to use the central default location (by not storing with Catalog) such that not only the user customised Lightroom Classic resources but also Adobe Camera Raw resources held alongside (which LrC shares the use of with ACR) can be managed together. That is a whole range of other stuff besides e.g. the user Develop presets. ... View more

You need to do two things: get the image to a shape that is not too skinny proportioned for IG to accept (which is done with the Crop tool), AND then size this cropped image suitably (which is done in the Export settings).   Portrait images should be cropped to 1:1.25 proportion at the slimmest, or squarer if you want. Landscape images should be cropped to 1:1.9 proportion at the slimmest, or squarer. if you want   Do that to each image first, then export everything (no matter whether portrait landscape or square) using export settings of max 1080 pix wide and max 1360 pix high.      ... View more

just to comment, the LrC automated Copy import method can still be used to file images shoot by shoot even if not interested in a strictly date based scheme. It can do those parts of the work that it can do. Several ways to proceed.   For example, pehaps one uses a different card or else begins a new folder on the card, per separate shoot when multiple shoots occur on a given day. Or, perhaps everything from a given day is considered as one. So the filing scheme might consist of a fairly flat date based scheme of YYYY / YYYYMMDD inside a constant destination and then one renames the YYYYMMDD subfolder once imported, inside LrC, to characterise the shoot differently. And then one moves on to the next one. Or in the case where one manages multiple shoot folders on the same card, one might select YYYY as the destination (changing that as each new year comes along) and then inside that, have LrC subdivide according to the original folders on the camera card. Then rename each of those after import and before moving on to the next card.   If the images are mixed on the card and not in folders there, and all coming from the same day, one can do a selective import then rename the folder then do another selective import and rename the folder and so on.    IOW it is not a cut-and-dried dichotomy between the fully manual option, and a completely hands-free and neutral import method. But my goodness it is so liberating and pleasant and pilot-error-free, if one possibly can do the latter! ... View more

You can either copy newly taken images images into the computer yourself, in the course of that manually creating and directing picture files (camera JPGs or camera Raw) into whatever folders and subfolders you think best - or else you can have Lightroom Classic take over the task for you and save yourself a lot of that work.   If working manually, you can implement whatever folder scheme you want but must then micromanage which photos go into what folder. After that you still have a further separate operation to identify which of those folders should or should not have their contents brought into the LrC Catalog's image library, and then use an "ADD" import which keeps everything where you've put it without any subsequent moving or copying.   For LrC to take over the task, depends on using some consistent import folder scheme which LrC can implement all by itself, such as most commonly an auto capture date based scheme.   This is what I have done for many years: a designated location on disk contains Year subfolders, inside each Month subfolders, inside each Day folders, each that has been created automatically as required, and then each incoming photo is automatically filed under the appropriate Year and Month and Day. So I see one consistent dated folder structure inside the Catalog which LrC has accumulated over many years. This has happend.with zero input from me except telling LrC to Copy and Import new photos off the card reader when needed. No settings were individualised by me each time, except for batch keywording. That has been the long and the short of my file and folder management.during all this time.   Consequence: automatically filed images are not going to be characterised so far as their folders names, unless you then  optionally go in and rename the automatically made folder name to add some descriptive words. I don't bother doing so since I think it is more important to characterise the photos themselves (by adding bulk keywording during import). Descriptive text within the folder name is only ever seen in practice when you are looking at these photos in the context of the Catalog. Metadata added to the individual photos follows them into exported copies - including to some other folder, or when exported directly to the web. The source file's folder location is purely a local management matter, and functionally limited anyway IMO compared with the more flexible and productive forms of virtual image management that a Catalog makes possible.   IOW: Folders are a necessary technicality of storing images, that you can safely subcontract out to LrC to implement - but that do not HAVE to then serve as your primary, nor even as a secondary, means of management so far as your image library.  ... View more

" (a height between 566 and 1350 pixels with a width of 1080 pixels). If the aspect ratio of your photo isn't supported, it will be cropped to fit a supported ratio."   So 320h x 1080w (1:3.4) is problematic, being much slenderer proportioned than 566h x 1080w (1:1.9).   In my opinion it would be better to crop and output for 566 instead of 320 in the short direction, for 1080 in the long direction. That would mean setting the Develop crop to 1:1.9 or (which amounts to the same result) to 566 x 1080. What you are setting means in effect posting a less detailed picture (after being automatically cropped to shape by IG) , than you could have got by posting to IG's requested shape in the first place, and then not being cropped to shape.   If you do not have that much picture area in your original photo (for example, if only a slender pano was originally captured) then you are going to have to fall back on padding out the photo to the width:height proportions that IG wants. One built-in way to do that without involving other software to postprocess, is to output to JPG from the Print module instead of Exporting. Unfortunately this method does not adapt to portrait vs landscape variation in the way one might wish, so needs a bit of manual intervention. IG is basically more conducive for portrait IMO simply because that is the way round that people like to hold their phones. ... View more

these are the Instagram specifications for uploaded photos. If the uploaded photo is not of the same aspect ratio as the display of the device being used, you can expect to either see only the zoomed-in central part of what you have uploaded, or else to see it not filling the display - neither has to do with the uploaded image, per se, except that it may influence you to crop to a different aspect ratio in the first place. There is no need to use Scaling at all, AFAICT, to have Export deliver the output you want. Just crop the image suitably inside the Catalog, then Export / upload that cropped image with suitable output specifications.   Can you show any screenshots of what is currently going on for you (with what you have called a 'cropped' image), that you do not like? First as it is seen within Lr Classic and then as it is seen within Instagram. ... View more

Yes: Photo merge takes as input the underlying content of the imported files, and does not work from the visual result of overlaid nondestructive edits. Effectively it sets those aside. The conception is I would think, that one would schedule the merging step early on in the editing workflow, thus before detailed editing has happened,.   If you do want your edits to be included into what Photo Merge takes as its imput, I think you are going to have to commit those edits into some freshly rendered image files. One way would be to Export these images to some intermediate TIFFs selecting the option to reimport back to the Catalog, then merge those intermediates, then you can get rid of them optionally.   Sending images out to Merge in Photoshop seems to work the same way, as when merging directly inside LrC. ... View more

The upsides IMO are for individual images considered in isolation, as to how each can be most 'pleasingly' postprocessed in its own terms. It is probably only those doing timelapse sequences or similar operations who experience much of a practical downside from having image-adaptive rather than non-adaptive adjustments. Some workaround strategies have been discussed here which may help, and not mentioned yet has been the option of prrocessing in a much earlier PV (not very attractive as I see it), but the development of LrC's tools over time,seems to have simply moved in this direction like it or not.  ... View more

I think 'image adaptive' can be taken to just mean that the varying content of each image can make a difference in how the adjustment applies. An especially obvious artefact here is local-contrast enhancement, which inherently deals with proximity (as when strongly positive Shadows / strongly negative Highlights give a 'HDR' style tone-mapped look).   Still, much as if one were to set an auto WB or an auto Exposure (either in the camera or in postprocessing), one expects different outcomes for the whole image when (say) prominent red brakelights were illuminated within one night exposure and not within another.  ... View more

If you have not already done so, I strongly advise assigning a particular (and different) drive letter to each drive - besides whatever drive naming you give it. The former is definitive with Windows, the latter is just informational. Whatever drive letter you define will always get requested when the drive is attached / turned on, but if low in the alphabet there is a high likelihood it may already have been awarded to something else. But when a drive requests a letter further on through the alphabet (say P:) this will be almost certain to be always free in practice, and another drive might use Q:, and so on. That way all of these drives can repeatably appear under their own consistent drive letters without conflict.    It will then be a one-off re-browse within the Catalog telling it to in future look for the affected images and folders inside (say) Q: instead of inside (say) E:  ... View more