[jmarshall]

1. Reduce image during caching and encoding. I'll specify a maximum of 2048 in either direction.
2. On load, the only options are to either downsample (slow) or just crop. I prefer the latter. Given that image caching will downsample anyway, this isn't a problem.
3. I'll look at adding said cropping into SVN.

Cheers,
Jonathan

[AnalogKid]

1. Reduce image during caching and encoding. I'll specify a maximum of 2048 in either direction.
2. On load, the only options are to either downsample (slow) or just crop. I prefer the latter. Given that image caching will downsample anyway, this isn't a problem.
3. I'll look at adding said cropping into SVN.

Cheers,
Jonathan

Confirmed via DX.... max size is 2048x2048.

I'd favour a downsample (keep aspect ratio) until it's in limits. A crop is harsh esp if it's a BIG image.
I would reckon the majority of folks are using 1920 at the most, with a few geeks like me liking to keep the highest resolution available. It's not going to be many users, but I couldn't live with a crop. I'd end up fixing the issue outside of XBMC.

Something to think about though.... is photos. A lot of folks are going to prefer dumping their images on XBMC 'as is' and these WILL be bigger than 1920. Most users won't want to be having to downsize.
I assume you'll be wanting to use DDS for photos too? or opting to consider the compression inappropriate for photos? (fair comment I'd say)

[jmarshall]

See r23486.

[jmarshall]

All downsampling will be done at the caching side, and currently "slow" image loading (i.e. jpg and the like) is done with texture size limits already taken care of.

Thus, nothing to worry about that the resulting cache load is cropped - it's merely there to ensure we don't run amok over memory etc.

[AnalogKid]

Will you let us know when this goes truly 'live' and we can ditch the advanced settings option (unless you intend to keep that / reverse it to force jpg is need be)?

It might be nice as an interim measure to keep the advanced settings option, but you're creating the DDS format thumbs behind the scenes and side by side with your traditional jpg thumbs... then finally phase out the jpg's once it's clear you're bug free ;-)

Oh, and, what happens if one day, you do ditch the jpg cache altogether, but someone restores an older backup? will you provide an update tool, or have a check in the code for it?

What say you?

[jmarshall]

It'll be AGES before the new imagecache is up and running, and when it is there'll be no upgrade functionality from old stuff built in - it'll require a full rescrape. Someone might take the time to write an upgrade tool, but that someone won't be me.

Obviously when things are getting close I'll publish full details etc. I wouldn't expect it to be done until the new year at the earliest.

Cheers,
Jonathan

[arco]

Wow! I tried this on my ASRock 330, and the speed improvement when loading the fanart is amazing! It's literally instant and makes for a much smoother experience scrolling through the movie/tv-show list. No more 1-2 second delay before the CPU has decompressed the image. I really really hope this will be the default soon, and even though the images takes a bit more space, it's well worth it considering how much faster it is.

[IceNine]

Is this still in the works, or is it more or less finished somewhere deep in the code? I'm very interested since I recently got an ASRock Ion 330 and have been looking for every way I can optimize the GUI and this seems like a promising way. I have looked around the forums a bit for more information but it doesn't seem to be being discussed much. Does this work on linux or just Windows versions of XBMC? I am running the latest SVN from the Team XBMC PPA on Ubuntu 9.10. Based on my research on the web it looks like the images would still need to be converted on a Windows machine, fine I have one around, but does the decoding still work on Linux? Will conversion ever be built into XBMC so they are converted when they are initially cached? Is setting this in advancedsettings.xml still required? I am at a bit of a higher version than r23431, I'm on r26540.

[t00fan]

I would also like to try this out on my Revo AR1600. Did the idea get dropped? Would love to get the Makedds file and give it a shot.

Any help appreciated. Keep up the great work!

Thanks,
t

[jmarshall]

Please read the thread.

[paul]

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.

Ok I give in where can i Grab a copy of MakeDDS.exe and Convert.bat script,
as i could not find any attached zip file??

[IceNine]

Please read the thread.

Very well, from all of my digging around the net and the forums here is what I have learned:

- The DXT compression system for fanart and other large images was first suggested here about 4 months ago. There has been some controversy in this thread whether this was even necessary or desirable, as compression to DDS format compared to JPG could potentially result in lower quality images.

- DXT compression and DDS formats seem to already be supported on the Xbox version of XBMC and in all versions for skin textures.

- It seems that this type of compression support has been implemented at least a little bit, although I can't tell if it is only on the Windows-specific versions of XBMC.

- On your initial post, there was an attached file with a Windows-based DDS compression tool and batch script that is no longer there. The file can still be found(ish) here i believe here, in the svn trunk tools folder.

- Support for DDS images for fanart can be enabled through an advancedsettings.xml setting, at least as of October of last year. There isn't much more information in Trac since around that time.

- This kind of compression offers a potentially significant performance increase for people running XBMC on low cpu-power systems (such as myself with an ASRock 330 Pro). As these kind of systems seem to be gaining popularity for home theater systems, I would think this kind of development would be worthwhile.

- I can't tell if this kind of compression is easier to implement on Windows over Linux and I am not a developer myself so I am working on a very limited knowledge of how this would be built. It does seem that nVidia offers tools that allow for working with this kind of file on Windows and Linux for those people running CUDA-enabled nVidia GPUs (ie. ION systems).

- There has been one post from someone running an ASRock 330 that used this and reported a significant speed increase. Although there are no other details in the post, I am assuming Linux is being run on that system, so it gives me hope I will be able to figure out how to set it up on my own box, which is why I am pestering you guys so much for more information.

- It's been said that it will be a long time before this type of system is implemented: so be it. As I've said I am not a developer so my contribution to the project pretty much stops at feedback. By all means, take your time. I understand the developers don't get paid and I have loved the XBMC project since it ended up on my Xbox many years ago. I won't stop using it if this gets dropped altogether, or for any other reason. I just recently got my ION system to replace the Xbox (gotta keep up with h.264) and have been searching high and low to get it to run as smoothly as possible while still keeping the look that I like (ie. Aeon. I know it's a crusher on cpu and such, hence the optimization).

Any more information that you provide is always appreciated. This just sounds like something that would work for me personally, so I am selfishly pursuing it (although I suppose the info could be useful to my ION/Atom brothers).

[bleze]

Does source code exist which can convert a JPEG to DSS without the need for SDL? I'd like to implement something running on a Windows Home Server (Windows 2003 Server).

[arco]

^^ I'm the one who tested this on my ASRock 330. I have XBMC Live 9.11 installed. I'm using the nVidia texture tools to convert the images. Can be done it both Windows and Linux, but I do it in Windows for now and use sftp to transfer the images back and forth. It's a bit work as you need to find the new images (I go by date on that), and the .tbn files needs to be renamed to .jpg before converting. Then I just run a simple bat file that does the conversion, as the convert program is not able to convert multiple images at once. If I had the knowledge, I would have made a script in Linux to automate this process, as that would be the best. As for the loading speed, it's a whole different world compared to loading jpg images. You can browse through movies/tv-shows as fast as you can click next/previous on the remote, and the fanart image is on the screen instantly. It's sooo much smoother. Image quality looks perfectly fine to me, can't say I notice any difference.

[IceNine]

I'm glad you are reading this thread, arco! It is great to be able to get some info from someone who has done it firsthand. I'm assuming you are doing the DDS conversion just for fanart, not for other thumbnails? Does anyone know if it would work for movie/tv posters as well? Are there any other settings you changed on your system other than adding the <useddsfanart> setting to your advancedsettings.xml file? Also it sounds as if you are leaving the original .tbn files on the XBMC machine along with the new .dds files. Is this the case, and if so why not just delete the .tbn files and have only the .dds files on the XBMC machine?