• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
2

P: Develop zoom interpolation algorithm incorrectly including input pixels from outside the crop bou

LEGEND ,
Oct 12, 2021 Oct 12, 2021

Copy link to clipboard

Copied

[Update: The bug is caused by the Develop zoom interpolation algorithm incorrectly including input pixels from outside the crop boundary.  See here:

https://community.adobe.com/t5/lightroom-classic-bugs/small-display-glitch-in-develop/idc-p/12456139...]

 

Develop at Fit zoom shows a small glitch on the bottom edge of a LR-made panorama.  The glitch appears at zooms of 25% and smaller but disappears at zooms 33% and larger. Disabling the GPU has no effect. The glitch doesn't appear in Library Loupe at any zoom. LR 10.4 / Mac OS 11.6. 

 

Here's the offending DNG:

https://www.dropbox.com/s/1nu6fvp9d26lmn0/DSC00452-Pano.dng?dl=0 

 

Screen Shot 2021-10-12 at 6.45.13 PM.png

Screen Shot 2021-10-12 at 6.45.28 PM.png

Bug Started
TOPICS
macOS

Views

505

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines

correct answers 1 Correct answer

Adobe Employee , Oct 30, 2021 Oct 30, 2021

Changing status to started

Status Started

Votes

Translate

Translate
21 Comments
Adobe Employee ,
Oct 14, 2021 Oct 14, 2021

Copy link to clipboard

Copied

Hi there,

I'm not able to see the problem at my end. Also, the issue is not clear in the screenshots. Would you mind telling us what exactly are you seeing at your end?

Is it possible to record a video and share it here?

You may also try resetting Lightroom's Preferences and let us know if that helps: 

https://helpx.adobe.com/lightroom-classic/help/setting-preferences-lightroom.html

 

Regards,

Sahil

Votes

Translate

Translate

Report

Report
LEGEND ,
Oct 14, 2021 Oct 14, 2021

Copy link to clipboard

Copied

You can see the screenshot at full resolution by clicking it, then right-clicking it and saving it to your computer.  Here's what the relevant portion looks like:

johnrellis_0-1634250149891.png

 

As described above, that small glitch only appears at zooms of 25% and smaller, including Fit zoom.

Votes

Translate

Translate

Report

Report
LEGEND ,
Oct 14, 2021 Oct 14, 2021

Copy link to clipboard

Copied

Resetting preferences (and changing the background to Darker Gray) doesn't help -- the small glitch is still there at zooms 25% or smaller:

 

johnrellis_0-1634251015750.png

 

 

 

 

Votes

Translate

Translate

Report

Report
LEGEND ,
Oct 14, 2021 Oct 14, 2021

Copy link to clipboard

Copied

Lightroom Classic version: 10.4 [ 202108071231-af9219b9 ]
License: Creative Cloud
Language setting: en
Operating system: Mac OS 11
Version: 11.6.0 [20G165]
Application architecture: x64
Logical processor count: 16
Processor speed: 2.4GHz
SqLite Version: 3.34.0
Built-in memory: 32,768.0 MB
Real memory available to Lightroom: 32,768.0 MB
Real memory used by Lightroom: 3,330.7 MB (10.1%)
Virtual memory used by Lightroom: 16,135.6 MB
Memory cache size: 2.9MB
Internal Camera Raw version: 13.4 [ 872 ]
Maximum thread count used by Camera Raw: 5
Camera Raw SIMD optimization: SSE2,AVX,AVX2
Camera Raw virtual memory: 841MB / 16383MB (5%)
Camera Raw real memory: 926MB / 32768MB (2%)
Displays: 1) 2560x1440

Graphics Processor Info:
Metal: AMD Radeon Pro Vega 20

Votes

Translate

Translate

Report

Report
LEGEND ,
Oct 14, 2021 Oct 14, 2021

Copy link to clipboard

Copied

The glitch also occurs on my LR 10.4 / Windows 10 (in a virtual machine, thus not using the GPU):

 

johnrellis_0-1634251778134.png

 

Lightroom Classic version: 10.4 [ 202108071231-af9219b9 ]
License: Creative Cloud
Language setting: en
Operating system: Windows 10 - Home Premium Edition
Version: 10.0.19043
Application architecture: x64
System architecture: x64
Logical processor count: 16
Processor speed: 2.4GHz
SqLite Version: 3.34.0
Built-in memory: 16383.5 MB
Real memory available to Lightroom: 16383.5 MB
Real memory used by Lightroom: 3375.0 MB (20.6%)
Virtual memory used by Lightroom: 3918.6 MB
GDI objects count: 967
USER objects count: 2724
Process handles count: 1987
Memory cache size: 72.7MB
Internal Camera Raw version: 13.4 [ 872 ]
Maximum thread count used by Camera Raw: 5
Camera Raw SIMD optimization: SSE2,AVX,AVX2
Camera Raw virtual memory: 2132MB / 8191MB (26%)
Camera Raw real memory: 2207MB / 16383MB (13%)
System DPI setting: 96 DPI
Desktop composition enabled: Yes
Displays: 1) 2560x1440
Input types: Multitouch: No, Integrated touch: No, Integrated pen: No, External touch: No, External pen: Yes, Keyboard: No

Graphics Processor Info:


Application folder: C:\Program Files\Adobe\Adobe Lightroom Classic

Votes

Translate

Translate

Report

Report
LEGEND ,
Oct 17, 2021 Oct 17, 2021

Copy link to clipboard

Copied

John, I downloaded the panorama DSC00452-Pano.dng file and can see the artifact on my Windows 10 system using LrC 10.4. Looking at the uncropped image in PS at 1200% zoom there is a 1 pixel stairstep artifact visible along the bottom edge. The crop line is right across this 1 px stairstep. Did you use Auto Crop in the Panorama Merge settings? The Develop module uses a simpler zoom interplation algorithm, which is creating the artifact. The Library module's more accurate zoom interpolation does not reveal the artifact.

 

I'm not sure what's creating the stairstep in the panorama DNG file, but the simplest solution is to just manually reset the bottom crop line up a few pixels.

Stairstep.JPG

 

Stairstep-2.JPG

 

 

 

 

Votes

Translate

Translate

Report

Report
LEGEND ,
Oct 17, 2021 Oct 17, 2021

Copy link to clipboard

Copied

Excellent observation about the lower edge of the auto-cropped panorama.  However, the bug is not related to the  differences between the interpolation algorithms of Develop and Library -- rather, the interpolation algorithm is incorrectly incorporating pixels outside of the crop boundary. An interpolation algorithm should only use as input those pixels that lay within the crop boundary.

 

There would be no significant performance penalty to fixing this bug. To see why, consider this screenshot from Develop of a simple example 4000 x 4000 TIFF, with a 1-pixel white "notch" along the bottom edge, cropped to 4000 x 3999 to exclude the notch:

johnrellis_0-1634509996631.png

(Click the image and then right-click it to download to your computer, so you can zoom in on the bottom edge.) In Develop at zooms less than about 53%, the notch still appears.

 

Now consider this screenshot from Develop of a 4000 x 3999 TIFF exported from the cropped original:

johnrellis_1-1634510318329.png

Of course, Develop correctly displays this at all zoom levels. Surely a fixed Develop interpolation algorithm could display a 4000 x 4000 image cropped to 4000 x 3999 just as fast as it can a 4000 x 3999 image.

 

You can download these two sample images from here:

https://www.dropbox.com/s/x56ddobaob5tv0j/crop-display-bug.2021.10.17.zip?dl=0

Votes

Translate

Translate

Report

Report
LEGEND ,
Oct 17, 2021 Oct 17, 2021

Copy link to clipboard

Copied

"the interpolation algorithm is incorrectly incorporating pixels outside of the crop boundary. An interpolation algorithm should only use as input those pixels that lay within the crop boundary."

 

I hear what you're saying, but with your DSC00452-Pano.dng file both the Develop module and Library module previews show the same pixel dimensions using screenshots compared in PS using layers. If the Develop module was incorrectly incorporating pixels outside of the crop boundry wouldn't its height dimesnion be larger (i.e. 3116 vs 3115)? I agree this can probably be fixed, but just not sure what's actually causing it. Perhaps a rounding error soemwhere.

Votes

Translate

Translate

Report

Report
LEGEND ,
Oct 17, 2021 Oct 17, 2021

Copy link to clipboard

Copied

[This post contains formatting and embedded images that don't appear in email. View the post in your Web browser.]

 

By "incorporating pixels outside of the crop boundary", I mean that when the interpolation algorithm computes a pixel value inside the crop boundary, its using as input to the interpolation the values of pixels that are outside the crop boundary. 

 

For example, here's the bottom edge of a 4000 x 4000 TIFF shown in Photoshop, with the pixels in row 3999 (the bottom row) changing from green to white to blue:

johnrellis_0-1634517128584.png

 

I cropped that image to 4000 x 3999, cropping out the last row of pixels. Here's a closeup of how the new bottom edge displays in Develop at 21.4% zoom:

johnrellis_2-1634517359338.png

 

The interpolation of the bottom edge in the cropped image has used the values of the pixels in row 3999 (the last row of the original image), even though row 3999 is outside the crop boundaries.

 

Why is that wrong?  Develop's display of a cropped image should always match that of the exported image, reimported into Develop.

 

Another way to think about this: LR is currently zoom-interpolating the image first, then cropping the result.  It should crop first, then zoom-interpolate. 

 

 

 

 

 

 

 

 

Votes

Translate

Translate

Report

Report
LEGEND ,
Oct 18, 2021 Oct 18, 2021

Copy link to clipboard

Copied

"Another way to think about this: LR is currently zoom-interpolating the image first, then cropping the result. It should crop first, then zoom-interpolate."

 

John, that appears to be the case. What I'm also seeing on my Windows 10 system with LrC 10.4 is that the artifact does not appear when 'Use Graphics Processor' is set to Off. However, if I just uncheck 'Use GPU for image processing' the artifact is present. So it appears the artifact is being created in the GPU display output path only, at least on Windows 10. Regardless of the cause it should be fixed.

 

I've noticed other anomalies due the "order" that Develop settings are being applied. It appears the local adjustments are applied before the global adjustments. For example this causes the new Color Range mask tool to create an edge artifact when the shooting lens has visible color aberrations. This is because the 'Remove Chromatic Aberration' and 'Defringe' controls are being applied after the local controls. This causes the Color Range Mask tool to create additional color fringing, which can't be removed by the local controls. Feedback from Rikk Flohr is that Adobe Engineering has stated it will require a new process version to fix it. Hopefilly they can also fix this issue if and when a new process version is created.

 

https://feedback-readonly.photoshop.com/conversations/camera-raw-and-dng/lightroom-and-camera-raw-co...

 

 

Votes

Translate

Translate

Report

Report
LEGEND ,
Oct 18, 2021 Oct 18, 2021

Copy link to clipboard

Copied

[This post contains formatting and embedded images that don't appear in email. View the post in your Web browser.]

 

"What I'm also seeing on my Windows 10 system with LrC 10.4 is that the artifact does not appear when 'Use Graphics Processor' is set to Off."

 

Interesting. On closer examination, I see that on my Mac, the artifact is more noticeable with the GPU on but still present with it off:

johnrellis_0-1634586825269.png

johnrellis_1-1634586864053.png

 

 

Votes

Translate

Translate

Report

Report
LEGEND ,
Oct 18, 2021 Oct 18, 2021

Copy link to clipboard

Copied

[This post contains formatting and embedded images that don't appear in email. View the post in your Web browser.]

 

Something curious I noticed while investigating this: the Photo Merge > Panorama algorithm is stochastic (incorporating random sampling), producing a slightly different merge each time I run it on the same three input photos. Here are the sizes for five successive merges (Cylindrical, Auto Crop) for the example above:

 

johnrellis_0-1634587845092.png

 

I'm guessing the merge algorithm probably uses some sort of random sampling of different overlapping positions of the photos to narrow down to a good set of positions.  That would make sense, though it would be a tiny bit better if the algorithm used the same starting seed for its random number generator (e.g. a seed based on the hash of the photo), so that the results would be identical each run.  I've done hundreds of panorams and never noticed this before.

 

Votes

Translate

Translate

Report

Report
LEGEND ,
Oct 18, 2021 Oct 18, 2021

Copy link to clipboard

Copied

@Sahil.Chawla , as you can see, we've narrowed down the conditions of this bug, so it would be great if you could file a bug report, thanks.

Votes

Translate

Translate

Report

Report
LEGEND ,
Oct 18, 2021 Oct 18, 2021

Copy link to clipboard

Copied

I'm seeing similar results when running the same set of image files through Photo Merge Panorama multiple times. Interestingly I'm also seeing stitching errors on some of the merges, but not on others. The selection and matching of control points is using some random sampling algorithm. You can't manually fine-tune the control points, but you can run the merge multiple times and perhaps catch and correct stitching errors. I guess it's an undocumented feature....oh boy!

Votes

Translate

Translate

Report

Report
LEGEND ,
Oct 19, 2021 Oct 19, 2021

Copy link to clipboard

Copied

John and @Sahil.Chawla I've submitted a bug report for this issue.

Votes

Translate

Translate

Report

Report
LEGEND ,
Oct 19, 2021 Oct 19, 2021

Copy link to clipboard

Copied

Thanks.

Votes

Translate

Translate

Report

Report
Adobe Employee ,
Oct 30, 2021 Oct 30, 2021

Copy link to clipboard

Copied

Changing status to started

Rikk Flohr - Customer Advocacy: Adobe Photography Products
Status Started

Votes

Translate

Translate

Report

Report
LEGEND ,
Nov 18, 2021 Nov 18, 2021

Copy link to clipboard

Copied

John, can you please upload the original files used to create the panorama to Dropbox. Also let us know what Panorama Merge settings you used. Adobe Engineering wants them for further investigation. Thank you.

Votes

Translate

Translate

Report

Report
LEGEND ,
Nov 18, 2021 Nov 18, 2021

Copy link to clipboard

Copied

Here's a much simpler example of the bug, a 4000 x 4000 all-black TIFF with a "notch" of a single row of white pixels along the bottom. It's been cropped to 4000 x 3999, with the bottom row of pixels (including the notch) cropped out.  The LR crop settings are saved in the TIFF, so when you import it, you'll import the crop:

https://www.dropbox.com/s/r7dh7trp9t2i1vm/crop-display-bug-square.2021.11.18.tif?dl=0 

 

Even though the notch of white pixels has been cropped out, it still appears in Develop at 50% zoom:

johnrellis_0-1637255142594.png

Votes

Translate

Translate

Report

Report
LEGEND ,
Nov 18, 2021 Nov 18, 2021

Copy link to clipboard

Copied

[This post contains formatting and embedded images that don't appear in email. View the post in your Web browser.]

 

As I explained in my previous reply, the bug can be simply demonstrated completely independent of panoramas. I'm afraid that engineering might go down the wrong rabbit hole by looking at the original panorama that demonstrated the bug, rather than the much simpler test case illustrating the core bug.

 

Nevertheless, here is a folder with the original photos and the panorama created with these options:

https://www.dropbox.com/s/nszmjh1hjmpvce5/crop-bug-display-bug-pano.2021.11.18.zip?dl=0 

johnrellis_0-1637256418675.png

 

Here is the notch artifact displayed in Develop at 50% zoom:

johnrellis_1-1637256546798.png

 

 

 

Votes

Translate

Translate

Report

Report
LEGEND ,
Nov 18, 2021 Nov 18, 2021

Copy link to clipboard

Copied

LATEST

Thank John. I have forwarded this information in the bug report to Adobe Engineering.

Votes

Translate

Translate

Report

Report