Jump to content
CJ Randolph

Incorrect Pixel Visibility on Export

Recommended Posts

Hi there!

I've been participating in a thread about deformities when expanding strokes, and while conducting some tests to research that issue, I stumbled on something else. I had suggested folks work at a larger resolution (like 640x640) and export at their target resolution (64px for instance), but when I tried this myself I got rather incorrect results.

So, I put together a file just to test the results I got, and I'm including it as an attachment. In summary, I created two rings of different colors that are perfectly overlapping one another. They're in-place duplicates, just with different colors. The first test should have a 1 pixel stroke and the second should have a 2 pixel stroke, and that stroke should only reveal the top ring's color (cyan) at any resolution, but that's not the case. The cyan top color is polluted by the red beneath. This would appear to be an error in the way the program calculates visibility, especially (I think) in sub-pixel sampling.

This probably isn't a critical issue for most designers, but it could present some challenges to anyone working on small icons and the like.

Cheers

~CJ

Pixel Pollution Test - 20190626.afdesign

Share this post


Link to post
Share on other sites

Hi @CJ Randolph,

Sorry for the delayed reply. 

On 6/26/2019 at 11:11 PM, CJ Randolph said:

The first test should have a 1 pixel stroke and the second should have a 2 pixel stroke, and that stroke should only reveal the top ring's color (cyan) at any resolution, but that's not the case. The cyan top color is polluted by the red beneath. This would appear to be an error in the way the program calculates visibility, especially (I think) in sub-pixel sampling.

Why do you expect this? I would expect this behaviour on a straight line where you don't have any anti-alias. On a curved line, this is expected. You have 2 layers that will get rasterised and some "transparent" areas on both. Those areas will overlap and combined will show that "pollution". If you want to have clean edges, you would need to change the coverage map to a vertical line (basically bypassing the anti-alias). 

Thanks,

Gabe. 

 

Share this post


Link to post
Share on other sites

Because the shapes perfectly overlap. If one shape is totally covered by the one above it, it logically should have zero visibility in the final render. For reference, Illustrator given the same test produces the correct expected results at all resolutions — an anti-aliased cyan ring with no red color pollution.

The test is contrived (as tests often are), but there are certainly real world cases where curved shapes will overlap and mask one another, and shapes that logically are unseen shouldn't be contributing to final pixel colors. This would especially be a problem for designers working at very small resolutions and expecting pixel-perfect results, where the aliasing color pollution can affect an entire shape and not just its fringes.

I haven't tested it, but I suspect an object constructed of straight-lines and right angles would exhibit the same issues if tilted off axis, which means that you're getting inconsistent masking & aliasing results dependent on angle. I can't imagine that would be your expected behavior.

Edited by CJ Randolph
said beneath rather than above.

Share this post


Link to post
Share on other sites

I'll add that my own workflow often includes multiple overlapping duplicate shapes, and since the first day using Affinity Designer, I've noticed the odd fringing/aliasing behavior while working (especially while zooming in/out), but I assumed it was an artifact of fast/inaccurate live rendering to keep the interface snappy. Finding the same issues in saved images caught me off guard. So I documented it.

Share this post


Link to post
Share on other sites

Ran a few more tests this morning, and thought I'd share the results. First up, I tested straight-lined objects (squares) and they suffer the same color pollution along their edge just as curves do. That's shown in the screenshot called Square Overlap Test.

Test number two is a little different. Here, I created a red square to use as a vector mask and inserted an image that's pure white. The expected result is a pure white square. It displays a red fringe in the user interface, but on export it's clean. The results can be seen in the image labeled Vector Mask Test.

Cheers,

~CJ

Square Overlap Test.png

Vector Mask Test.png

Share this post


Link to post
Share on other sites
On 7/21/2019 at 1:35 AM, CJ Randolph said:

Because the shapes perfectly overlap. If one shape is totally covered by the one above it, it logically should have zero visibility in the final render. For reference, Illustrator given the same test produces the correct expected results at all resolutions — an anti-aliased cyan ring with no red color pollution.

They overlap, but when you rasterise them they will have transparent pixels, and those transparent pixels will make up the "pollution". Have you actually tried illustrator? It produces the exact same "pollution" as Affinity Designer because this is the correct and expected behaviour. Actually, it would be a problem if it did not show the pollution, as this would imply it's ignoring layers/transparency below the current layer. 

16 hours ago, CJ Randolph said:

Ran a few more tests this morning, and thought I'd share the results. First up, I tested straight-lined objects (squares) and they suffer the same color pollution along their edge just as curves do. That's shown in the screenshot called Square Overlap Test.

Have you got integer values for position/size for those straight lines? If not, it is expected 

Share this post


Link to post
Share on other sites
1 hour ago, GabrielM said:

They overlap, but when you rasterise them they will have transparent pixels, and those transparent pixels will make up the "pollution". Have you actually tried illustrator? It produces the exact same "pollution" as Affinity Designer because this is the correct and expected behaviour. Actually, it would be a problem if it did not show the pollution, as this would imply it's ignoring layers/transparency below the current layer. 

 

I've tried it in Illustrator multiple times now, and as I mentioned previously, I get the expected and correct results, which are no color pollution from masked objects. And this is Illustrator CS4, which is 11 years old now. I'm guessing you only looked at it in in the user interface where a thin discolored fringe is visible, but on export, Illustrator properly prevents unseen objects from contributing to rendered pixels. I'm attaching an image, and maybe you can tell me which sample cyan shapes have red duplicates hidden behind them. I've attached the .ai file so you can check for yourself.

I'm also including a second set of files with another test, an exported image and the .ai file that produced it. Here, I've created objects that are black squares masked by identical white squares, then arranged them around a white page with zero care for their final pixel alignment and tilted them all off axis, which should provide a pretty rigorous test of anti-aliasing and masking behavior. Again, we see a final exported image from Illustrator that is pure white, the result I would expect. Should I report this as a bug to Adobe, though? I mean, Illustrator is clearly ignoring layers/transparency below the current layer, which you've just told me is a problem. :35_thinking:

(It's worth noting that Illustrator has a toggle for Anti-Aliasing on export, which would seem to indicate they're performing anti-aliasing later in rendering.)

Look... I understand where you're coming from, but you're looking at it from an engineering perspective — we rasterize a shape, that produces transparent pixels along the anti-aliased edge, and overlapping transparent layers will have mixed colors. Totally understandable. But from an end-user perspective (and I'd argue, from a software design perspective), the expected behavior should be that a masked shape is masked, pixel visibility should be calculated earlier, and anti-aliasing only performed on pixels that belong in the final image. Put another way, is this your preferred behavior? Having a miscolored fringe along overlapping objects. Is that what you want to happen? Is that what you prefer it look like when two shapes overlap?

Illustrator Depth Culling Test.png

Illustrator CS4 Depth Culling Test.ai

Illustrator Depth Culling Test 2.png

Illustrator CS4 Depth Culling Test 2.ai

Share this post


Link to post
Share on other sites

Here's another version from CS4, exported at 32x32 px, then blown up so we can see the results. I cannot locate any red tinged pixels.

I know I'm getting a bit sarcastic, and I apologize for that. I'm not here to be an annoyance. I'm not a wacko who's gonna make weekly threads complaining about this and crying that you don't care about your customers. I've used Illustrator for 13 years and hated it the whole time, and after using your product for 2 months, I get my work done in 1/4 the time. Without even swearing at my computer.

But can we at least agree that these examples I'm showing you here are the desired result? In an ideal situation, this is what I want a renderer to do, and you're going to have a very, verrrrry hard time convincing me otherwise.

Illustrator CS4 Depth Cull Test - Low-Res Enlarged.png

Share this post


Link to post
Share on other sites

I believe your CS4 does not treat the anti-alias correctly, and you might have got used to that "bug". I see where you're coming from, but that result is wrong. I tested your file in the latest Illustrator CC 2019 and you can clearly see the red underneath in test, and the black boxes in test2. 

 

Illustrator CS4 Depth Culling Test.jpg

Illustrator CS4 Depth Culling Test 2.jpg

Illustrator CC 2019.zip

Share this post


Link to post
Share on other sites

Hahaha... Oh, goodness. No, the older behavior is neither a bug nor incorrect, and Illustrator has apparently gotten worse at rendering in newer versions. Interestingly, there are about a dozen more boxes in the box test, which CC is still correctly masking. The ones you can see have (I believe) the steepest inclines. Those are the six boxes where it failed. Sorry.

Incidentally, I was using the newest version of CC until I switched to your product about two months ago. So no, this isn't just something I've been used to on an old version. CS4 is simply the last licensed version I have left.

But, anyway... there doesn't appear to be much either of us can accomplish here. But do me a favor, and please ask one or two of your coworkers to read through this thread. Just for perspective.

Have a nice day.

Edited by CJ Randolph

Share this post


Link to post
Share on other sites

@CJ Randolph, I downloaded your first "Pixel Pollution Test - 20190626.afdesign" file & opened it in Affinity Designer. I am confused by something that maybe you can help me with:

The artboards you have labeled as "Target 1 Pixel Stroke" & "Target 2 Pixel Stroke" don't contain pairs of circles with 1 px & 2 px stroke values respectively. Instead, they are "Curves" objects (note the plural), each I believe you constructed from a pair of un-stroked circles of slightly different dimensions with the smaller one boolean subtracted from the larger one.

Selecting any of them & using the Divide boolean reveals that they are not precisely centered one over the other, nor is the difference in their sizes exactly 1 px. (To see this, set Preferences > User Interface > Decimal Places for Unit Types > Pixels to at least 2 decimal places.) For example, when I do this for the divided Cyan Curves shape in Target 1, I get this for the smaller & larger curves:

1920561518_smallercyan.jpg.9dbaddf62f1f3e90a5d1dcee170cdacd.jpg 773094210_largercyan.jpg.5e295789aa0f732834f22e8d8d0cb900.jpg

The divided red Curves object shows the same values, so as Curves objects they are coincident, but neither one is exactly 1 px thick, nor is anything centered on whole pixel values.

Was this your intent?


Affinity Photo 1.7.3, Affinity Designer 1.7.3, Affinity Publisher 1.7.3; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.3.155 & Affinity Designer 1.7.3.1 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 13.1.2

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

Please note the Annual Company Closure section in the Terms of Use. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.