Error in Auto Levels function

[FotoSteffen]

Hello together,

I think I found a serious bug in the Auto Levels function. The bug I'd describe as follows, and to prove it, I'll add some images. I already reported this bug to Affinity support some time ago, but they weren't able to follow my bug description, sorry. And any Affinity Photo updates since then did not contain any bugfix for this issue. Therefore I'm reporting the error here in the forum, looking for confirmation.

Bug overview (my interpretation): If you load an image / photo into Affinity Photo, and perform a crop and after that an Auto Levels operation, then the Auto Levels function calculates the White balance correction based on the FULL image (initially loaded), not on the cropped image cutout.

Test case: To reproduce my presumption let my provide some files and the steps I performed in AP. I provide the "source" file (the first one) as PNG, and the resulting files as JPG to save space.

Source file:

This is an old, yellowed photo I scanned (and resized and blurred for the test case). If you download it, you can see that it has an uncropped white border, which is the background from the flatbed scanner's lid. This means, the photo is yellowish, but the scanner lid adds some more or less neutral white component to the whole image. Now let's do it wrong and perform Auto Levels directly:

As one would expect, the Auto Levels performs only little correction, because the scanner's lid provides enough neutral white, so there's nothing to correct.

Now we close everything in Affinity Photo and reload the first image. Let's cut away the white margin of the photo (crop function), leaving only the yellowish content over.

Before continuing, save this cropped image as separate file to disk (PNG, .afphoto, JPG, doesn't matter). We'll need this working copy later below.

As there is no "scanner lid white" anymore in the visible area, we'd expect the white balance correction to be way more aggressive. But, this is the result of the Auto Levels, directly performed after saving our working copy:

As you can see, no real improvement.

Now close the open files in Affinity Photo and open our already cropped working copy from above. After opening, apply Auto levels to this newly opened image (where Affinity Photo has no  traces of the cropped white content in its history buffer). And that's the result:

This is what I actually expected. Yes, might need some more manual correction, but that's not the point. The problem of Affinity Photo is clearly visible. When you perform a crop operation, and then apply Auto Levels on your already opened image, that the Auto Levels correction delta is being calculated based on the initially loaded buffer, and not on the visible cutout.

And I've even got a second prove, that this is a bug. As long term Serif / Affinity user I still have a copy of Serif PhotoPlus X2 installed. This old successor of Affinity Photo does everything correct. I can crop and directly perform the Auto Levels, and the result is like the last image I provided. Without interim save and reload workaround. This means, that the bug has been introduced sometime between PhotoPlus X2 and Affinity Photo.

Looking forward for your feedback / confirmation.

cu, Steffen

 

[NotMyFault]

while I can confirm your observation, I would see this as feature on how filters and adjustment work (always affecting the complete layer)

Just rasterise & trim after cropping, before auto-levelling and you get what you want.

Filter and adjustments consistently affect the layers in total, it would introduce inconsistency if Affinity would change this.

 

[FotoSteffen]

Hello NotMyFault,

you are right. Coming from the older X2, I never dealt with "Rasterizing" that much in the context of simple photo editing. I watched this video

which helped me a lot to understand the basic concept now. I'll just insert this additional step in my workflow wherever needed.

Thanks!

cu, Steffen