Album Art picture (jpg format) does not scale up

[eshchenko]

Steps to reproduce the problem

Add the Album Art column to the "play list with tabs" (I do not remember - may be this column is already present by default).
Load any album containing the jpg art in the same directory e.g. cover.jpg.
Deadbeef will pick it up and show.

What's going on? Describe the problem in as much detail as possible.

The cover will appear either in the reduced size but never bigger than the original size (e.g. 419 pixels) independent on the Album Art window tab size and on the "Image Size" in the Album Art plugin configuration (see details below).

This "Image Size" setting is very misleading: you can make the image smaller (e.g. the default value "256" will really reduce the 481 pixels image to 256 pixels), but if you change the image size e.g. to 512 the picture will in its original size.
Also, by resizing the the art by mouse - one can make it smaller but not bigger than the original size.

Information about the software:

I found this bug just by chance.

The deadbeaf I was using so far, e.g. git from 16.05.2022, shows all the art perfectly.
Actually, I suspect, this "old" deadbeef even ignores the "Image Size" settings of the Album Art plugin. All the pictures are scaled to the size of the Album Art tab window. I discovered this plugin settings only now, when tried to understand - where this small picture size is coming from.

Before opening this issue I searched similar problems in the open issues and found one:
#2929
The author actually did not describe the problem in details.

Deadbeef version:
Tested versions:
Bad Album Art up scaling:
git from 03.03.2024
last stable 1.9.6 compiled from the source code.

Working as expected versions:
git from 14.05.2022 and lot of versions before this date.

I had tried to use Album Art plugin from the working version with the new deadbeef, but this trick does not help.

OS:
Tested both on "intel"
Linux Mint 20.1
and on the last Raspberry Pi OS

How to reproduce:
Start old deadbeef (e.g. git from 14.05.2022):
gtkui plugin compiled for gtk version: 3.24.20

Note that the size of the art is the size of the Album Art tab.
Close old deadbeef, open new deadbeef (e.g 1.9.6 or git from 03.03.2024):
gtkui plugin compiled for gtk version: 3.24.20

Now the size of the art is reduced to 256 pixels - the default setting of the "Image Size" of the Album Art plugin:

The rest of the Art window is blank.
One can make picture smaller by drugging by mouse the border of the Album Art tab:

But it is not possible to make the art bigger by resizing the tab than the "256" pixels from the plugin:

OK, one can say - it is the feature - the settings really restricts the maximum size of the art.
Let us try to increase the "Image Size" in the plugin settings to 1024.

What is expected -
the picture should be scratched to 1024 pixels. But the scaling stopped at its original size of 419 pixels.
So the maximum size of the art is either the "Image Size" from the plugin or the original size of the image, what comes first.

Hope I provided enough information to reproduce this bug.
Best regards, Dmitry
The cover file is attached.

[eshchenko]

Dear Oleksiy
I found the commit which triggered the problem:

commit c1e9ed3
c1e9ed3 gtkui: fix album art column left/right/center alignment (fixes #2878) 2022-12-27

All the builds before this commit work as expected.
Best, Dmitry

[eshchenko]

Dear Oleksiy

I found a temporary "solution" returning to the previous logic in your
plugins/gtkui/playlist/playlistrennderer.c
by commenting the line number 328 and adding the line with the "old" call:

// cover_draw_cairo(scaled_image, art_x, min_y, next_y, scaled_image_width, scaled_image_height, cr, CAIRO_FILTER_FAST);
cover_draw_cairo(scaled_image, art_x, min_y, next_y, art_width, art_height, cr, CAIRO_FILTER_FAST);

I am little bit surprised that the new logic after the commit c1e9ed3 was accepted by the community, because this new "feature" is rather old and already present in e.g. 1.9.5 and 1.9.6 versions.
It looks like no one needs scalable big covers!
I personally prefer the size (on the TV screen) of the real LP cover.

To conclude - for me I had found the solution, but I do not know if I should close the issue.
Are the closed issues still searchable?
Just to share my "trick"...
Sorry for troubles!

Best regards, Dmitry

[Oleksiy-Yakovenko]

Thanks for investigating, please keep the issue open. At the moment I'm fairly busy with another project so can't dedicate much time to deadbeef, but I'll get to it sooner or later.