Why the .uasset textures are so big compared to the origianl .jpg textures?

There are 13 jpg files with total size 3.53 MB, and the total size of their .uasset textures is 23.4 MB, that’s so big, almost 7 times bigger than the JPGs, there is no compression. I double clicked on the asset then turn on “Compress Without Alpha” but it doesn’t work.

The total size of my unreal engine project is about 500 MB and most of the big files are textures, then just imagine if unreal engine has a good compression then the total size of my project will be approximately (500 MB / 7 x 2 = 142 MB), I multiplied by 2 because JPGs are accompanied with .uasset, but that compression doesn’t exist in unreal engine, it’s a feature proposal.

size of the source file doesnt determine size in packaged build.
Easy as that.

and jpg is the worst format to choose from


Game engines have to compress textures to a specific format, it doesn’t matter what the original source was it all gets converted to the same compression formats depending on what the texture is being used for. So a 1024 x 1024 texture is the same size whether the original source was a JPG or an uncompressed TGA

Quite possibly also needs to store mipmap data.

Make sure it’s a power of 2 in resolution (like 512x512 or 1024x2048, etc). Don’t use jpgs for textures, you don’t want a texture going through compression twice. PNGs or TGA are the most common working format for artists.

Thank you all for the replies, I think I’m going to use PNGs because they support Alpha.

My problem is the total size of my project becomes so big because I don’t use JPGs anymore. JPGs are not that bad, most of google images are JPGs and they are good. The only big problem with JPG is it doesn’t support alpha and a true artist uses alpha.

I care about project size because I always make many copy backups of my project if something goes wrong like not undo-able things, if the project is so big then the copies take many times. And BACKUPS are IMPORTANT for me. Suppose that my project is so big as 5 GB then the copy as backup will take forever because there are many of them.

Making a .zip, .7z or .rar archive of a 5GB project folder/directory usually takes no more than a few minutes at maximum compression settings on modern PCs.

@DarkS474 , thanks, I usually use .zip to compress the backups to avoid the accidentally open of a backup folder which is very dangerous, but for a big files such as unreal project, I don’t compress because it’s too big. My problem is I make backups at least 3 times per day, therefore I cannot wait to zip all the time.

A .png cannot be compressed with .zip, because it’s size is the minimal that cannot be compressed.

If your projects are just in the 5GB range then a cheap USB 3.0 2TB or 4TB 2.5" HDU would be more than enough to store many days of backups.

Many times using compressors like zip, 7-Zip, rar is useful even with no compression or using fastest compression settings.
You can automate compression to an archive in many ways thru various kind of scripts. A simple example with 7-Zip might be: Automate Zipping Tasks using the CLI and Batch Files

Archiving a whole folder/directory with all its folders and files recursively is the best way to do it. UE4 projects being self-contained into the their own project folder are easy to backup that way.

Thanks, the idea of automate compression is very interesting, I’m a backup-er person. Sometimes there is something goes wrong then I have to check my backup to see things when everything worked without problem.

I didn’t tell the truth that I use Microsoft OneDrive to backup my files, and it’s very interesting, I just copy the files in File Explorer then wait for uploading. I use it because in case my laptop crashes on the ground then I lost my files, and I always backup easily my files on OneDrive, more easy than finding my External Hard Drives all the time. But the limitation is OneDrive is very slow when uploading, if the files are about 200 MB then there is no problem, but if it exceeds 5 GB then problems happen.

You might want to look into source control and version history in order to speed up your workflow when creating new versions or backups of your files.

Source control would do that for you, and also provide tools for comparing changes in case something breaks. Github/gitlab are pretty good.

The texture assets store all source mips in uncompressed format. It makes the uasset files really unnecessarily huge in the project.

Thanks to this forum, I decided to always use PNGs and I like it because of the alpha channel. And I discovered that the textures are converted into something like PNGs as .uasset instead of uncompressed format, because the size of the PNGs and the .uasset are almost the same.

Edit: To prove this theory, see my next post.

TGA is better tho

@Raildex_ , but I care about project file size, PNG is already 5 times bigger than JPGs in average, then it should be more than that for TGA. But I don’t understand why the project “Open World Demo Collection” uses TGA.

In my old / new project:

  • There are (5 rgb + 3 alpha) group of JPG textures, the total size is 2.19 MB, and the linked .uasset files total size is 11.4 MB.
  • There are (5 rgba) group of PNG textures same as above, the total size 11.1 MB, and the linked .uasset files total size is 14.6 MB.
  • Then it should be bigger for TGA.

See I still can know the size of the JPGs even if don’t use it anymore, that’s because I use backups, I really like backups for many perspectives.

Quote from google: tga vs png

Some applications do weird things with transparency/alpha channels with the PNG file format, such as deleting RGB data where the alpha channel says it’s completely transparent. That’s awful when you are using the alpha channel for something besides transparency. I don’t particularly like how Photoshop handles PNG. Also there’s some weirdness around how 16 bit PNG images are handled as well.

I’d simply prefer not to work with PNG due to those inconsistencies causing more headaches than the disk space saving is worth. Most artists I know stick pretty much exclusively to TGA as their main working format. I don’t mind PNG for alphaless textures though.

There also seems to be part of artist communities that view JPG as unprofessional for anything but photographs and websites. That lossy compression is never acceptable.

@ZacD, Maybe old Photoshop deletes information where area is 100% transparent? But it’s not the case for me, I use Photoshop CC 2018.
Can anyone explain how did you do to occur the famous problem on destroyed area where transparency is 100% with PNG? I cannot believe because it doesn’t happen to me, are you using Photoshop CC 2018?

Let me prove that the problem doesn’t happen to me on this “Untitled-1.png”, there is no deleted information on the area where alpha is 0, I use Photoshop CC 2018 and Maya’s FCheck to check the image, … I prefer using Blender for professional modeling because I love it 5 times than Maya.

Edit: The famous problem happens when I use the Eraser Tool in Photoshop, but I never use that tool, I always use Layer Mask since the beginning even if I didn’t knew the problem yet. That’s how the problem never happen to me. I can even apply the Layer Mask, then no problem happen. … So my suggestion is never never use the Eraser Tool. Anyway, who will use Eraser Tool when the Alpha Channel is the roughness or thickness or something like that because it’s not a transparent.

Does anyone else has another idea on why you prefer TGA instead of PNG? Because the problem never happen to me. Please explain because the problem is so famous, all the artists use TGA. https://forums.unrealengine.com/deve…g-for-textures

I spent my time on saving all the textures into PNGs, and TGAs are sooo biiiiig, I don’t use it yet, people say that an example on a texture that TGA is 8 MB, PNG is 2.5 MB. … For that example, TGA is 3 times bigger than PNG or 15 times bigger than JPG.

Personally I stick to using TGA for anything with Alpha Channels, and PNG for anything without.

Some programs are terrible at the way they store PNG since they are all optimized to create the smallest file size. It’s often destructive and I’d rather lose a few extra MB’s of hard drive space than irreplaceable work. Hard drives are cheap nowadays :wink:

It needs to be said, but JPG is a horrendous format by the way.