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

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

[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 

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

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:

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.

Thanks.

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

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!

@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.

[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:

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.