Low resolution fanart rendering?

[TwistedMelon]

Is background fanart supposed to be super pixelated?

I'm setting up on an HD200 and HD300, running on 55" and 42" displays respectively, both outputting 1080p, though I understand the UI is always rendered at 720p.

In testing the fanart abilities of Gemstone, and downloading all assets with BMT, I notice that the art come in appearing as if it's much lower resolution than the actual source files. This is especially true of the background files. I've verified the files are 720p or 1080p and look phenomenal when viewed at their native resolutions, however, when the appear in Gemstone as background fanart they look like they've been scaled down to something like 320x180 before being used to fill the screen - in other words, extremely pixelated.

Oddly, the effect on the HD200 is that I can see very squared off pixel blocks as if only a simply nearest neighbor scaling has been done and on the HD300 it looks like the image has passed through bilinear scaling. Everything is still low res, but looks like it's been smoothed out.

[jusjoken]

I am doing this from memory but go into Utility Options, Image Options, Advanced Scaling and set the UI Width to something more appropriate. By default it uses the result Sage reports for the server UI width and for headless or VM servers this is not an appropriate value.

After changing this the clear the file system cache and rerun the precache

Hope this helps as it was just added in one of the recent releases.

k

[TwistedMelon]

Thanks for the info. I'll try this out and report back the results. I've also found a number of rendering bugs which I'll report after trying this out, in case their results change.

[TwistedMelon]

So, the default setting for UI width was 1280, which seems correct since the UI is only rendered at 1280x720 even when outputting 1080p.

Below that setting are some values for each of the art asset types, which I'm assuming are scaling percentages for the cached images. There are some types pre-labeled with the word "FULL" which are set to 100. But the non-full types are listed with percentages as low as 20. 40 for background. If this is correct that can explain the pixelation. I'm setting some of these higher and rebuilding to check the results.

I'm assuming that the percentages refer to the original image size and not the width specified for the UI. I'd probably prefer to specify this as a size in pixels rather than percentage, because otherwise you will get different results depending on the resolution of the source assets, which you may not be in control of if you're importing them automatically from the net using something like BMT. I've seen a number of different sized files imported, and I don't know if the sources BMT downloads from use only normalized sizes or if they allow anything at all to be uploaded/served. For instance, for background fan-art one might want to set the images to exactly the same value as the UI width, 1280. Otherwise you may get images that are less than and others that are greater than 1280, producing some that are pixelated.

While higher values will incur higher memory and cache usage, the low values as defaults simply make fanart looks quite bad. It would be a good idea to significantly increase the scale values so that new users aren't spooked by this in the future.

[jusjoken]

Let's see how your testing goes before we make any default changes as you are the first to raise the issue.... not that others may not have experienced the issue and just accepted the fanart as is. Either way let's get to the bottom of the issue.

The non-FULL items are percentages based on the typical percentage of the screen that the poster/background etc would be displayed in so we scale to that percentage by default. The FULL items are scaled to 100% of the UI width.... but still scaled non-the-less.

Let us know how it goes.

k

[TwistedMelon]

There's an issue right now with the caching. After having pre-built everything most backgrounds are not showing up, many posters not showing up, and no banners are showing up.

Further, using the Fanart manager to see if I could manually re-select a poster or background for a show that wasn't displaying one, all images appear blank in the list. See attached screen shot. You can move the selection around showing all black rectangles.



Excuse the blurriness, but the iPhone 4 camera really (really) stinks at indoor available-light shots.

[TwistedMelon]

Originally Posted by jusjoken

The non-FULL items are percentages based on the typical percentage of the screen that the poster/background etc would be displayed in so we scale to that percentage by default. The FULL items are scaled to 100% of the UI width.... but still scaled non-the-less.

Ok, let's run some numbers here to check out these defaults.

I believe the sizes from BMT have already been normalized, as I'm seeing that posters are all 680x1000. However, some of them are clearly scaled up from lower-quality images.

So if I understand correctly, a setting of 20 for poster does not mean 20 percent of the original size, but 20 percent of some other size which is built into Gemstone as the default poster rendering size. Let's say this is 340x500 by default. That means that 20% of that would yield an image scaled down to 68x100. When this image is displayed as a poster it is then rendered to the screen at the pre-determined 340x500, making it look pixelated.

Again, if the above is how it works, setting the cache percentage to 100 would yield a cached image of 340x500 which is down from the original on disk, but exactly the same size it will be rendered to in the UI (when the UI is at max resolution of course). That will leave as clean an image as possible.

I'll take some photos once I can get all the art appearing again, possibly after reverting Gemstone to standard defaults first.

[jusjoken]

Can you let me know what your Image Options are set to and if you have changed any of them? Especially Cache Type. There is a bug that has been fixed in the code I am working on where some of the Cache Setting values were being set incorrectly if adjusting them in the UI. The only way to solve it really is to clear the Gemstone Settings (bakcup Flows/Menus/Widgets first so you can reimport those if they are important to you).

Others have had a single corrupt fanart item that has stalled the pre-cache run.... did that complete without error?

And thirdly.... try a restart of the Extender/Server and see if anything changes.

My settings screen attached...

[jusjoken]

Originally Posted by TwistedMelon

Ok, let's run some numbers here to check out these defaults.

I believe the sizes from BMT have already been normalized, as I'm seeing that posters are all 680x1000. However, some of them are clearly scaled up from lower-quality images.

So if I understand correctly, a setting of 20 for poster does not mean 20 percent of the original size, but 20 percent of some other size which is built into Gemstone as the default poster rendering size. Let's say this is 340x500 by default. That means that 20% of that would yield an image scaled down to 68x100. When this image is displayed as a poster it is then rendered to the screen at the pre-determined 340x500, making it look pixelated.

Again, if the above is how it works, setting the cache percentage to 100 would yield a cached image of 340x500 which is down from the original on disk, but exactly the same size it will be rendered to in the UI (when the UI is at max resolution of course). That will leave as clean an image as possible.

I'll take some photos once I can get all the art appearing again, possibly after reverting Gemstone to standard defaults first.

Close but not quite....

Basically we take the image from the Fanart Folder and scale it to 20% (for a poster) of 1280 (UI width value) or 256 for width and the height is adjusted dynamically to maintain aspect ratio.... so that could be a scale up or down depending on the image in the fanart folder. The end result is an image for Gemstone to use that is 256 pixel wide (20% of the screen).

k

[TwistedMelon]

Ok, so basically the percentage yields an absolute image size which is dynamically resolved from the set UI width.

Honestly, it would be easier/more straight forward to just specify the size in pixels. The only drawback being the potential need to re-adjust if changing the UI width to something other than 1280 and possibly carrying heavier images than required. But does anyone use Gemstone with a UI set to anything other than 1280?

[TwistedMelon]

Originally Posted by jusjoken

Can you let me know what your Image Options are set to and if you have changed any of them? Especially Cache Type.

The settings you showed are an exact match for mine. I did change the percentages for the individual art types, but that was on the second run and things were already missing after the first pre-build.

I didn't leave the cache type set to anything different, but I did use the UI to cycle through all the available options to see what they were. Is it possible this has damaged some setting?

UPDATED: I just restarted the server and everything is now appearing again.

The changes to the percentages definitely made a huge difference to the rendering of the art, as expected. Originally, with a setting of 40% that means that background images rendered out to 1280x720 on a large screen (like my 55") were only cached at 512x288. That might look acceptable on a small notebook screen, but it's not on a big screen.

[jusjoken]

Well... that's why we put in advanced options so users can choose to adjust the settings. For example, I have a 102" projected screen and I use the default settings as the small background doesn't matter all that much to me.... but I know many users who it does matter to so we have settings.

I am glad you got it working and hopefully you can find settings that work best for your display.

Comments/Suggestions welcome as I am always interested to add things to the todo list to improve Gemstone and SageTV.

k

[TwistedMelon]

I'm waiting to restart the server again after making some additional changes to the percentages - need to wait until something finishes recording first.

My HD200 was actually set to use a screen width of 1024 for the UI, unlike the HD300 which has been 1280. I changed it to 1280 to match the HD300 before rebuilding the caches.

I did notice that when I did a pre-cache, that only about half the items were actually rebuilt, the others being "skipped." Even after clearing the file-based cache, many of the images would come up saying they were already present.

And again, after the clear and pre-build, things don't work properly and artwork is missing. Hopefully this is something you can address otherwise you'll probably need to pop up a dialog letting people know they need to restart the server.

Another very odd issue prior to making these latest changes: While fanart images were showing up, if I went to the fanart manager for some shows, none of the images were marked as default. Shouldn't the current one being used show up initially as the default?

[jusjoken]

The skipped items are items that the cache process already built... for example, as it goes through a Series... it only needs to build the cached item for the series poster once... and then skips it for the rest of the episodes. Perhaps a little misleading but I didn't want to spend too much time on the caching screen when there were Flows to design

Default Fanart: there really is no Default unless one is set. The system will grab the first one it finds when the request occurs if there is NO Default set... and it IS the first one I leis in the Fanart Manager but it would be misleading to show it as the Default.... as if you recreate the fanart or download more fanart it is possible for a different fanart item to become the first one. So a Default is only identified if you have set it within the Fanart Manager.

k

[TwistedMelon]

Thanks for the clarification, I didn't happen to notice that it was multiple episodes whipping by the cache output.

With regards to the default, that's good to know. I was starting to think it was something that had just suddenly disappeared or changed. It makes perfect sense that the property has no state until it's set. The drawback is as you've mentioned, the possibility that artwork will suddenly change one day if BMT or other process puts additional image files into the fanart folders.

Are there any external tools you might suggest for batch managing art assets whereby I might be able to set the default(s)? As noted in the BMT forum, it doesn't seem to be working "just right" when trying to set defaults.

Also, besides the dependencies and BMT, is there anything else I should be installing to make sure I can take full advantage of what Gemstone has to offer?

[jusjoken]

Not really... I use Gemstone and BMT... and with a few minor exceptions BMT does everything I need in a Fanart Manager... and most of it automated.

I do also use the Phoenix Commanline Rename tool as well and that works great for naming my rips to make sure the work well in BMT.

And at this point I use CMT as well on occasion as it adds IMDB lookups and lets you do a few more fanart functions we have not added yet to Gemstone.

k

[TwistedMelon]

I just noticed that the image scaling settings are different between extenders. That is to say that I can make changes on one and then go to another and the numbers are not reflected there. Does this mean that all the caching of artwork is done on a per-client basis? If not, then the settings need to be reflected in sync on each client as it reads them from the server.

On a side-note I just saw that the UI width on the HD200 somehow reset itself to 1024. I'm still struggling to figure out why I'm seeing rendering discrepancies between HD200 and HD300 in terms of UI. Video playback looks great on both. But the UI on the HD200 looks noticeably inferior, including the various pieces of artwork we've been discussing.

Originally Posted by jusjoken

The skipped items are items that the cache process already built... for example, as it goes through a Series... it only needs to build the cached item for the series poster once... and then skips it for the rest of the episodes. Perhaps a little misleading but I didn't want to spend too much time on the caching screen when there were Flows to design

Just revisiting this again because I'm currently prebuilding. The status output is based on series, of which I currently have 48. There is one update per art asset for each series. So when it says "Poster" it's only updating the status for the poster for the series as a whole, it's not displaying the status for each episode of that series.

I've verified that during this status update it might say that it's already done a particular asset such as Poster and then it will say that it's newly caching the FULLPoster.

It seems like items that I didn't touch the settings for (the FULL items) are getting rebuilt, and many instances of the items I did touch (like Poster) are coming up that they've already been done.

If it's all still working properly in the end, that's great, but this output it really misleading and when trying to debug issues like this can lead one down the wrong path quite easily.

[jusjoken]

Originally Posted by jusjoken

The skipped items are items that the cache process already built... for example, as it goes through a Series... it only needs to build the cached item for the series poster once... and then skips it for the rest of the episodes. Perhaps a little misleading but I didn't want to spend too much time on the caching screen when there were Flows to design
k

Ok... I checked the code... which is obviously better than my memory and the skipped item count are items that for "some" reason were already in the cache.

Now they could be in the cache because the cache was not cleared before running this OR they could be there due to the way I cycle through all the media items.... I use a flatter list of media items for performance reasons and this causes some duplicates but it is faster going through the list... OR they could be duplicates such as a Movie that is stored in 2 parts but sahre the same fanart.

If you have changed ANY of the cache settings/percents/UIWidth then you should Clear the file system cache and then prebuild the cache... otherwise it will skip existing cached items... I guess I could keep track of changed settings but not sure I am going to go there right now.

Not sure the differences between the capabilities of the HD200/300 but we do not process them ANY differently.

AND... you are correct... the settings for the cache should be the same across ALL extenders sharing the same server as there is ONLY ONE cache... perhaps if that item gets added to the issues list we can get that resolved so we store that (and some other settings) at the server level.

Thanks for all the feedback and if you are interested in more data during the caching process turn on DEBUG logging in Gemstone Log Utility options and then clear and run the cache and check the Gemstone.log file in the logs folder for more details.

AND make sure you check out the Flows.... that is really where Gemstone shines (IMHO).

k

[TwistedMelon]

I'll be checking out the Flows heavily as it's definitely the reason I started using Gemstone to begin with. I just want to get all the basics down first before I unleash the rest of my media into the database. I've got a decent ReadyNAS full of media so it could get out of hand pretty quickly if I didn't know al the basics first.

Now I'm going to have to note down all these things I'm supposed to report.

Back to the cache building. I'm positive I've always cleared the filesystem cache each time just before selecting the prebuild option, but I still see those "already" messages appear.

I just finished an A-B comparison of the HD200 and HD300 - connected both of them to the same 55" TV and toggled inputs as I navigated menus. The difference in rendering for some elements is night and day, with the HD300 showing very smooth text and icons and the HD200 looking like a mess on many. I'll provide close-up images below when I can unload them from my iPhone. I'm pretty sure that this is because the HD200 is actually rendering the UI at 1024x576 and the HD300 at 1280x720, however still not sure why the 1080p output of the RE-scaled UI looks so choppy for some elements on the HD200 - it should be different, but the difference should not be THAT pronounced.

[Hunter69]

Do you mind posting the numbers for changes that you are working?

I have an HD200 and HD300 that I need to adjust these settings on to make the fanart look nice.

Thanks