Half-tone at small cell sizes (<= 2) darkens on export/flattening

[debraspicher]

This is being viewed at 100%. Theoretically, it should be the accurate view. On export/flattening, however, the results are subpar. Have tried rasterizing as well. I can raise the cell size and it'll be accurate. I can't get the original texture result though of the smaller size obviously.

(Click for accurate preview)

[thomaso]

Does one of them show the exported result? The preview appears with higher contrast (not darkened only). Do document and export size both have 400 px? And how come that "Monochrome" maintains colours (to me in V1 it's gray as expected).

[debraspicher]

1 minute ago, thomaso said:

Does one of them show the exported result? The preview appears with higher contrast (not darkened only). Do document and export size both have 400 px? And how come that "Monochrome" maintains colours (to me in V1 it's gray as expected).

I'll attach a sample document. It'll be easier to answer these questions definitely.

230316_blend-modes-overlay-half-tone-issue.afphoto

TLDR: Export is the same size as the document. I know half-tones can be very tricky when scaling is utilized but in this case, I'm trying to keep the result 1:1 so that it preserves preview as much as possible.

To answer your other question, the half-tone was added as a Live Adjustment and set to Overlay (in this case). (Don't worry about the seams, I know those can be adjusted for. I'm just concerned with the half-tone being lost for the moment.

In-document preview:



Export:

 

In normal blend mode (showing monochrome), the export has the same issue:

[debraspicher]

I did not try V1. I will open that since I still have Photo V1 installed and give it a go...

(Fast-forwarding...)

I did try it and the contrast/preview looks different a significant amount, so not consistent with V2. Again, here 100% preview is the issue. On export, same problem. I also tried the destructive method... same... the preview is off, but when I actually commit the filter, it averages out and appears darker (ie no tone). Basically same output and same export, so all that is consistent. It's preview that is faulty.

[Dan C]

Hi @debraspicher,

Thanks for your report and a copy of your document!

7 hours ago, debraspicher said:

It's preview that is faulty

Interestingly, I believe it is the other way round. Opening your document here and viewing at 100% zoom (with both H.A. enabled & disabled), the canvas matches the Export Preview for me, and appears the same as the Export Preview shown in your screenshots -

I have not yet been able to replicate this document rendering on the canvas incorrectly as shown in your screenshots, even when setting the Adjustment to Overlay -

Can you please provide a screenshot of your Preferences > Performance settings for me?

Are you using monitor scaling, though Windows Settings, for your display?

Out of interest, how does the canvas render at 99% and 101% zoom when set in the Navigator Studio?

Many thanks in advance!

[thomaso]

To me in V1 I get another result: The retina screen shows the result at 100% zoom in the macOS Preview.app in a size which corresponds in APub with 200%. (while I don't get an export preview). The result appears to me with same contrast but with obvious halftone grid (top & bottom), which is not visible in the same zoom level in the layout object (centre). From this persepective the layout appearance in APub is wrong, respectively "smoothening" the grid.

[debraspicher]

To add information for the thread. Zooming in (larger) makes it look more like the export result. I will do some testing when I get the chance and take video.

@Dan C All my scaling/DPI, resolutions, build info is in my forum sig. I'll try playing around again with DPI scale when I start testing. I have other threads up with DPI scale-related issues which are reported as bugs. So I wouldn't be surprised if it's yet another case of DPI scaling causing inaccurate pixel/1:1 preview in-program on my machine. I can't always trust preview on my machine. In fact I just remembered I have another situation of weird rendering in-program at 100% that I need to go update another thread on... because I experienced inaccurate preview in another situation as well and caught evidence of it that time, but never did re-reproduce it...

@thomaso The only thing I'd like to add here is if I zoom out, it'll make things look more like an export result, but I haven't tested "exhaustively". I really didn't think it was a bug. I had hoped it was just user error.

[thomaso]

48 minutes ago, debraspicher said:

The only thing I'd like to add here is if I zoom out, it'll make things look more like an export result, but I haven't tested "exhaustively". I really didn't think it was a bug. I had hoped it was just user error.

In my understanding the dependency on the zoom level for the displayed halftone within Affinity reduces the sense of a discussion for any general use, respectively makes it obvious that the output use matters, too. (by the way I wonder whether a halftone cell size = 2 would ever be useful?)

The 200% zoom level in my screenshot above are = "Pixel Size". As addition below the view within Affinity on the same items (layout object + previously exported .jpg result) at 100% and 74% ("Actual size", 300 dpi doc., retina screen):

• 100% zoom level (note the exported jpg gets downsized & smoothened in APub, the halftone almost disappears for both, layout & exported jpg):

• "Actual Size" = 74% / 300 dpi document / retina screen:

[Dan C]

Apologies for the delayed response has I have been off for a few days - I just wanted to inform you that the team is still investigating this internally and I'll be sure to respond here ASAP with our findings

[debraspicher]

1 minute ago, Dan C said:

Apologies for the delayed response has I have been off for a few days - I just wanted to inform you that the team is still investigating this internally and I'll be sure to respond here ASAP with our findings

Thanks. I still plan to get around to doing some testing with it. I just haven't had time.

[Dan C]

Many thanks for your patience here, I can confirm that there is already an issue logged with our developers regarding halftone filters and zoom levels, however I've also been able to replicate additional issues when using different DPI scaling resolutions through Windows - so I will be 'bumping' this current report with your thread now, and updating this internally to include the new information I have found in my testing.

I hope this helps

[debraspicher]

1 minute ago, Dan C said:

Many thanks for your patience here, I can confirm that there is already an issue logged with our developers regarding halftone filters and zoom levels, however I've also been able to replicate additional issues when using different DPI scaling resolutions through Windows - so I will be 'bumping' this current report with your thread now, and updating this internally to include the new information I have found in my testing.

I hope this helps

Thanks for letting us know. I was about to start doing some testing today. Your timing is impeccable!

DPI scaling seems to cause all kinds of "issues" in terms of rendering, sometimes so periodic for me it is difficult to always reproduce and hard to know what is normal while in app (I've become accustomed to quirky display). One such example, I somehow got Bilinear to be blurrier than NN in my photo in one session, only for bilinear to go back to being the crispier option. If it happens again, I will do testing because sometimes it's easy to miss. I suspect it's due to DPI scaling because that almost always seems to be the root for rendering problems on this setup. As you know, Pixel mode is not working in Designer for me properly if I'm at or above 150%. Anyway I say all this to say, the rendering engine is certainly quirky with Windows scaling in some manner (at least here) and it's something I think worth checking for more during testing.

Thank you for taking a look at this ❤️❤️