Connect with fellow editors in our Lr Classic community.
Recently active
I'm currently running Lightroom Classic 13.4 under Windows 11. In a previous version of Lightroom, I used to be able to change the justification of custom text overlays in a slideshow template by moving the anchor to the left, middle and right, but now all such text is left-justified no matter where I place the anchor. How do I fix this?
Issue: Lights Out mode causes screen to shrink a little Lightroom Classic Version Number: 13.3.1 OS Version Number: Sonoma 14.5 (23F79) Macbook Air 2022 - M2 Steps to reproduce: While Lighroom Classic is open on Laptop Monitor (laptop monitor only), pressing "L" causes the desktop size to shrink just a little. It appears the desktop as a whole will sit just below the laptop's camera. It will not go back to its normal size UNLESS Lightroom is not the primiary application selected. Pressing "L" to turn off "Lights Out" mode does not resolve the issue. It will remain unless I use one of the work arounds. My workarounds: Restart LR Making LR full screen, then windowed again Moving LR to a secondary monitor I attached a video of me switch applications with cmd+tab to show the odd bug that happens. Thank you for the help!
That's great that the SDK is still getting updated. The new log location, unfortunately, has not been updated in the LrLogger.html documentation - it still says it's in "My Documents". It would be great if that could be updated - I just spent 45 minutes trying to figure out why I can't find the logs any more...
After LR Classic 13.0 and update 13.0.1 Lightroom is behaving weird on my second monitor.Before I could use the compare mode on the second monitor when in the develop module on the first without any issues.Could zoom in and out on the comparisons.After the update this behaves odd. Sometimes it will zoom in and out as before but most of the time it doesn't and one of the selected pics for comparison won't even show (just black) or sometimes even zooms in at a different percentage compared to the other. This only occurs when in the Develop module. Switching from Compare to Loupe on the second monitor sometimes won't work either - display goes black. When I switch to the Library module on the first screen there's no issue. I've got a very robust Windows system with 32 GB of RAM and a NVIDIA GeForce RTX 3060 Ti 8GB of RAM which before (v 12.5) just did the job without any trouble. Seems like Adobe rushed to do this update but forgot to test it thouroughly.
自動補正を全体にかけハイライトやコントラス、彩度などの項目ごとの設定を同期するとチェックしていない項目がリセットされて0となってしまいます。 11.3.1のみこの状態となっており11.3では問題なく同期できました。
When I have several photos selected (two or more), and I "create a virtual copy" from the "Develop" or "Loupe" view, the current selected photo moves to the next or previous selection, rather than remaining on the newly created virtual copy. The new virtual copy appears, but I have to go back to it with each new virtual copy I create.
Lightroom Classic 14.1 crashes when I select seperate masks for one person (hair, eye, skin, etc).When I create one mask for the same entire person, it works fine.One more try to create seperate masks for one person, and Lightroom Classic quit.No compatibility issues, Mac OS Sequoia. System reports are sent.
I just upgraded my 16-inch M1 Macbook pro to Lightroom Classic 14.0. When I go in to crop overlay mode and try to incrementally shift the image right or left using the Option key plus right or left arrow keys, nothing happens; I get an audible feedback that it is not available. Using the up and down arrow keys with the Option key works just fine. I'm running Sonoma 14.6.1 I've rebooted my machine and the behavior persists. Thanks, Scott
Hey all, huge bug in crop tool in 14.0 LR classic. When I open the crop tool, it does not show the file I have chosen, but the one I edited before, until it switches to the file I actually want to edit. Very annoying, got to adjust lots of images and have to wait for like 3 seconds each time, before I can start to edit. Please fix this cheers, Stephan
This might be a bug in LRC, using v. 14.0.1 on MacOS 15.0. When I export a RAW file as a regular JPG with ProPhoto RGB profile and select "Limit File Size To:", LRC obeys the limit (say, 15,000 K). However, the moment I check "HDR Output" in that Export dialog box, LRC outputs a JPG that's much larger (in my case, 112 MB). (My original is a ~200 MB RAF raw file.) What's going on here? Why is LRC ignoring the filesize limit checkbox when outputting HDR profile images? Thanks.
LR 13.4 fixed most problems with the keyboard shortcuts shown in LR's built-in Help, but it introduced many new ones, most associated with the newly added Remove shortcuts. The most common problem is using the incorrect localization of key modifiers ("incorrect" meaning different than used in the rest of the Help): EN: Ctrl instead of Control FR: Ctrl instead of Contrôle IT: Ctrl instead of Control NB: Ctrl instead of Control NL: Ctrl instead of Control PL: \\ instead of \ PT: Ctrl instead of Control SV: Alternativ instead of Alt There are still some Help shortcuts with inconsistent case or spacing: EN: Command + Shift+ J EN: Command + Option+ Up Arrow RU: Shift+F SV: Ta bort instead of Ta Bort zh_TW: Alt+^U+2192 zh_TW: Option+^U+2192 zh_TW: Alt+^U+2190 zh_TW: Option+^U+2190 zh_TW: Command + Shift + J Full details are in the file "errors.txt" generated by the Any Shortcut plugin: ht
In LR 14, some of the in-program help entries for keyboard shortcuts in TranslatedStrings have extra spaces around the shortcuts, causing unaligned display in the help windows. For example, see below for what the Remove help looks like and what it should look like. Obviously not a significant impact on usability, but it looks sloppy, like the team doesn't take pride in its work, especially considering that it's so easy to run the Any Shortcut plugin to find these issues. (Note that the forum is removing extra spaces when I copy/paste the output from the plugin here.) es_ES: original: corrected: * (*, *): 290 Develop Module > Brush > Increase Brush Feather ($$
LR 13.5 incorrectly changed the TranslatedStrings keyboard shortcuts for Secondary Display > Loupe - Live to use invalid syntax for shortcut definitions. The shortcuts, defined by these ZString keys: $$$/MultiMonitor/LiveLoupeShortcut/Win $$$/MultiMonitor/LiveLoupeShortcut/Mac should be "Shift+Z" (no spaces). But instead they have these values: Note that the keyboard shortcut for Loupe - Live doesn't work on Mac but it does on Windows: https://community.adobe.com/t5/lightroom-classic-bugs/p-shortcut-shift-z-loupe-live-doesn-t-work-on-mac/idi-p/13201806
In LR 14.0, the in-program help for Remove on Mac incorrectly shows Backspace as the shortcut for Delete. On Mac, the key is called "Delete": For example, the Mac Library Shortcuts shows the correct name of that key (Delete): The offending line in TranslatedStrings is: "$$$/AgDevelop/Menu/Photo/DeleteSpot/Key=Backspace" It should be: "$$$/AgDevelop/Menu/Photo/DeleteSpot/Key=Delete" LR's convention is that occurrences of "Delete" in the help shortcuts in TranslatedStrings get translated to "Backspace" on Windows. For example: "$$$/AgLibrary/Help/Shortcuts/Remove_from_Library/Key=Delete" Windows LR help translates that Delete to Backspace before displaying it. But it appears for the Remove > Delete help, even after you change "Backspace" to "Delete", LR isn't calling the code to do that translation. So two mistakes: 1) TranslatedStrings has "Backspace" instead of "Delete", and 2) The code
In EN and ZH_TW, LR 14 uses "Ctrl" in the help for Cycle Upright Mode, though in those languages "Control" is used everywhere else in the program shortcut help. Screenshots of Help > Develop Module Shortcuts:
Command + Option + O doesn't toggle Remove > Detect Objects on Mac, though Control + Alt + O works on Windows. Tested on LR 14.0 / Mac OS 14.6.1, Windows 11. To reproduce: 1. In Develop, open the Remove panel and click on Mode: Remove. 2. Type Command + Option + O and observe that instead of toggling Detect Objects, it invokes View > Loupe Overlay > Show (incorrect). 3. Hover the mouse over Detect Objects and observe that Command + Option + O is advertised as its keyboard shortcut: 4. Click the "?" icon in the Remove panel and observe that Command + Option + O is advertised as the shortcut for Toggle Detect Objects: 4. Close the Remove panel and observe that Command + Option + O invokes View > Loupe Overlay > Show (correct)
The SDK method exportRendition:waitForRender() returns incorrect results for videos. The documentation says: For photos, it works correctly. But for videos, it returns "false, nil" even when the video is correctly exported. To reproduce: 1. Download and unzip this catalog: https://www.dropbox.com/scl/fi/g9ihjg69c85v8ets6h6kj/export-video-bug.2024-10-19.zip?rlkey=20fnn83lz8aao1bmii6pr4wlk&dl=0 2. Copy the file "export-video-bug.lua" from the catalog folder to the Scripts subfolder in the Lightroom settings folder. 3. Open the catalog in LR. 4. Do File > Export, right-click the preset folder User Presets, do Import..., and select the file "Video Test.lrtemplate" in the catalog folder. That is an export preset that will export video files to the Desktop. 5. Select one of the videos in the catalog and do File > Export With Preset > Video Test. Observe that the video is correctly exported to the Desktop. 6. Wi
if a dng file is created from pre-processing app (e.g. Topaz Photo AI), the returned DNG will show up correctly in Lightroom with all metadata intact. However, if this file is exported as jpg (all metadata included), the resulting jpg does not contain any exif data (no aperture, no exposure time, no lens info, no model ect). The original DNG can be found in this link (the file is too large to be attached): DNG The exported JPG is attached to this post.
When Export's Image Format is set to JPEG XL, the Export window doesn't remember that the previous setting of Bit Depth was 16 bits. Tested on LR 13.5.1 / Windows 11, Mac OS 14.6.1: 1. Reset LR's preferences. 2. Select a raw file and do File > Export. 3. In File Settings, set Image Format to JPEG XL and Bit Depth to 16 bits: 4. Click Done. 5. Do File > Export, and observe that Bit Depth has been reset to 8 bits/component (incorrect): 6. Change Bit Depth to 16 bits/component and click Export. 7. Do File > Export and observe that Bit Depth has again been reset to 8 bits/component (incorrect). 8. Change Bit Depth to 16 and click Export. 9. Do File > Export With Previous and observe that file size of the export from step 8 is quite a bit larger than that from this step. Use the "jxlinfo" command (on Mac, "sudo port install libjxl") to observe that the step 8 .jxl is 16-bi
Version: 14.0.1 Platform and OS Version: Windows 11 Pro 23H2 When exporting an HDR image from a plugin, one cannot turn off the maximum compatibility setting. This results in overly large files that are not yet widely processed correctly. The following creates a minimal (?) plugin that reproduces the problem. Expected: two exports are created, one with maximum compatibility off ("normal" HDR render) and one with maximum compatibility on (SDR + gainmap(?) render). Actual: two identical files are rendered. Info.lua: return { LrSdkVersion = 14.0, -- 13.0: HDR settings LrSdkMinimumVersion = 13.0, -- minimum SDK version required by this plug-in LrToolkitIdentifier = "name.stolle.martin.max_compat_repro", LrPluginName = LOC "$$$/PluginName=Max Compat Repro Plugin", -- Add the menu item to the Library menu. LrLibraryMenuItems = { { title = LOC "$$$/CreateNew=Trigger", file = "Tri
Sent xxxx.dng file with Lr develop edits to Ps as Smart Object. Various edits in Ps then Saved The Ps xxxx-Edit.tif file does not show any Ps edits in Lr Library module but does if I swich to Develop module Tried Sync Folder & metadata but no change Top image is visible in Ps & Lr Develop Lower image is Lr Library This problem has only occured since latest Ps & LrClassic updates Lr Classic V14.0.1 Cam Raw v17.0 Ps V26.0 Win 11 fully updated Nvidia Latest Drivers
LR 14 uses invalid keystroke syntax for the Next and Previous Variation commands in the TranslatedStrings files for 8 of the 16 languages. Instead of "Option+Right" and "Option+Left", for those languages it uses the localized translation, e.g. "Opzione+Sinistra". The incorrect lines: es_ES.txt:"$$$/AgDevelop/Menu/Photo/NextVariation/Key=Opción + derecha" es_ES.txt:"$$$/AgDevelop/Menu/Photo/PreviousVariation/Key=Opción + izquierda" it_IT.txt:"$$$/AgDevelop/Menu/Photo/NextVariation/Key=Opzione+Destra" it_IT.txt:"$$$/AgDevelop/Menu/Photo/PreviousVariation/Key=Opzione+Sinistra" ja_JP.txt:"$$$/AgDevelop/Menu/Photo/NextVariation/Key=Option+右向き矢印" ja_JP.txt:"$$$/AgDevelop/Menu/Photo/PreviousVariation/Key=Option+左向き矢印" ko_KR.txt:"$$$/AgDevelop/Menu/Photo/NextVariation/Key=Option + 오른쪽" ko_KR.txt:"$$$/AgDevelop/Menu/Photo/PreviousVariation/Key=Option + 왼쪽" nl_NL.txt:"$$$/AgDevelop/Menu/Photo/NextVariation/Key=Option+rechts" nl_NL.txt:"$$$/AgDevelop/Menu/Photo/PreviousVariati
Ligthroom Classic 7.5 Windows10 32 gig of memoryAll Photos is showing 4 gray thumbs that I can't delete. The thumbs are not in my folders, which shows a count of 4 fewer photos than all photos does. When I try to delete the 4 empty thumbs it prompts this error message: an internal error has occurred: ?:0: attempt to index field 'rootFile' (a nil value). Also, the thumbs show no metadata, and a right click to locate in the folder in library returns no results.I have disabled all plugins, no change, synchronize photos, no change, find missing photos, no change. I searched the forum, and the web andhave not found a solution. Any help would be greatly appreciated. Bob
Issue: Lightroom's Panorama merge feature is adding a strange and changing color tint to the final merged photo. The photo looks fine when viewing the preview for different panorama merge types, but once selected, the merged photo comes out with an odd tint. Lightroom Classic Version Number: 13.1 OS Version Number: macOS Sonoma 14.2.1 (23C71) Steps to reproduce: Select a few photos to merge (11 in my case) Select cylinder projection merge, auto crop, and merge View merged photo Expected result: Actual result:
Hello, Working with LRC 12.3, I've noticed an odd behavior of the mouse pointer a number of times now, but I can't really figure out the exact conditions and how to reproduce it (yet). I'm posting here just to see if anyone else is experiencing this. For example: when I'm zoomed in, the mouse pointer only shows the "Hand" symbol (to move the zoomed area around) while I make movements (with my mouse); when I don't move it, it reverts to the normal pointer. similary, when I'm using the Brush with a local adjustment, it only shows the brush as pointer while I move it; when I don't move it, it reverts to the normal pointer. I hope this description makes sense. My system is a 2019 27" iMac with 40GB memory, Radeon 580X 8GB. If it's of any importance, I'm running the iMac's 27" screen scaled, at 2880 x 1620 instead of its native 2560 x 1440, but this behavior is new to Lightroom Classic 12.3 and did not occur in version 12.2.1
Remix with Firefly Community Gallery
Thousands of free creations to fall in love with and remix in Firefly.
Already have an account? Login
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.