Kodi Community Forum
FanArt and Thumbnails Naming-Standard and File-Structure Convension Rationalisation? - Printable Version

+- Kodi Community Forum (http://forum.kodi.tv)
+-- Forum: Development (/forumdisplay.php?fid=32)
+--- Forum: Feature Suggestions (/forumdisplay.php?fid=9)
+--- Thread: FanArt and Thumbnails Naming-Standard and File-Structure Convension Rationalisation? (/showthread.php?tid=49801)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16


Latest revision... with help from interested parties - AnalogKid - 2009-06-16 22:28

Filenaming Schema

This schema is designed to resolve a number of issues with the current plethora of possible artwork naming schemes AND improve skin functionality by:
1) Offering a totally consistent naming convention for art
2) Being completely unambiguous about what the art is doing
3) Is placeable ANYWHERE in the filesystem (does not 'have' to reside alongside the media, although it my if it wishes)
4) Allows a wider range of art than is currently possible
5) Supports different orientations of art (landscape and portrait)... so skins can pick up whichever style they require
6) Is possible to rapidly port the existing scheme to this proposed scheme via a script (which is also reversible!)
7) Allows for art at all levels of media (eg. Tv show, season AND episode level for all artwork types)

note:
Fanart = Large image / wallpaper, usually full screen representing the media
Cover.Front =The image you'd expect to see on the front of the box (DVD, CD case)
Cover.Back = The image you'd expect to see on the back of the box (DVD, CD case)
Cover.Inner = The image you'd expect to see on the liner notes / inside the cover)
Cover.Sleeve = The unfolded back, spine and front cover all in one
Cover.Disc = The image of the physical disc label (usually a round image)
Poster = Usually a 'Promotional' poster... promoting a movie or album release.
Banner = A highly oblong image usually landscape representing the media
Framegrab = A snapshot of the media (screen shot) of the playing TV show or movie, not applicable to Audio
Logo = A 'symbol' associated with the media, usually an iconic logo or symbol
Genre = A general classification for the category/style of media. e.g. Comedy, Rock, Horror, Jazz, Documentary.
<n> = Some number to allow multiple instances of artwork types. e.g. Starwars.movie.framegrab.001
MediaInfo = 'Flags' as they are termed today. I felt the term MediaInfo was easier to understand
HasBeenPlayed = 'Watched', but a more generic term to cover Audio and even Images

Items in GREEN are optional


<moviename>.movie.fanart[COLOR="green"](.landscape/portrait).<n>

<moviename>.movie.cover(.front/back/inner/sleeve/disc)(.landscape/portrait).<n>
<moviename>.movie.poster(.landscape/portrait).<n>
<moviename>.movie.banner(.landscape/portrait).<n>
<moviename>.movie.framegrab.<n>
<moviename>.movie.logo.<n>

Examples:
Star Wars.movie.fanart.landscape.01.jpg
Superman.movie.coverart.portrait.jpg

Regex for the above is:
(.*)(\.movie.*)$



<tvshow>.tvshow.fanart(.landscape/portrait).<n>
<tvshow>.tvshow.cover(.front/back/inner/sleeve/disc)(.landscape/portrait).<n>
<tvshow>.tvshow.poster(.landscape/portrait).<n>
<tvshow>.tvshow.banner(.landscape/portrait).<n>
<tvshow>.tvshow.framegrab.<n>
<tvshow>.tvshow.logo.<n>
<tvshow>^<season>.tvshow.fanart(.landscape/portrait).<n>
<tvshow>^<season>.tvshow.cover(.front/back/inner/sleeve/disc)(.landscape/portrait).<n>
<tvshow>^<season>.tvshow.poster(.landscape/portrait).<n>
<tvshow>^<season>.tvshow.banner(.landscape/portrait).<n>
<tvshow>^<season>.tvshow.framegrab.<n>
<tvshow>^<season><episode>.tvshow.fanart(.landscape/portrait).<n>
<tvshow>^<season><episode>.tvshow.cover(.front/back/inner/sleeve/disc)(.landscape/portrait).<n>
<tvshow>^<season><episode>.tvshow.poster(.landscape/portrait).<n>
<tvshow>^<season><episode>.tvshow.banner(.landscape/portrait).<n>
<tvshow>^<season><episode>.tvshow.framegrab.<n>

Examples:
Friends.tvshow.fanart.landscape.jpg
The Simpsons^S01E12.tvshow.framegrab.04.jpg

Regex for the above is:
TBD



<artist>.music.fanart(.landscape/portrait).<n>
<artist>.music.cover(.front/back/inner/sleeve/disc)(.landscape/portrait).<n>
<artist>.music.poster(.landscape/portrait).<n>
<artist>.music.banner(.landscape/portrait).<n>
<artist>.music.logo.<n>
<artist>^<album>.music.fanart(.landscape/portrait).<n>
<artist>^<album>.music.cover(.front/back/inner/sleeve/disc)(.landscape/portrait).<n>
<artist>^<album>.music.poster(.landscape/portrait).<n>
<artist>^<album>.music.banner(.landscape/portrait).<n>
<artist>^<album>^<track>.music.fanart(.landscape/portrait).<n>
<artist>^<album>^<track>.music.cover(.front/back/inner/sleeve/disc)(.landscape/portrait).<n>
<artist>^<album>^<track>.music.poster(.landscape/portrait).<n>
<artist>^<album>^<track>.music.banner(.landscape/portrait).<n>

Examples:
Madonna.music.fanart.landscape.jpg
Bon Jovi^Greatest Hits.music.cover.front.jpg

Regex for the above is:
([^\^]*)\^?([^\^]*)?\^?([^\^]*)?(\.music.*)



<genre>.genre.fanart(.landscape or .portrait).<n>
<genre>.genre.cover(.front/back/inner/sleeve/disc)(.landscape/portrait).<n>
<genre>.genre.banner(.landscape or .portrait).<n>
<genre>.genre.framegrab.<n>

Examples:
Rock.genre.fanart.landscape.jpg
Comedy.genre.fanart.landscape.02.jpg

Regex for the above is:
(.*)(\.genre.*)$



<audioformat>.mediainfo.audio.mono
<audioformat>.mediainfo.audio.color
<videoformat>.mediainfo.video.mono
<videoformat>.mediainfo.video.color
<resolution>.mediainfo.resolution.mono
<resolution>.mediainfo.resolution.color
<studio>.mediainfo.studio.mono
<studio>.mediainfo.studio.color
<source>.mediainfo.source.mono
<source>.mediainfo.source.color
<played>.mediainfo.HasBeenPlayed.mono
<played>.mediainfo.HasBeenPlayed.color
<lang>.mediainfo.subtitle.mono
<lang>.mediainfo.subtitle.color
[/COLOR]

Examples:
mp3.mediainfo.audio.color
h264.mediainfo.video.mono
true.mediainfo.HasBeenPlayed.mono
fr.mediainfo.subtitle.mono

Regex for the above is:
(.*)(\.mediainfo.*)$






NOTES:
*The very wordy examples given above should be abbreviated at some point, they are here to make the examples more readable. So, for instance, Music.Fanart might end up being abbreviated to MusicFA or similar.

*The ^ delimiter is used to allow media titles to have '.' character in them, and makes parsing very easy... although is movie has "^" in the title... we have a problem

*The seemingly redundant .movie ".tvshow" and ".music" etc are needed to prevent namespace collisions where Movie / TVshow / Artist items have the same title.

*We might need a way to figure for unicode characters to be encoded in the filename (for the titles). But this problem must already exist with all media right? We just need to clarify how it's resolved / handled

*For MediaInfo files, it's unclear if there needs to be one mediainfo file for EVERY (say) studio, or if it would be possible to create a "disney.mediainfo.studio" file that would be found for any studio containing the word "Disney"

*MediaInfo have ".mono" and ".colour" options, this is because the typical usage of this type of art is to act as an overlay / icon / indicator. Since some skins are light, and some dark... the icon would need to be visible in both cases... hence two versions... I could have relied on these images being monochrome and therefore 'invertible' but I felt this was too much of an assumption. So this way, you can have colour ones if you wish.
Just to make this clear....
".mono" = White logo on transparent background... Any skin can then colourize the image to fit the skin theme accordingly
".colour" = Full Colour logo on transparent background... so a skin should just display the logo 'as is'


- Gamester17 - 2009-06-16 22:43

Nitpicking; "colour" should be "color", no? The rest of XBMC strings uses American English Wink


- AnalogKid - 2009-06-16 23:00

Gamester17 Wrote:Nitpicking; "colour" should be "color", no? The rest of XBMC strings uses American English Wink

ha!
I remain the last bastion of my wonderful language.

But since I'm a man alone in this.... color it shall be (done)


- jmarshall - 2009-06-17 00:44

Off topic, but the strings should use British English. There's an English (American) directory for a reason.


- AnalogKid - 2009-06-17 01:16

jmarshall Wrote:Off topic, but the strings should use British English. There's an English (American) directory for a reason.

I have the solution to this
"Mono" and "notMono" ... lol


- digitalhigh - 2009-06-17 01:28

I'm liking the setup you've come up with. Although, I should point out that for this section:

Quote:<audioformat>.mediainfo.audio.mono
<audioformat>.mediainfo.audio.color
<videoformat>.mediainfo.video.mono
<videoformat>.mediainfo.video.color
<resolution>.mediainfo.resolution.mono
<resolution>.mediainfo.resolution.color
<studio>.mediainfo.studio.mono
<studio>.mediainfo.studio.color
<source>.mediainfo.source.mono
<source>.mediainfo.source.color
<played>.mediainfo.HasBeenPlayed.mono
<played>.mediainfo.HasBeenPlayed.color
<lang>.mediainfo.subtitle.mono
<lang>.mediainfo.subtitle.color

It might be a bit unnecessary, simply because with the inclusion of CapnBry's Media flagging stuff now, the (video/audio) codec, resolution, audio channels, and subtitle language can all be divined by using various infolabels available to skinners...meaning that I can place a generic tag in my skin, add the <texture>ListItem.VideoResolution,path/foo/,.png</texture>, and it will substitute 720, 1080, 560, w/e to create the path to the image as found in path/foo/.

Same goes for the rest of the stuff there...except for the source. I dunno. Some people might want it...but the functionality exists already in one facet that's pretty simple to use.




On the other hand, I whipped up a little example of the infolabels that I would hope to see as a result of this setup. These would be the values that could be called for any media item, and displayed as desired by skinners.

Mind you, this is just a rough idea made up after a long day at work, so I don't claim it to be perfect in any means...I hope to hear some commentary/criticisms on this.

These should be applicable to any basic media item.

ListItem.Image(fanartn,orientation)

Your basic fanart. "n" denotes the image number to use. Orientation defaults to landscape if there is none specified. Maybe "n" should be seperated out with a comma as well?

ex: ListItem.Image(fanart01,portrait) ; ListItem.Image(fanart); ListItem.Image(fanart03,landscape)


ListItem.Image(thumbn,orientation)

I know that there's currently a listitem.thumb property, and that every skin in existence probably uses it. But I just figured that if we're aiming for consistency, maybe this should be transitioned to, and start depreciating infolabels like Listitem.Thumb/Listitem.Icon/Listitem.Property(Fanart_Image).

This would be the "cover" or "poster" or "banner", depending on the media being used. As with fanart, n could be used to have multiple images available, and the orientation would determine whether a banner or poster is displayed.

Ex: Listitem.Image(thumb01,landscape) - would display the first banner.
ListItem.Image(thumb03,portrait) -would display the third poster.
ListItem.Image(thumb) - whatever people decide on. I'm just trying to get a rough idea going. Wink


ListItem.Image(framegrabn)

Pretty simple. Uses the first screenshot if no "n" is specified, otherwise, shows the desired number.

ListItem.Image(frontcover)
Listitem.Image(backcover)
ListItem.Image(innercover)
ListItem.Image(combinedcover)

These four are pretty self-explanitory. IDK if "n" should just be included as in the other examples right off the bat?

ListItem.Image(discn)

Disc image. Since multiple discs are common, I obviously opted for a number as in other instances.

ListItem.Image(logo)

I see this as being more for TV shows or bands, but I bet people will come up with spiderman and batman logos...or the X-men or transformers or something. Wink



So, that's just a first shot at an idea. I also think that for TV shows, TV season folders, and Music tracks and albums, it would be a good idea to have a Listitem.ParentImage(foo) tag available for everything, and even go so far as to suggest that it be defaulted to if Listitem.Image(foo) is not available.

Yeah yeah...that's my 2 cents for the day. Big Grin


- AnalogKid - 2009-06-17 02:25

You made my head hurt and I read this three times!

Some of it made sense, and some of it I need to think about, since I'm not a skinner, but get the gist of things...

The <n> option, I had envisaged more for constantly changing image... fanart and moviegrabs is an obvious one. For the large part, most users wouldn't have <n>, but if they did... a skin 'could' cycle through them all, if it had the right control and way to signal that the control should cycle.

As for deprecating the use of 'thumb'. I'd guess for the moment... thumb would equate to cover.front. That would be a direct one to one mapping. So any request for a thumb would retrieve the cover.front

For the mediainfo artwork... slightly confused about that. I know that XBMC now has them natively supported, so no need to bastardise the Studio tag in NFO... but it still has to render the icons right? the scheme was just meant to have a uniform way of picking up those icons (via name). However... I've thought of a stange dilemma: It could be argued that the skin look after it's own mediaflag icons, so no need to have a naming convention. That said, there are so many new codecs and studios appearing, isn't it better to have the icons apart from the skin?... so that the user only needs one icon set for all skins? I can see an argument for both cases here. Tricky!


Also for <n> images... I'd figured the following

Starwars.fanart.landscape <--- the default fanart
Starward.fanart.landscape.<n> <--- an additional fanart for skins that want the 'cycle' through fanart

So, a skin that just wanted a still fanart, would omit any index number

I can't see a reason for a skin to request a specific index number (except perhaps when displaying more than one at the same time) in which case it still be movieframe<n> and movieframe <n+1>. I'm not sure how image cycling works in a skin... does the skin request a new image based on a timer, or as I suspect, it gives XBMC a root folder and gets XBMC to cycle through images in that folder. If the latter?

I really appreciate your input on how this scheme would be utilised within a skin. I'd started out just trying to help the library scanning find artwork, but the two kinda go hand in hand

Finally, I changed the term CombinedCover to Sleeve. I think it's a more identifiable term. Can't really see a skin using it... but skinners are funny folks... if it's there, they'll use it! ;-)


Right... as I said earlier, you've given me a headache!... I need a lie down for about 8 hours in a darkened room.

And I've just noticed someone's raising the topic of 'cache to local disk THEN play' for server based media!. Another fave subject of mine!

Gracias amigo!


- digitalhigh - 2009-06-17 02:59

AnalogKid Wrote:You made my head hurt and I read this three times!
The <n> option, I had envisaged more for constantly changing image... fanart and moviegrabs is an obvious one. For the large part, most users wouldn't have <n>, but if they did... a skin 'could' cycle through them all, if it had the right control and way to signal that the control should cycle.

Right, and we have a <multimage> control, which is typically pointed at a directory, and then displays that directory's contents in a slideshow-type format. I failed to include the idea that using just putting "
"ListItem.Image(type,orientation)", would then make a Multimage display all available images.

Quote:As for deprecating the use of 'thumb'. I'd guess for the moment... thumb would equate to cover.front. That would be a direct one to one mapping. So any request for a thumb would retrieve the cover.front

The usage of "thumb" was actually just to differentiate from "front.cover", which (in my mind) would be a scan of the actual DVD cover, whilst the majority of movie collections use posters for the main display. I thought about calling it "poster", but then that screws up people who would want to use a banner.

Else...just call them poster, banner, and frontcover respectively.

Quote:For the mediainfo artwork... slightly confused about that. I know that XBMC now has them natively supported, so no need to bastardise the Studio tag in NFO... but it still has to render the icons right? the scheme was just meant to have a uniform way of picking up those icons (via name). However... I've thought of a stange dilemma: It could be argued that the skin look after it's own mediaflag icons, so no need to have a naming convention. That said, there are so many new codecs and studios appearing, isn't it better to have the icons apart from the skin?... so that the user only needs one icon set for all skins? I can see an argument for both cases here. Tricky!

I agree that it would be quite convenient to have ONE set for everything...I can bet you that some skinner is going to want stylized icons, at which point, there becomes a problem. It's really up to whoever decides to be kind enough to put this into code as to how much work they want to put into that aspect.

Quote:Also for <n> images... I'd figured the following

Starwars.fanart.landscape <--- the default fanart
Starward.fanart.landscape.<n> <--- an additional fanart for skins that want the 'cycle' through fanart

So, a skin that just wanted a still fanart, would omit any index number

I can't see a reason for a skin to request a specific index number (except perhaps when displaying more than one at the same time) in which case it still be movieframe<n> and movieframe <n+1>. I'm not sure how image cycling works in a skin... does the skin request a new image based on a timer, or as I suspect, it gives XBMC a root folder and gets XBMC to cycle through images in that folder. If the latter?

Again, as I mentioned earlier...static and "slideshow" images are defined differently via the <image> or <multimage> controls. So, using multimage, just putting Listitem.Image(type,orientation) would make all show, while using the same tag in a static image (without <n>) would show the first image.

If, however, say you wanted to show two or three different posters, it would be beneficial to be able to have ListItem.Image(foo1), Listitem.Image(foo2), and ListItem.Image(foo3) all available at the same time. I don't know why you'd want to do it, but somebody may.


hmmmm - AnalogKid - 2009-06-17 18:52

digitalhigh Wrote:Right, and we have a <multimage> control, which is typically pointed at a directory, and then displays that directory's contents in a slideshow-type format. I failed to include the idea that using just putting "
"ListItem.Image(type,orientation)", would then make a Multimage display all available images.



The usage of "thumb" was actually just to differentiate from "front.cover", which (in my mind) would be a scan of the actual DVD cover, whilst the majority of movie collections use posters for the main display. I thought about calling it "poster", but then that screws up people who would want to use a banner.

Else...just call them poster, banner, and frontcover respectively.



I agree that it would be quite convenient to have ONE set for everything...I can bet you that some skinner is going to want stylized icons, at which point, there becomes a problem. It's really up to whoever decides to be kind enough to put this into code as to how much work they want to put into that aspect.



Again, as I mentioned earlier...static and "slideshow" images are defined differently via the <image> or <multimage> controls. So, using multimage, just putting Listitem.Image(type,orientation) would make all show, while using the same tag in a static image (without <n>) would show the first image.

If, however, say you wanted to show two or three different posters, it would be beneficial to be able to have ListItem.Image(foo1), Listitem.Image(foo2), and ListItem.Image(foo3) all available at the same time. I don't know why you'd want to do it, but somebody may.


You've just raised an interesting point regarding 'Posters'. I thought folks only used posters as a substitute for Front Covers... and had to make do with the additional 'coming soon' etc text. That said, they ARE technically different... so I'm going to add Poster art to.


- bidossessi - 2009-06-17 19:42

AnalogKid Wrote:That said, there are so many new codecs and studios appearing, isn't it better to have the icons apart from the skin?... so that the user only needs one icon set for all skins? I can see an argument for both cases here. Tricky!

very true, and there's a thread in the forum where folks are build what could be called the most complete studio tag collection under the sun (i think positive and negatives are covered as well for dark/light skins).
if a consensus can be reached as to naming schema for studio tags, then this ongoing work could be the starting point.


- AnalogKid - 2009-06-17 22:37

bidossessi Wrote:very true, and there's a thread in the forum where folks are build what could be called the most complete studio tag collection under the sun (i think positive and negatives are covered as well for dark/light skins).
if a consensus can be reached as to naming schema for studio tags, then this ongoing work could be the starting point.

Cool, and if like DigitalHigh has suggest, a skinner really insists / wants a themed icon set for their skin.... they can supply one for the end user to use (leaving the choice up to the end user).

The critical thing here is that the naming convention is highly consistent and well considered *hint* *hint*, that way, it doesn't need revisiting every 2 weeks. Although say in 2 years, it may need a revamp and new ideas come to fruition, and no scheme is entirely future proof.

It would be very helpful if the guys coming up with the naming convention took a look at this thread and offered their ideas... I'm happy to mention this work in their threat too... see if we can agree on something


- digitalhigh - 2009-06-17 23:31

AnalogKid Wrote:You've just raised an interesting point regarding 'Posters'. I thought folks only used posters as a substitute for Front Covers... and had to make do with the additional 'coming soon' etc text. That said, they ARE technically different... so I'm going to add Poster art to.

Yeah, I think that most people actually prefer the posters because they're more stylized than a DVD cover...plus then there's not a redundancy for studio logo, MPAA rating, etc...

AnalogKid Wrote:Cool, and if like DigitalHigh has suggest, a skinner really insists / wants a themed icon set for their skin.... they can supply one for the end user to use (leaving the choice up to the end user).

The critical thing here is that the naming convention is highly consistent and well considered *hint* *hint*, that way, it doesn't need revisiting every 2 weeks. Although say in 2 years, it may need a revamp and new ideas come to fruition, and no scheme is entirely future proof.

It would be very helpful if the guys coming up with the naming convention took a look at this thread and offered their ideas... I'm happy to mention this work in their threat too... see if we can agree on something

I wasn't necessarily including Studio images in my statement about the stylized icons...more so stuff for 1080, audio channels, etc. There are a bunch of different variations that can be used for 5.1 or 8.1 or stuff like that, that was what I primarily meant when I said that skinners would probably be wanting their own icons.

As far as the Studio Icons go...it just so happens that I do a fair amount of contributing in that section as well. Wink

The naming conventions being used for the studio icons is pretty simple...it should just be the studio name as listed on IMDB or TMDB. The reasoning behind this is that a skinner can then use <texture>listitem.studio,/PATH,.png</texture>, and the image is automagically pulled from whatever PATH is. However, it wouldn't be too hard to rename all the files so that the naming convention would work. The new tag would just read as:
<texture>listitem.studio,/PATH/.mediainfo.studio.mono,.png</texture>

(the resulting string would look like soSmile

<texture>/PATH/disney.mediainfo.studio.mono.png</texture>

Or even better, <texture>listitem.image(studio,mono)</texture> if this were somehow incorporated into an image database...


- AnalogKid - 2009-06-18 00:56

digitalhigh Wrote:Or even better, <texture>listitem.image(studio,mono)</texture> if this were somehow incorporated into an image database...

This is the right way to go.... this way the skin doesn't "interpret" the mediainfo... it's completely agnostic. Then is new studios appear, the skin will still work with no knowledge of the studio name.

This (in my opinion) is how it should work for the codecs too.

Infact, the skins shouldn't even be referring to the filename directly, just as you say "poster,<n>,portrait", and XBMC will map that to the correct filename.


- digitalhigh - 2009-06-18 01:50

AnalogKid Wrote:This is the right way to go.... this way the skin doesn't "interpret" the mediainfo... it's completely agnostic. Then is new studios appear, the skin will still work with no knowledge of the studio name.

This (in my opinion) is how it should work for the codecs too.

Infact, the skins shouldn't even be referring to the filename directly, just as you say "poster,<n>,portrait", and XBMC will map that to the correct filename.

I see what you're saying.

And codecs...other than maybe MP3, I'd guess that the majority of them probably have their own "brand-name" logo as well. It's just that "what if somebody wants something different" factor that still *niggles* me. The thought that somebody will want their own customized icons for codes or resolution info.

In that case, what does one do to allow for a separate set from the "standards" that doesn't require overwriting said standard images?


- kortina - 2009-06-18 03:00

I just thought that I would let you guys know that I am a big fan of the discussion, I think that it is important to standardise the format ASAP.

The renaming of *.png to *.jpg has never sat well with me.

I think that in the age where many people are begining to own a NAS/File Server at home, it is more important than ever to have standards for storing the content.

I am not a big fan of storing the content in a *external* database (external to XBMC). Databases are great for nerds, but I dont know of any NAS appliances that will run a DB instance.

Once the standard is nailed, it should be fairly easy for some of the Media Manager crowd to write apps to suit.

I do also like the idea of having a share that contains the thumbs/nfo etc, this can be store away from my files, and can be made a writeable share by XBMC. One big benifit is that I wouldnt have to run scrapers after every re-install/additional XBMC client. When you have over 2tb of content scraping is not as ideal as a dedicated share for the content.

Personally I do not use scrapers or library view, I am stuck in the age of nfo and tbn files. I use XBMC Companion for NFO, EpNamer to fix my filenames, and TheTVDB for my wide icons. The main issue I have is that none of these apps will run as a service and monitor my ever expanding media collection.


My partner, and guests are always amazed at how great XBMC looks (PM3.HD) and how easy it is to use.

Keep up the great work!