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

Exporting to DNG assumes the output is intended to act as a Raw (or a mock Raw equivalent, if exporting to DNG from say a camera JPG). By this I mean that it creates a duplicate of the unedited DNG as imported, but attaches metadata describing your edits. Same as when exporting choosing the filetype selection "Original". So that is functionally equivalent to writing edit metadata back to the external file which has been imported, and then inspecting that - except, the latter method could not externally save the edits of a virtual copy, while you can do so via Export.   The embedded file preview of your imported DNG, or of an exported duplicate, may or may not reflect latest edits depending on the exact steps followed.   So it depends what XnConvert is referring to - extracting whatever preview image is present? Carrying out a default Raw conversion? Or (less likely IMO) carrying out a full Raw conversion and adjustments by correctly interpreting all of the Adobe proprietary editing parameters that are found attached. Perhaps by looking at these DNGs in your file browser and seeing what the thumbnail looks like (which should refer to the embedded preview as that currently stands AFAIK) some clues may be gleaned. I have just now desaturated a DNG based image, then exported a copy of that to DNG. The file previews properly as B&W within the file browser. But opened into a non-Adobe aware program (I tried Affinity Designer) the image is interpreted and displayed as if I had never desaturated it. So that program is neither extracting the (B&W) preview, or using the (B&W) editing instructions that LrC will have included.    Incidentally, as I understand it editing a DNG will not in itself update the preview image present within the imported file. That needs to explicitly be made happen. ... View more

My advice (though not knowing all the details of the OP's circumstances) is to avoid using "Pictures" as the location either for the imported photos, or for the Catalog with its accompanying support folders.   For several practical reasons I find it much more robust to use a user-neutral disk location instead - one which is not nested inside any particular computer account's files area. For example, C:\data\lightroom.   Consequences: first, it is then not dedicated to and limited to any particular computer user account; it is not affected if that account username might differ when set up inside a new computer - and there have been nasty recorded issues where someone has simply capitalised that differently than before - or if the particular local user profile ever becomes corrupted and a fresh one needs to be made. Second, for all the imported photos and for the Catalog and also for all the generated previews etc, OneDrive will simply stay out of the way.   This is not to say that the Pictures folder should not be used for exports of course (simple JPG files which are not themselves imported to the Catalog); I find that completely appropriate and consider it beneficial to have OneDrive monitor and back those up to cloud.   Just, a Lightroom setup being functionally different from a standard static set of files does require a different backup solution. One that intrudes less into the expectations of constant availability, stable referencing, and interdependence of external files / working Catalog. ... View more

One thing, I believe Instagram may dictate 1080 pixels wide regardless whether the image is landscape or portrait. If that is right, then the 1080px width x 1350px height specification would be exactly suitable. That way a landscape image will export 1080px wide (and less than that tall) while a portrait image will export 1080px wide (and more than that tall).     If the above information is correct then I think you would not want a landscape image 1350px wide x 1080px tall anyway. Not if Instagram is going to automatically downsize that to 1080px wide; since it will likely not do as good a job of that secondary resizing, as if Lightroom had exported straight to that same end result, which Instagram could then display as-is. Whenever we export we must IMO consider the needs of the final result as it will effectively be viewed. ... View more

Images seen within a collection - including Quick Collection - can be stacked together (or not) on an independent basis, completely separately from any stacking going on in their respective folders.   Two images happening  to come from the same folder can be stacked together in the context of that collection with a third image, coming from a different folder. Or, say,, you may have two images that are stacked within their folder, but only one of those is added to the Collection. Thus, stacking within the collection is logically and practically distinct from any stacking within the folder. And the same applies to custom sort also.   In other words: we may make multiple collections relating to some of the same photos (alongside varying other photos as well) because we have a different usage purpose in mind for each collection; and that purpose will duly govern any stacking, any custom sorting, as well as the selective inclusion of different members in the first place. ... View more

As further input: LrC does not ever work in true monochrome anyway (even a B&W treatment may receive tinting / grading, and regardless of that, will still produce a RGB encoded JPG when you export - not a monochrome encoded JPG).  So using a monochrome Profile, or selecting B&W processing, or applying a desaturating adjustment, are effectively the same. The only differnce being that images for which B&W mode has been explicitly chosen, are the more easily distinguished since LrC makes this available as a searchable image attribute.    My own habit is to apply a preset which sets 0 saturation for all colour ranges (Color Mix panel), since this method leaves all of the interface the same as when working on a full colour treatment. Going to B&W explicitly will suppress some of the colour specific controls (that one may still want to vary, in pursuit of exactly the mono conversion one wants). I replicate the same function the B&W panel would otherwise supply, via the Luminance controls within the normal Color Mix panel. ... View more

Maybe try exporting to JPG with otherwise the same settings, and see how those results compare against PNG. My understanding is that EXIF metadata is not so well, or in some cases not at all, supported with PNG: for inclusion and/or for later interpretation. ... View more

Subjectively, the fact than one image has got twice the pixels of the other; taken together with the fact that one image is zoomed half as much as the other, seems to cancel out and present as if there were no differences.   But objectively, there really are two differences between these images as viewed - 1) the number of pixels in each case, AND 2) the zoom factor in each case. Two differences is not the same as no differences.   Locking the zoom factor is considering only difference (2) and can only synchronise things for that one aspect. 100% vs 200% would count as not synchronised, IMO logically enough, as far as that goes. ... View more

I do understand. Someone else may not want their carefully curated sequence to be intruded into by newly made virtual copies, and may think it completely appropriate to cluster those new copies at the end initially by default. Do you want this new image before or after its original, and what is considered the original? Say the photo's master instance is not a member in the collection, but two different virtual instances from the same file are; which one of those should it then go next to, and should that be before or after? Questions raising more questions.   I am not being difficult for the sake of it, truly: I have a wider point. Sometimes even perfectly sensible and productive ideas (which this is of course, withiin the bounds of the specific use case you mention) simply cannot be reconciled neatly and consistently into LrC's general paradigm - given that this paradigm has to cover a much broader range of possibility including use cases under which the opposite of this idea might be desirable.   Very often, AFAICT, the decision will come down to: what will make the least number of people more frustrated - rather than, what will make the most interested people more satisfied. ... View more

Custom means it is up to you to move images into the order you intend. And another user will have different ideas on what order is desirable AND on how newly added images should show. How could LrC know what is in each user's mind? ... View more

There is more that you can do "for free" if such a postprocessing step is being included, for example adding a border line (which is not otherwise offered by the standard LrC export)..   The suggestion has been made to subcontract this cropping to Photoshop - if you want to research that, the key concept is to save an action as a 'droplet' which LrC can then tell PS to execute onto each image in turn. Calling in PS is more 'computationally heavy' I would think, compared with a compact and simple image processing utility. ... View more

I suppose my two questions are, similar in what way? (from a similar original technically; with similar metadata assigned; with similar collection memberships in common; with similar processing applied; based on some auto-analysis of the picture content, with similar subject material; or with similar framing / composition)    And, for the aspects that require some interpretation - similar in whose opinion? (grin) ... View more

This is because Export can unfortunately only achieve a "zoom to fit (within rectangle)" outcome rather than a "zoom to fill (entire rectangle)" outcome.    Alternative 1 is to export to JPG from the Print module instead, which does offer a zoom to fill option. This is however no good for preserving individualised file naming, keywords etc into the output.   I would suggest alternative 2: add Postprocessing steps using a utility such as ImageMagick directly (controlled by commandline options) or else in the form of a LrC plugin (Mogrify) to trim off any surplus pixels present. So calling that in would be specified in your export settings, and made easily repeatable for the future by saving those settings into a named export preset.    One more thought first: you are quite certain the identical aspect ratio of crop was consistently in place? ... View more

Are you perhaps renaming as part of import? Or, converting to DNG? ... View more

To be clear, I see absolutely no issue with working on JPGs and on Raws appearing separately and being edited and managed separately. For each one, that is no different, than if this had been the only format captured.   My only hesitation is with having changes that you may apply onto (say) an imported JPG IMG12345.JPG, then automatically go and look for an imported Raw that had a matching filename (IMG12345.NEF) and then repeat the same change onto that one also.   This may indeed sometimes be the desired behaviour, but will equally very often not be - complicated as I say by the possibility that Virtual Copies may also exist relating to these two files. I doubt that there is any reliable way to specify and then implement the difference between these cases.   Either these two are to be independent, or they are not - there is no comfortable midpoint between. ... View more

IMO this proposal if implemented would rather undercut the Catalog paradigm, and be an ill fit with its logic. If the separate Raw and JPG are meant to be regarded as independent and not one,  then they should not act as if they were one. How is LrC to distinguish between actions that are meant to differentiate them (like adding a keyword which makes one or the other show up in a Smart Collection) from actions that are meant to apply in common to both (like adding a keyword which relates to the original photo's capture).    Once you include the possibility than one or the other may exist (virtually) as several alternative treatments represented by different thumbnails in the Catalog - the question complicates further. Again, virtual copies share the use of one underlying file but are specifically made in order to be independently editable and independently manageable.  ... View more

"Taller" is about scaling. It's sometimes assessed in physical terms (inches or centimetres @ a certain ppi) but more often with digital images  it's assessed directly in absolute pixel dimensions, for example an image might be 1200px tall. And that scaling would be specified in the Resizing section of the Export settings - or else in the image cell specifications when printing.   "Thinner" is about shape. We might say of two people that they look equally "thin", even though one is 2m tall and weighs 100kg, and the other is much less tall and weighs 50kg. We are saying their body proportions are similar. And that shape in LrC is set by the image's Crop; only removing picture information of course, not adding more than was present in the original capture.   All that said, there is a Transform panel where you can (somewhat) distort the image's natural appearance. If there is a certain crop shape you want for the output but the picture in its natural presentation cannot include quite what you want into that boundary, you can (for instance) make the whole photo look more squat or more stretched by changing the Aspect slider. A slightly different selection from the original capture will then show within this constant crop boundary.   So that involves a stylistic decision. I've have noticed that often people are uncomfortable (consciously or unconsciously) seeing this kind of distortion though. They might dislike it on aesthetic grounds - or on 'faithfulness to the subject' grounds - or both. ... View more

Output sharpening takes proper account of the relationship between starting pixel dimensions and output dimensions, and does so on the fly. If you like, it builds into each resize an appropriate level of compensation for resize softening, intelligently.    So, the character of sharpening that you see previewed in the Develop module (as judged at 1:1 zoom on screen) can be replicated, or slightly enhanced, or not, for export.   You would need to confirm which output sharpening setting you like the results of aesthetically, by trial and error. But then that same setting will in my experience always deliver a perceptually constant relationship between how sharpened the edits on your originals 'look' inside the Catalog, and how sharpened output made from that 'looks'. Even despite these originals perhaps varying in their resolution as cropped, AND even though your outputs may happen to varying pixel dimensions too.   There is no need to dedicate the edited image seen in Develop for any particular output specification. Different outputs will bring different practical requirements, but that can be addressed in the respective Export (or Print) settings.   Sometimes a version of an image must be dedicated for particular output nonetheless - not so much in terms of output sharpening, but perhaps a different crop or some special visual editing. In that case I would recommend either a virtual copy, or else (which practically amounts to the same) using SoftProof to generate a virtual proofing copy. For screen viewing purposes, in my opinion soft proofing is not necessary. You should in any case be using a hardware calibrated display that gives you a reliable consistent impression of your edited image, and that should prove sufficient. ... View more

Can you please clarify what you mean by "saved as a copy". Any additional versions that are made solely in PS, will not be automatically seen or imported by LrC.   To summarise normal process: starting image sent to PS using "edit a copy with Lightroom adjustments". In the case of a Raw, that will be the only possibility so no other options are presented. Image now seen in PS shows effects of prior Lightroom editing. Further editing applied inside PS.    If LrC and PS are version intercompatible, that image seen inside PS initially is not yet saved to disk or imported back to LrC, and its document title temporarily repeats the filename of the underlying source file you started with (even though you do not literally have the stated file open In PS). In this case clicking Save will create a new file on disk, import this to Catalog, and update PS document title accordingly. Further Save will do a further update of what is on disk and of what is seen in LrC.   If there is not that intercompatibility OR if you've used an additional external editing preset, the new file on disk is created straight away by LrC and that is what is then opened into PS for any further editing. That is similar to how, once an external edited file shows in LrC, sending that to PS AGAIN tells PS to re-open the same file on disk for further change. In either case, Save causes an update of what already exists on disk, and an update of a PS edit version which is already seen in the Catalog.    But Save As will then generate a different, separate file anew. LrC will be simply unaware of. this: it will be none of its business. ... View more

Marek: if you are using email - you will need to use a web browser to see the screenshot which has been posted.   Otherwise, you can find this in the Lightroom Classic "Preferences". General tab, Import Options section, "Treat JPEG files next to Raw files as separate photos" - the default is for this option to be un-checked. ... View more

edit: Good point above about Raw+JPG, that is the most likely explanation IMHO    One other possibility is that LrC has detected some (suspected) duplicates. When LrC evaluates that a given file appears to match up with another that has already been imported (if seems to be a second instance of the same photo) it will - by default - disregard that.   IMO rightly - while it is possible to change the Catalog's import behaviour for suspected duplicates, including this check does serve a useful purpose.   Another possibility is that your LrC session lacks the needed access permissions to some parts of the NAS file system.   A further possibility (I suppose, tentatively) might be - if you use symbolic links - that a spurious count of the discrete physical files present, may be being presented by your file browser. ... View more

My advice would be, import the image in original form and then have LrC perform any alterations and then export processing all in one go (output sharpening being integral to that).   There is no benefit IMO in having PS save an intermediate, output-specific file. To the contrary, it is best IMO to regard everything imported within LrC as output-neutral. Whenever you may in future want differently sized or specified output, or differently cropped or straightened, you can just export accordingly. Only the specifically needed resampling will have then happened, and only happening to that eventual output, without cumulatively affecting your photo. ... View more

If you have several images highlighted and you have AutoSync active, then anything done to any one of the images is applied immediately to all of the images. But there are some issues especially around differing rotation / orientation, that can give unexpected results with the syncing of masks betweeen images.   It is fine to apply global adjustments across a whole batch of images (and it will not matter which one of these happens to be the active image at a given moment, since all will receive the same adjustments together).   It is usually OK to batch invoke a Sky or Subject auto-selection, which will be analysed and implemented separately in the case of each picture, and then apply whatever local adjustment you have stipulated.    But when it comes to localised mask selection e.g. with the brush, you may want to do this individually per image. Of course you can apply a number of different masked adjustments across a batch of photos working from one sample image; but accept that the location and extent of the brushing on a mask, or the positioning of a gradient filter, within the other photos - may need to be individually re-done. To switch to individual editing per photo you would either need to NOT have other images than that highlighted at the same time; or more radically, to turn AutoSync mode off. That is done at lower right of Develop (the button only appears when multiple images are selected, and when only one is, the whole thing is moot). ... View more