Closed heyhippari closed 3 years ago
For reference, here's the current repository used: https://github.com/MediaBrowser/Emby.Resources/tree/master/images/imagesbyname
Early example of a proposed poster design for studios:
Another possibility for a clean design (Credits to Carlossap on ThePosterDB):
This project should start with proper documentation so we don't get 32x32 8-bit BMP icons mixed with 4k jpeg's in different aspect ratio's etc.
I think we should push for vectors (probably SVG) for all images and determine a required aspect ratio with minimum and maximum resolution for all assets. We could probably use GitHub Actions to convert SVG->PNG or similar and publish that to GitHub pages (or a different CDN).
Global picons for TV networks are available over here in SVG under GPLv3: https://github.com/picons/picons/tree/master/build-source/logos
@nielsvanvelzen That's more or less what I had in mind.
For the aspect ratios, here are the usual ones:
Type | Ratio | Dimensions |
---|---|---|
Poster | 1:1.5 | Usually 1000x1500 |
Thumb | 16:9 | Usually 1000x562 |
Background | 16:9 | Usually 1920x1080 |
Logo | 80:31 | Usually 800x310 |
I think at least poster and thumb should be required when adding a new image, so we cover the main types. Backgrounds and Logo are probably not even needed, except if there's a real desire for them amongst users and client devs (We'd probably use a rotation of backdrops from items in the Studios/Genres as a backdrop for Vue, and we don't use logos for these in that client, so personally I don't care much for them)
We can make SVG templates for both with a small tutorial on how to use them, then have some linting and checks to ensure quality.
Hey, sorry for chiming in without any jellyfin background or deeper core knowledge. I am a long time KODI user and team member though and got to get deeper insights there.
Over at KODI we have "artwork" add-ons (= plugins in jellyfin) for various types of artwork. Be it studio icons, genre icons, weather icons and fanart etc. Instead of referencing to a remote server where stuff is getting downloaded, we provide them as ready to install bundles (with a default one pre-installed), while only one bundle can be active/used for a specific type. KODI then grabs those files from the local installation and does not require an active internet connection after that (unless you want to update the bundle ofc). So in a scenario where users prefer "only use local NFO and artwork" when scanning in their libraries, we do not need to fetch related genre icons etc from any online source.
So while I understand that giving users the option to simply point to a different webserver URL, I think on the long run it would be better to also support running jellyfin in pure "offline" scenarios and provide the artwork via plugins that ship all the media files, maybe with the option to do online lookups in case a local version of a specific artwork can not be found.
Also, I think using SVGs for logos might be a good idea - they are small and work well with any screen resolution as well as web based clients and can be fit by clients into any aspect ratio of their liking. So IMO the pure logo itself would be the base requirement, with the option of additional poster and thumb versions.
@da-anda studio images are a bit of a grey area, but in general we support this already. There are currently two scenarios, the first of which is the remote sources being discussed here. The other one is a local image provider, which has historically only contained dynamically generated assets. A good example would be the GenreImageProvider, which makes a collage of albums in a genre.
Right now, local image providers aren't configurable through the admin dashboard, but ideally that will eventually be possible. I'm not sure asset packs are a good idea though, because it's really only viable for this exact scenario of studio images. Most media (albums, movies, artists) requires local assets attached to the media (or in the same folder) or a remote server hosting the assets. I'd much rather expand on the dynamic LocalImageProviders than try and support asset packs personally.
Sorry for asking, but I can't see any option to show/search/sort by studios. Only in TV-shows there's the studio given in jellyfin-web/android app. In movies the studio even isn't displayed but in edit metadata. So studio artwork would be nice, but only if the artwork would be visible somewhere ;) SVG would allow for easy scaling and studio artwork could be displayed even also in a movie's information page.
You are right that there is no page that currently shows a list of studios. However, the data is there and can be used to build such a view. For example, here is a view by studio on the Vue client (Don't mind the missing images, it's a known bug on that client):
SVG would be nice, but Jellyfin doesn't currently support it for artwork. And while we could add it, a few clients wouldn't support such artwork (Roku for example, doesn't seem to support using SVG).
So would something like this just try and download images based off of name matching or would it use studio ids from all the plugins like tmdb or tvmaze?
I think currently, it's just based on studio names. So it looks into a text file for a list of files, tries to find the studio's name and then uses that image.
We could likely use JSON to describe the contents of the repository instead, with a schema like this one:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "Jellyfin studio artwork",
"description": "A set of artwork for studios, used by Jellyfin",
"type": "object",
"properties": {
"name": {
"description": "Standard name of the studio, network or label in English",
"type": "string"
},
"tvdbId": {
"description": "ID of the network on TVDB",
"type": "string"
},
"tmdbId": {
"description": "ID of the network or studio on TheTVDB",
"type": "string"
},
"imdbId": {
"description": "ID of the company on IMDB",
"type": "string"
},
"musicbrainzId": {
"description": "ID of the label on MusicBrainz",
"type": "string"
},
"artwork": {
"type": "object",
"properties": {
"primary": {
"type": "string"
},
"logo": {
"type": "string"
},
"backdrop": {
"type": "string"
}
},
"required": [ "primary", "logo" ]
}
},
"required": [ "name" ]
}
Looks good, I would make a few changes:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "Jellyfin studio artwork",
"description": "A set of artwork for studios, used by Jellyfin",
"type": "object",
"properties": {
"name": {
"description": "Standard name of the studio, network or label in English",
"type": "string"
},
"provider": {
"type": "object",
"description": "Identifiers for various metadata providers",
"tvdb": {
"description": "Identifier of the network on TVDB",
"type": "string"
},
"tmdb": {
"description": "Identifier of the network or studio on TheTVDB",
"type": "string"
},
"imdb": {
"description": "Identifier of the company on IMDB",
"type": "string"
},
"musicbrainz": {
"description": "Identifier of the label on MusicBrainz",
"type": "string"
},
"anilist": {
"description": "Identifier of the studio on AniList",
"type": "string"
},
"additionalProperties": true
},
"artwork": {
"type": "object",
"properties": {
"primary": {
"type": "string"
},
"logo": {
"type": "string"
},
"backdrop": {
"type": "string"
}
},
"required": [
"primary",
"logo"
]
}
},
"required": [
"name",
"providers",
"artwork"
]
}
What's wrong with a normal API again? JSON schema seems a bit overkill to me.
What's wrong with a normal API again? JSON schema seems a bit overkill to me.
There is no API currently. It just polls a series of text files to get a list of available files and there is no ID matching, so you have to match the name on the provider exactly.
I think providers
should be a proper object:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "Jellyfin studio artwork",
"description": "A set of artwork for studios, used by Jellyfin",
"type": "object",
"properties": {
"name": {
"description": "Standard name of the studio, network or label in English",
"type": "string"
},
"providers": {
"type": "object",
"description": "Identifiers for various metadata providers",
"properties": {
"tvdb": {
"description": "Identifier of the network on TVDB",
"type": "string"
},
"tmdb": {
"description": "Identifier of the network or studio on TheTVDB",
"type": "string"
},
"imdb": {
"description": "Identifier of the company on IMDB",
"type": "string"
},
"musicbrainz": {
"description": "Identifier of the label on MusicBrainz",
"type": "string"
},
"anilist": {
"description": "Identifier of the studio on AniList",
"type": "string"
},
"additionalProperties": true
}
},
"artwork": {
"type": "object",
"properties": {
"primary": {
"type": "string"
},
"logo": {
"type": "string"
},
"backdrop": {
"type": "string"
}
},
"required": [
"primary",
"logo"
]
}
},
"required": [
"name",
"providers",
"artwork"
]
}
Good catch @crobibero that was my intention but I forgot to wrap it in the properties object.
Some small changes for the artworks, as talked about on Matrix before and above in the thread:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "Jellyfin studio artwork",
"description": "A set of artwork for studios, used by Jellyfin",
"type": "object",
"properties": {
"name": {
"description": "Standard name of the studio, network or label in English",
"type": "string"
},
"providers": {
"type": "object",
"description": "Identifiers for various metadata providers",
"properties": {
"tvdb": {
"description": "Identifier of the network on TVDB",
"type": "string"
},
"tmdb": {
"description": "Identifier of the network or studio on TheTVDB",
"type": "string"
},
"imdb": {
"description": "Identifier of the company on IMDB",
"type": "string"
},
"musicbrainz": {
"description": "Identifier of the label on MusicBrainz",
"type": "string"
},
"anilist": {
"description": "Identifier of the studio on AniList",
"type": "string"
},
"additionalProperties": true
}
},
"artwork": {
"type": "object",
"properties": {
"primary": {
"type": "string"
},
"thumb": {
"type": "string"
},
"logo": {
"type": "string"
},
"backdrop": {
"type": "string"
}
},
"required": [
"primary",
"thumb"
]
}
},
"required": [
"name",
"providers",
"artwork"
]
}
Here is the initial plugin https://github.com/crobibero/jellyfin-plugin-artwork
Untested as we don't have any repos yet
We could probably use the https://github.com/jellyfin/jellyfin-ux repository as a source, but we should most likely bundle the files with the server/client during build. We already pull that one in for the logo's so it should have minimal impact on CI and build pipelines.
Would it make sense to potentially ship hundreds of megabytes of artwork with the server, though?
Because there are a ton of potential genres, music genres and studios which require artwork, which could make the size balloon quite a bit, if we ship them in any resolution that would make sense up to 4k.
due to probably copyright issues if you ship/bundle f.e. trademarked studio logos, I would not bundle any of these. Also, there is no guarantee that the enduser will actually use any of that artwork.
edit: the only thing that might be worth bundling would IMO be genre icons, but nothing else
I think it would be better to leave it out of server as well, would prefer a nice extension that can be added/removed at will, that will update with the latest logos whenever they become available.
A preliminary repository, with Inkscape templates and an example, has been created here: https://github.com/MrTimscampi/jellyfin-artwork
It has a CI action to validate the contents of the studios.json
file based on a slightly modified JSON schema (The root item is now an array, since we want multiple studios in the file)
Some further refinements around the template may happen, mostly around tall logos (One example being the one for the E! network).
A building action still needs to be figured out and ideas for a web-based tool for helping to create these images has been thrown around for a future improvement.
A preliminary repository, with Inkscape templates and an example, has been created here: https://github.com/MrTimscampi/jellyfin-artwork
It has a CI action to validate the contents of the
studios.json
file based on a slightly modified JSON schema (The root item is now an array, since we want multiple studios in the file)Some further refinements around the template may happen, mostly around tall logos (One example being the one for the E! network).
A building action still needs to be figured out and ideas for a web-based tool for helping to create these images has been thrown around for a future improvement.
Thank you for taking action here, but could you possibly tell us if this is still an ongoing project? Just curious
I'm not part of the Jellyfin team anymore due to differences in goals, so I have no idea if anyone picked this back up or not.
Given the repository hasn't been updated since last May, I doubt anyone is looking at contributing images currently. The plugin also hasn't been published yet, afaik (But I may be mistaken on that, as I don't follow Jellyfin super closely nowadays).
I'm not part of the Jellyfin team anymore due to differences in goals, so I have no idea if anyone picked this back up or not.
Given the repository hasn't been updated since last May, I doubt anyone is looking at contributing images currently. The plugin also hasn't been published yet, afaik (But I may be mistaken on that, as I don't follow Jellyfin super closely nowadays).
Hmm, I see, that's a bit of a shame. Thanks for the heads-up!
The repo is currently maintained at https://github.com/jellyfin/jellyfin-artwork
I had some time and opened a PR with some studios and general discussion.
A heads up though on the current situation: The Emby repo has around 3k entries, converting them all will take a lot of time and effort from multiple people for our repo to be a valuable replacement.
For 2 years now, we've still been using the Emby resources repository for some artwork for Studios.
With jellyfin/jellyfin#5009, this provider is exposed as a plugin and the URL to said repository can be changed. This puts us to a place where we can finally get rid of the dependency to Emby and host our own repository, as well a define a structure so others can do the same (In accordance with the project's goal of allowing people to spin up their own instances of anything we host, so they don't have to rely on us).
We currently only support Studios, but the following types could potentially be supported easily:
In addition, it'd be nice to provide a unified set of TV station icons at a later date, in order to make the entire Live TV experience nicer to look at (See known issues about black logos on black backgrounds for an example of what improvements could be made).
Some early goals: