Resized JPG exports show artifacts around inpainting edits

[lphilpot]

Photo 2.1.0 beta 1732, Windows 11 (I don't recall seeing this in earlier betas, but I don't have them installed any more)

I have a TIFF (nature scene) in which I used the inpainting brush to remove some visually distracting details. I used an additional layer for the edits and set the inpainting brush to Current Layer & Below (to protect the pixel layer):

Here's a sample edit:

   

When I exported the image as a JPG, per my standard procedure I resized it down using the Lanczos 3 Non-separable algorithm. The resulting image showed outline artifacts around all the inpainted edits, for example (enlarged screenshot):

More examples:

So, I then exported test samples using Bicubic, Bilinear, Lanczos 3 Separable and Lanczos 3 Non-Separable algorithms, both full size and reduced to 2048 pixels on the long vertical edge (my usual web export size). The end result is, only* the Lanczos 3 reduced exports show artifacts and the Non-separable algorithm is far worse than Separable, although artifacts can be faintly seen in the Separable exports as well.

* After later exporting the same image twice using Bicubic with reductions in size to 2048 and 1080 on the long edge, the 1080 version does in fact show a slight artifact, but it's faint. So it appears maybe (??) both reduction and / or Lanczos can cause artifacts, with stronger reductions making them more visible.

[UPDATE] - After looking VERY closely even the 2048 Bicubic export does actually show artifacts very faintly. But I don't see them at all in the 100% exports, nor in the original Photo document.

I've not exhaustively gone through each and every possible permutation of algorithm, size, image format, tool, etc. But it's clearly happening per the examples above. Also, I've not tried reducing the size first, then exporting it -- This is all done via the export dialog because the other way requires too much undoing, etc. I'll assume that now alerted, Serif can do whatever testing is required to identify the scope of the issue.

I guess for now I'll use Bicubic for any reduced exports. I can upload the file(s) in question if needed (although the afphoto file is 100MB).

Thanks.

Edited March 26, 2023 by lphilpot

[NotMyFault]

Can you upload the afphoto file?
As a workaround, did you try „merge visible“ before exporting?

I have the assumption that either semi-transparent edge pixels in the „correction“ group lead to lighter colors by anti-aliasing / resampling to lower resolution, or the (intended) sharpening effect of Lanczos 3 causes this .

[NotMyFault]

And see https://en.wikipedia.org/wiki/Lanczos_resampling

When using the Lanczos filter for image resampling, the ringing effect will create light and dark halos along any strong edges. While these bands may be visually annoying, they help increase the perceived sharpness, and therefore provide a form of edge enhancement. This may improve the subjective quality of the image, given the special role of edge sharpness in vision.^[7]

 

 

[lepr]

@lphilpot The problem you have is not really a bug and it's not new.

When Affinity does a scaled export to a raster format such as JPG, each layer of the document is resampled on-the-fly to a new size, potentially introducing undesirable artefacts as you've encountered, and then these resampled layers are composited to the image that is exported.

To get a reliable export, you need to first generate a full size composite and then export that at the required size.

Layer > Merge Visible [Shift+Option+Cmd+E] will non-destructively add a full size composite to the document and then you can safely do a scaled export.

 

Edit: I gave a Mac shortcut. You should find the Windows shortcut in the Layer menu.

Edited March 26, 2023 by ,,,

[NotMyFault]

You can reproduce the effect using a simple file, having a blue square with a small red inside square on bottom layer.

On top, another pixel layer in blue covering the red fully.

When you resize the document from 8 to 6px using lanczos, you can see that the bottom layer gets a red-blue mix, and the top layer gets too small to cover all "red-contaminated" pixels.

Bottom Layer

top layer

Both layer active: red is covered

Resize from 8 to 6 px

after resample with lances: widespread red contamination in bottom layer, resampled top layer is too small to cover that area.

The workaround by ,,, and me gives the desired result. 

 

For me: works as designed, no bug.

[lphilpot]

1 hour ago, NotMyFault said:

The workaround by ,,, and me gives the desired result. 

For me: works as designed, no bug.

There may be workarounds, but by definition when a document looks a certain way in Photo and then looks different when exported into a visually-sufficient format, that's a bug -- No matter how it's packaged.

But thanks for the workarounds, at any rate. I'll take a closer look when I have a few minutes.

[lphilpot]

5 hours ago, ,,, said:

@lphilpot The problem you have is not really a bug and it's not new.

When Affinity does a scaled export to a raster format such as JPG, each layer of the document is resampled on-the-fly to a new size, potentially introducing undesirable artefacts as you've encountered, and then these resampled layers are composited to the image that is exported.

To get a reliable export, you need to first generate a full size composite and then export that at the required size.

Layer > Merge Visible [Shift+Option+Cmd+E] will non-destructively add a full size composite to the document and then you can safely do a scaled export.

@,,,  @NotMyFault

To follow up on my somewhat terse earlier reply (I was in a hurry)...

I understand the logic and function of what you've described, and most likely it's what I'll do in the future. But (rhetorically) if that's what's required to get a proper export, then that's what Photo should do internally, by default: Rather than scale layer-by-layer and reassemble, it should create a temporary flattened layer, rescale / export that layer and then remove it. Whether it's old or new behavior -- expected or not -- it's still by definition a bug and should be fixed. Whether they'll do that or not, who knows...

If the Photo macro facility was up to snuff, we'd be able to record / script all the necessary steps (short of the actual filename), save and then assign a keystroke to that macro. But alas...

[lepr]

3 minutes ago, lphilpot said:

that's what Photo should do internally, by default

I don't disagree. I'd prefer that to happen. My only disagreement is whether the present behaviour of the software is technically a bug.

[NotMyFault]

16 minutes ago, lphilpot said:

Whether it's old or new behavior -- expected or not -- it's still by definition a bug and should be fixed

It might be a bug by your definition. Affinity probably has its own definitions (as all software vendors use own) and the final authority what is rated as bug or not, and how priorities are assigned.

[lphilpot]

Well, I guess (if I wanted to be semi-snarky) if it's not a bug, "Export" should be renamed to "Export possibly with added artifacts". In every other context I've experienced, an export is assumed to be a faithful copy, as far as the target medium / format will allow. JPG certainly doesn't imply the presence of editing artifacts, so the export process isn't living up to its responsibility, as it were.

But we do as we must.

Thanks.

[lphilpot]

10 minutes ago, NotMyFault said:

It might be a bug by your definition. Affinity probably has its own definitions (as all software vendors use own) and the final authority what is rated as bug or not, and how priorities are assigned.

Look at it in any other context. For example (going back a few years, but the concept is still relevant) -- Let's assume you make a copy of a vinyl LP onto tape. You know the tape won't have quite the S-N ratio of the vinyl, there will be some hiss, etc. But that's a byproduct of the target medium. But if the copy process dropped all the bass below 100 Hz, sped up the tempo by 10% and included frequent drop-outs, you'd rightly assume the recording was flawed. I.e., a bug, because the process didn't fully "live up to" its potential.

And that's all an export is, a copy, so it should be a faithful copy.

I'm not in the mind to necessarily excuse it just because it's been known to happen before. If I were to systematically skip a corner of my yard every time I mowed, would that mean the grass there stops growing? And if Affinity (or Adobe or Microsoft or Apple or Google...) just arbitrarily decides something isn't a bug, it doesn't mean it suddenly ceases to be a malfunction.

But at any rate, I'll merge and export until / unless it's fixed.

Thanks again.

[NotMyFault]

If you resize the afphoto file with lanczos resample you probably get the same artifacts, at least i got in my test case explained above. Can you please try and share the result?

 

 

[lphilpot]

Yep, definitely. Here's a screenshot of part of a 1080 reduction (which is to match the size request of a forum I frequent). Check the sky and water.... ick.

[Gabe]

I'm afraid this is not a bug. I'll move it to improvements. 

[lphilpot]

@Gabe

I'm just curious -- and honestly not wishing to argue, just wondering about the logic...

If the image is clean on the editing preview but an unrelated operation (resizing) causes artifacts, how can that not be a bug? That seems a bit like selling a car with a five speed gearbox. not including the cogs for fifth gear work and then saying that's normal. It's "normal" only as long as you don't need to use fifth gear.

Anyway, once again if it's officially not a bug, then officially it's not a bug. But sure seems that way to me.

Thanks.

[Granddaddy]

19 hours ago, lphilpot said:

if it's officially not a bug, then officially it's not a bug. But sure seems that way to me.

I also had a problem understanding the definition of the word "bug" as used by Affinity Photo.

I've been told by moderators in these forums that a bug occurs when the software does not work as intended. 

As I understand it, here the intent is to export an image at a reduced size. Affinity succeeds in doing this, so the intent is satisfied.

Unfortunately for your purposes, this successful export is accompanied by unintended consequences.

An unintended consequence is not seen as a bug. Rather, it is a feature of Affinity software.

I frequently embed reduced size images of my photos in e-mails to friends and family. After editing and exporting an image from Affinity, I crop, resize, and sharpen it as necessary using Faststone Image Viewer. It's quick and easy and accurate for my purposes.

[lphilpot]

6 minutes ago, Granddaddy said:

I've been told by moderators in these forums that a bug occurs when the software does not work as intended. 

...

An unintended consequence is not seen as a bug. Rather, it is a feature of Affinity software.

Yeah... Logically speaking from a user viewpoint, unintended == not intended, so the artifacts must be an intended consequence since they're officially "not a bug".

I recall an old saying: "Don't p** on my boots and tell me it's raining." With apologies to the Bard, "A bug by any other name stings just as much." 🙂

Whatever.