• 1
  • 2(current)
  • 3
  • 4
  • 5
  • 26
Compressed textures for FanArt - testing here with XBMC 2009-10-05 (r23431) or newer
#16
obviously we won't be requiring a cron job if this goes golden! but currently, it does not convert them.
Reply
#17
OK...

Tested, and it works :-)

Findings:

1) Could see no obvious compression artefacts at 720p or 1080p (for photo style art)
2) Could see some very minor artefacts with some geographic art around, but cannot detect once nose no longer touches the screen
3) Could see no performance improvement (or degradation) using GMA945 and GMA950 in DX or GL modes.
4) Could see dramatic increase in image cache size (as mentioned in earlier posts)


Additional issues:
-The DDS converter (tbn to dds) is slow. It took 3 hours to convert my fanarts.
-The DDS converter has SxS issues on some PC's (definitely didn't like a virginal Vista SP2 pc)
-I wonder if it would be useful to have 'tbn' as a fallback (if the dds doesn't exist), or might this complicate testing with folks THINKING they're using DDS and aren't?
-Is it fanart only for a reason?... just because those are the largest images, or because it's a quick and dirty test?
-Regarding the NPOT issue... if the image is somehow 'adjusted' (read distorted) to 2048x2048, are we then asking the GPU to downscale it and distort it back to 1920x1080?...mute issue I suppose, since I couldn't visually tell. Would be curious to see if 1024x1024 upscaled to 1920 would be noticeable!
-Do we NEED the advanced settings?.. why not just see if the DDS exists, if so, use it... or is that check considered too much of a speed penalty?
-Where a DDS file doesn't exist for a movie, the home page fanart is momentarily seen (then overlayed via white rectangle). Not sure if this is a skin issue, but curious as to why there are two image draws (homescreen fanart, then movie/tvshow fanart).
Reply
#18
this is a test. if it works and there's no artifacts we will change. please ignore the advancedsetting and pretend its not there if it bugs you guys so much. 'la la la' and all that.
Reply
#19
Update:

About 2% of the fanart has issues....

On the DX build, the fanart is considerably oversized (definitely width ways, and I think height too)
On the GL build, the very same fanarts are corrupted (and not recognisable).. a little like interlaced, then garbled!)

Will try to ascertain if this the DDS converter or XBMC, BUT, my logic says it must be XBMC since there's a difference in behaviour between the builds

oh and that 3 hours is gonna p**s folks of when doing a library scan!

Build is: 23436 for DX and GL
Reply
#20
I've tested it so.

No visible speed improvement or noticeable cpu difference on a C2D 3ghz.

But a HUGE difference of size. My Thumbnails folder was around 700 mo.
Now it's a 5 Go directory.
Reply
#21
hotlobster Wrote:I've tested it so.

No visible speed improvement or noticeable cpu difference on a C2D 3ghz.

But a HUGE difference of size. My Thumbnails folder was around 700 mo.
Now it's a 5 Go directory.

"700 mo" / "5 Go", very strange units you are using Smile
Reply
#22
hotlobster Wrote:I've tested it so.

No visible speed improvement or noticeable cpu difference on a C2D 3ghz.

But a HUGE difference of size. My Thumbnails folder was around 700 mo.
Now it's a 5 Go directory.

I'd expect the slower PC's would be the ones hopeful of any speed gain (if there is any to be had), plus, I don't know if the devs are actually loading the GPU with more textures yet. Perhaps they are just passing the new format textures but not utilising the gain memory yet.
Reply
#23
davilla Wrote:"700 mo" / "5 Go", very strange units you are using Smile

We all work in Mo's !!!

a small Mo is a moment in time.... a gigaMo is 'quite a while'. Thus is increase in filesize is resulting in a more Mo !
Reply
#24
Quote:a small Mo is a moment in time.... a gigaMo is 'quite a while'

lol. Good one.

Meant MB, Mo are french Mega Bytes.
Reply
#25
Build 23458 (GL and DX).

Same DDS texture issue with a rare few images. And (could be a placebo) a good speed increase in rapid coverflow scrolling. Could be a skin improvement though, since I've updated skin too.

Confirmed texture corruption with two artefacts:

a) All (bar one) of the texture corruptions behave the same way: In the GL build it's a corrupted and 2x Width image. In the DX builds it's not corrupted but 2xWidth

b) One image has some colour channel and alpha profile. It appears slightly colourised and has transparency in parts!!!! and what is TOTALLY mindblowing... is that the transparency is showing the homepage fanart STILL doing a Ken Burns effect LOL. It's very groovey, but a total waste of CPU to be doing Ken Burns on an image that cannot be seen! (this is the same in GL and DX)
Reply
#26
Thanks, I appreciate the comments (particularly the "I can see the difference, but I don't care" stuff). Some comments:

1. JUST compress your fanart directories. No way in hell it should take 3 hours - it takes about 4-5 seconds per image here, so unless you have several thousand fanart images...

2. Obviously if you convert your entire thumbnails folder (thumbs as well as fanart) size is going to increase quite a bit - some thumbs are tiny in JPG format compared to the resulting DXT. Also, note that many of the files sitting in your thumbs folder currently are not even being used by XBMC (we never clean it out). 5GB indicates 2,500 1080p images - do you really have that many?

3. It's not optimized for size on disk, but size in memory. Size on disk is a secondary consideration, and obviously something like lzo compression can assist here.

4. Anything with an alpha channel (i.e. a png) will look strange - I haven't bothered to support or detect that as yet (clearly that needs at least DXT5).

5. Any images that show corrupt I need to know full details of your GPU, plus info on how big the image is. If it corrupts in GL and DX then that indicates a broken image I suspect. I presume you tried to load the corrupt images in a DXT viewer? If it's corrupt in a DXT viewer then I'm doing something poo on the compression. If it's only corrupt within XBMC, then I'm doing something poo on setting up the texture.

6. You're not likely to see performance benefits per-se from this change, as images still only lie in memory for 2 seconds once unused. Once we bump that up, however, things change somewhat - it will reduce swapping from GPU to system memory. Obviously there's nothing we can do about scrolling through thousands of 2MB images, however!

Oh, and as spiff says: This is a test. That is all. Obviously the caching stuff will be done automatically in the future!

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
#27
jmarshall Wrote:Thanks, I appreciate the comments (particularly the "I can see the difference, but I don't care" stuff). Some comments:

1. JUST compress your fanart directories. No way in hell it should take 3 hours - it takes about 4-5 seconds per image here, so unless you have several thousand fanart images...

about 1500 fanart only images all with a min 1080 some are higher, but rarely by much. Processing time between 8-20 seconds each

Quote:2. Obviously if you convert your entire thumbnails folder (thumbs as well as fanart) size is going to increase quite a bit - some thumbs are tiny in JPG format compared to the resulting DXT. Also, note that many of the files sitting in your thumbs folder currently are not even being used by XBMC (we never clean it out). 5GB indicates 2,500 1080p images - do you really have that many?

Some of us are nerds. We are scarey.

Quote:3. It's not optimized for size on disk, but size in memory. Size on disk is a secondary consideration, and obviously something like lzo compression can assist here.

Totally understood, but 8x increase in file size is a fair hit on read performance esp if running from USB or slow drive.
I did a quick compression test on the DDS and averaged about 50% (rar max compression)

Quote:4. Anything with an alpha channel (i.e. a png) will look strange - I haven't bothered to support or detect that as yet (clearly that needs at least DXT5).

No worries, I think these will be small niggles that get ironed out. The basic thing is working!


Quote:5. Any images that show corrupt I need to know full details of your GPU, plus info on how big the image is. If it corrupts in GL and DX then that indicates a broken image I suspect. I presume you tried to load the corrupt images in a DXT viewer? If it's corrupt in a DXT viewer then I'm doing something poo on the compression. If it's only corrupt within XBMC, then I'm doing something poo on setting up the texture.

Cards are both integrated GMA's 845GM and 850 / Core2 1.8s. Definitely not high end, but arguably typical of Bookshelf size HTPC's.... I've got access to NVidia's but reluctant to start screwing with other machines that have a different purpose at home!

Couldn't load in my viewer due to NPOT. I have since located a DDS plugin for Photoshop... the image is fine... so the error lies in the decode, the driver, or the card. Likely to be decode or driver I expect.... image dimensions are 2183x1281

Quote:6. You're not likely to see performance benefits per-se from this change, as images still only lie in memory for 2 seconds once unused. Once we bump that up, however, things change somewhat - it will reduce swapping from GPU to system memory. Obviously there's nothing we can do about scrolling through thousands of 2MB images, however!

Again, understood... but... you could create super textures! and combine possibly 4 at a time (if the GPU can handle large textures)... probably not worth the hassle, I'm happy with the performance on a low end HTPC.

Quote:Oh, and as spiff says: This is a test. That is all. Obviously the caching stuff will be done automatically in the future!

Need to get a handle on the encoding time for these images. Let's hope I'm not 'typical' with high volume art and slow encoding time. Can you not use the GPU to encode?




Cheers,
Jonathan[/quote]
Reply
#28
Good quality encoding takes time. Realtime compression sucks, big time. Completely unacceptable quality from my tests.

Obviously any encoding will be backgrounded - you won't notice it, and it's likely just a blip compared to the download time of information + images.

I suspect your problem is real simple: Your GPU probably has a max texture size of 2048, and you're loading images larger than that. Thus the double width and other strange problems.

Will check the code and do up a diff for you - you can build, right?

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
#29
jmarshall Wrote:Good quality encoding takes time. Realtime compression sucks, big time. Completely unacceptable quality from my tests.

Obviously any encoding will be backgrounded - you won't notice it, and it's likely just a blip compared to the download time of information + images.

I suspect your problem is real simple: Your GPU probably has a max texture size of 2048, and you're loading images larger than that. Thus the double width and other strange problems.

Will check the code and do up a diff for you - you can build, right?

Cheers,
Jonathan

Nope.
My coding days are over. I only do 'architecture' now and even that's under duress cos I've forgotten how to spell C let alone code in it, and I believe Object Orientation is when you protest against cross country running ;-)
So, if the max texture is 2048 (which seems to be accurate having just done some googling) what's the proposal...
- Reduce the image size during XBMC's encoding phase? (my favourite)
- Expect end user to keep images within scope? (pffft)
- Multiple textures? (sounds like madness)
- Use existing technique for troublesome images (might not be possible to mix and match easily)
- Go for a lie down in a silent darkened room with a cool damp towel?
Reply
#30
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
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
  • 1
  • 2(current)
  • 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