feh icon indicating copy to clipboard operation
feh copied to clipboard

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

Open taylordotfish opened this issue 1 year ago • 3 comments

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:

screenshot.png

With levels adjusted:

screenshot-adjusted.png

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

taylordotfish avatar Jan 22 '24 23:01 taylordotfish

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.

g-rden avatar Feb 21 '24 09:02 g-rden

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.

taylordotfish avatar Feb 25 '24 00:02 taylordotfish

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.

g-rden avatar Feb 25 '24 08:02 g-rden