Bug Reports

I've posted this as a comment in another bug, but thought it would be best, to open a seperate issue. My Problem is the Following: Since the Update to 13.3, applying presets to an unedited picture in the develop tab randomly does not affect the custom curve saved within that preset. Also the preset is not shown as applied, so I can't change the intensity of the preset. When I change to another picture and then back to the one I applied the preset to, the correct curve is shown, but has no effect on the image. I need to manually change the curve a little bit, and wooosh it's applied. Another option is to apply a different preset and then switch back to the one, I wanted to apply in the first place. I have had performance issues (RAM leaking, slow downs etc) for years and it's annoying, but at least I can get rid of those by restarting every 30 or so minutes. But this just slows me down so much it's painfull. For reference, I've attached 2 Screenshots. This right here is how the picture

The map module in Adobe Lightroom Classic v12.3 will not load Google Maps correctly. Error message: "See the JavaScript console for technical details." 

The smart-collection operator "is empty" doesn't work for Alt Text and Extended Description. To reproduce in LR 13.3 / Mac OS:   1. Download and open this tiny catalog: https://www.dropbox.com/scl/fi/3d1gd67l2fmkrqjtc16sh/smart-collection-empty-bug.2024.05.29.zip?rlkey=24brlsqla8mh5mla0tv4gmid0&dl=0   The catalog has two photos, "empty.jpg" with all blank metadata fields and "non-empty.jpg"  with Alt Text, Extended Description, and other text fields non-empty.   2. Observe that the smart collections "Alt Text is empty" and "Extended Description is empty" contain no matching photos -- they should contain one each:  

LR 13.3 fixed most of the keyboard shortcuts displayed in Help having incorrect localizations and inconsistent spacing and case, but it introduced many new errors.   Most are for the new commands Generative AI and Object Aware, using the wrong localizations for Command and Control instead of the ones established for each language:   EN: Cmd instead of Command, Ctrl instead of Control DE: Cmd instead of Befehl, Ctrl instead of Str ES: Cmd instead of Comando, Ctrl instead of Control FR: Cmd instead of Commande, Ctrl instead of Contrôle IT: Cmd instead of Comand, Ctrl instead of Control JP: Cmd instead of Command KO: Cmd instead of Command, Ctrl instead of Control NB: Cmd instead of Kommando, Ctrl instead of Control NL: Cmd instead of Command, Ctrl instead of Control PL: Cmd instead of Command, Ctrl instead of Control PT: Cmd instead of Command, Ctrl instead of Control RU: Cmd instead of Command, Ctrl instead of Control SV: Cmd i

The Map module command Map > Tracklog > Set Tracklog Time Offset always shows the wrong starting date/time for a tracklog, 12/31/00 4:00 PM PST (which is represented internally as the number 0).  LR 13.1 and prior versions showed the correct starting date/time.  Tested on LR 13.2 / Mac OS 14.4.1.   For example, download this tracklog: https://www.dropbox.com/scl/fi/j76cd3q3aavr3fz8hhnz4/Big-Lake-2023-Tracks.gpx.20234.05.04.zip?rlkey=ow8vsa0wn3bl1hfyo2pgk837l&dl=0   and load it into the Map module. Observe that in LR 13.2, the Set Tracklog Time Offset command displays the incorrect starting date/time:   But LR 13.1 displays the correct date/time:  

Photographed in RAW (CR3) format with Tokina AT-X PRO D 100mm F2.8 Macro and Canon EOS R6 MarkII. Select Edit in Photoshop from Lightroom Classic (13.2).White lines may appear on images imported into Photoshop.There are images where white lines are displayed and images where they are not.   When I pressed "Edit in Photoshop" on the same image in Lightroom (7.2), the white line did not appear. Lightroom Classic(13.2)、Photoshop（25.7）、CameraRAW（16.2.1） Japanese version（Win11）

When you export a JPEG with a watermark, the thumbnail embedded in the JPEG doesn't contain the watermark. This causes the Windows 8.1 File Explorer to show thumbnails of the exported pics without a watermark, confusing users who are checking to ensure their pics were properly marked. (It appears that the OS X 10.10 Finder doesn't use the embedded thumbnails, so watermarks show up in Finder thumbnails.)To reproduce, export a JPEG with a watermark, using these export options: Image Format: JPEG, Quality: 60, Include: All Metadata, Watermark with PNG watermark. Open Windows 8.1 File Explorer on the containing folder and do View > Extra Large Icons to view the folder's files as thumbnails. Note that the thumbnail of the exported pic doesn't show a watermark. Use Exiftool to extract the embedded thumbnail: exiftool -b -thumbnailimage myfile.jpg > thumbnail.jpg The extracted "thumbnail.jpg" is missing the watermark. Setting Limit File Size To: 100,000K (100 MB) avoids embedding a thum

I'm using Lightroom Classic on an M3 Macbook Pro running OS X 14.5. Since upgrading to Lightroom 13.3, searching in the Map module seems to have stopped working. When I enter a search location and hit Enter, the message "Searching" pops up for a moment, then disappears. The map remains unchanged; it does not move or place a marker at the searched-for location.   I am able to apply GPS coordinates successfully from Saved Locations. I'm able to use Google Maps in a browser without problems (so I know that my network connection to Google Maps isn't getting blocked). I have tried the "Switch to Library, then quit Lightroom, then re-open Lightroom" procedure that was a fix for some Map problems in earlier versions, but that doesn't resolve the issue. Multiple restarts of Lightroom have not resolved the problem.   STEPS TO REPRODUCE 1. Open Lightroom 2. Switch to the Map module. 3. Type in a findable location in the search field. 4. Hit Enter   EXPECTED BEHAVIOR Map should shi

I have been, successfully, trying out linear profiles in LRC. They are very helpful for certain images. The problem is, when the image is posted to LR Mobile.First, while reviewing the images, I get a pop up message that editing in Mobile will lose settings as it is not a standard profile. That would be ok, as I was just using LRM to display the images. The problem is, the image is not rendered as it was with the original linear profile…it is much brighter and washed out as if another profile (tone curve) had been used.I had a mix of ‘Adobe Neutral’ and linear profile images. The ‘AN’ images rendered as shown on LRC, the linear were washed out.LRC 10.4, Win 10Is this a bug or ‘as designed’?

In LR 13.3, Library Grid view incorrectly sorts file names with leading punctuation, and the Keyword List panel incorrectly sorts keywords with leading punctuation.  The Folders and Collections panels and the Metadata browser's Keyword column all sort correctly.  In contrast, LR 13.2 sorted all those correctly.   This is more than an inconsequential nit -- many users find it helpful for Library to use the same file-name ordering as Finder and File Explorer, and many use the common convention of prefixing a name with "_" to have it appear at the top of the list.  For example, my Any Tag plugin creates a top-level keyword "_Any Tag To Delete" that should appear at the top of the Keyword List. And obviously, it's an imposition on users to use one ordering in the Keyword column and another in the Keyword List.   To reproduce on Mac OS 14.4.1 (I haven't tested on Windows):   1. Download and unzip this tiny catalog folder, which contains the LR 13.2 catalog "sor

LR Classic 13.3 reads incorrect GPS coordinates (54°35'51" N 5°0'0" W) from this video: https://www.dropbox.com/scl/fi/brfy2bj001zh4uemo0k4t/gps-bug.2024.05.29.mp4?rlkey=wbngt05sl4ms4w1pftod2iz67&dl=0   while LR 7.3 and Exiftool agree on 54°35'51" N 5°55'48" W.  Exiftool shows the internal representation agreeing with what little is published of that part of the standard (outside of the ISO docs that cost hundreds of dollars).   1. LR Classic 13.3:     2. In LR 7.3:     3. Exiftool:     $ exiftool -a -G -gpscoordinates gps-bug.2024.05.29.mp4 [QuickTime] GPS Coordinates: 54 deg 35' 51.00" N, 5 deg 55' 48.36" W $ exiftool -m -b -gpscoordinates gps-bug.2024.05.29.mp4 | od -c -t u1 0000000 5 4 . 5 9 7 5 - 5 . 9 3 0 1 53 52 46 53 57 55 53 32 45 53 46 57 51 48 49    

Hi, I am trying to set up a simple slideshow for a forthcoming major family event. But every time it crashes after several minutes of being fine. I send an error report in.... I have checked my IBM (Dell) laptop's power management settings and screensaver to ensure they will not hang on power - but it keeps failing. Windows 11 Pro OS. Really disappointing. Any tips welcome! thanks.

Hi, I have recently experienced LR crashing while I am deleting photo's from the tray. I have already edited & sync'd the files, it's when I scroll through & delete files I don't want is when the crash occures. It's not every deletion but random. I have been doing this process for years without issue. I am noticing that as I delete a file & another enters the tray it does not instantly load & crop to the sync'd file. Maybe this is creating the issue by deleting too fast?? 

LR Classic 12.0.1 macOS Ventura 13.0.1   Steps to reproduce: Create a Published Folder in a Hard Drive Publish Service. Add one or more photos to that folder. Publish the photos. Check the name and contents of the folder in Finder (everything is fine at this point). Rename the Published Folder in LR Classic.   Expected Result: The original folder has been renamed by LR Classic in Finder as well. Actual Result: The original folder has not been renamed in Finder!   Additional Remark: When re-publishing the photos of the renamed Published Folder, LR Classic creates a new folder with those photos in Finder, and leaves the original folder (the one with the original name in LR Classic) alone.  

The Accessibility fields Alt Text and Extended Description in the Metadata panel's IPTC tagset were added to LR 13.1, but the implementation is incomplete:   1. In the Library Filter bar and smart collections, they aren't searchable via Any Searchable Field, Searchable Metadata, or Searchable IPTC (like the other fields in the IPTC tagset).   2. In the SDK, the method photo:getFormattedMetadata() doesn't support the keys "altTextAccessibility" and "extDescrAccessibility".   3. The Lightroom Classic Programmers Guide should document the tagset field ids "com.adobe.altTextAccessibility" and "com.adobe.extDescrAccessibility", in two sections:   Token Patterns (page 62) Custom Metadata Tagset Example (page 77)

Local-adjustment presets saved with default tone curves won't reset tone curves back to the default values.   To reproduce on LR 13.1 / Mac OS (see the attached recording):   1. Make a Linear Gradient mask.   2. Save a local-adjustment preset named Clear.   3. Change every setting in the local-adjustment panel, including the tone curves.   4. In the Preset menu, select Clear.   5. Observe that every local-adjustment setting has been reset back its default value except for the tone curves.

If you've applied a local-adjustment preset X to a mask and then use the local Point Color tool, the preset menu doesn't change to show X (edited), and you can't update X with the current settings.   To reproduce in LR 13.1 / Mac OS (also see the attached screen recording):   1. Create a Linear Gradient mask.   2. Set the mask Exposure = -4.   3. Save as a local adjustment preset X.   4. Change any other local adjustment other than Point Color, and observe that Preset: changes to X (edited).  Resetting that adjustment to its default value changes Preset: back to X. 5. With Point Color, use the eye dropper to select a color. Then change all of its sliders to non-default values.   8. Observe that Preset: still shows X rather than X (edited), and the Preset menu won't let you update X with the current settings. This is incorrect.

"Date" is one of the filter options in Lightroom Classic's library module.  When I take a raw file (with all date fields) and "Edit in Adobe Photoshop 2024", the file that is returned to Lightroom shows up as "Unknown" in that date filter.  A "sync" operation between the old and new files is needed to restore the date information.   This has been an issue for a few months, and wasn't fixed in the last update.   Running LR Classis 13.1, Photoshop 25.3.1, on Windows 10

Apple ProRaw images taken in Apple's camera app on my iPhone 14 Pro generally work well in LrC these days, which is great. In LrC I often use the "Apple ProRaw" profile.   When I perform a panorama merge of these images, however, LrC reports that the resulting .dng file is using the profile "Apple Embedded Color Profile" but shows an exclamation mark: "Profile missing." See attached screenshots.   I wonder if this is an inadvertent result of LrC's rule that only Apple ProRaw files have the option of the LrC ProRaw profile, and that the merged file is not recognized by LrC as a ProRaw file. Can this please be improved, or is there a workaround?   Thanks, Wallace

The new Metadata panel Last Exported Date field doesn't always match the corresponding History step. This occurs when the photo is exported in one time zone and LR is currently running in another.    To avoid confusion, the Last Exported Date field should always show the date shown in the History step. This would be consistent with how LR handles capture time, always showing the time in the time zone when the photo was captured, regardless of the computer's current time zone.   See this very small catalog for an example: https://www.dropbox.com/scl/fi/8ri9yej3y9pj5k8f5e1gl/exported-date-bug.2024.05.23.zip?rlkey=dx2ppke4b0m6ono8j5h3bn1md&dl=0      Test in LR 13.3 / Mac OS 14.4.1.

In French, Window > Secondary Display > Loupe - Live has invalid keyboard shortcuts defined in TranslatedStrings_Lr_fr_FR.txt:   "$$$/MultiMonitor/LiveLoupeShortcut/Mac=Maj+Z" "$$$/MultiMonitor/LiveLoupeShortcut/Win=Maj+Z"     Localized versions of key modifiers ("Maj") aren't allowed in shortcut definitions. Those lines should be:   "$$$/MultiMonitor/LiveLoupeShortcut/Mac=Shift+z" "$$$/MultiMonitor/LiveLoupeShortcut/Win=Shift+z"   (Note the lower-case "z".)   Tested on LR 12.0.

When looking at photogaph information under metadata, the fractions shown for shutter speed are too small. They appear to be about 3 point type. Is there any way to change the style so they're more legible (e.g. 1/3) or increase their size. This is on MacOS and the font preferences are already set to large. "Use typographic fractions" is unchecked, but seems to make no difference. The screen shot below is much bigger than actual size, but these are the fractions I'm talking about.  

In Help > Develop Mode Shortcuts, LR 13.2 added Cycle Upright Mode under the View Shortcuts heading, whereas it should be under the Mode Shortcuts heading. The View Shortcuts section contains commands controlling what is displayed, while Mode Shortcuts has all the commands for controlling the editing tools such as Enter Healing Mode and Cycle Heal Type. It's inconsistent to have Cycle Upright Mode in one section and Cycle Heal Type in the other:    

The GPS-Positioning doesn't work anymore. I have installed the latest version of Lightroom Classic. When I start allocating GPS-Positions on the map, nothing happens. When I restart Lightroom it works for one or two images and then it stopps working again. I've never had any issues with GPS-Positioning before. So, I wonder what the problem is. Edit 05.02.2024: Please refer to my failure description in my comment below..... I am on LRC-Version 13.1 and MAC OS 14.3!

Running 13.1 on intel iMac, Sonoma.  Grab the eyedropper for white balance and the loupe window gets stuck on the first color it touches.  Still can pick different spots to change WB, but the loupe never changes as you move around image.  This is new since Sonoma upgrade.  Restarts, etc., did not resolve.