I have a PNG file that’s 1.24 MB. When I build it through the content pipeline with default importer and processor settings, it builds an XNB file that is 103 MB. Same with another PNG that’s 1.59 KB (literally a 100x100 circle), when I build that one it becomes 40 KB. I tried creating a new project and building them with a fresh Content Pipeline, but no luck. I have never had this problem before so if anyone has any idea what I’m doing wrong, I’d appreciate your advice.
Eh, what is in the image, and screenshot your setting choices, is alpha included?
Settings:
Image: https://drive.google.com/file/d/1YL9Y1YVZ_CpHgCn8zhquZv3kZ55rKlR6/view?usp=sharing
If by is alpha included you mean does the image have transparent pixels, then yes.
Under TextureFormat there are a number of options that tell the content pipeline to compress your texture this depending on what you pick takes longer to build your project and there is some overhead for decompression on load but it will save space. If you don’t have a lot of hard drive space when debugging.
Typically this is reserved for just before when you release your game (so it doesn’t slow down compiles).
2 Likes
Thanks. Though I’m still wondering why a 1 MB becomes a 100 MB file, regardless of whether or not it’s compressed, that’s gonna be a pretty big issue. It doesn’t even let me load the texture, it gives me an error in my code.
I tried every compression format, the only one that works is Color16, which cuts the xnb file size in half, but it’s still way too big.
Pixels right?
Can you share the image somehow? I suspect there is something with the image…
The circle is yes, 100 pixels in width and height
It’s all white but I uploaded it on the next line
It’s 477 bytes.
The xnb is 40 kilobytes.
This is the same with the other texture I posted yesterday, except that was a way larger file before I built it.
I’m aware that compressing it can make the image smaller, but I feel like with this much of a size change, I must be doing something wrong.
If I take your circle into a image editor and save it back to disk in a uncompressed format like .bmp with 32 bit depth it becomes 40 kilobytes. Your original image has a bit depth of 8
1 Like
Sorry I don’t totally understand what the means. Could you please explain?
In the simplest explanation possible; MonoGame handles the conversion correctly and there’s nothing suspicious about the size.
Bit depth decides how many colors a pixel can hold. If all of your images has a bit depth of 8, and are also compressed it’s probably why they are so much smaller. If the bit depth is lower, they also are simpler (less colors, less complexity), so I imagine they’d also be easier to compress to a smaller size.
Just to verify with simple maths that the size checks out we can check the wiki for bitmaps for how much space a single row of data holds https://en.wikipedia.org/wiki/BMP_file_format#Pixel_storage, we plot that into wolfram alpha, multiplying with the number of rows, and we see that the expected file size is indeed 40 kb. click
1 Like
So the xnb is just raw information about the image?
It really depends, the default MGCB processors will take whatever asset you feed into them and process them into something that the target platform can use with minimum performance cost. I think for most platforms you can assume that any image you input in the content builder it will output a raw image, because that’s what’s most convenient for a GPU. Although there might be small variations depending on whether your target platform is Windows, DesktopGL, Android or whatever.
Ok that makes sense. So with my 1 mb image, would would you suggest doing to lower the xnb size, which is currently 106 mb?
I tried converting to 8 bit color depth, which decreased the size of the png file, but the xnb file was still 106 mb. I also tried converting it to a bitmap, which made the png much larger, but the xnb was still106 mb.
This might be a stupid question:
I’m on a laptop, should I consider building the textures with the integrated gpu?
The .xnb is always the raw image, it doesn’t matter how you compress it, it will always decompress and output the raw image. Unless you used a compression format that loses data like .jpg, but you probably shouldn’t do that.
1 mb for a png is actually quite large, a full HD wallpaper image take less space than your file. What exactly is this image in the first place?
I’m on a laptop, should I consider building the textures with the integrated gpu?
AFAIK that’s not even something you can do.
https://drive.google.com/file/d/1YL9Y1YVZ_CpHgCn8zhquZv3kZ55rKlR6/view
It’s just a spritesheet. I made it in photoshop which I believe is the reason it’s using so many colors.
Well, when I open the image up and export it to .bmp with a image editing software like Paint .NET or GIMP it becomes 103 mb, so this has nothing to do with MonoGame, the problem is the image itself.
And I think I see why, I notice that your image is a whopping 40 176 pixels high. If space is such a concern for you really need to look into lowering the dimensions of your sprite sheets. Just as a quick raw test you can try and scale the image down in photoshop and see the image disk size shrink a lot. For instance, I scaled the image down so that it had maximum 5000 rows height and it became 1.6 mb uncompressed.
Image disk space has a n^2 scale, which you can see in the chart here, that they will scale aggressively, so not using more pixels than you have to is key to avoid unnecessary disk usage.
Setting the compress flag is not always recommended, and I don’t think it’s necessary in this case anyway. https://docs.monogame.net/articles/tools/mgcb.html#content-compression