Sign in to follow this  
SweetToothKane

Combine two JPGs on load time to create one texture?

Recommended Posts

I'm curious if there is a way to merge two JPGs when they are loaded into one LPDIRECT3DTEXTURE9. The specific case would be a diffuse and alpha texture. Two JPGs would be much smaller in file size than a DDS with an alpha channel and the extra load time (I assume there would be for two textures and combining as opposed to just one texture) would be well worth it in this instance.

Share this post


Link to post
Share on other sites
Quote:
Original post by SweetToothKane
I'm curious if there is a way to merge two JPGs when they are loaded into one LPDIRECT3DTEXTURE9. The specific case would be a diffuse and alpha texture.

I guess you're asking this because you're using the D3DX framework facilities. If you have jpglib running, simply processing the returned data would be enough.
Quote:
Original post by SweetToothKane
Two JPGs would be much smaller in file size than a DDS with an alpha channel and the extra load time (I assume there would be for two textures and combining as opposed to just one texture) would be well worth it in this instance.

When it comes to disk, you're speaking about tens of gigabytes of availability. By saving a few bytes (or even megabytes) you save virtally nothing.
Also, when it comes to disk, don't really think you can save much perf, especially when requiring to open multiple files. Opening a file on NTFS volumes can take a lot of time. Furthermore, no matter how you optimize it, the disk isn't a performance path anyway.

Share this post


Link to post
Share on other sites
Quote:
Original post by Krohm
When it comes to disk, you're speaking about tens of gigabytes of availability. By saving a few bytes (or even megabytes) you save virtally nothing.
Also, when it comes to disk, don't really think you can save much perf, especially when requiring to open multiple files. Opening a file on NTFS volumes can take a lot of time. Furthermore, no matter how you optimize it, the disk isn't a performance path anyway.

IMO that's the kind of thinking that leads to 20GB games and loading times of a minute or two per level.

Although I agree with the actual answer. For now, I'd suggest not giving this too much attention. You might, for example, decide later that using DXT compressed textures is the best way, and you won't want to create that at runtime. So for now don't try to optimise too much, but build your loading system so that it's easy to change it later.

Share this post


Link to post
Share on other sites
First of all, I don`t understand how can you use alpha texture compressed into JPG. From my experiments, even 100% jpg quality doesn`t give you errorless alpha texture, but your mileage may vary.

Then, there is fundamental difference between the space saved : With DXT, you save also the precious VRAM, and don`t say that there`s lots of it. There`s always a shortage of VRAM, even if you 512 MB of it, since on such cards, with clever usage of it, you could create stunning rich worlds.
Plus, you get a performance benefit, since the texture occupies just 12.5% (or ~17%) of original size, thus if driver needs to move it around, it`s faster and it should be faster to sample texels from it also (I believe that`s due to some specific chip tailored for compressed textures, but I could be wrong here).

I would suggest exploring JPG2000, since that can give you easily 20%-50% file-size of the original JPG (for the price of longer loading/initialization times) or maybe even more (i remember I got my files into 10% of JPG size, and they were still usable).

Still, how many of those textures do you have that you need to save so much space ? It seems you should fill up your VRAM faster, especially if you don`t use DXT compression.

Share this post


Link to post
Share on other sites
Quote:
Original post by ET3D
IMO that's the kind of thinking that leads to 20GB games and loading times of a minute or two per level.

In my opinion instead it's using 1024^2 textures... they begin to make sense only now.
Quote:
Original post by VladR
Then, there is fundamental difference between the space saved : With DXT, you save also the precious VRAM...

Maybe it would be a good idea to speak about "file format" and "surface format". DXT compression or decompression isn't nearly as slow as JPG or PNG.
Quote:
Original post by VladR
I would suggest exploring JPG2000, since that can give you easily 20%-50% file-size of the original JPG (for the price of longer loading/initialization times) or maybe even more (i remember I got my files into 10% of JPG size, and they were still usable).

Wow! Could you point the library?

Share this post


Link to post
Share on other sites
Quote:
Original post by Krohm
Wow! Could you point the library?
Unfortunately not. I googled it last time when I played with it and I don`t even remember the name of it right now.
Just google for JPEG2000 and you`re set.
There`s a license fee for the commercial usage of the package (that I used), but it was about $50 or $100, so that`s acceptable considering the gains. The free utility (as far as I remember) was very slow at decompressing. But during last 3-6 months, it`s also possible that someone came with some new implementation (I think I saw some news about JPG2000 in terms of fast and affordable plug-in/code lately).

Share this post


Link to post
Share on other sites
Normally, everybody that responded would be right about the size on disk not mattering so much that we would need to save some minor space with textures. However, when you are shooting for a very small size on disk and the DDS (DXT compressed) files are taking up too much space, it is a great idea to think that you could combine two small JPGs that would still be smaller than the DDS. It doesn't seem like there is a simple way to do this though and I would be better off working with existing compressed formats, despite the fact that alphas bloat DDS textures.

Share this post


Link to post
Share on other sites
Sorry i'm only a novice to DirectX programming but is it not possible to do the following at load time..:

- Load in two JPEGs as two seperate textures
- Use a pixel shader to modulate the two images and render to an off-screen surface the exact size of the images
- Render the off-screen surface into a single texture

Like I said i'm a novice at this so i haven't tried doing anything like this myself.. I just thought it maybe possible..?

Share this post


Link to post
Share on other sites
I asked this exact same question about two years ago (look thru my history to find it.) Don't listen to people here -- it IS a good idea and it DOES work and saves you a tremendous amount of space! A high quality JPG is almost lossless, and looks WAY WAY WAY better than DXT* compression. You can save tremendous space by using a 2nd grayscale JPG to load alpha data at run time. Just lock both surfaces and copy an RGB byte from the alpha texture to the Alpha byte of the RGB texture.

Note that my game was for download-only and I was able to save several MB using this technique. If space is no object, then obviously PNG/TGA is superior but this is a good compromise. People here that constantly comment on the quality of JPG don't know what they're talking about, or they are talking to a very low quality JPG. Try using at least quality 8-9 (or more) in Photoshop for good results.

Share this post


Link to post
Share on other sites
Awesome, thanks for the good response. I am going to look through your history and find that topic. Also, I will try implementing that method when I get the time (currently stuck in the middle of a gameplay task).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this