starred/jellyfin
1
0
Fork 0
mirror of https://github.com/jellyfin/jellyfin.git synced 2026-05-04 18:09:12 +03:00
Code Issues 822 Packages Projects Releases 10 Wiki Activity

API serves some logos in non-transparent format #6936

New Issue
Closed
opened 2026-02-07 04:18:37 +03:00 by OVERLORD · 4 comments
OVERLORD commented 2026-02-07 04:18:37 +03:00
Owner
Copy Link

Originally created by @samglt on GitHub (Apr 21, 2025).

Description of the bug

The API's get item image endpoint (/Items/{itemId}/Images/{imageType}) sometimes gets transparent logos in jpeg format when it should return a transparent format like webp or png. This doesn't affect the webUI because it has an Accept header that doesn't include jpeg, but does affect clients like Swiftfin and can be replicated by downloading the image with wget.

This issue affects only some items. Examples given in a Swiftfin issue are Redline and House.

Looking at GetItemImage and the functions it calls, I see that ProcessImage is checks that the file it's processing is saved in a transparency-supporting format and returns a webp/png in that case, so I don't know why this bug happens.

Reproduction steps

  1. Using the WebUI
  2. Open the detail page for an affected show/movie
  3. Right-click and inspect the transparent logo at the top of the page
  4. Copy the background-image url (format: {url}/Items/{itemId}/Images/{imageType})
  5. wget image url
  6. less the image and see the jpeg magic number

What is the current bug behavior?

The image downloaded is a jpeg, not a png or webp like it should be to have transparency

What is the expected correct behavior?

The image should be transparent

Jellyfin Server version

10.10.0+

Specify commit id

No response

Specify unstable release number

No response

Specify version number

10.10.6

Specify the build version

10.10.6

Environment

- OS:
- Linux Kernel:
- Virtualization:
- Clients:
- Browser:
- FFmpeg Version:
- Playback Method:
- Hardware Acceleration:
- GPU Model:
- Plugins:
- Reverse Proxy:
- Base URL:
- Networking:
- Storage:

Jellyfin logs

N/A

FFmpeg logs

Client / Browser logs

No response

Relevant screenshots or videos

No response

Additional information

No response

Originally created by @samglt on GitHub (Apr 21, 2025). ### Description of the bug The API's get item image endpoint (/Items/{itemId}/Images/{imageType}) sometimes gets transparent logos in jpeg format when it should return a transparent format like webp or png. This doesn't affect the webUI because it has an Accept header that doesn't include jpeg, but does affect clients like Swiftfin and can be replicated by downloading the image with wget. This issue affects only some items. Examples given in a [Swiftfin issue](https://github.com/jellyfin/Swiftfin/issues/1240) are Redline and House. Looking at [GetItemImage](https://github.com/jellyfin/jellyfin/blob/576f6d411a5bf5c9a27aa832e9eb56556725f505/Jellyfin.Api/Controllers/ImageController.cs#L550) and the functions it calls, I see that ProcessImage is checks that the file it's processing is saved in a transparency-supporting format and returns a webp/png in that case, so I don't know why this bug happens. ### Reproduction steps 1. Using the WebUI 2. Open the detail page for an affected show/movie 3. Right-click and inspect the transparent logo at the top of the page 4. Copy the background-image url (format: {url}/Items/{itemId}/Images/{imageType}) 5. wget image url 6. less the image and see the jpeg magic number ### What is the current _bug_ behavior? The image downloaded is a jpeg, not a png or webp like it should be to have transparency ### What is the expected _correct_ behavior? The image should be transparent ### Jellyfin Server version 10.10.0+ ### Specify commit id _No response_ ### Specify unstable release number _No response_ ### Specify version number 10.10.6 ### Specify the build version 10.10.6 ### Environment ```markdown - OS: - Linux Kernel: - Virtualization: - Clients: - Browser: - FFmpeg Version: - Playback Method: - Hardware Acceleration: - GPU Model: - Plugins: - Reverse Proxy: - Base URL: - Networking: - Storage: ``` ### Jellyfin logs ```shell N/A ``` ### FFmpeg logs ```shell ``` ### Client / Browser logs _No response_ ### Relevant screenshots or videos _No response_ ### Additional information _No response_
OVERLORD added the bug label 2026-02-07 04:18:37 +03:00
OVERLORD commented 2026-02-07 04:18:41 +03:00
Author
Owner
Copy Link

@samglt commented on GitHub (Apr 21, 2025):

After a bit of looking, all the logos that have this problem are stored as SVGs (run find /config/data -name 'logo.svg' to find these in your server) and indeed, the list of _transparentImageTypes only contains png, webp, gif. So SVG's are treated as opaque formats and thus get delivered as jpeg. I think just adding ".svg" to that list will solve this issue, but at the moment I don't have a development instance of Jellyfin running to confirm that.

@samglt commented on GitHub (Apr 21, 2025): After a bit of looking, all the logos that have this problem are stored as SVGs (run `find /config/data -name 'logo.svg'` to find these in your server) and indeed, the [list of _transparentImageTypes](https://github.com/jellyfin/jellyfin/blob/576f6d411a5bf5c9a27aa832e9eb56556725f505/src/Jellyfin.Drawing/ImageProcessor.cs#L36) only contains png, webp, gif. So SVG's are treated as opaque formats and thus get delivered as jpeg. I think just adding ".svg" to that list will solve this issue, but at the moment I don't have a development instance of Jellyfin running to confirm that.
OVERLORD commented 2026-02-07 04:18:42 +03:00
Author
Owner
Copy Link

@gnattu commented on GitHub (Apr 21, 2025):

The client should explicitly tell the server that it supports one of the transparent format because the server cannot make unsafe assumptions. When the client does not explicitly require a format or has not pass a supported image format in its request header, the server will fallback to jpeg as safest option.

I do agree that it’s extremely rare for a client to be unable to read PNG files though.

@gnattu commented on GitHub (Apr 21, 2025): The client should explicitly tell the server that it supports one of the transparent format because the server cannot make unsafe assumptions. When the client does not explicitly require a format or has not pass a supported image format in its request header, the server will fallback to jpeg as safest option. I do agree that it’s extremely rare for a client to be unable to read PNG files though.
OVERLORD commented 2026-02-07 04:18:43 +03:00
Author
Owner
Copy Link

@crobibero commented on GitHub (Apr 21, 2025):

SVG images have specific handling (https://github.com/jellyfin/jellyfin/pull/11077)

It's possible there is a bug in how I implemented it but it's been a year so I don't recall my testing results.

@crobibero commented on GitHub (Apr 21, 2025): SVG images have specific handling (https://github.com/jellyfin/jellyfin/pull/11077) It's possible there is a bug in how I implemented it but it's been a year so I don't recall my testing results.
OVERLORD commented 2026-02-07 04:18:44 +03:00
Author
Owner
Copy Link

@samglt commented on GitHub (Apr 21, 2025):

I don't think it's a problem with SVG handling, because explicitly requesting png/webp results in a correctly transparent logo.

When the client does not explicitly require a format or has not pass a supported image format in its request header, the server will fallback to jpeg as safest option.

In that case, the real issue is that images in webp/png/gif format get served as webp/png even when no supported formats are specified, not that svg images get served as jpeg when no formats are specified. GetClientSupportedFormats always adds jpeg and png, so when GetOutputFormat determines what format to use for an originally transparent image, it will always use PNG if webp isn't supported and will never fall back to jpeg.

@samglt commented on GitHub (Apr 21, 2025): I don't think it's a problem with SVG handling, because explicitly requesting png/webp results in a correctly transparent logo. > When the client does not explicitly require a format or has not pass a supported image format in its request header, the server will fallback to jpeg as safest option. In that case, the real issue is that images in webp/png/gif format get served as webp/png even when no supported formats are specified, not that svg images get served as jpeg when no formats are specified. [GetClientSupportedFormats](https://github.com/jellyfin/jellyfin/blob/576f6d411a5bf5c9a27aa832e9eb56556725f505/Jellyfin.Api/Controllers/ImageController.cs#L2010) always adds jpeg and png, so when [GetOutputFormat](https://github.com/jellyfin/jellyfin/blob/576f6d411a5bf5c9a27aa832e9eb56556725f505/src/Jellyfin.Drawing/ImageProcessor.cs#L224) determines what format to use for an originally transparent image, it will always use PNG if webp isn't supported and will never fall back to jpeg.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
EFjellyfin.db
area:database
awaiting-feedback
backend
blocked
breaking change: web api
bug
build
ci
confirmed
discussion needed
dotnet future
downstream
duplicate
enhancement
feature
future
github-actions
good first issue
hdr
help wanted
invalid
investigation
librarydb
live-tv
lyrics
media playback
music
needs testing
nuget
performance
platform
pull-request
Mirrored from GitHub Pull Request
 question
regression
release critical
requires-web
roadmap
security
security
stale
support
syncplay
ui & ux
upstream
wontfix
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/jellyfin#6936
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?