Lightroom Classic

Issue: The Color Mixer Target Adjustment Tool does not choose the correct color(s) for H/S/L adjustment when HDR editing is enabled.    It should choose, and then adjust, the color/two-color mix that is clicked on. However, that selection seems to be skewed in HDR-enabled images. For example, blue sky will register only as magenta if using the target tool. This problem occurs in both non-HDR and HDR areas of an HDR-enabled image.   If HDR editing is then disabled for the same image, the target adjustment tool will identify and adjust the appropriate colors when going to the exact same spots.   Video attached of incorrect behavior in HDR editing mode. The image used in the video is a JPG, but I have confirmed this behavior also occurs on a DNG.   --   Lightroom Classic v13.2; MacOS v14.3.1; MacBook Pro M1 2020

HiThere is a small error in Polish translation of word "Contains" in Text search menu /see attached photo/.In Polish it should be "Zawiera" not "Operator Contains" i think 😉Wersja Lightroom Classic: 13.1 [ 202312111226-41a494e8 ]Ustawienie języka: plSystem operacyjny: Mac OS 14Wersja: 14.2.1 [23C71] ThanksPaweł Słowik

Since the latest version of Lightroom 3.0, it has been introduced that a photo loads faster than its actual colour. Sometimes I have to wait a second after opening a photo to get the correct colouring. This is very annoying as it's hard to focus on comparing the photo against the previous one. Is it possible to turn this off somehow? I would prefer to wait even a second for a photo to appear already with the correct colour scheme rather than initially having to preview a false version.

See screenshot. (1) The cursor was on the sky (trust me!). You can see that the LAB values for the A and B channels (shown below the histogram are zero (as they are throughout the image) - not surprising because the image has been changed to B&W. But the histogram and the image clearly show a blue sky. (It's blue because I've applied a mask for the sky with a curves adjustment in the Red and Green channel which makes it blue).  But why do the LAB values (which are zero in A and B) not reflect the histogram and the image? (2) Why would LR allow colour in a B&W profile? I would have expected that applying such a profile would remove all colours? Educate me please!  P.S. I'm wasn't trying to create this blue sky. It's just a hangover from the original colour edit after applying the monochrome profile. And yes, I know how to get rid of it. . LR Classic 13.0.1. on Mac Mini 2018

Raw images with a custom camera profile not look correct when synced from Lightroom Classic to the cloud.  This is r-e-a-l-l-y inconvenient for updating my Adobe Portfolio.  The images look lousy in lightroom.adobe.com, LIghtroom Mobile (Android and iPadOS).  The workaround is to export as jpg, and then reimport into LrC and sync the jpg to the cloud - but that is unmanageable for more than just a few images.  

Adobe Photoshop Lightroom Classic 13.0.1 Release (Camera Raw 16.0)Windows 10 version 22H2 (Build 19045.3693)   I am using two calibrated monitors, laptop + external.LR's Secondary Window is on the external monitor, showing the Survey view.    LR on the primary monitor is in the Develop module, with two near-identical images selected on the filmstrip. The image with focus on the film strip becomes slightly desaturated on the secondary monitor - the image next to it is shown correctly (!), so this cannot be an issue with monitor profile.   The saturation changes are not immediate or simultaneous. Times below are guesstimated. 1) Focus changed on filmstrip -100ms delay- 2) Image that lost focus regains saturation on the secondary display -100ms delay- 3) Image that has gained focus loses saturation on the secondary display   Same behaviour if three images are selected on the filmstrip. Exiting LR and restarting makes no difference. Problem is not present in t

Sync Metadata clears the Altitude field of all selected photos when just GPS (but not Altitude) is checked (incorrect). Pasting the clipboard into the GPS field also clears Altitude (incorrect).  A metadata preset with just GPS checked also clears the Altitude field (incorrect).   The Altitude field shouldn't be modified when copying just GPS. This is clearly not designed behavior, since otherwise there would be no point in having a separate Altitude checkbox in the Sync Metadata and Metadata Preset dialogs. The bug was introduced somewhere between LR 6.14 and 9.1.     To reproduce on LR 13.2 / Mac OS 14.4.1:   1. Download and open this small catalog: https://www.dropbox.com/scl/fi/fpom4b2bgdhmfdfxjlbhr/copy-gps-bug.2024.04.29.zip?rlkey=gssyo3jfgvpih24t2lcaom1h2&dl=0    2. Observe in the Metadata > Location panel that both photos have non-blank GPS and Location fields.   3. In Library Grid view, select both photos, with 1.jpg most sel

After I copied all my photo files in Lightroom to a new PC, all the photo files have been marked with an exclamation mark in the upper right corner. When I mouse over the exclamation mark, the message appears: "Error writing metadata". When I click on this mark, I get the following message: "There was an unknown error while writing metadata to this photo. Retry?" Below the message there are two options I can click: "Import settings from disk" and "Retry Metadata Export". I don't understand what Lightroom is trying to tell me, nor what the consequences are of clicking these two options.

Dear all   Windows11 LrC 13.0.1   Step to reproduce.    1) Activate GPU. Select several photos with development. Export them. Look at your resource monitor for GPU   2) Deactivate GPU. Restart Lightroom. Select the same photos. Launch the same export    3) A warning message tells you that the GPU is deactivated and ask you if you want to activate to speed up export. Press cancel to keep it deactivated. Look at you resource monitor for the GPU. The GPU and GPU memory is used anyway    Kind regards

I am attempting to tether a Nikon Z9 using Lightroom Classic, but LRC can't detect the Z9.  I am able to download pictures from the Z9 to LRC all day long, and LRC successfully detects my Nikon D850 for tethering.  Nikon Z9 firmware is 4.0.  Mac iOs is 13.4.1.  LRC release is 12.4.  All are up to date.  Any ideas?

The modifiers Ctrl, Cmd, and Opt are incorrectly localized in the shortcuts Help for a number of commands, in all languages. For example, the German help shows the shortcut for Cycle Upright Mode as Ctrl + Tab, but it should be Strg + Tab.   In the listing that follows, lines have the form:   incorrect shortcut (correct shortcut) command (TranslatedStrings id)   For example:   Ctrl + Tab (Strg + Tab) Develop Module > Transform Upright > Cycle Upright Options ($$$/AgDevelopShortcuts/circle_upright_mode/Key)   This was generated by the Any Shortcut command in LR 13.1:   ---------------------------------------------------------------------------/Users/john/Desktop/plugins/anyshortcut.lrdevplugin/TranslatedStrings_Lr_en_US.txt:   Ctrl+Shift+Enter (Control + Shift + Enter) Workspace > Secondary Display > Loupe - Locked ($$$/MultiMonitor/LockedLoupeTooltip/ShortcutWin)Ctrl + Tab (Control + Tab) Develop Module > Transform Upright > Cyc

A keyboard shortcut assigned to Go To Folder In Library via TranslatedStrings will stop working after you go to Develop and back to Library.  This happens on LR 13.2 / Windows 11 but not Mac OS 14.4.1.   To reproduce:   1. Create the file C:\Program Files\Adobe\Adobe Lightroom Classic\Resources\en\TranslatedStrings_Lr_en_US.txt containing this one line:   "$$$/AgLibrary/Menu/Photo/GoToFolderInLibrary/Key=Cmd+Shift+y"     2. Start LR.   3. Go to Library Grid view and select All Photographs.   4. Select a photo and type Ctrl Shift Y. Observe that the current source correctly changes to the containing folder in the Folders panel.   5. Go to Develop.   6. Go to Library Grid view and select All Photographs.   7. Type Ctrl Shift Y and observe that the current source incorrectly remains All Photographs.   8. Restart LR.   9. With the same photo selected, type Ctrl Shift Y and observe that the current source correctly change

When the Fetch Altitude For Coordinates button in the Location tagset of the Metadata panel is pushed while in the Map module, it correctly sets Altitude but it doesn't display it in the Metadata panel. This appears to be an old bug filed in 2019 that didn't get migrated from the old feedback forum: https://community.adobe.com/t5/lightroom-classic-discussions/map-module-altitude-of-the-points-si-0-in-the-gps-coordinates-of-the-photos/m-p/10313076#M136897    To reproduce on LR 13.2 / Mac OS 14.2.1:   1. In Library, select a photo that doesn't have any assigned GPS coordinates.   2. In Map, drag the photo to the map. Observe that it gets assigned GPS coordinates but not Altitude (correct).   3. Click the Fetch Altitude For Coordinates button. Observe that the Altitude field remains blank (incorrect).   4. Go to Library and observe that the Altitude field is filled in (correct).   5. Go back to Map and observe that the Altitude field is filled in (correc

Hi, When trying to synchronize folders, Lightroom Classic treats differently folders having a special character (e.g., an a vowel with an accent). For example, on the folder "Mickaël", all pictures are treated as missing, and need to be removed then reimported. See screenshot below: Conversely, folders without special characters are treated normally. Note that this happens on all folders having special characters, which means around 12,000 photos are affected. Needless to say, I am not interested in doing a massive synchronization at this stage because of this problem.   I recently imported my catalogue from Lightroom 6 to Lightroom Classic CC. My photos are stored on a Synology NAS and mounted as SMB remote folders.   Thanks

[This post contains formatting and embedded images that don't appear in email. View the post in your Web browser.]   Auto-Stack By Capture Time sometimes stacks photos whose capture times are separated by more than specified by Time Between Stacks.  To reproduce:   1. Create a new catalog.   2. Make a copy of a raw.   3. Import the raw and its copy into the catalog.   4. Select the copy, do Metadata > Edit Capture Time, and change its time to one year earlier.   5. Do Photo > Statcking > Auto-Stack By Capture Time, with Time Between Stacks set at the default 0:08:00.    Observe that the the two photos are stacked, even though their capture times are separated by a year:     Doing Metadata > Save Metadata To File followed by Read Metadata From File and then auto-stacking doesn't avoid the bug.   I've observed that sometimes exporting the catalog as a new catalog avoids the bug, sometimes not.   A couple other

I have been doing bird photography and importing hundreds of images, and I rely on Embedded Previews for my intial triage/culling. I have ALL of the options for replacing embedded previews disabled (Idle time, etc). Yesterday, I imported 1400 photos into my Lr 11.2 catalog, and Lr built Standard Previews for every file. Sometimes, it leaves me a few Embedded Previews, but this is maddening.    The Embedded Preview feature is ideal for those of us who need to triage quickly, including viewing images at 1:1.   Not sure if there's something I'm missing, or if this is a bug in Lr 11. 

Issue:  Lightroom Classic Version Number: 13.1 OS Version Number: Windows 11 23H2 Steps to reproduce: Create a publishing service, e.g. publish to harddrive Manually put a single video into the corresponding collection Hit the publish button   Expected result: Video gets published to harddriveActual result: A warning dialog appears saying "This collection can't be updated. An internal error occurred: assertion failed!"   This took me a while to figure out. I'm a long time user of Jeffrey Friedl's Folder Publisher and all of a sudden it started failing with the above message. After quite some testing I found out that it didn't even get as far as starting the plugin, but failed on the collection itself. Then found out that it occurs only when I add a video and also for the regular publishing service that comes with Lightroom. I tried different video formats, doesn't seem to matter.  

When a Mac computer is set to a primary language and region not supported by LR (e.g. Hungarian/Hungary), and LR's Preferences > General > Language is set to Automatic (Default), LR fails to read the keyboard shortcuts in the file TranslatedStrings_Lr_en_US.txt even though the LR user interface is displayed in English and the English shortcuts are active.   This causes confusion for users of my Any Shortcut plugin, a disproportionate number of whom are running LR in unsupported languages with non-English keyboards (and thus want to adjust the English shortcuts that don't work well on their keyboards).   Tested on LR 13.2 / Mac OS 14.2.1. I haven't tested Windows, though it's very possible the same bug occurs there.  To reproduce:   1. In Mac Settings, General > Language & Region, set the Primary Language to be English (US) and the region to be United States, and restart the computer if the language and region get changed.   2. Create this

En el filtro por nombre de Biblioteca->Carpetas ignora los textos más allá del caracter 32.  PROPUESTA: Permitir filtrar por cualquier texto de los nombre de las capetas.

When searching for specific folders in the folder section of the Library module, the search engine is generally case insensitive, except when using letters with accents. Latest version of LRC used (13.2). Steps to reproduce: 1. Having a folder named "Saint-Étienne" (capital E with accent) 2. Search for "étienne" 3. No result found 4. Search for "Étienne" 5. Results found      

LR 13.2 won't save the current flag to XMP if the field XMP:Pick is missing from the file and no other metadata field has been changed in the catalog. To reproduce:   1. Download and open this tiny catalog: https://www.dropbox.com/s/1yvu2uib5uup416/pick-bug.2024.03.10.zip?dl=0   2. Select the one photo and do Photo > Set Flag > Flagged. Observe that the pick flag now appears on the thumbnail but Metadata Status is still Up To Date (incorrect)   4. Do Metadata > Save Metadata To File.   5. Run "exiftool -xmp:pick 7.jpg" and observe there's no output (incorrect).   6. Change the caption to "Hello world!". Observe Metadata Status is now Has Been Changed.   7. Do Metadata > Save Metadata To File and observe Metadata Status is now Up To Date.   8. Run "exiftool -xmp:pick 7.jpg" and observe the correct output:     Pick : 1       9. Do Photo > Set Flag > Unflagged and observe Metadata Stat

Since LR Classic v13.0 & 13.0.1, I cannot work in a collection anymore due to systematic crashes.

keyword:setAttributes() can't change the case of a keyword's name, e.g. from "a" to "A", even though the user can do that in the UI. To reproduce in LR 13.0.1 / Mac OS 14.1:   1. Download this tiny catalog:  https://www.dropbox.com/scl/fi/r17o9uf94v3plsr4i5yxs/keyword-name-bug.2023.11.29.zip?rlkey=wnvyv921uso57zqsq75w83eds&dl=0   2. Copy the script "keyword-name-bug.lua" from the catalog folder to the Scripts subfolder in the Lightroom settings folder.   3. Open the catalog in LR. Observe it has one keyword named "a".   4. Do Scripts > keyword-name-bug, which should rename that keyword to "A" and display "true". But observe the rename fails and it returns "false" (incorrect).   5. In the Keyword List panel, right-click the keyword, do Edit Keyword Tag, and change its name to "A", demonstrating that users can change the case of keywords.   6. In the Keyword List panel, rename the keyword to "x".   7. Do Scripts > keyword-name-bug, and ob

Lightroom Classic 13.2 (and also some erlier versions) Camera Raw 16.2MacOs 14.2.1   Hi,I found that sometimes Lightroom refused to export with an "unknown error"Other similar images did export.After some comparison I found out that when texture was applied to an image the error occurs.  

It is a display problem in the Japanese version   Click the bottom of the histogram to create a smart preview.There is an error in the message displayed at that time. After the capacity MB, there is "つ" left."つ" is a classifier for expressing 1 to 9.We don't use "つ" to indicate capacity.It seems that the expression used in the previous version remains even after the specification change.   I think that "つ" is difficult to use as a unit to represent the number of smart previews, so I think that "個" is better.