Disparity between what's on screen vs. what gets output

[daveconrey]

This is not unique to version 2 of Affinity Photo, I've experienced this before in previous versions, and I realize that maybe I'm pushing the limits of what Photo is supposed to render, but whenever I push certain filters or adjustments (displace, threshold, affine, and others), what I see on my screen is not what gets created after I flatten or export. 

Separately, but not disimilar, often, I can create an image using radical color adjustments, save the file, and import that image into a new document with the exact same color profile as the first image, but the imported image color shifts significantly. It's frustrating to say the least that I cannot trust what I see on screen to be what gets exported.

I've included an example and also a Zip of my original file so you an take a look for yourself. 

masseuphoria-daveconrey.zip

[NotMyFault]

Hi,

 

can you provide screenshots of the exact export settings used?
Which OS, display(s), display color profile do you use?
 

the screenshot is zoomed out. If you compare, use 100% or 200% zoom level to get accurate rendering.

[daveconrey]

1 hour ago, NotMyFault said:

Hi,

can you provide screenshots of the exact export settings used?
Which OS, display(s), display color profile do you use?

the screenshot is zoomed out. If you compare, use 100% or 200% zoom level to get accurate rendering.

Apparently you are correct. If I'm zoomed into 100%, I see it the way it exports, but even THAT is problematic. I would think Affinity would want our images to render accurate at any level of zoom.

M1 macbook and display, most recent MacOS.

[walt.farrell]

5 minutes ago, daveconrey said:

I would think Affinity would want our images to render accurate at any level of zoom.

At lower zoom levels, a technique called mip-maps is used to provide better rendering performance. However, for certain kinds of adjustments and filters, it can give misleading results because (as I understand it) the adjustments/filters are applied to the zoomed-out data, not to the real data. Unless you evaluate the adjustments/filters at 100% zoom (or possibly multiples, such as 200%) you get this misleading view and don;'t see the true effect of the changes.

[deeds]

Mipmaps shouldn't be used in professional presentation applications. They're for games that need realtime performance improvements for objects at an angle to the camera, on surfaces at unknown and varying angles to cameras at significant distance from the camera. Mipmaps only ever have negative visual consequences in 2D.

 

There is no acceptable excuse for the differences in appearance at differing zoom levels. The entire reason a user zooms in and out is better examine and determine the appearance of that which they're making, not just to move around.

It's also a problem at higher zooms, wherein 200%, 400% etc are inaccurately presented, too, in a different way to being zoomed out. This is a truly ridiculous situation that needs to be fixed, but probably won't ever be because it'd require a rewrite of the presentation code.

[NotMyFault]

4 hours ago, deeds said:

Mipmaps shouldn't be used in professional presentation applications. They're for games that need realtime performance improvements for objects at an angle to the camera, on surfaces at unknown and varying angles to cameras at significant distance from the camera. Mipmaps only ever have negative visual consequences in 2D.

 

There is no acceptable excuse for the differences in appearance at differing zoom levels. The entire reason a user zooms in and out is better examine and determine the appearance of that which they're making, not just to move around.

It's also a problem at higher zooms, wherein 200%, 400% etc are inaccurately presented, too, in a different way to being zoomed out. This is a truly ridiculous situation that needs to be fixed, but probably won't ever be because it'd require a rewrite of the presentation code.

I agree this unreliable rendering is a very undesired consequence of using MIPMAPS, on the other side the snappiness and live rendering of filters and adjustments is the USP of Affinity Apps.

This would be acceptable if Affinty could switch to a “true preview” view mode which is reliable, at the cost of being very slow. Like exporting, and then zooming the exported file with a method avoiding all the artifacts, but staying in the app. No edits allowed in this mode.

Unfortunately, even the export preview can differ from final result.

[daveconrey]

Here's another example, and this one is GLARING! The first is at full screen view as I see it. The second is the output. There's a piece of my collage in the lower middle that's resizing and moving. How is that even a thing?

[deeds]

10 hours ago, daveconrey said:

Here's another example, and this one is GLARING!

Transparency of the black letters graphic are significantly different, too!

[NotMyFault]

Please provide screenshot of export settings used to create the export file.

It is well known that some Affinity functions cannot be exported to all formats without issues.

If you flatten the file and export as raster, it normally always works.

Exports to PDF or other Adobe formats are more problematic.

What we can do is providing help to get a properly exported file, or what specific combination of  features in you file causing the issue, so you can avoid them.

[debraspicher]

20 hours ago, daveconrey said:

Here's another example, and this one is GLARING! The first is at full screen view as I see it. The second is the output. There's a piece of my collage in the lower middle that's resizing and moving. How is that even a thing?

I wish it worked similar to other programs. That is where the expectation has been set. An option to enable a "more realistic" preview comparable to other 2D programs would be ideal. I get the speed is a major factor for some, for sure, but even on a 4K, when I work large res, it's impossible to work with "preview" a full image without exporting.

For your style of work, it's a particular point of pain because you have 1) a high texture work-piece 2) collisions of items highly dependent on edges for this texture "to work" 3) high contrast color and detail work

To complicate the issue, there's also differences in "preview" pre-export when elements are rescaled (1). Pixel layers in particular don't suffer from degradation like in other programs when resized (2), so there's behind the scenes logic to consider there. There are real world trade-offs obviously.

[Dan C]

I have hidden multiple posts from this thread, please remind yourselves of the Forum Guidelines before posting.