.png .jpg .webp

[3D Novelist]

So, I'm thinking about image formats right now. Daz Studio only allows the creation of .png files. In general I though that's good because .png is loss free not like jpg and wbp as well I believe. But i tested a bit and converted some images into both jpg and webp. While the file size of png is around 3MB webp and jpg are around 400-500 KB. Now I'm thinking about converting all my images to reduce the total size, but on the other hand I don't want to reduce the quality of my renders.
I would like to hear some ideas, opinions or knowledge about this topic.

 

[AnimeKing314]

webp is generally what most devs use because it has usually the smallest filesize while still having an alpha channel for transparencies. It doesn't matter too much in early development but as your game grows and you get to having hundreds to thousands of renders it's important to try to keep the filesize down.

 

[anne O'nymous]

I would like to hear some ideas, opinions or knowledge about this topic.

The main problem with compression is that there isn't one single compression factor that you can apply to all the images.
Therefore, the best way to do this is by scripting the conversion (by using

You must be registered to see the links

by example) in order to not have 1 converted image by render, but many, all with a different compression factor. Then you browse the images, and for each render keep the converted image that give you the most acceptable compromise between size and quality. For some, it will be "almost no compression", for others a high compression factor. This will lead to a good size reduction when you'll report it to all the renders proceeded.

 

[79flavors]

Keep in mind though... those file sizes you are quoting are not really about the image format (.png/.jpg/.webp)... well, not completely... it's about the default compression values used by whatever tool you did the conversion with. Yes, you can end up with 500 KB .webp files - but with a lower compression (higher quality) setting, that same .webp could end up being 1.6 MB. Yes, .webp is generally smaller than .jpg and .jpg are generally smaller than .png - but it's those all importing settings that matter more than the image format.

For me...

Render everything in .png ... as big and high definition as your graphics card, skill, time and schedule allow.
Keep these files separate from your RenPy project.

Convert full screen background images to 1920x1080 (or 1280x720) .jpg files. Play around with the quality settings on whatever software you are using to convert them until you get a value you are "mostly" happy with. Then, any file that aren't happy with - just re-convert it again with a higher quality setting.

Convert any other images (sprites, characters, buttons, images that needs transparency, whatever) to .png files again - but perhaps resize to 1080p/720p if needed or adjust the quality settings down a little compared with the render files out of Daz3D.

Save the resulting converted images into the RenPy project /images/ folder (or subfolders).

Rinse and repeat until you are happy.

If you really must use .webp and .webm instead... sure. People rave about them - whereas I'm more of a "if it ain't broke - don't fix it" sort of programmer... well, these days anyway. Same deal... render to .png and convert to .webp using a quality setting that works "most" of the time, then reconvert specific images with a higher setting anything that looks blocky to you.

Generally speaking, there are two groups of players. Those who don't care if a game is 4.5gig... and those who do. Personally... I'd create a 4.5gig game and let someone else compress the images down further for an "unofficial compressed version" for those people with limited download capacities.

If you are a Daz3D prodigy... maybe even consider creating the finished game with 2560x1440 images (You can set it as a custom size when creating your RenPy project). If you really are are that good, people will appreciate the larger images. Realistically though... it's a porn game... 720p is just fine.

 

[InCompleteController]

I would highly recommend you look into separating your images into several layers and then recombining them in the actual game, if you wish to save space.

I've seen many devs that have a scene play out with a fixed camera, meaning the background could easily have been rendered by itself and then have each character pasted on top of it.
This can be taken a step further by subdividing characters as well, since there's no reason to create a full render of a person if you only have to change their facial expression.

I know why a lot of devs aren't doing this, since the trade for saving space is by making the rendering process and game programming more complex.

 

[3D Novelist]

Generally speaking, there are two groups of players. Those who don't care if a game is 4.5gig... and those who do. Personally... I'd create a 4.5gig game and let someone else compress the images down further for an "unofficial compressed version" for those people with limited download capacities.

Does compressed mean, the size of the image was reduced (e.g. 1080p -> 720p) or also the conversion from png to e.g. jpg?

 

[recreation]

Does compressed mean, the size of the image was reduced (e.g. 1080p -> 720p) or also the conversion from png to e.g. jpg?

Image-compression usually means data-compression, which has nothing to do with the resolution. Color information in images for example is data: what ever program or algorythm you use will search for very similar colors and replace them. A very simplified example would be if you have an image with black, white and two different greys, the algorythm would replace one of the greys with the other, or both with a grey that matches both of them so that you get one grey instead, this will result in a smaller amount of data that has to be stored in the image file.
Thats is just a very simple explanation though and there are other compression methods as well. I think wikipedia has some good information about that kinda stuff.

 

[InCompleteController]

Does compressed mean, the size of the image was reduced (e.g. 1080p -> 720p) or also the conversion from png to e.g. jpg?

Compression doesn't mean changing the resolution or file type, but relying on patterns to reduce file the size. Lossy compression means that you are sacrificing some details to make the data easier to save as a pattern.

Take colors for example, they are stored in values from 0-255, which is 256 unique values. A crude compression method would be to half every value, when saving the image, and then multiplying by two, when showing it. This means that you only have to save 128 unique values, but you loose some details in your image.

However, loosing some detail in your image isn't always an issue, since that detail can be because of noise which will get removed when compressed. Just remember to save the originals somewhere, since it will be impossible to restore the image in case you realize you are a bit too aggressive when compressing your images.

 

[79flavors]

Does compressed mean, the size of the image was reduced (e.g. 1080p -> 720p) or also the conversion from png to e.g. jpg?

The answer has already been covered, but perhaps let me try a 3rd way...

Instead of pictures, imagine movies.
Lots of movies are available for download from the internet. Let's keep it simple and say we're talking about a single 1080p movie.
One download could be 16 GB, another 8.75 GB, another 4.75 GB and yet another 1.2 GB.
They're all the same movie, same soundtrack - but the data rate is different. The "compression" is different.

The 16 GB version might have an average data rate of 25 MB/s. The 1.2 GB version might be nearer to 2 MB/s.
All that means is there is more data for each image that makes up each frame of the video.

Movies (and pictures) save space by instead of storing every single pixel, they store groups of pixels that are the same color (lossless) or by storing groups of pixels that are "more or less" the same color (lossy). The newer algorithms are really clever and aren't just doing simple things like "this pixel and the pixel next to it" or even "this pixel and the 8 pixels around it" - instead they are doing complex math to reduce sections of the image down to mathematical summaries.

Ever watch a really low quality movie where there is a solid color? Maybe it's a white wall or a black night sky?

In porn games, it's usually walls or clothing. But instead of seeing what the eye would normally see as a solid single color, you instead see obvious circles within circles - the lower the quality... the more obvious those circles of graduated color. The 16 GB version of the movie would have the same gradient of color - but can use more data (more intermediate shades of colors) to paint the picture... so you don't see the edges and you don't see boundaries between each layer of color.

That's the compression we're talking about.
Most graphics conversion programs will let you tweak the quality/compression - but most people use them without altering the default values.
So it's the trade off between file size and how much of that blocky graduated color patterns you want.

For example, here's data for a 1080p picture I chose to convert at random...

• .png 24 bit color - 1.9 MB
• .jpg Quality=85 - 623 KB
• .jpg Quality=60 - 359 KB
• .jpg Quality=30 - 137 KB

Same image... even the same file format in some cases... but the quality/compression means different file sizes, despite the image being the same dimensions each time.

I would usually start with .jpg Quality=60... then if I noticed any color pooling or other graphical glitches... I'd up things to either 85 or 95, depending on the problems the image is having.

I offer these two examples. Both 1080p. Both .jpg.



The first is 34 KB, the second is 13 KB.
Honestly, it was a quick and dirty example... and not really a good one, because I was using too few colors and the color boundaries are clearly visible even on the first image. But you should see what I'm talking about.

 

[anne O'nymous]

I know why a lot of devs aren't doing this, since the trade for saving space is by making the rendering process and game programming more complex.

More complex yes, but not necessarily "this more complex".

I still have so much to learn regarding Daz (and so few free time for it), but there's two things I know:
1) You can change all the materials of the scene, or just of a figure, in few seconds with a script.
2) With the most basic materials and a low rendering setting, a scene is rendered in few second even with an average computer.

What mean that, with two clicks and, lets say 1 minutes, you can also have a mask picture for each one of your renders. Then with a tool like

You must be registered to see the links

, you can batch process all your renders, using "scene001-mask" to generate "scene001-background" and "scene001-front" from "scene001". Only keep one file for all the common "scene001-background", and in your game just assemble them accordingly to the image you're supposed to display at this time.

If you use only primary colors, like green for the background and blue for the foreground, you can use a high tolerance factor without mixing the two parts, what would easily compensate the low quality of the render. It would need more times if you want to keep the shadows and reflections implied by the foreground, since you'll need to have a plain color only for the background, and have a high quality render, but theoretically there's no reason for this to not works.

It will lead to a lower quality than if you kept all the renders as originally made by Daz. But this quality should still be higher than the one you would get by compressing the image, this for a final size that should probably be smaller than what you can get with a compression.

 

[InCompleteController]

More complex yes, but not necessarily "this more complex".

Yeah, I probably made it sound way too dramatic.
What I wanted to get at is that space is cheap, so adding extra steps to be more efficient isn't something I would expect from hobby developers.

 

[anne O'nymous]

What I wanted to get at is that space is cheap, so adding extra steps to be more efficient isn't something I would expect from hobby developers.

This I totally agree. AAA studios don't care about space optimization, it's not some guy, or girl, doing this on his free time and with near to no knowledge, that will start thinking about this. At least not thinking more than the usual "best way to compress my images".

 

[hardwire666]

I admit to being lazy and not reading the rest of the thread so I'm probably going to repeat what someone said above but I'm gonna say it any way. Lol

So far as I understand it WebP is essentially a PNG with compression. So think kind of like a JPG with an alpha channel. I was just looking it up the other day as to why it hasn't seen wider adoption, and really I found no damn good reason. In reality though, when you think about it image compression was born out of necessity. If high speed internet and gigs of RAM were not a thing, and software wasn't bound to the limitations of physical media in the early to mid 90's BMP would still be the common format. In the end there are only niche areas that are looking to cut image file size down. So with it not being a priority it falls on the wayside. Even though it is awesome.

Basically... people just don't give a shit. lol

 

[3D Novelist]

Thank you all so much for the insights. You helped me a lot

 

[jamaag21]

PNGs are fantastic for maintaining a crisp, lossless quality, but they can be hefty in terms of file size. So, it's great that you're exploring alternatives like JPEG and WebP.

As for maintaining quality—this is where compression comes into play. There are tools that allow you to

You must be registered to see the links

files without sacrificing too much quality. It's all about finding that sweet spot where you get the best of both worlds: smaller file sizes without a noticeable drop in image quality.

 

[osanaiko]

!!!***###NECROMANCY ALERT!###***!!!

USER jamaag21 HAS BEEN FOUND GUILTY OF RESURRECTING A DEAD THREAD FOR NO GOOD PURPOSE.

SUMMARY JUDGMENT HAS BEEN AUTHORIZED.

 

[<Code/>]

Compression is very important, especially since your players have to download and run your game.

The size will impact whether they are willing to download it, since it will take up space on their storage, and it will also take time for the download to complete.

It also limits the number of hosters that you can use, since they have certain storage limitations. That's also why you start seeing games with multiple parts, since the devs haven't compressed their assets well, and that further increases the friction that people will download the parts to play your game.

I also believe that android has an APK size limit, (Around 2-4GB), but I believe that RenpyTom has added a streaming solution in the latest renpy update.

Luckily compression is pretty easy. I recommend suing 90% webp for images.

I have heard stuff like: *Compression makes the images look a lot worse*

I disagree, and I think you will too if you drag one of your images into

You must be registered to see the links

, which lets you compare your image before and after the compression. I recommend zooming the image out to be the size it should be to the viewers, and then seeing if you actually think the players will notice a difference, in the seconds they spend glimpsing at the image.

For easy compression of the images, I think someone already mentioned

You must be registered to see the links

, which is a good utility to easily batch compress your images.

It has been a while since I've used renpy, but I believe they also added avif support, which should make even smaller files for the same quality, but I'm not sure how good the hardware encoders are, so they might take longer to compress.

Here's a good video on how compression works by the chrome dev team, who made Squoosh:

You must be registered to see the links

 

[MissFortune]

Luckily compression is pretty easy. I recommend suing 90% webp for images.

I have heard stuff like: *Compression makes the images look a lot worse*

I disagree, and I think you will too if you drag one of your images into

You must be registered to see the links

, which lets you compare your image before and after the compression. I recommend zooming the image out to be the size it should be to the viewers, and then seeing if you actually think the players will notice a difference, in the seconds they spend glimpsing at the image.

I've said it before, but anything below 95% results in visible artifacting:



So, with a simple eye test, yeah. It does look a lot worse. Visible banding/artifacting in a visual work people are often paying for isn't a good look. Lossless WebP at 1080p is oft. under a 1MB, and bridges the gap between file size and quality.

As for the whole Android 2-4GB limit? It's largely not worth the effort after a certain point. Android is far and away the most pirated platform (there's a reason they're playing on a phone and not a PC/laptop), and largely the least downloaded by Patreons/supporters (it's not exactly close, either.). It's fine if you can easily make an Android version, but there's no point in jumping through hoops for something that'll ultimately be pirated.

 

[osanaiko]

As for the whole Android 2-4GB limit? It's largely not worth the effort after a certain point. Android is far and away the most pirated platform (there's a reason they're playing on a phone and not a PC/laptop), and largely the least downloaded by Patreons/supporters (it's not exactly close, either.). It's fine if you can easily make an Android version, but there's no point in jumping through hoops for something that'll ultimately be pirated.

Cue the millions of penniless phone users pouting at their tiny device screens and then recording tiktoks to shout their anger into the walled garden mobile world in reaction to this statement because they can barely read, and certainly can't write full sentences to respond and rebut.

 

[<Code/>]

I've said it before, but anything below 95% results in visible artifacting:

View attachment 3386669

So, with a simple eye test, yeah. It does look a lot worse. Visible banding/artifacting in a visual work people are often paying for isn't a good look. Lossless WebP at 1080p is oft. under a 1MB, and bridges the gap between file size and quality.

As for the whole Android 2-4GB limit? It's largely not worth the effort after a certain point. Android is far and away the most pirated platform (there's a reason they're playing on a phone and not a PC/laptop), and largely the least downloaded by Patreons/supporters (it's not exactly close, either.). It's fine if you can easily make an Android version, but there's no point in jumping through hoops for something that'll ultimately be pirated.

99% of your users are not going to notice the difference, since they are not zoomed into the image. I only noticed by zooming into the areas you pointed out.