Artist picture less compressed?

Feature description:

Album covers compression is fine, but artist pictures seem to be a lot more compressed, sometimes quite dirty with compression artifacts.
Is it possible to compress them a little bit less ?

Problem solved:

Too much compressed artist pictures

Brought benefits:

Cleaner artist pictures

Other application solutions:



Additional description and context:

Check the uploaded images: they’re actually the same image. But the album one is way clearer than the artist one.

Screenshots / Mockup:



Another comparison:

Original image in Navidrome

Image in Symfonium

The images are the images that Navidrome returns, there’s no different in the compression or storing of image in Symfonium.

Provide logs and see what Navidrome returns.

Here: Dropbox

What I’ve done:

  1. Removed cache for both album and artist picture
  2. Toggled on debug mode
  3. Closed/reopened Symfonium
  4. Displayed both album and artist picture

In the requests that seem to be called to get images, one of them has a size=320 query string, while the other one (that seems to be related to album cover, since it has getCoverArt in it) doesn’t.
Maybe the issue is not a matter of compression, but a matter of size ?

I know this is hard to grasp, but again the url is sent by Navidrome I do not invent it.

I need logs during a sync to see the urls that Navidrome sends, Symfonium takes the larger one Navidrome sends.

For full logs, it’s better if you enable logs then add a new provider to have all fresh data.

And use for the logs.

Just to be clear, I’ve never implied that the URL wasn’t sent by Navidrome and/or that you were invented it: I’ve just noticed that one had a size-related query string, which could maybe explain why the artist images are dirty, nothing more :slight_smile:

Anyway, I’ve uploaded a new log to the url you provided. i didn’t received any url so I hope you’ll find the proper file (filename:
I’ve not used a new provider since it’s the only one I have, but here’s what were done during debug mode:

  1. removed some albums and artists images
  2. restarted symfonium
  3. sync
  4. displayed the removed albums and artists pages

You can add again the same provider as asked :slight_smile:

And I’ve explained already that Symfonium uses the data the Navidrome sends, so the issue is the data Navidrome sends :slight_smile:

Now proper logs can help figure out what they send to see if they send a better url somewhere or not.

You have enabled the option to gather additional metadata so it’s additional query that are then cached.

So I’m sorry but I’m forced to ask again, enable logs, add the provider again wait for the full sync with additional metadata fetched then upload them to see all that Navidrome sends.

done, filename

So yes:

  "subsonic-response": {
    "status": "ok",
    "version": "1.16.1",
    "type": "navidrome",
    "serverVersion": "0.52.5-SNAPSHOT (45c4583f)",
    "openSubsonic": true,
    "artistInfo2": {
      "biography": "DEATH DEVIL was an indie speed metal hailing from Japan from early 90's and a short reunion concert for the wedding reception of one classmember in 2010. With the cult for obscure/indie metal bands such like X, Saver Tiger, or Tokyo Yankees and respect for the well know acts like: Anthem, Loudness or Bow Wow (mask and demon-styled white wig image for the band leader), but the most influental band must be one of the strongest screams from USA - speed/thrash Death Angel. <a target='_blank' href=\"\" rel=\"nofollow\">Read more on</a>",
      "musicBrainzId": "026f3d8c-6ab9-4984-b948-29e866fee924",
      "lastFmUrl": "",
      "smallImageUrl": "https://redacted/share/img/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6ImFyLTYzNzU4MzgzMzg0MzY3NTNiMTdlMTk5ZDc0YjIyNDQzXzAiLCJpc3MiOiJORCJ9.4sKUv9xdMMCaQT9_icuoN3SBO36j3Izkyv_RKt5f5dQ?size=150",
      "mediumImageUrl": "https://redacted/share/img/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6ImFyLTYzNzU4MzgzMzg0MzY3NTNiMTdlMTk5ZDc0YjIyNDQzXzAiLCJpc3MiOiJORCJ9.4sKUv9xdMMCaQT9_icuoN3SBO36j3Izkyv_RKt5f5dQ?size=300",
      "largeImageUrl": "https://redacted/share/img/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6ImFyLTYzNzU4MzgzMzg0MzY3NTNiMTdlMTk5ZDc0YjIyNDQzXzAiLCJpc3MiOiJORCJ9.4sKUv9xdMMCaQT9_icuoN3SBO36j3Izkyv_RKt5f5dQ?size=600"

Navidrome sends the large url with the size=600 parameter and Symfonium uses that.

Downloading image: ImageRequest(imagePath=ImagePath(file=null, url=https://redacted:443/share/img/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6ImFyLTYzNzU4MzgzMzg0MzY3NTNiMTdlMTk5ZDc0YjIyNDQzXzAiLCJpc3MiOiJORCJ9.4sKUv9xdMMCaQT9_icuoN3SBO36j3Izkyv_RKt5f5dQ?size=600&u=REDACTED&t=REDACTED&s=REDACTED&v=1.13.0&c=Symfonium&f=json, shouldCache=true, providerId=null, headers=[]), cachedOnly=false, keepTransparency=false, exactSize=false, size=null, crossFade=false, debugTag=null, sourceOnline=true)

I take the highest quality possible picture provided by Navidrome. Nothing more I can do on my side.

Ping @deluan for the Navidrome side details about those urls.

Ok thanks. 600px is rather small imho, considering resolutions nowadays.

Yeah, I agree. I copied these sizes from the original Subsonic code. We could maybe remove the size param for the largeImageUrl, but the issue with changing it now is that it may cause problems for users who store the full-size image with their libraries, sometimes 5MB or larger.

Any suggestions?

No quick solution :frowning:

It would either be changing the api to return an orginalImageUrl or something like that but not sure it’s worth changing the current API for those and should work on the new endpoints.

Or a setting on Navidrome side to increase the sizes.

Yeah, an originalImageUrl would be the best solution.

For now, I think it is feasible to just bump these values, maybe 300, 600, 1200?

Of course if the image is smaller than that it won’t upscale, and return the original image without sizing.

EDIT: Remember that there’s also a CoverJpegQuality config option in Navidrome that sets the JPG quality to use when sizing. The default is 75, but it can be bumped to something like 90, to have less artifacts.

1 Like

Yes 1200 for the large one would help a lot for this and premium phone hi res screens.

The CoverJpegQuality affect both albums and artists no ? So if the albums looks ok for him and it’s the same image I suppose it’s only the resizing that generate the lower quality. Maybe there’s some options for a better quality resizing algo too ?

Yes 1200 for the large one would help a lot for this and premium phone hi res screens.

Make sense. Will change the size values then.

The CoverJpegQuality affect both albums and artists no ? So if the albums looks ok for him and it’s the same image I suppose it’s only the resizing that generate the lower quality.

Yes, CoverJpegQuality affects both album and artist images, and yes, it is only used in resizes.

Maybe there’s some options for a better quality resizing algo too ?

This is the best one I got in pure Go :frowning:

EDIT: Lanczos is the one I use: GitHub - disintegration/imaging: Imaging is a simple image processing package for Go

1 Like

Yes Lanczos should be fine. I guess it’s the size and how Android upscale by default.

So 1200 should fix this, the only issue is that I cache data on Symfonium side, so will need to see how to handle that.

1200 should be fine, thanks a lot👍🏼
I’ve tried to use the URL with a larger size in query string, like size=3000 (on a 1200x1200 image), and the resulting picture is just the 1200x1200 image, so it does not seem to upscale the image once it has reached its actual size (which is a good thing, it would be kind of dumb in this case)

the quality of album covers looks fine to me. I don’t know what’s its resolution, but it can be keep as is imho.
Regarding artists images, it’s rendering a 600x600 image on a 1080*2400 screen that makes the image dirty.