• 1(current)
  • 2
  • 3
  • 4
  • 5
  • 26
Compressed textures for FanArt - testing here with XBMC 2009-10-05 (r23431) or newer
#1
Information 
Hi all,

Those following the SVN logs will have noticed that we now support compressed DXT1, 3 and 5 textures in the skin engine. This opens the door for the possibility of storing fanart and thumbnails in these compressed formats rather than in JPG.

The main advantage here is memory usage and loading time. DXT1 is a 1:8 compression ratio (4 bits per pixel) in terms of the amount of data kept in GPU memory, as the GPU decodes the image as it's rendering it. Thus, no CPU decode is needed at all, compared with JPG which needs CPU decode, then a full 32 bits per pixel texture. For a 1080p backdrop, this is 8MB versus 1MB - a large saving. It means more textures can be kept in memory longer further reducing load time.

The disadvantage is quality: DXT1 may not be as good as JPG, and some images may suffer from this more than others. This is what this thread is for - determining whether or not the quality degradation is:
1. Noticeable.
2. Acceptable.

To do this, I've added support for loading .dds versions of fanart in SVN via the <useddsfanart> advancedsettings.xml tag. You need SVN r23421 or higher for this
Code:
<advancedsettings>
  <useddsfanart>true</useddsfanart>
</advancedsettings>

Secondly, you need your fanart converted to .dds. If you're on windows, you can use the batch file and script in the attached .zip file. Simply place the MakeDDS.exe and Convert.bat script in your fanart folders (UserData/Thumbnails/Video/Fanart and UserData/Thumbnails/Music/Fanart) and run the convert.bat batch file. with convert.bat *.tbn It'll take a few seconds and 1-2MB per image. NOTE: You'll need the SDL libraries (SDL.dll, SDL_image.dll) in your path - you can place them in windows/system32 or next to MakeDDS. Grab them from the SDL website if you don't have them.

If you're on linux or OS X you'll have to wait someone to do you up a build - the source code is in tools/TexturePacker in SVN.

If you have a good eye for detail, please give it a go and see what you think. If a particular image is bad, please note down what the quality level was when it was compressed (just rerun MakeDDS on it), and perhaps post which image it is and what the quality number was.

Cheers,
Jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#2
Forgive my blissful naiveté on this... but...

Would the long term intention be to scan the source image (png, jpg etc), and cache locally in the compressed format, rather than compress the actual source images?

A double edged sword this one... since it would (in theory) be nice if local caching wasn't necessary, and the original source was used all the time. Since this still seems unfeasible, caching still has to happen, in which case, might as well take a hit during the media scanning when the images can be cached and compressed as necessary.
Reply
#3
the only difference as far as operation is concerned is that currently the image cache holds jpeg images, with this change it will hold dds images...

as for an explanation of dxt compression see e.g. wikipedia
Reply
#4
Right... it was my quick reading of 'fanart folders' leading me to wonder if he meant the SOURCE folders, I should have read the brackets!

Slightly off topic / off the wall question...

For skins, would be madness to supply them with the compressed textures, but the currently focused UI element be redrawn with a lesser compressed texture?
I understand that would mean having two textures in the cache, but wouldn't it allow a faster build out of the UI, that slowly improved as the user navigated? or even reverted back to highly compressed texture when focus was lost?
Of course, a skin might be able to explicity override with thumb quality to use for critical elements.

Might be more trouble that it's worth, but it might improve stuff like coverflow scrolling etc.
Reply
#5
even if you could gain .1 fps by doing that, it's way way way too much code for slight-to-none gain. besides, if your coverflow has issues, your gpu is too weak. this puts more load on the gpu, not less. this is all about saving memory and cpu cycles at the expense of gpu cycles.
Reply
#6
Regular JPG:
Image


DXT1: (with minimal jpg compression)
Image


DXT5: (with minimal jpg compression)
Image


It's very subjective... and for reasons I don't want to go into... I couldn't get the perfect comparisons... but I would say that you're hard pressed to notice any difference.... and little chance if you're +10ft from a screen.

I will try a similar comparison of a more geometric image with hard edges... but will only post the shots if there's any horrible artefacts.
I am pleasantly surprised... some sample comparisons on the web were not flattering at all!

Also, the DXT format files sizes are approx 9x that of the jpg... yes 9x LARGER. So would have to balance the disk loading speed vs time to decompress jpg, but of course, it's still less 'processing'.
Reply
#7
Are there no issues with None Power Of Two dimensions passed to the gpu? rumour has it, a good number of cards don't like texture sizes that are NPOT.
Reply
#8
Not really knowing what DXT1, 3 & 5 is and that its in the general section of the forum - with sentences like "The main advantage here is memory usage and loading time" & "Thus, no CPU decode is needed at all," - at the risk of a chewing..... will this be available for or of any help to Xbox? Laugh

I know - I know! I have a Windows box but the Xbox still gets switched on first. Cool
Reply
#9
xbox did this for textures for a long while. and sure, it could probably be ported to run there for fanart. not that we care
Reply
#10
Geeba Wrote:Not really knowing what DXT1, 3 & 5 is and that its in the general section of the forum - with sentences like "The main advantage here is memory usage and loading time" & "Thus, no CPU decode is needed at all," - at the risk of a chewing..... will this be available for or of any help to Xbox? Laugh

I know - I know! I have a Windows box but the Xbox still gets switched on first. Cool

It should do yes.
It's just a graphic format that the Graphics Processor understands and has hardware support to decompress. Meaning XBMC can toss the file at it and let the graphics chip do all the work. With JPG, XBMC has to do all the hard work :-(
Reply
#11
Thanks Spiff/AnalogKid - better than I was expecting Big Grin
Reply
#12
Great, 10 posts and zero testing :p

NPOT issues are taken care of. If the card doesn't support NPOT compressed textures (eg my ATI card under directx - seems ok under GL, but the driver may be taking care of it) then we already expand to a POT texture. This does have a large effect memory-wise ofcourse (1920x1080 -> 2048x2048) but it's still about a quarter of the memory, and that's assuming that a linear texture would be NPOT.

As for quality, there's some trickery we can do with DXT5 (double the size of DXT1) that'll get miles better picture quality than DXT1 gives, at the cost of twice the memory. Note that DXT5 offers zero benefit over DXT1 if there's no alpha involved. (For the curious, convert to YCoCg and store the Y in the alpha channel, with the Co and Cg in the R, G and B channels. The conversion from YCoCg to RGB is done in a shader on the GPU).

Now, I'd really appreciate some testing on this.

Thanks,
Jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#13
As soon as 23421 comes downstream to me (Via the Windows Auto Update tool). I'll give it a blast on OpenGL and DirectX builds.

Incidentally, the tool you provided needs the SGL libraries included with it for it to work.
Reply
#14
Yep my windows box is needing an update - I'll try for this weekend. Big Grin
Reply
#15
I'll test this after next svn update so.

Quick question, does fanarts are compressed in DXT1 automatically when the scrapper grab some jpg fanarts and <useddsfanart> is set to true ?
Or do we have to cron a daily compression in the fanarts directory ?
Reply
  • 1(current)
  • 2
  • 3
  • 4
  • 5
  • 26

Logout Mark Read Team Forum Stats Members Help
Compressed textures for FanArt - testing here with XBMC 2009-10-05 (r23431) or newer1