Just to point out, deleting an unwanted keyword also deletes any child keywords it has (you should see a warning message first).   So if you still want those other keywords (as they are assigned variously to lots of images), you should not simply delete that unwanted parent. You should re-organise these wanted keywords (centrally, in the List) so they are no longer nested inside that unwanted one.   Then this unwanted 'China' keyword will stop showing up indirectly as a parent keyword, on any images. However, any images which had got 'China' directly assigned in its own right - intentionally - will continue to show this as one of their standard keywords. ... View more

The place to sort this out is in the Keyword List panel, not in the Keywording panel   The Keyword List panel shows you any keyword nesting that exists. Keywords that are dragged out of a particular nesting will stop showing that as a parent keyword. You can highlight a number of keywords to do this, e.g. clicking the first in a sequence and shift-clicking the last. Then drag to another place in the list - that is not within "China". Dragging partway down the list will nest them inside another keyword instead. But right at the top of the list there is a narrow gap you can drag them to, which removes them from all nesting. It may take one or two goes to locate this, it's quite a precise target.    That said, personally I think keyword nesting is a great feature when done intentionally, so you may want to implement some sort of scheme anyway and drag your keywords into more suitable parent ones.   A parent keyword is simply any normal keyword. which one or more others have been either created or else later dragged inside. ... View more

Possibly if you switch the import settings over to Copy import, the presented options to do with import presets may change?   When importing with a card reader as the source, Copy is the default method unless you say different, except that the Add option is (generally, not always) unavailable in that case. When a standard drive is the source all methods are available but Add becomes IIRC the default instead. Unclear to me why or how that difference of behaviour should affect the management of import presets but seems it somehow does [mystified shrug]. ... View more

The Delete option presented in the same place where you would select which preset to use, is a widespread method used across many LrC features. That works one at a time.   Another method lets you go to where these presets are stored on disk: where you can delete those, copy them to/from another computer, back them up and so forth. Go to Lightroom Preferences in the menu; Presets tab; Location section. There is one button to show your saved Develop presets (these are shared with Adobe Camera Raw) and another to Show All Other (these are not). The second button opens a file browser window with a "Lightroom" folder selected. Inside that are the subfolders for various kinds of presets including your import presets, export presets ... etc    If you delete or add something here, no change will be seen within the Catalog until you've closed and reopened that. I believe (the organisation of all this has changed around quite a bit over time) if you've created a preset yourself, the proper place for that may be the respective User Presets subfolder, not the Lightroom Presets subfolder alongside. It certainly used to be the case that only a User Presets location would get re-scanned for any changes whenever LrC started up. ... View more

Thanks for taking the trouble John. Difficult to form a simple idea of what's going on but I think that even if images might report an abbreviated path that looks relative, and even if they might in effect 'travel' successfully with the Catalog, somewhere there must be absolute path info remembered. Reason I say this is:   Make folders parent..path \ A and parent..path \ B alongside each other, and create a new catalog in A. Put image-containing folder X within A and import those images with Add. Move this catalog bodily into folder B instead, and open that. The images are still found. They must therefore have 'remembered' in some way the absolute location of folder "parent..path \ A \ X", because if they only knew about having a local subfolder "X", that would now have failed.   I wonder if this apparent 'relative path' behaviour function may be just automatic substitution - re-pathing when necessary, and perhaps suppressing the display of upper parts of actual path whenever that repeats the location of the active Catalog. The latter presentation would in effect preview what 'as if relative' path updating behaviour would ensue, if something changed in future about the locations of both Catalog and images together. So the outcome would be a different absolute path, but one which nonetheless would look the same as it does now once 'trimmed' in this manner. But without suffering the downside I describe above (orphaning imported images which have not themselves moved).   Another way of saying this: your sunglasses possess an absolute position in the world at each moment. Sometimes - when they are on top of your head, say - their absolute position in the world is continually updating to follow your own position changing. When travelling in a car (say) the "On top of your head" description is more convenient than "currently at these GPS coordinates" even though both may be correct. But were they to get knocked out of the car window, the "on top of your head" style description now becomes invalid - but the sunglasses' GPS coordinates having now ceased tracking that of the moving car, still remain accurate for their continuing location. ... View more

AFAIK Catalogs don't literally implement relative pathing vs absolute pathing: using absolute paths always, so with no separate "feature" to document. One could test this by moving a Catalog away from the physically associated photos that it references (the photos staying put). If their pathing within the Catalog had really been relative before, affected photos would then become "not found". I don't think that is what happens - the paths for wherever they absolutely were before, and where they continue to be, would still work fine. I expect! (careful disclaimer)   Assuming so we can think of this association of files with Catalog as a special-case situation: and what makes it special is that LrC has a fallback "what-if" tactic. Whenever LrC cannot locate its sunglasses where it thought they last were left, it prompts itself: did I also check the top of my own head? (grin) ... View more

Individual presets themselves define any different grouping they should appear within, as seen in the Presets panel. Groupings seen there, do not necessarily correspond to any actual subfolders.    A given preset  can be assigned to one of the already seen groupings, or else to a newly created grouping, by right-clicking on that in the panel and choosing Move. This takes immediate effect: LrC physically edits the external XMP file accordingly, re-scans that and then reflects the change straight away.   Another method is to - from outside of the Catalog - use some separate text editing utility to selectively change the relevant statement inside the chosen XMP files. The Catalog will not I believe re-scan for and then reflect any updated groupings until its next startup.   so as screenshot above, the only reason two of my presets group themselves under the heading "lens related" (green highlighted) is because those two presets contain within their XMP file this particular text (orange highlighted) within the section named "Group". These two presets still live physically alongside the others - there is no actual subfolder called "lens related". This is an example of virtual organisation only.  ... View more

Yes people might as well know about this feature - still I suspect that many, even knowing about it, would not have that as an aim. The location of a Catalog and the location of image files (whether in one volume or spread across many) involve differing practical requirements and I can see many ways how it could be restrictive to in effect require metadata (the Catalog's info about where the source images are) and the data (the images referred to) to both live in one storage location together.   Unless one was constantly moving things around - but that raises the question: why not, instead, find a way not to need to? ... View more

unsafe link was for something called "space urchin" - my curiosity got better of me, but I think my anti-malware blocked all the potentially bad stuff that resulted ... View more

See this explanation: https://www.fastrawviewer.com/blog/fujifilm-x-series-iso-bracketing    If the article linked is correct, only one photo is exposed when this feature is active. It's not 'exposure bracketing' at all, strictly speaking. It is 'appearance bracketing' where additional slightly lighter and darker processing treatments of this image are presented. If shooting JPG, each would have different picture content because the camera has saved different  processing outcomes into these three files.   If shooting Raw, that will not be the case: the Raw content of each file being identical. This is despite the JPG previews embedded by the camera, and then initially shown in the Catalog, representing three different 'notional' brightnesses.   In my opinion there is no advantage from this feature if shooting Raw, You would get substantially the same results by moving the Exposure slider after import into the Catalog: even, make virtual copies which can show this brighness variation side by side. But you will have avoided the duplication involved in making three copies of effectively the same identical Raw file. ... View more

Conrad_C's post higher up illustrated this very nicely. In that case "retain size" / "expand" borderless alternatives are presented, besides the standard of printing with margins, in the paper selection.   With another printer / computer type: you might select (say) A4 just as the physical page, and then use a separate option to control whether the standard printable extent should apply, or whether one or another kind of borderless printing should happen. ... View more

Is bulk generation possible in the develop module?   I don't think so. It is the Library module (not Develop) where an embedded preview made by the camera is first seen, before a LrC-generated preview can be generated. A 1:1 preview may also wait until you first view that particular photo full size within Library.   But you can select a bunch of photos and manage what the Catalog does for their Library previews:   Any changed image gets its Library previews invalidated requiring their re-creation.   All of this works independently of, and I think as a background task in relation to, whatever previewing and dynamic appearance updates happen inside Develop.   Personally, I don't wait for 1:1 Library previews and such, preferring to evaluate image detail and content inside Develop - which is where I would be carrying out actions in relation to that image detail and content. ... View more

word to the wise: some very old posts in this longstanding thread contain external weblinks which since been nastily compromised - great care please! Links within Adobe / Photoshop.com forums not of the same concern.  ... View more

It seems you have selected a 'borderless' A4 page size to print onto. Typically, printer drivers add some extra enlargement (about 5%) onto each Borderless print job after receiving it from the application. This matches what the OP is experiencing.    The LrC application does not anticipate that this further enlargement will happen, so does not preview or allow for it.   Some print drivers offer an alternative Borderless (true-to-size) option - but failing that, all Borderless (with scaling) printing is deliberately inaccurate for size. ... View more

[edit: on reflection, the below is not I think the OP's issue - but I'll leave in place just for general info.]   It is not always necessary to change the main crop of the image (in Develop) to match exact image Print dimensions - though it would be, to match exact Export dimensions. You can achieve the former entirely inside the Print module..   In Print, each goes inside a containing cell. Dimensions of this cell are controllable directly. If this cell is any smaller than the physical page, then white margins must be left for that reason.   These dimensions define a printed aspect ratio: which may or may not match the current Develop crop of this image. The way the image sits inside this Print cell is controlled by two checkboxes:    The orange option sets (in English) Zoom to Fit (when unchecked) / Zoom to Fill (when checked).   FIT means: scale the image so that nothing is lost - which means further white margins must show to the extent that there is a difference between the shape of the cropped image and the shape of the containing cell.     FILL (checked) - means: scale the image as needed such that no white margins show inside the cell (though white margins may still show outside the cell). And, dynamically trim off - just for the output, not affecting the image itself - whatever picture edges are needed to achieve this. The image can be moved around to achieve the composition you want, if you don't want a centred automatic trim.     This dynamic cropping is no different in its effect, than if you had changed the main crop in the exact same way - just, it is much more convenient not to have to do this.   Furthermore, the same image can this way be printed to a variety of shapes, even on the same page and at the same time. As shown in the above screenshots: these only differed from each other, in their "Fill" checkbox setting. ... View more

Perhaps as an analogy, consider an old fashioned control panel for a power station or something, with lots of manual dials and levers and such. A preset in this analogy would be a shaped piece of wood you press against the panel which turns some of the dials to certain values. And over time, various of these shaped pieces of wood are used as well as manually turning dials prior, in between or since. Maybe you wrote on each of these pieces of wood, each date and time when it was pressed against the control board. But the only thing that can tell you is that those particular dials (but not the others) were then on certain settings (but may have since changed). And you've also kept a full log (History) of every time any change, manual or preset, was made on the control board.    Looking at this from the other side, someone could look at a dial and ask "why is it on that setting?" - so you look back at the History. This only informs you usefully about the last setting change made to that dial. Prior settings are not useful information, since they have been since obliterated - presumably, for good reason at the time. And you haven't recorded what that reason was: possibly associated also with the settings of other dials, and not just this one. Possibly specific to that one situation and not of any broader significance (as, when considering using the same setting change for a different image).    To reiterate, the past use of a preset is not any kind of  (reliable) information. That was just one way, among several equivalent ways, to change the image adjustments. The adjustments as they are now is what matters functionally. If you want to classify images by what processing decisions were taken on them, yes the presence of a given preset in that image History may be informative. Or you can note or mark images in some way.   But later adjusting the result from having previously used a preset: LrC does not work like e.g. a parametric 3D modeller (where the final result seen is due to a stacked set of modifiers that each operate on the outcome from all the modifiers appllied prior). That is because the application of a Lightroom develop preset REPLACES (it does not relatively alter) the value of each parameter affected by it. Just as any manual settings change does. ... View more

If there is a particular brushed local fix that you use a lot, and that always needs to apply the same adjustment (at least as a starting point) then you can make this on a photo as a mask - you'll need to add a brushed spot to do this, but you can then erase that - and name this mask meaningfully - and include this mask by name into a new Develop preset.   Now when you apply this Develop preset to a different photo - or to many photos - the same mask will be seen there, applying your same adjustments. You can then click to activate this mask and brush in which parts of each photo you want it to apply to.   You can make, and include by name into the preset, multiple such pre-made masks if you want.   OR you can sync or copy/paste a mask or multiple masks made for one image, onto one or more others. Same result.   So: rather than trying to repeatedly create from scratch in a way that matches how something was previously created - duplicating that already-made thing is IMO the more efficient approach.    This is not restricted to brushed masks - it can be any kind of simple or combined mask, manually made or involving some automatically detected AI selection such as "Sky". From there on not only this mask's selection, but also the adjustments it applies, remain further alterable of course. ... View more

Thanks for your diligence Johan, I shouldn't have posted that detail without checking first.  ... View more

You may be right about how the % works for presets, some time since I've experimented with that (since I make little use of presets). I would be a little surprised. It could perhaps mean that a preset which relatively lightened an image when applied at one %, might darken it when applied at another % - which seems counter-intuitive to me. I am unable to test actual behaviour just now though. I will be curious to do so!    Regardless, my focus was more on what presets are, as distinct from what adjustments are. Also, pointing out that changing the % action of a given preset - however that is implemented - is only briefly an option, immediately after applying that preset. ... View more

Presets are just a convenient and standard way to move the standard adjustment sliders to particular values. It is those adjustments, not the preset itself, that make a difference to your photo.   The same difference happens regardless whether you've manually moved an adjustment to a certain value, or copied that across from another photo, or used a preset to set it to that value.   Furthermore if any later preset or manual change has further altered relevant adjustments then it no longer makes sense to talk of the photo as "having" that preset applied any more. The record of its usage in the History has to be considered together with all the other History steps, to explain how the photo currently looks.   Some presets can be modified in their % effect immediately after they are used - before dpoing anything else - but this is again merely a matter of what setting the actual adjustments concerned are to adopt. Say a preset is going to set Exposure to -1, and then you choose to moderate that preset's action to 50%. This just means that the Exposure slider moves half the distance from whatever its present value is, to the value of -1 that is written into the preset. Exactly the same as if you had manually moved the Exposure slider to this final setting. That is what the photo goes forward with - there is no ability to later change % action of the preset. A preset is not any kind of persisting "thing" that would be further adjustable, or listable - it is a momentary past "event" in the image's History.   Analogy: knowing something perhaps from school, or perhaps from encountering that fact somehow else. We can't assess or extend our current knowledge by reconsidering what school lessons we had as a child (some of which information was later forgotten or corrected or superseded), nor by reviewing our other past experiences for that matter.   We work from, and update as needed, our present situation - which results from a combination of all that. ... View more

While the versions of LrC and ACR you've listed do look OK to me - and should work together AFAICT - the symptoms are nonetheless those seen with a version incompatibility. Perhaps more than one version of PS is (or has been) installed on your PC, and your LrC is currently looking for the wrong one. If so: a reinstall of latest PS should probably resolve that. ... View more

You don't need multiple masks, you can simply combine multiple adjustments within the single mask as applied by your (for example) brushed selection. Almost never in Lightroom Classic is one adjustment going to suffice alone!    Brown is indeed (more or less) an orangey yellow, but darkened. Thus you will need a tonal change plus a hue change. In LrC these two are kept well separated. I like to go partway towards such changes in White Balance, to maintain some of the original lighting feel, finishing off the effect with the colour overlay tool to intensify and tweak the hue. Plus for the tone aspect e.g. negative Exposure.   Another tack might be to (in local) use  Tone Curve: dropping the Blue curve quite a bit, maybe the Green slightly, with the Grey (luminance) curve brought right down to make the wall brown and not just yellowy. Both approaches shown below.         ... View more

the "-2" simply means that a prior file of that name already existed in that folder (physically on disk, and regardless of any importation to Catalog or not) before a second file was created. ... View more

Further reasons why a file saved by a PS external edit may not then re-import to the Catalog include:   For PSD, the option "Include Compatibility Preview" has been disabled perhaps to economise file size (though a TIFF will include this preview regardless, AFAIK) The image has been converted into a non-supported colour mode, for example 'Duotone'. ... View more

I don't do much at all with syncing so can't advise from experience. My suggestion for "leanness" was in case you wanted to reduce image numbers within the library. If that is not the case, it would merely be duplicating the same thing which ultimately (once new previews are generated) would end up in the same situation - all else being equal.   If it's the previews infrastructure that is concerning you, but you still want all those images in the library, as already commented the obvious first step to review Catalog and LrC settings which relate to preview generation and also to preview expiry and removal. ... View more

To help narrow things down please - since there are many many fields within LrC which report various natures of date - what specific metadata in the file does your script rewrite before import?   Where is this revised date then seen / not seen in the Catalog after import? Then, after adding the image to a Publish service, in which particular metadata field(s) is this date seen (from within the Catalog) to have been reset? Or, are you viewing attributes of the external file directly? ... View more

"Folders are meant for storage, and they're inflexible as a way of categorising pictures."   This is a crucial insight IMO. ... View more