Fully opaque images with alpha channel are rendered slightly transparent when zoomed out

[taylordotfish]

PNG images that are fully opaque but have an alpha channel appear slightly transparent when the zoom is less than 100%, allowing the checkered background to be faintly visible.

Steps to reproduce:

Create an opaque white image with an alpha channel:

convert -size 2000x2000 xc:white png32:white.png

Run feh --zoom 50% white.png.

A faint checkerboard pattern might be visible behind the image depending on your display settings. For confirmation, use a color picker to see that the colors in the image alternate between #fdfdfd and #fefefe.

To see the effect more clearly, take a screenshot of feh and adjust the levels:

convert screenshot.png -level 98%,100% screenshot-adjusted.png

Screenshots:

Screenshot of feh --zoom 50% white.png:

With levels adjusted:

In case it's useful, here's the copy of white.png I used.

Program version:

feh version 3.10.2-1-g1d02f90
Compile-time switches: curl verscmp xinerama

[g-rden]

This is a side effect of anti-aliasing. If you use --force-aliasing or press shift-a it will be #ffffff. Something similar occurs with images without transparency: convert -size 2000x2000 xc:white png8:white.png. I don't know if the anti-aliasing could be better, but it's not unexpected for me. As long as an image is downscaled there are bound to be inaccuracies.

[taylordotfish]

You're right, it does also happen for images without an alpha channel. I didn't realize because the effect isn't as large—I guess there's a compounding effect with the addition of an alpha channel.

It's still somewhat surprising to me that artifacts would occur in the case where every pixel is the same, though. This is the easiest case for an anti-aliasing filter—all frequencies are 0. Intuitively, it should be possible to handle this without adding a DC offset.

I haven't looked through the code, but I have a small suspicion that somewhere in the anti-aliasing algorithm there are some floating-point values being truncated vs. rounded to the nearest integer, or an off-by-one error, or something similar.

[g-rden]

If I am not mistaken anti-aliasing is handled by imlib_context_set_anti_alias() from imlib2. I think https://git.enlightenment.org/old/legacy-imlib2 is the repo for it. That might be the correct place for this bug report.